http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #48 from Michael Matz 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=gcc&view=rev&rev=170284
Log:
PR fortran/45586
* gfortran.h (struct gfc_co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joseph S. Myers changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #47 from Mikael Morin 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=gcc&view=rev&rev=170074
Log:
2011-02-12 Mikael Morin
PR fortran/45586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #46 from Tobias Burnus 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 (attachment 23047), taking int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #45 from Tobias Burnus 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=gcc&view=rev&rev=170072
Log:
2011-02-12 Michael Matz
Janus Weil
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 tel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #43 from Michael Matz 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 contain
something as first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Mikael Morin changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Comment #42 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #41 from Joost VandeVondele
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 ?
--enable-checking=release ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #40 from Michael Matz 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: fortran/trans-expr.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #39 from Mikael Morin 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 after all.
> And voi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #38 from Mikael Morin 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 #37 from 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 2011-01-21
> 22:54:53 UT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #36 from Mikael Morin 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
> end type bar
> type(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #35 from Michael Matz 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 for top-level
symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #34 from Michael Matz 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 target attributes on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #33 from Mikael Morin 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 necessary, basically
> from gf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #32 from Michael Matz 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 gfc_sym_type(), whenever sym->attr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #31 from 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 2011-01-18
> 12:48:41 UT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #30 from Mikael Morin 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 sense
> thus, if one does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #29 from Michael Matz 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 'a%b%ptr%d' depends on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #28 from Tobias Burnus 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 just different model, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #27 from Mikael Morin 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 luck,
> things would then
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #26 from Richard Guenther 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 somebody point me to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #25 from 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 would then work automatical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Tobias Burnus changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #21 from Richard Guenther 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
> >
> > --- Comment #19 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #20 from 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 VandeVondele uzh.ch>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #19 from Joost VandeVondele
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 tried to get to a testcase for which t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #17 from Richard Guenther 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
Joost VandeVondele changed:
What|Removed |Added
Depends on||45777
--- Comment #16 from Joost Van
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #15 from Richard Guenther 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 the middle-end doesn't know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #14 from Joost VandeVondele
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 myself and am not too fluent in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #13 from Michael Matz 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 have the pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #12 from Michael Matz 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 isn't marked TARGET but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #11 from Joost VandeVondele
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), DIMENSION(:, :, :), POINTER::
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #10 from Richard Guenther 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
which is invalid? Valid w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
CC|
43 matches
Mail list logo
