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.
