https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #14 from Mikael Morin ---
Created attachment 37613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37613=edit
Fix for comment #10
This is sufficient to fix comment #10.
It removes the optional attribute on c(1) if c is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #13 from Mikael Morin ---
Author: mikael
Date: Fri Feb 5 21:41:15 2016
New Revision: 233188
URL: https://gcc.gnu.org/viewcvs?rev=233188=gcc=rev
Log:
Fix fortran scalar elemental dependency mishandling
PR fortran/66089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #10 from Mikael Morin ---
Here is a variant that fails similarly (even with the patch) with optional
arguments.
type :: t
integer :: c
end type t
type(t), dimension(5) :: a, b, c
a = t(1)
b = t(7)
c = t(13)
call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #11 from Mikael Morin ---
(In reply to vehre from comment #9)
> I am still wondering whether there isn't a counterexample where this is not
> working, i.e., we have lhs-rhs-dependency that is polymorphic. But because
> assignment to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #9 from vehre at gcc dot gnu.org ---
That was a rhetorical question.
In the patch you submitted in comment #2 could you put a comment (in the
source) at:
Index: trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #7 from vehre at gcc dot gnu.org ---
Ah, ok, which opens the question why that isn't done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #6 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to vehre from comment #5)
For the interpretation of (intrinsic) assignment, you have to look at
7.2.1.3:
The execution of the assignment shall have the same effect as if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #5 from vehre at gcc dot gnu.org ---
Let's have a look at the standard (F2008, 12.8.2, last sentence):
In the array case, the values of the elements, if any, of the result are
the same as would have been obtained if the scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #8 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to vehre from comment #7)
Ah, ok, which opens the question why that isn't done?
Performance, for (very) big arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #4 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
The code in comment 0 does not abort at run time up to revision r222352
(2015-04-23), but does so at r222398 (2015-04-24), likely
15 matches
Mail list logo
