http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #48 from Michael Matz matz at gcc dot gnu.org 2011-02-18 19:52:19
UTC ---
Author: matz
Date: Fri Feb 18 19:52:16 2011
New Revision: 170284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170284
Log:
PR fortran/45586
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #45 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-12
13:09:06 UTC ---
Author: burnus
Date: Sat Feb 12 13:09:03 2011
New Revision: 170072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170072
Log:
2011-02-12 Michael Matz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #46 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-12
13:12:26 UTC ---
(In reply to comment #45)
New Revision: 170072
That patch fixed the issue of comment 40 to comment 44.
TODO: The actual restrict patch of comment 35
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #47 from Mikael Morin mikael at gcc dot gnu.org 2011-02-12
14:56:35 UTC ---
Author: mikael
Date: Sat Feb 12 14:56:32 2011
New Revision: 170074
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170074
Log:
2011-02-12 Mikael Morin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #44 from janus at gcc dot gnu.org 2011-02-07 22:15:47 UTC ---
(In reply to comment #42)
(In reply to comment #40)
There is indeed something fishy here.
Your change does the right thing in the non-class case I think ; can't tell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #43 from Michael Matz matz at gcc dot gnu.org 2011-01-26 12:39:04
UTC ---
Yep. With my patch the saner looking
new_person-service.education.person.ss = *ss;
statement is generated. It's possible that class containers actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #38 from Mikael Morin mikael at gcc dot gnu.org 2011-01-25
14:32:28 UTC ---
The patch looks good.
Somewhat hackish as you acknowledge, but worth submitting anyway.
A few minor comments below.
Index: fortran/trans-expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #39 from Mikael Morin mikael at gcc dot gnu.org 2011-01-25
14:40:40 UTC ---
(In reply to comment #37)
That's what we do ;)
Wow! Middle-end gurus take design decisions of mine before I have ever thought
them. They are real wizards
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #40 from Michael Matz matz at gcc dot gnu.org 2011-01-25 15:02:40
UTC ---
The patch from comment #35 requires another change in unrelated code, which
I think actually fixes a pre-existing bug in type extension support:
Index:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #41 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-01-25 15:03:55 UTC ---
(In reply to comment #39)
void *. So you get the ICE.
Hum, may I suggest a --push-harder/--will-you-swallow-it option ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #37 from rguenther at suse dot de rguenther at suse dot de
2011-01-24 09:41:28 UTC ---
On Fri, 21 Jan 2011, mikael at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #36 from Mikael Morin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #36 from Mikael Morin mikael at gcc dot gnu.org 2011-01-21
22:54:53 UTC ---
(In reply to comment #34)
Yep, that's what I figured eventually :) The question now is if for:
--
type bar
integer :: a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #35 from Michael Matz matz at gcc dot gnu.org 2011-01-20 16:36:23
UTC ---
Created attachment 23047
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23047
possible patch
So, this is my current version. I'm creating a different type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #34 from Michael Matz matz at gcc dot gnu.org 2011-01-19 16:39:30
UTC ---
As I said in comment #27, gfc_component structs belonging to the type, they
are shared between target and non-target variants. Thus one cannot set
inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #30 from Mikael Morin mikael at gcc dot gnu.org 2011-01-18
12:48:41 UTC ---
(In reply to comment #28)
One way would be to keep for data types all the time the two versions around:
One with restrict and one without restrict;
makes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #31 from rguenther at suse dot de rguenther at suse dot de
2011-01-18 13:37:42 UTC ---
On Tue, 18 Jan 2011, mikael at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #30 from Mikael Morin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #32 from Michael Matz matz at gcc dot gnu.org 2011-01-18 13:56:01
UTC ---
Yes, but it's possible I was going up the wrong tree. My idea was to
build the no-restrict variants of types on demand, as necessary, basically
from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #33 from Mikael Morin mikael at gcc dot gnu.org 2011-01-18
17:21:54 UTC ---
(In reply to comment #32)
Yes, but it's possible I was going up the wrong tree. My idea was to
build the no-restrict variants of types on demand, as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-17
10:08:13 UTC ---
(In reply to comment #24)
(In reply to comment #23)
We could do the analysis that fixed PR 45777 here, I just don't know
where :-)
Could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #27 from Mikael Morin mikael at gcc dot gnu.org 2011-01-17
13:01:23 UTC ---
(In reply to comment #25)
Maybe it would be better to set the inherited pointer and target
attributes much earlier, in gfc_variable_attr. With a bit of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-17
13:20:42 UTC ---
(In reply to comment #26)
It is, btw, a sign of bad Fortran language design and makes the point
of the pointer/target attributes moot.
Well, I think it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #29 from Michael Matz matz at gcc dot gnu.org 2011-01-17 13:52:20
UTC ---
It is, btw, a sign of bad Fortran language design
I don't see that. The frontend merely needs to emit correctly typed
expressions. And that the type of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #25 from tkoenig at netcologne dot de tkoenig at netcologne dot
de 2011-01-16 16:23:29 UTC ---
Maybe it would be better to set the inherited pointer and target
attributes much earlier, in gfc_variable_attr. With a bit of luck,
things
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu.org |unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #14 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2010-11-26 10:08:11 UTC ---
(In reply to comment #13)
Ugh. That might be terrible. Can you point to some language in the standard
supporting that (I haven't looked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-26
11:32:53 UTC ---
You then need to make sure to create variant types of aggregates with the
target attribute applied to all subtypes (thus, the restrict stuff removed)
as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:
What|Removed |Added
Depends on|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-26
12:49:39 UTC ---
(In reply to comment #16)
I think this implies this bug depends in somehow on PR45777.
Yes indeed - that bug looks very much related.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #19 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2010-11-26 13:39:00 UTC ---
Tobias, thanks for the clean explanation. I overlooked that the target of a
pointer has that target attribute (seems logical!).
Richard, I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de
2010-11-26 14:29:41 UTC ---
On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #19 from Joost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-26
14:36:02 UTC ---
(In reply to comment #20)
On Fri, 26 Nov 2010, Joost.VandeVondele at pci dot uzh.ch wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-25
16:50:50 UTC ---
Thus, isn't what the program does equivalent to
REAL(dp), DIMENSION(:, :, :), ALLOCATABLE :: z
REAL(dp), DIMENSION(:, :, :), POINTER:: y
y=z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2010-11-25 17:00:19 UTC ---
(In reply to comment #10)
Thus, isn't what the program does equivalent to
REAL(dp), DIMENSION(:, :, :), ALLOCATABLE :: z
REAL(dp),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #12 from Michael Matz matz at gcc dot gnu.org 2010-11-25 17:02:19
UTC ---
The following needs to be taken into account when determining the
validity:
If this use is supposed to be valid (we can associate a pointer with
and entity that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #13 from Michael Matz matz at gcc dot gnu.org 2010-11-25 17:07:10
UTC ---
no, your example here is different, and is not allowed. The original
testcase is fine.
so y=a%b%c%d%z
is allowed as soon as any of a, b, c, or d or z
43 matches
Mail list logo
