[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-22 15:59 --- The reason why the return stmt, at least after lowering, doesn't have a location, is because after lowering there is just one return instead of possibly multiple returns from before lowering. So the location_t of the

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #10 from jamborm at gcc dot gnu dot org 2010-09-22 15:33 --- gimple_has_location returns false for the return statement on both i686 and x86_64. When I hacked SRA to set the location of return statement to the location of the preceding statement (" = res;" or "D.1523 = res

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #9 from jamborm at gcc dot gnu dot org 2010-09-22 11:00 --- I have just examined the Fortran testcase more thoroughly and to my surprise I realized SRA did not create any new statements on i686. It merely changed statements res = *arg_1(D); into res$yr = MEM[(struct bar &)a

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-17 15:08 --- (In reply to comment #7) > > The added MEM = SR.1_10 uses location_t of the stmt after it, as > sra_modify_expr > emits statements before gsi. I'm arguing that in this case the MEM[(struct S > *)&D.2694] = SR.1_10;

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-17 12:46 --- You now set the location, but I believe the wrong one. esra changes are: foo (struct S * arg) { + int SR.1; + int s$a; struct S s; struct S D.2694; int D.2690; @@ -72,10 +37,12 @@ foo (struct S * arg) g

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #6 from jamborm at gcc dot gnu dot org 2010-09-14 13:55 --- Jakub, I have not understood whether you think the warning emitted when compiling the c code from comment #4 has the correct line number or not. I see it attributed to the line with the return statement which I thin

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #5 from hp at gcc dot gnu dot org 2010-09-07 13:28 --- Subject: Bug 45505 Author: hp Date: Tue Sep 7 13:23:24 2010 New Revision: 163949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163949 Log: PR fortran/45505 * gfortran.dg/pr25923.f90: XFAIL warni

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-07 08:05 --- This isn't specific to Fortran, struct S { int a; }; struct S foo (struct S *arg) { struct S s; if (bar ()) baz ("not valid"); else s = *arg; return s; } has the exactly same difference. I believe thi

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #3 from hp at gcc dot gnu dot org 2010-09-07 07:11 --- (In reply to comment #2) > xfail the test-case for ilp32 targets with a reference to this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #2 from hp at gcc dot gnu dot org 2010-09-06 22:02 --- I think I'll try doing it the IIUC documented preferred way for deferred bugs; to xfail the test-case for ilp32 targets with a reference to this PR. And yes, seen by the cris-elf autotester too. -- hp at gcc dot gnu

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

--- Comment #1 from burnus at gcc dot gnu dot org 2010-09-02 18:32 --- That's a -m32 (fails) vs. -m64 (works) issue, cf. http://gcc.gnu.org/ml/fortran/2010-09/msg00062.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505