[PATCH] Fix middle-end/30132: ICE with complex and taking the real part of a ?:

Andrew_Pinski@PlayStation.Sony.Com Andrew_Pinski@PlayStation.Sony.Com
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 
invalid gimple. 

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.

Andrew Pinski


        * 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 
temp decl.


        * 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...
Name: fixpr30132.diff.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070314/4e81adc1/attachment.txt>

More information about the Gcc-patches mailing list