diff mbox

[Fortran] PR45186 - P2 regression - gfortran 4.6 emits wrong line numbers

Message ID 201009070532.o875WJ7f026823@ignucius.se.axis.com
State New
Headers show

Commit Message

Hans-Peter Nilsson Sept. 7, 2010, 5:32 a.m. UTC 
> Date: Thu, 02 Sep 2010 20:31:55 +0200
> From: Tobias Burnus <burnus@net-b.de>

>   H.J. Lu wrote:
> > On Thu, Sep 2, 2010 at 6:21 AM, Tobias Burnus<burnus@net-b.de>  wrote:
> >> Built and currently regtesting on x86-64-linux.
> >> OK for the trunk? (Assuming that there are no testsuite failures
> > This may cause:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
> 
> Maybe.

It is definitely the trigger for that regression on "32-bit"
targets.

> I think I defer the problem until all files are converted - maybe it 
> disappears then, or one can find the place where input_location is the 
> wrong location.

For deferred regressions (ones not jumped to post-haste but
saved...for another day), the canonical way to handle them is to
open a PR (done) then xfail the tests referring to the PR.  I
can't find this mentioned in the Written Rules in
<http://gcc.gnu.org/bugs/management.html> though, maybe only
mentioned on the mailing lists.  Anyway, as follows.  I don't
know whether the test fails for < 32-bit targets, but IIRC
they're aren't supported by gfortran anyway and either way this
fix is better than status quo.

Tested cris-elf, native x86_64-unknown-linux-gnu including /32.
Ok to commit?  

gcc/testsuite:

	PR fortran/45505
	* gfortran.dg/pr25923.f90: XFAIL warning on wrong line for ilp32.



brgds, H-P

Comments

Mikael Morin Sept. 7, 2010, 10:25 a.m. UTC | #1 
Le 07.09.2010 07:32, Hans-Peter Nilsson a écrit :
>
>> Date: Thu, 02 Sep 2010 20:31:55 +0200
>> From: Tobias Burnus<burnus@net-b.de>
>
>>    H.J. Lu wrote:
>>> On Thu, Sep 2, 2010 at 6:21 AM, Tobias Burnus<burnus@net-b.de>   wrote:
>>>> Built and currently regtesting on x86-64-linux.
>>>> OK for the trunk? (Assuming that there are no testsuite failures
>>> This may cause:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
>>
>> Maybe.
>
> It is definitely the trigger for that regression on "32-bit"
> targets.
>
>> I think I defer the problem until all files are converted - maybe it
>> disappears then, or one can find the place where input_location is the
>> wrong location.
>
> For deferred regressions (ones not jumped to post-haste but
> saved...for another day), the canonical way to handle them is to
> open a PR (done) then xfail the tests referring to the PR.  I
> can't find this mentioned in the Written Rules in
> <http://gcc.gnu.org/bugs/management.html>  though, maybe only
> mentioned on the mailing lists.  Anyway, as follows.  I don't
> know whether the test fails for<  32-bit targets, but IIRC
> they're aren't supported by gfortran anyway and either way this
> fix is better than status quo.
>
> Tested cris-elf, native x86_64-unknown-linux-gnu including /32.
> Ok to commit?
OK
diff mbox

Patch

Index: pr25923.f90
===================================================================
--- pr25923.f90	(revision 163934)
+++ pr25923.f90	(working copy)
@@ -10,7 +10,7 @@ 
 
 contains
 
-  function baz(arg) result(res) ! { dg-warning "res.yr' may be" }
+  function baz(arg) result(res) ! { dg-warning "res.yr' may be" "PR45505" { xfail ilp32 } }
     type(bar), intent(in) :: arg
     type(bar) :: res
     logical, external:: some_func
@@ -19,7 +19,7 @@ 
     else
       res = arg
     end if
-  end function baz
+  end function baz ! { dg-bogus "res.yr' may be" "PR45505" { xfail ilp32 } }
 
 end module foo