This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix middle-end/30132: ICE with complex and taking the real part of a ?:
- From: Jason Merrill <jason at redhat dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Andrew_Pinski at playstation dot sony dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Nov 2007 15:37:57 -0500
- Subject: Re: [PATCH] Fix middle-end/30132: ICE with complex and taking the real part of a ?:
- Newsgroups: gmane.comp.gcc.patches
- References: <OFA237F55F.3B8A094C-ON8825729F.003ABE48-8825729F.003C46F9@playstation.sony.com> <20070320212627.GE27763@redhat.com> <email@example.com>
Andrew Pinski wrote:
* 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.
What about the other transformations in unary_complex_lvalue? Or the &*
The problem is that build_address is trying to do something very simple,
but the name makes it attractive to other parts of the compiler that
want the address of something without all the diagnostics in
build_unary_op. Really it's only safe to call build_address if you know
that there aren't any tree simplifications to be done on the operand.
I think what we really need is to split out most of the address handling
in build_unary_op so we can call it with diagnostics on or off, call the
latter build_address, rename the current build_address to
build_addr_expr and go through the callers of build_address to see which
one they really want.