[Bug c/47150] [4.5/4.6 Regression] ICE in gimplify_expr at gimplify.c

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

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.