|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Severity|normal |enhancement
--- Comment #3 from Thomas Koenig ---
Actually, the problem is in the program. We should warn about
this, but not repack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54633
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 24 13:51:39 2017
New Revision: 253125
URL: https://gcc.gnu.org/viewcvs?rev=253125&root=gcc&view=rev
Log:
2017-09-24 Thomas Koenig
PR fortran/54633
* gfortran
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This is a spin-off from PR 54633.
integer y((sum(minloc((/1/
end
is rejected with the (IMHO misleading) error message
integer y((sum(minloc((/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54633
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
Bug 54613 depends on bug 54633, which changed state.
Bug 54633 Summary: ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due
to lacking compile-time simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54633
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sun Sep 24 14:26:55 2017
New Revision: 253126
URL: https://gcc.gnu.org/viewcvs?rev=253126&root=gcc&view=rev
Log:
2017-09-24 Thomas Koenig
PR fortran/66328
* gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056
Bug 33056 depends on bug 66328, which changed state.
Bug 66328 Summary: Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834
Bug 32834 depends on bug 66328, which changed state.
Bug 66328 Summary: Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328
What|Removed |Added
--
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Thomas Koenig ---
Test case committed to trunk, closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82332
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
--- Comment #11 from Thomas Koenig ---
Created attachment 42250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42250&action=edit
Proposed patch
This patch is an attempt at getting rid of the lock-order
inversion. It seems to do the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
--- Comment #12 from Thomas Koenig ---
Correction... the patch does not work with a simple
example such as
program main
!$OMP PARALLEL NUM_THREADS(4)
print *,"Hello, world"
!$OMP END PARALLEL
end program main
Some more digging to do...
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #13 from Thomas Koenig ---
Let's see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82362
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.0
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Building an instrumented gfortran with
make -j4 CFLAGS="-std=gnu99 -g -O2 -fsanitize=thread " FCFLAGS="-g -O2
-fsanitize=thread" CXXFLAGS="-std=gnu99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82378
Thomas Koenig changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45435
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #2 from Thomas Koenig ---
Working on it.
:00 |2017-10-1
Component|libfortran |libgomp
Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #14 from Thomas Koenig ---
Following the discussion at
https://gcc.gnu.org/ml/fortran/2017-10/msg2.html
all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
--- Comment #15 from Thomas Koenig ---
*** Bug 82378 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82378
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #5 from Thomas Koenig ---
This should be rejected, or at least warned about.
See also PR 49232.
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
As shown in PR82362, the alignment of arrays can have
a significant effect on execution speed. Using alloca with
aligment for -fstack-arrays could be a win.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82362
--- Comment #3 from Thomas Koenig ---
The Fortran part is now PR82392.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #28 from Thomas Koenig ---
(In reply to Nicolas Koenig from comment #27)
> program main
> implicit none
> open (10, file='foo.dat', asynchronous='yes')
> call s()
> close(10)
> contains
> subroutine s()
>
||tkoenig at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #10 from Thomas Koenig ---
(In reply to Jos de Kloe from comment #8)
> I understand that you wish to enforce "standards", but removing a
> "Non-standard extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
--- Comment #29 from Thomas Koenig ---
Another thing... if we do
WRITE (10, ASYNCHRONOUS="YES") A
we need to mark A as ASYNCHRONOUS which we will probably have
to treat similar (or identically) to VOLATILE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80118
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Tue Oct 3 15:50:45 2017
New Revision: 253383
URL: https://gcc.gnu.org/viewcvs?rev=253383&root=gcc&view=rev
Log:
2017-10-03 Thomas Koenig
Steven G. Kargl
Backp
||2017-10-04
CC||dominiq at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
This was an intentional
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Thomas Koenig ---
You are passing an unallocated array to an input
function, probably in the expectation that it will
be allocated by the READ.
This is a feature which Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #10 from Thomas Koenig ---
Here are some gprof timings:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
28.73 2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #12 from Thomas Koenig ---
This was for trunk.
This patch
Index: io.h
===
--- io.h(Revision 253377)
+++ io.h(Arbeitskopie)
@@ -773,6 +773,7 @@
extern i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80118
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Fri Oct 6 18:15:26 2017
New Revision: 253500
URL: https://gcc.gnu.org/viewcvs?rev=253500&root=gcc&view=rev
Log:
2017-10-06 Thomas Koenig
Steven G. Kargl
Backp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80118
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #16 from Thomas Koenig ---
Jerry,
what do you think of this approach? This creates a local copy
of the gfc_unit, without putting it into the tree.
Index: transfer.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #17 from Thomas Koenig ---
I mean apart from the fact that this creates a huge memory leak :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sat Oct 7 11:48:28 2017
New Revision: 253509
URL: https://gcc.gnu.org/viewcvs?rev=253509&root=gcc&view=rev
Log:
2017-10-07 Thomas Koenig
PR fortran/49232
* expr.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68546
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #4 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709
--- Comment #9 from Thomas Koenig ---
The generated code for the loop seems to be on par with what
clang and icc do, so that part is fixed.
Initialization is strange for icc. For clang, it really quite short:
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #19 from Thomas Koenig ---
Created attachment 42320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42320&action=edit
patch which failes with dtio_14 and dtio_15, among others
Well, this one doesn't work yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #21 from Thomas Koenig ---
Jerry,
I think you know more about this than I do, so please go ahead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||tkoenig at gcc dot gnu.org
Blocks||82471
--- Comment #6 from Thomas Koenig ---
Still present..., and is being found "in the wild", so to speak...
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
[Bug
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #4 from Thomas Koenig ---
Let's take a look here.. this sounds doable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #5 from Thomas Koenig ---
This looks good:
Index: intrinsics/execute_command_line.c
===
--- intrinsics/execute_command_line.c (Revision 253525)
+++ intrinsics/execute_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #4 from Thomas Koenig ---
I am testing a patch.
||tkoenig at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Thomas Koenig ---
Same root cause as PR 82471 - loop interchange (or lack thereof).
*** This bug has been marked as a duplicate of bug 82471 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
--- Comment #6 from Thomas Koenig ---
*** Bug 82495 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Summary|do-concurrent is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Tue Oct 10 16:49:32 2017
New Revision: 253593
URL: https://gcc.gnu.org/viewcvs?rev=253593&root=gcc&view=rev
Log:
2017-10-10 Thomas Koenig
PR libfortran/82233
* intri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #10 from Thomas Koenig ---
(In reply to Christophe Lyon from comment #9)
> Indeed, it passes/fails randomly in subsequent builds. It is killed, maybe
> because of a timeout, but there is nothing in the standard logs.
>
> I've been tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #11 from Thomas Koenig ---
Another idea: Could there be a network drive in the PATH
that does not respond in time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #13 from Thomas Koenig ---
I am not sure what to do with this failing test case.
To me, this sounds more like a problem with your test setup.
execute_command_line calls the C system() function. What
does that do on your system if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82372
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sun Oct 15 12:00:29 2017
New Revision: 253768
URL: https://gcc.gnu.org/viewcvs?rev=253768&root=gcc&view=rev
Log:
2017-10-15 Thomas Koenig
PR fortran/82372
* fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82372
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79864
Bug 79864 depends on bug 79863, which changed state.
Bug 79863 Summary: Assignment of unallocated array to unallocated array
variable leads to access of unallocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79863
What|Re
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from Thomas Koenig ---
Steve is correct, this is invalid Fortran.
||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
Still fails on current trunk.
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #2 from Thomas Koenig ---
Let's see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79446
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #9 from Thomas Koenig ---
I just checked on powerpc64 with a rather current trunk with
gfc::bank testing status:0 (PASSED): Performance:
2888199.6889235629
gfc::vector testing status:0 (PASSED): Perf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #11 from Thomas Koenig ---
With r241438, the test passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #12 from Thomas Koenig ---
And with r241439, the test fails.
Andre, any ideas?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #15 from Thomas Koenig ---
Author: tkoenig
Date: Wed Oct 18 17:54:18 2017
New Revision: 253865
URL: https://gcc.gnu.org/viewcvs?rev=253865&root=gcc&view=rev
Log:
2017-10-18 Thomas Koenig
PR libfortran/82233
* gfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #16 from Thomas Koenig ---
(In reply to Christophe Lyon from comment #14)
> Removing the last
>call execute_command_line(command , wait=.false., exitstat=i)
> or moving it before
>call execute_command_line(command ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Wed Oct 18 20:32:34 2017
New Revision: 253868
URL: https://gcc.gnu.org/viewcvs?rev=253868&root=gcc&view=rev
Log:
2017-10-18 Thomas Koenig
PR fortran/79795
* resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Wed Oct 18 21:29:37 2017
New Revision: 253872
URL: https://gcc.gnu.org/viewcvs?rev=253872&root=gcc&view=rev
Log:
2017-10-18 Thomas Koenig
PR fortran/82567
* frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #18 from Thomas Koenig ---
Author: tkoenig
Date: Thu Oct 19 17:49:24 2017
New Revision: 253907
URL: https://gcc.gnu.org/viewcvs?rev=253907&root=gcc&view=rev
Log:
2017-10-19 Thomas Koenig
Backport from trunk
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #20 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to Christophe Lyon from comment #17)
> > Thanks for your effort; I'm still seeing noise though.
> >
> > Sorry, I'm not fluent in fortran: is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Fri Oct 20 18:01:36 2017
New Revision: 253951
URL: https://gcc.gnu.org/viewcvs?rev=253951&root=gcc&view=rev
Log:
2017-10-20 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Fri Oct 20 19:26:35 2017
New Revision: 253956
URL: https://gcc.gnu.org/viewcvs?rev=253956&root=gcc&view=rev
Log:
2017-10-20 Thomas Koenig
Backport from trunk
PR fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79795
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #21 from Thomas Koenig ---
We could do something like
program boom
implicit none
interface
subroutine mywait() bind(c)
end subroutine mywait
end interface
integer :: i,j
character(len=256)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #13 from Thomas Koenig ---
Created attachment 42429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42429&action=edit
Patch which works for maxloc except for some cases
This patch works, sort of, but it fails with a s
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This variant of maxloc_bounds_4.f90
module tst
contains
subroutine foo(res)
integer(kind=4), allocatable :: f(:,:)
integer(kind=8) , dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
Thomas Koenig changed:
What|Removed |Added
Attachment #42429|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48997
Bug 48997 depends on bug 48025, which changed state.
Bug 48025 Summary: Unnecessary function evaluations in arguments to size and
ubound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48025
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48025
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
I think we can close this. The preferred way is to
use C interop. Anybody mind if I close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
--- Comment #22 from Thomas Koenig ---
Author: tkoenig
Date: Sun Oct 22 14:21:16 2017
New Revision: 253983
URL: https://gcc.gnu.org/viewcvs?rev=253983&root=gcc&view=rev
Log:
2017-10-22 Thomas Koenig
Backport from trunk
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #3 from Thomas Koenig ---
Yes, simplification is the key.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #39 from Thomas Koenig ---
Clang has this implemented via polyhedral optimization,
see https://polly.llvm.org/ (news from September 2017).
Can gcc do something similar?
||14741
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #9 from Thomas Koenig ---
I'm trying something.
More generally, I think I should try for some very simple
loop interchange so that we at least get the simple
case of m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
--- Comment #10 from Thomas Koenig ---
Created attachment 42482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42482&action=edit
Here's a first attempt...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
--- Comment #17 from Thomas Koenig ---
What I am trying to do is to have only one version of each
library routine (the one using gfc_index_kind), and then
convert to the KIND parameter that the user specified (or to
default integer if the user di
401 - 500 of 1385 matches
Mail list logo
