[forwarded from http://bugs.debian.org/400484] seen on i486-linux-gnu with 3.4, 4.1.2, 4.3 20061022, works with -O0 $ gcc -c -O1 complex.c complex.c: In function 'testit': complex.c:4: internal compiler error: in find_lattice_value, at tree-complex.c:133 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 12774 [details] preprocessed source #include <complex.h> void testit(double complex* t, double* b) { b[0] = t[0]==0.0?0.0:-t[0]; } main(void) { static double complex k = 5; static double b; testit(&k,&b); } The following modification fixes the problem: void testit(double complex* t, double* b) { b[0] = t[0]==0.0?0.0:__real__(-t[0]); }
The gimplifier is messing up ...
Note, what we have is invalid gimple which we don't catch until tree-complex.c which is wrong, I have a patch to catch it earlier. Confirmed.
Also note moving catching it earlier makes this a middle-end (gimplifier) issue rather than an optimization issue.
After gimplification: D.1853 = *t; if (D.1853 == __complex__ (0.0, 0.0)) { D.1854 = __complex__ (0.0, 0.0); iftmp.0 = &D.1854; } else { D.1855 = *t; D.1856 = -D.1855; iftmp.0 = &D.1856; } D.1857 = REALPART_EXPR <*iftmp.0>; *b = D.1857; Before: *b = REALPART_EXPR <*t == __complex__ (0.0, 0.0) ? __complex__ (0.0, 0.0) : -*t>; I have not figured out why we need to take the address of the temp variable yet.
We have: if ((fallback & fb_lvalue) == 0) { result = tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), "iftmp"); ret = GS_ALL_DONE; } But fallback is "fallback=fb_either" so the above if is false. So we have two problems, an ineffient gimplification and a gimplification that is wrong. The ineffient gimplification is easy to fix. I will now go to figure out why we get an invalid one.
The second issue (the invalid gimple), comes from marking a variable as ADDRESSABLE late after the orginal gimplification to that variable had happened: /* Mark the RHS addressable. */ lang_hooks.mark_addressable (TREE_OPERAND (expr, 0));
I now have a fix for both issues (fixing the first problem of ineffient gimplification is enough to fix this bug but might not be enough to fix others).
The patch which fixed PR 20280 causes this invalid gimple to show up.
Here is a Fortran test case: $ cat bug2737.f90 PROGRAM get_tst_inc_complex implicit none external subrrg, checkrr complex :: vrr, trr vrr=cmplx(1.,2.); call subrr ( ) contains subroutine subrr () trr=vrr-(1.0,0.0) call checkrr (trr) return end subroutine subrr END $ gfortran --version GNU Fortran 95 (GCC) 4.1.1 20060524 (rpm:5) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -c -O0 bug2737.f90 $ gfortran -c -O1 bug2737.f90 bug2737.f90: In function 'MAIN__': bug2737.f90:1: internal compiler error: in find_lattice_value, at tree-complex.c:133 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. $
(In reply to comment #10) > Here is a Fortran test case: I think that Fortran issue is something unrelated to this bug. In fact that Fortran testcase was fixed for 4.1.2 by PR 27889.
Created attachment 13201 [details] patch which I need to retest and fix the last regression
Updated patch send: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00060.html
Patch is waiting for approval of the C++ bits.
This was caused by the patch which fixed PR 20280 and the 2nd iteration of the patch was rejected so unassigning from me.
4.0.0 really did not work either, it just did not cause a crash as the checks for invalid gimple was not there.
Mine.
Subject: Bug 30132 Author: rguenth Date: Wed Jan 9 15:46:49 2008 New Revision: 131430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131430 Log: 2008-01-09 Richard Guenther <rguenther@suse.de> Andrew Pinski <andrew_pinski@playstation.sony.com> PR middle-end/30132 * gimplify.c (gimplify_cond_expr): Do not create an addressable temporary if an rvalue is ok or an lvalue is not required. * gcc.c-torture/compile/pr30132.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr30132.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
Fixed on the trunk.
Closing 4.1 branch.
Closing 4.2 branch, fixed in 4.3.