This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 3 Jan 2011 16:22:31 +0000
- Subject: [Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c
- Auto-submitted: auto-generated
- References: <bug-47150-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-03 16:22:17 UTC ---
On Mon, 3 Jan 2011, jakub at gcc dot gnu.org wrote:
> The problem is in save_expr called by convert_to_complex when converting
> non-COMPLEX_EXPR _Complex float expression to _Complex double. As this is not
> c_save_expr that is called there (and can't, because convert_to_complex is used
> in non-Cish FEs), c_fully_fold is not called on the argument and as further
The non-C-family front ends seems generally to be using it in their
implementations of "convert", the legacy magic-name langhook. If this
could be eliminated (making remaining users in the language-independent
compiler use fold_convert unless they really need language-specific
semantics) then quite possibly the "convert" functions in those front ends
could go away and much of convert.c could move into c-family code (it does
checks for invalid conversions and gives errors for them, which is clearly
something that belongs in front ends) - while some of those front ends use
their own "convert" functions internally, they may well not need special
semantics for complex types that fold_convert doesn't have. But this
certainly isn't a Stage 4 fix....
> c_fully_fold doesn't dive into SAVE_EXPRs, nothing afterwards fully folds it
> either, which means it survives until gimplification and crashes there.
>
> An ugly fix would be duplicate the problematic part of convert_to_complex in
> c-convert.c (if converting COMPLEX_TYPE to a different COMPLEX_TYPE and
> expression is not COMPLEX_EXPR) and use c_save_expr there instead.
In view of the above and the notion that convert_to_complex really belongs
in the front ends, this seems reasonable.