This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

aggregate_value_p in the gimplifier


Hi,

I'm investigating the following failures on SPARC 64-bit:

FAIL: gcc.c-torture/execute/920501-5.c compilation,  -O0 
FAIL: gcc.c-torture/execute/920501-5.c compilation,  -O1 
FAIL: gcc.c-torture/execute/920501-5.c compilation,  -O2 
FAIL: gcc.c-torture/execute/920501-5.c compilation,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/920501-5.c compilation,  -O3 -g 

The ICE is due to a problem in the SPARC back-end so I'll eventually fix it 
(and the fix is required for Ada anyway) but the problem has been there 
since 3.3.x and the test previously didn't fail.

What has changed is that the gimplifier (namely gimplify_modify_expr) invokes 
aggregate_value_p on types that the back-end didn't use to see for the C 
language.  In our present case, the array_type of the rhs in

  void *j[] = {&&x, &&y, &&z};

is sent to the back-end via aggregate_value_p.  Now the head comment of that 
function reads:

/* Return 1 if EXP is an aggregate type (or a value with aggregate type).
   This means a type for which function calls must pass an address to the
   function or get an address back from the function.

A C function will never see such an array_type, so I would have thought that 
the C compiler should not invoke aggregate_value_p on it (and it appears 
that this was the case before).

Is this reasoning valid or should I do my homework and get rid of all these 
obsolete assumptions?

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]