[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] [BUG] assertion failure when compiling initialization

From: Michael Matz
Subject: Re: [Tinycc-devel] [BUG] assertion failure when compiling initialization of array of structs on x86_64
Date: Wed, 25 May 2016 22:51:00 +0200 (CEST)
User-agent: Alpine 2.20 (LSU 67 2015-01-07)


On Wed, 25 May 2016, grischka wrote:

Could it be that a compiler not necessarily needs to support this?

I don't see any leeway in the initializers rules of the standard. Compilers have to support this: it's a braced initializer list for a single element array, the initializer list (correctly) contains one element, that initializer itself is type compatible (in fact the same type) with the type of the initialized subobject (the struct).


Hmm, I don't think this is complete. It may avoid the assert but probably generates wrong code (try e.g. with the struct containing multiple elements). For instance it doesn't assert on i386-tcc, but generates a too short memmove when the struct is larger (for the example it works by accident).

I've traced this until I found that the dbt in gen_assign_cast is actually int or llong, which is clearly bogus, the destination type is a struct itself but code higher up the chain already looks into the structs first member and tries to initialize that (though the initializer on the right hand side doesn't init the individual members but the struct).

So, for this code:

struct S { int i;}
void f(struct S *s) { struct S y[1] = { *x }; }
void g(struct S *s) { struct S y[1] = { { x->i } }; }

TCC needs to differ between both cases and when parsing the LHS needs to dive into the type struct S for function g() but not for function f(), i.e. it needs to do that based on the form of the RHS.

At that point I got distracted then :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]