https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #30 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 15 08:43:42 2019
New Revision: 275726
URL: https://gcc.gnu.org/viewcvs?rev=275726&root=gcc&view=rev
Log:
2019-09-15 Thomas Koenig
PR fortran/91556
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #28 from Thomas Koenig ---
Author: tkoenig
Date: Sat Sep 14 20:40:55 2019
New Revision: 275719
URL: https://gcc.gnu.org/viewcvs?rev=275719&root=gcc&view=rev
Log:
2019-09-14 Thomas Koenig
PR fortran/91557
PR fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
Thomas Koenig changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #26 from Steve Kargl ---
On Mon, Sep 09, 2019 at 11:21:05AM +, mario-baumann at web dot de wrote:
>
> --- Comment #25 from Mario Baumann ---
>
> the following fortran code (without module/interface statements)
>
> SUBROU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
Mario Baumann changed:
What|Removed |Added
CC||mario-baumann at web dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #24 from Steve Kargl ---
On Mon, Sep 02, 2019 at 06:51:23PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
>
> --- Comment #23 from anlauf at gcc dot gnu.org ---
> (In reply to Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #22)
> A problem with such code is that type violations like that are likely to
> cause
> actual wrong code issues because much of the aliasing analysis is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #22 from Thomas Koenig ---
A problem with such code is that type violations like that are likely to cause
actual wrong code issues because much of the aliasing analysis is type based...
What I could do is to
a) restrict the number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #21 from Steve Kargl ---
On Thu, Aug 29, 2019 at 09:38:09PM +, tkoenig at gcc dot gnu.org wrote:
> --- Comment #18 from Thomas Koenig ---
> (In reply to anlauf from comment #14)
> > The current solution is a bit annoying for impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #20 from Steve Kargl ---
On Fri, Aug 30, 2019 at 07:43:54PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
>
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #18)
> (In reply to anlauf from comment #14)
> > The current solution is a bit annoying for implicitly-derived interfaces.
> >
> > Consider a code like:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #18 from Thomas Koenig ---
(In reply to anlauf from comment #14)
> The current solution is a bit annoying for implicitly-derived interfaces.
>
> Consider a code like:
>
> module foo
> implicit none
> type t1
> integer :: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #17 from Steve Kargl ---
On Thu, Aug 29, 2019 at 07:18:01PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
>
> --- Comment #16 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Karg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #15)
> On Thu, Aug 29, 2019 at 06:49:15PM +, anlauf at gcc dot gnu.org wrote:
> > module foo
> > implicit none
> > type t1
> > integer :: i = 1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #15 from Steve Kargl ---
On Thu, Aug 29, 2019 at 06:49:15PM +, anlauf at gcc dot gnu.org wrote:
> module foo
> implicit none
> type t1
> integer :: i = 1
> end type t1
> type t2
> integer :: j = 2
> end type t2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #13 from Steve Kargl ---
On Thu, Aug 29, 2019 at 05:32:39AM +, tkoenig at gcc dot gnu.org wrote:
> --- Comment #12 from Thomas Koenig ---
> (In reply to Steve Kargl from comment #11)
>
> > Error: Type mismatch between actual arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #12 from Thomas Koenig ---
(In reply to Steve Kargl from comment #11)
> Error: Type mismatch between actual argument at (1) and actual
> argument at (2) (REAL(8)/REAL(16))
That sounds _much_ better (and is also shorter). When I am b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #11 from Steve Kargl ---
On Wed, Aug 28, 2019 at 09:34:36PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
>
> multi.f90:2199:23:
>
> 2199 |call evolvePDF (x(1), q, f)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #10 from Thomas Koenig ---
Created attachment 46776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46776&action=edit
Concept patch
Here's what a patch could look like.
With the test case, it yields
multi.f90:2186:23:
2186 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
22 matches
Mail list logo