This is the mail archive of the gcc-patches@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]

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


Hi,
   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.


Thanks,
Andrew Pinski

ChangeLog:

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


cp/ChangeLog:

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

testsuite/ChangeLog:

        * gcc.c-torture/compile/complex-5.c: New test.

Attachment: fixpr30132.diff.txt
Description: Text document


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