This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
aggregate_value_p in the gimplifier
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 5 Jul 2004 16:49:25 +0200
- Subject: 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