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

2011-01-06 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-06 
10:37:09 UTC ---
Author: jakub
Date: Thu Jan  6 10:37:02 2011
New Revision: 168537

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168537
Log:
PR c/47150
* c-convert.c (convert): When converting a complex expression
other than COMPLEX_EXPR to a different complex type, ensure
c_save_expr is called instead of save_expr, unless in_late_binary_op.
* c-typeck.c (convert_for_assignment): Set in_late_binary_op also
when converting COMPLEX_TYPE.

* gcc.c-torture/compile/pr47150.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr47150.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-convert.c
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


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

2011-01-05 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-05 
13:31:07 UTC ---
Created attachment 22903
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22903
gcc46-pr47150.patch

Untested fix.


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

2011-01-03 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-03 
11:16:35 UTC ---
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
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.


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

2011-01-03 Thread joseph at codesourcery dot com
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.


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

2011-01-03 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

  Component|middle-end  |c

--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-03 
21:53:13 UTC ---
It is a C FE bug actually, so c component is correct.


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

2011-01-01 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |4.5.3
Summary|4.5.1/4.5.2 ICE in  |[4.5/4.6 Regression] ICE in
   |gimplify_expr, at   |gimplify_expr at gimplify.c
   |gimplify.c:7146/7153 on |
   |fairly simple complex   |
   |expression  |

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 22:57:44 
UTC ---
[...@gnu-35 rrs]$ cat pr47150.c
float _Complex cmplx(float re, float im);
void bad_test(){
  float w = 2;
  float _Complex b;
  b = 0.5*(cmplx(0,w)+cmplx(1,w)/w);
}
[...@gnu-35 rrs]$ /export/gnu/import/rrs/147281/usr/bin/gcc -S pr47150.c
pr47150.c: In function \u2018bad_test\u2019:
pr47150.c:5: internal compiler error: in gimplify_expr, at gimplify.c:7045
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-35 rrs]$


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

2011-01-01 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-01 22:59:41 
UTC ---
It is caused by revision 147281:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00255.html