https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #26 from Paul Thomas ---
Author: pault
Date: Sun Jan 10 18:06:43 2016
New Revision: 232203
URL: https://gcc.gnu.org/viewcvs?rev=232203&root=gcc&view=rev
Log:
2016-01-10 Paul Thomas
Backport from mainline.
PR fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #24 from Paul Thomas ---
Author: pault
Date: Sun Jan 10 12:56:28 2016
New Revision: 232200
URL: https://gcc.gnu.org/viewcvs?rev=232200&root=gcc&view=rev
Log:
2016-01-10 Paul Thomas
PR fortran/67779
* trans_array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Bug 67779 depends on bug 69011, which changed state.
Bug 69011 Summary: [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE
with SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #23 from Thomas Koenig ---
(In reply to Paul Thomas from comment #21)
> the right patch this time
Works well, looks obvious.
Pre-approved if you don't think it is, in fact, obvious :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #22 from Dominique d'Humieres ---
> Created attachment 37201 [details]
> the right patch this time
Works as expected without regression!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Paul Thomas changed:
What|Removed |Added
Attachment #37198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #20 from Dominique d'Humieres ---
> Created attachment 37198 [details]
> Patch to fix the problem
>
> The attached fixes all versions of the problem and regtests OK on FC21/x86_64.
Are you sure you attached the right patch to the rig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #19 from Paul Thomas ---
Created attachment 37198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37198&action=edit
Patch to fix the problem
The attached fixes all versions of the problem and regtests OK on FC21/x86_64.
I would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #18 from paul.richard.thomas at gmail dot com ---
It works for me - a mystery for tomorrow :-)
Paul
On 29 December 2015 at 23:10, dominiq at lps dot ens.fr
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
>
> --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #17 from Dominique d'Humieres ---
> Now sorting the right-hand part of the array fails:
Confirmed, starting with
2 9 8 7 6 5
4 3 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #16 from Thomas Koenig ---
Created attachment 37190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37190&action=edit
Test case that still fails
Hi Paul,
> (i) To fix the ICE in trans.c. This is fixed by the change to trans-stm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #14 from Thomas Koenig ---
The error occurs for class arrays only.
Changing
class(myclass), dimension(:) :: array
to
type(mysortable), dimension(:) :: array
in the more simplified test case results in correct
behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #13 from Paul Thomas ---
(In reply to Thomas Koenig from comment #11)
> Created attachment 37182 [details]
> More simplified test case
>
> This illustrates the problem - the array is passed wrong on
> the first call to the subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #12 from vehre at gcc dot gnu.org ---
That rings a bell. I feel like already have done some work on a similar issue.
I will take a look, when I have some time left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #11 from Thomas Koenig ---
Created attachment 37182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37182&action=edit
More simplified test case
This illustrates the problem - the array is passed wrong on
the first call to the su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #9 from vries at gcc dot gnu.org ---
PR69011 is probably a duplicate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #7 from Arjen Markus ---
Yes, I can confirm this - I also tried with the Intel Fortran compiler and that
sorts the integers and strings in the way one would expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #6 from Dominique d'Humieres ---
The problem is not limited to strings. If I add the following lines
array(1)%value = 2
array(9)%value = 10
write( string_array(1)%value, '(a,i0)' ) "String = ", 2
write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #5 from Dominique d'Humieres ---
Apparently there is a nasty bug somewhere: if I sort
'String = 2 '
'String = 9 '
'String = 8 '
'String = 7 '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #4 from Dominique d'Humieres ---
I have instrumented the test and found that 'String = 10 ', which at
the first position, is compared only once at the first call to quick sort, but
not for the other invocations of array(1:j).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #3 from Arjen Markus ---
Let me clarify:
the STRING "String = 10" should come after the STRING "String = 1 ". It is not
a matter of the numbers inside. If you compare these strings with LLT(), you
will see this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
Gerhard Steinmetz changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
27 matches
Mail list logo
