at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #7 from Thomas Koenig ---
Just to make sure I don't forget this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86119
Thomas Koenig changed:
What|Removed |Added
Target Milestone|8.3 |8.4
Summary|[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86119
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Thu Feb 21 18:01:41 2019
New Revision: 269070
URL: https://gcc.gnu.org/viewcvs?rev=269070&root=gcc&view=rev
Log:
2019-02-21 Thomas Koenig
PR fortran/86119
* class.c (gfc_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Tue Feb 19 17:55:33 2019
New Revision: 269024
URL: https://gcc.gnu.org/viewcvs?rev=269024&root=gcc&view=rev
Log:
2019-02-19 Thomas Koenig
PR fortran/89384
* trans-ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
--- Comment #3 from Thomas Koenig ---
This simple (too simple?) patch seems to fix things:
Index: trans-expr.c
===
--- trans-expr.c(Revision 268992)
+++ trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89384
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #26 from Thomas Koenig ---
Fixed on gcc 9 so far. I will backport this to the other
open branches, but only after the release of the next
version of gcc 8.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #25 from Thomas Koenig ---
Author: tkoenig
Date: Mon Feb 18 18:28:58 2019
New Revision: 268992
URL: https://gcc.gnu.org/viewcvs?rev=268992&root=gcc&view=rev
Log:
2019-02-18 Thomas Koenig
PR fortran/87689
* trans-decl.c (g
||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
Thomas Koenig changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #25 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #24)
> The warnings are gone between revisions r265814 and r265942.
I can confirm that.
So, are there objections to just committing a test case and
closing th
||tkoenig at gcc dot gnu.org
--- Comment #5 from Thomas Koenig ---
The test case is now rejected with trunk, looks like a recent 9 regression:
ig25@linux-p51k:/tmp> gfortran m_vstring.f90
m_vstring.f90:24:30:
24 | pure function vstring_length ( this ) result ( len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #23 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #22)
> FAIL: gfortran.dg/lto/20091028-1 f_lto_20091028-1_0.o-f_lto_20091028-1_1.o
> link, -O0 -flto -flto-partition=none -fuse-linker-plugin
These test cases are inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #22 from Thomas Koenig ---
Created attachment 45742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45742&action=edit
Patch that may work, but causes some regressions
The regressions are:
FAIL: gfortran.dg/lto/20091028-1 f_lto_
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #21 from Thomas Koenig ---
Think I might have something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #19 from Thomas Koenig ---
This is worse than I thought.
It seems that, if we compile
subroutine foo(a)
real :: a
end subroutine foo
program main
real :: x
call foo(x)
end program main
we call build_function_type_vec (type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
Thomas Koenig changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
--- Comment #14 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 16 16:12:51 2019
New Revision: 268960
URL: https://gcc.gnu.org/viewcvs?rev=268960&root=gcc&view=rev
Log:
2019-02-17 Thomas Koenig
PR fortran/71066
* trans-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #16 from Thomas Koenig ---
(In reply to Alan Modra from comment #12)
> A little more sophisticated.
>
> * fortran/trans-types.c (gfc_get_function_type): Use a varargs decl
> unless we have args other than hidden ones.
Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
Thomas Koenig changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84135
--- Comment #6 from Thomas Koenig ---
$ cat z1.f90
> program p
>integer :: i
>integer, dimension(3) :: x[2,*]
>data (x(i:i+2:i+1), i=1,2) /1,2,3/
This should be caught, there is no normal dimension
here, just a codimension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
--- Comment #13 from Thomas Koenig ---
z1.f90 has been fixed with r267356.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565
Thomas Koenig changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #10
,
||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
Jakub, do you know what the OMP standard has to say on this?
Is "STOP 1" in an OMP region defined behavior?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #15 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 10 18:41:03 2019
New Revision: 268751
URL: https://gcc.gnu.org/viewcvs?rev=268751&root=gcc&view=rev
Log:
2019-02-10 Thomas Koenig
PR fortran/71723
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 10 18:30:01 2019
New Revision: 268750
URL: https://gcc.gnu.org/viewcvs?rev=268750&root=gcc&view=rev
Log:
2019-02-10 Thomas Koenig
PR fortran/71237
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
Thomas Koenig changed:
What|Removed |Added
Summary|[7/8/9 Regression] [F08]|[7/8 Regression] [F08] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 10 15:56:41 2019
New Revision: 268749
URL: https://gcc.gnu.org/viewcvs?rev=268749&root=gcc&view=rev
Log:
2019-02-10 Thomas Koenig
PR fortran/71723
* expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 10 15:52:38 2019
New Revision: 268748
URL: https://gcc.gnu.org/viewcvs?rev=268748&root=gcc&view=rev
Log:
2019-02-10 Thomas Koenig
PR fortran/71237
* expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 10 15:38:19 2019
New Revision: 268747
URL: https://gcc.gnu.org/viewcvs?rev=268747&root=gcc&view=rev
Log:
2019-02-10 Thomas Koenig
PR fortran/67679
* gfortran.dg/war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89275
Thomas Koenig changed:
What|Removed |Added
Target||powerpc64le
Blocks|
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
See
https://www.phoronix.com/scan.php?page=article&item=power9-gcc-clang&num=4
there appears to be a ~ 20% slowdown for gcc9 vs. gcc8 on the memcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
--- Comment #12 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #11)
> Slightly different variant of z3.f90, with a different ICE:
>
> program p
>real :: a(2,2)[*]
>data a /1.0, 2.0, 3.0, 4.0/
> end
>
> Interner Compiler-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
--- Comment #11 from Thomas Koenig ---
Slightly different variant of z3.f90, with a different ICE:
program p
real :: a(2,2)[*]
data a /1.0, 2.0, 3.0, 4.0/
end
Interner Compiler-Fehler: Speicherzugriffsfehler
0xe24dff crash_signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
--- Comment #10 from Thomas Koenig ---
Removing the assert
gcc_assert (loop->dimen == 1);
> $ cat z3.f90
> program p
>real :: a(2,2)[*]
>data a /4*0.0/
> end
just hits a check later on:
d.f90:1:0:
1 | program p
|
interner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 9 20:09:56 2019
New Revision: 268731
URL: https://gcc.gnu.org/viewcvs?rev=268731&root=gcc&view=rev
Log:
2019-02-09 Thomas Koenig
PR fortran/71860
Backport from trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 9 20:07:28 2019
New Revision: 268730
URL: https://gcc.gnu.org/viewcvs?rev=268730&root=gcc&view=rev
Log:
2019-02-09 Thomas Koenig
PR fortran/71860
Backport from trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-valid-code
Blocks|
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat tst3.f90
program test
implicit none
integer :: i
character(*), parameter :: y = ''
character(*), parameter :: z = transfer ([&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89236
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||tkoenig at gcc dot gnu.org
Summary|[7/8/9 Regression] [OOP]|[7/8 Regression] [OOP] ICE
|ICE on pointing to |on pointing to null(mold),
|null(mold), verify_gimple |verify_gimple failed
|failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Wed Feb 6 20:34:42 2019
New Revision: 268590
URL: https://gcc.gnu.org/viewcvs?rev=268590&root=gcc&view=rev
Log:
2019-02-06 Thomas Koenig
PR fortran/71860
* gfortran
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #12 from Thomas Koenig ---
I have a patch, let's see if it survives regression testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006
--- Comment #5 from Thomas Koenig ---
However, this also fails:
program p
type t
integer i
end type
integer rslt
class(t), allocatable :: t_alloc(:)
allocate (t_alloc(10), source=t(1))
rslt = storage_size(t_alloc)
end program p
||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
Looks valid to me.
F2018, 16.9.184 STORAGE_SIZE (A [, KIND])
3 Arguments.
A shall be a data object of any type. If it is polymorphic it shall not be an
undefined pointer. If
it is unlimited polymorphic or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
|--- |FIXED
Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #30 from Thomas Koenig ---
Hm, looks like a bit more complicated. I'll look at some other
things first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Tue Feb 5 21:23:07 2019
New Revision: 268560
URL: https://gcc.gnu.org/viewcvs?rev=268560&root=gcc&view=rev
Log:
2019-02-05 Thomas Koenig
PR fortran/67679
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 67679, which changed state.
Bug 67679 Summary: [7/8/9 Regression] -Wunitialized reports on
compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Tue Feb 5 21:12:41 2019
New Revision: 268559
URL: https://gcc.gnu.org/viewcvs?rev=268559&root=gcc&view=rev
Log:
2019-02-05 Thomas Koenig
PR fortran/67679
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #29 from Thomas Koenig ---
This also fails:
type :: t
integer :: c
end type t
class(t), dimension(:), allocatable :: a, b
class(t), dimension(:), allocatable :: c
allocate (a(5), source=t(1))
allocate (b(5), source=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #28 from Thomas Koenig ---
This patch
Index: dependency.c
===
--- dependency.c(Revision
gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #27 from Thomas Koenig ---
I think I have an idea about this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #26 from Thomas Koenig ---
Works for
type :: t
integer :: c
end type t
type(t), dimension(5) :: a, b
type(t), dimension(:), allocatable :: c
a = t(1)
b = t(7)
allocate(c(5), source=t(13))
c = plus(c(1), b)
pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
,
||ice-on-invalid-code
CC||tkoenig at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #18 from Thomas Koenig ---
Still worth fixing, but IMHO a low priority.
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #9 from Thomas Koenig ---
(In reply to kargl from comment #8)
> I think that this should be closed.
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394
Thomas Koenig changed:
What|Removed |Added
Keywords||error-recovery,
|
||tkoenig at gcc dot gnu.org
--- Comment #9 from Thomas Koenig ---
I've read the discussion, but I am not clear about
what the problem actually is.
Is this something that we can close now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 3 19:38:25 2019
New Revision: 268502
URL: https://gcc.gnu.org/viewcvs?rev=268502&root=gcc&view=rev
Log:
2019-02-03 Thomas Koenig
PR fortran/67679
* trans-ar
,
||tkoenig at gcc dot gnu.org
Known to work|9.0 |8.2.1
Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
|fold_convert_loc, at|fold_convert_loc, at
|fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #6 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #5)
> Not sure if this
> is standard conforming (see PR 49755).
Actually, it's not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #5 from Thomas Koenig ---
This patch
Index: trans-array.c
===
--- trans-array.c (Revision 268432)
+++ trans-array.c (Arbeitskopie)
@@ -5960,19 +5960,7 @@ gfc
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
||tkoenig at gcc dot gnu.org
Component|fortran |middle-end
--- Comment #4 from Thomas Koenig ---
The code that gfortran generates is correct, it is just that
the middle-end does not quite understand it and generates a
warning for it.
The -fdump-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
--- Comment #13 from Thomas Koenig ---
The application of this patch caused PR 89079.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
Bug 47030 depends on bug 89079, which changed state.
Bug 89079 Summary: "Invalid compiler error: Segmentation fault" in module with
"equivalence" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
Thomas Koenig changed:
What|Removed |Added
Depends on||89079
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 2 17:07:40 2019
New Revision: 268479
URL: https://gcc.gnu.org/viewcvs?rev=268479&root=gcc&view=rev
Log:
2019-02-02 Thomas Koenig
PR fortran/88298
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 57048, which changed state.
Bug 57048 Summary: [7/8 Regression] Handling of C_PTR and C_FUNPTR leads to
reject valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
--- Comment #14 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 2 16:57:39 2019
New Revision: 268478
URL: https://gcc.gnu.org/viewcvs?rev=268478&root=gcc&view=rev
Log:
2019-02-02 Thomas Koenig
PR fortran/57048
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 2 16:53:28 2019
New Revision: 268477
URL: https://gcc.gnu.org/viewcvs?rev=268477&root=gcc&view=rev
Log:
2019-02-02 Thomas Koenig
PR fortran/88298
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 2 16:35:47 2019
New Revision: 268476
URL: https://gcc.gnu.org/viewcvs?rev=268476&root=gcc&view=rev
Log:
2019-02-02 Thomas Koenig
PR fortran/57048
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sat Feb 2 16:21:43 2019
New Revision: 268475
URL: https://gcc.gnu.org/viewcvs?rev=268475&root=gcc&view=rev
Log:
2019-02-02 Thomas Koenig
PR fortran/88298
* arith.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
--- Comment #8 from Thomas Koenig ---
(In reply to Christophe Lyon from comment #7)
> I've noticed a new ICE on arm likely caused by this fix. It appeared between
> r268426 and r268434 hence my suspicion.
Can you open a new PR (9 Regression] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88669
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Thu Jan 31 22:21:28 2019
New Revision: 268432
URL: https://gcc.gnu.org/viewcvs?rev=268432&root=gcc&view=rev
Log:
2019-01-31 Thomas Koenig
PR fortran/88669
* resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81651
--- Comment #3 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #2)
> What is a "fully qualified module name"?
Error: Module file /full/path/to/module/mymodule.mod is bletchful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jan 29 22:40:26 2019
New Revision: 268372
URL: https://gcc.gnu.org/viewcvs?rev=268372&root=gcc&view=rev
Log:
2019-01-29 Thomas Koenig
PR fortran/57048
* interfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89086
--- Comment #4 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #3)
> > > I don't think this is realistic unless someone steps on with at least a
> > > draft.
> >
> > Well, yes. Howewer, I would prefer if you did not close it
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #3 from Thomas Koenig ---
I'll give it a spin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89086
--- Comment #2 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #1)
> > We should add a Fortran language reference to the documentaiton.
>
> I don't think this is realistic unless someone steps on with at least a
> draft.
W
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A big project, not a high priority, but nice to have nontheless:
We should add a Fortran language reference to the documentaiton.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #11 from Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048
--- Comment #10 from Thomas Koenig ---
Here's something that appears to work.
Looks like a hack, swims like a hack, and quacks like a hack...
Index: interface.c
===
--- interface.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71066
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
--- Comment #25 from Thomas Koenig ---
I've come to a bit of a different conclusion.
For
module x
implicit none
contains
elemental subroutine foo(a,b)
real, intent(inout) :: a
real, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
Thomas Koenig changed:
What|Removed |Added
Attachment #45514|0 |1
is obsolete|
1301 - 1400 of 3598 matches
Mail list logo
