[PATCH] Fix middle-end/30132: ICE with complex and taking the real part of a ?:
Wed Mar 14 23:30:00 GMT 2007
The problem here is that the gimplifier can produce invalid gimple when
the address is of an non addressable expression like a conditional
expression. When Alexandre fixed PR 20280, he introduced the issue of
building addresses of the two operand of a conditional expression if we
wantted either a lvalue or a rvalue, this introduced this latent bug of
Now my patch fixes PR 20280 in the front-end so we never get &(a?b:c), we
always get a?&b:&c instead. This patch also fixes the invalid gimple
issue when needing a temp variable. This patch also reverts part of the
patch for PR 20280 so only when we want lvalue of a conditional, we take
the address inside the conditional.
The middle part of the patch is enough to fix the bug but we get worse
code as we get * (a?&b:&c) which is not optimized currently.
OK? Bootstrapped and tested on i686-linux-gnu with no regressions.
* gimplifier.c (gimplify_cond_expr): Don't create *(a?&b:&c), if a
rvalue is ok.
(gimplify_addr_expr): Create one more extra variable if we have a
* typeck.c (build_address): For COND_EXPR, create a?&b:&c instead
of the plain
&(a?b:c) so we don't get a temp variable in the gimplifier.
* gcc.c-torture/compile/complex-5.c: New test.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Gcc-patches