https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88008
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Mon Mar 18 07:28:42 2019
New Revision: 269750
URL: https://gcc.gnu.org/viewcvs?rev=269750&root=gcc&view=rev
Log:
2019-03-17 Thomas Koenig
PR fortran/88008
* gfortran
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Thomas Koenig ---
Fixed, closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009
--- Comment #13 from Thomas Koenig ---
Author: tkoenig
Date: Mon Mar 18 17:35:54 2019
New Revision: 269769
URL: https://gcc.gnu.org/viewcvs?rev=269769&root=gcc&view=rev
Log:
2019-03-18 Thomas Koenig
PR fortran/68009
* iresolv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |7.5
Summary|"is used uninitia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009
--- Comment #14 from Thomas Koenig ---
Author: tkoenig
Date: Sat Mar 23 15:58:25 2019
New Revision: 269889
URL: https://gcc.gnu.org/viewcvs?rev=269889&root=gcc&view=rev
Log:
2019-03-23 Thomas Koenig
PR fortran/68009
Backport from tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009
--- Comment #15 from Thomas Koenig ---
Author: tkoenig
Date: Sat Mar 23 16:01:57 2019
New Revision: 269890
URL: https://gcc.gnu.org/viewcvs?rev=269890&root=gcc&view=rev
Log:
2019-03-23 Thomas Koenig
PR fortran/68009
Backport from tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
Bug 37131 depends on bug 68009, which changed state.
Bug 68009 Summary: [7/8 Regression] prototype for gfortran_runtime_error with
inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89574
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sun Mar 24 12:51:19 2019
New Revision: 269895
URL: https://gcc.gnu.org/viewcvs?rev=269895&root=gcc&view=rev
Log:
2019-03-24 Thomas Koenig
PR fortran/78865
* interfac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Priority|P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
--- Comment #9 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #2)
> The test works for me with 4.8.5. The change occurred between revisions
> r2370089 (2016-06-04, OK) and r237310 + one patch (2016-06-10, wrong code).
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
--- Comment #10 from Thomas Koenig ---
Bisecting this leads to
/home/ig25/Gcc/Bisect-bin/./gcc/xgcc -B/home/ig25/Gcc/Bisect-bin/./gcc/ -xc -S
-c /dev/null -fself-test
../../Bisect/gcc/input.c:1154: FAIL: ASSERT_STREQ (exp_filename, LOCATION_FILE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
--- Comment #11 from Thomas Koenig ---
r237104 fails for me, testing r237008.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537
Thomas Koenig changed:
What|Removed |Added
Component|rtl-optimization|fortran
Summary|[7/8/9 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #34 from Thomas Koenig ---
(In reply to Vittorio Zecca from comment #2)
> The following produces a Segmentation fault in gfc_conv_structure (r178925)
>
> type t
>integer g
> end type
> type(t) :: u=t(1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830
--- Comment #9 from Thomas Koenig ---
Rather than create a new compiler option, it is possible to compile to an
assembler
file using -S, look for .ascii „bar/foo.f90\0“ and replace with a sed or perl
script
according to your specification (for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
--- Comment #16 from Thomas Koenig ---
(In reply to Jeffrey A. Law from comment #15)
> Based on c#14 this seems most likely like a Fortran FE issue, right?
Certainly looks like it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85686
--- Comment #5 from Thomas Koenig ---
(In reply to Jürgen Reuter from comment #4)
> Any update on this one, that should possibly be not so hard to fix I'd guess.
A combination of character, associate, and arrays?
How many hoenest's nests do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Sat Mar 30 13:23:38 2019
New Revision: 270032
URL: https://gcc.gnu.org/viewcvs?rev=270032&root=gcc&view=rev
Log:
2019-03-30 Thomas Koenig
PR fortran/78865
Backport f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89830
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sat Mar 30 13:41:10 2019
New Revision: 270034
URL: https://gcc.gnu.org/viewcvs?rev=270034&root=gcc&view=rev
Log:
2019-03-30 Thomas Koenig
PR fortran/89866
* gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sat Mar 30 13:45:47 2019
New Revision: 270035
URL: https://gcc.gnu.org/viewcvs?rev=270035&root=gcc&view=rev
Log:
2019-03-30 Thomas Koenig
PR fortran/89866
* gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627
Bug 39627 depends on bug 89866, which changed state.
Bug 89866 Summary: [8 Regression] [F08] wrong-code problem with POINTER,
INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Target
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There are quite a few places where we access memory in rejected
statements. This should be a place to gather them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87946
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #9 from Thomas Koenig ---
I think this is a high-priority bug that we should try to fix
before the GCC 9 release.
Some discussion here:
https://gcc.gnu.org/ml/fortran/2019-03/msg00124.html
Jeremy, you mentioned that you commented o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #10 from Thomas Koenig ---
This patch
Index: class.c
===
--- class.c (Revision 269895)
+++ class.c (Arbeitskopie)
@@ -1031,11 +1031,13 @@ finalize_component (gfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #11 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #10)
> This patch
>
> Index: class.c
> ===
> --- class.c (Revision 269895)
> +++ class.c (Arbe
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #26 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #25)
> > If you find anything still missing in the library, please let me know.
> > I thought I had converted everything to the macros, which are fairly
> > eas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #13 from Thomas Koenig ---
With -O2, the combiner takes up quite a lot of time:
$ time gfortran -ftime-report -g0 -O2 -fdefault-integer-8 -c fe_objective.f90
alias stmt walking : 15.75 ( 4%) 0.11 ( 5%) 15.89 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #48 from Thomas Koenig ---
The test case from comment#5 and comment#6 has regressed for M7/8/9:
$ time gfortran-4.8 -O1 gener-4.f90
real0m11.509s
user0m11.356s
sys 0m0.148s
$ time gfortran-7 -O1 gener-4.f90
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #15 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #14)
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01478.html
> might also cure this one, without source I cannot tell.
No, it does not help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #16 from Thomas Koenig ---
A shorter reproducer:
$ cat types-2.f90
module TYPES_MODULE
implicit none
type archive_type
character(2**18) :: root_name
end type archive_type
end module TYPES_MODULE
$ gfortran -c types-2.f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #17 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #16)
> A shorter reproducer:
which results in the assembly file
.file "types-2.f90"
.text
.globl __types_module_MOD___def_init_types_modul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #18 from Thomas Koenig ---
Or see https://gcc.gnu.org/ml/fortran/2019-04/msg2.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #19 from Thomas Koenig ---
Unfortunately, this patch
Index: class.c
===
--- class.c (Revision 269895)
+++ class.c (Arbeitskopie)
@@ -911,6 +911,9 @@ finalize_com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #20 from Thomas Koenig ---
Sometimes life can be easy.
We need to make -fzero-initialized-in-bss the default for
gfortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #21 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #20)
> Sometimes life can be easy.
>
> We need to make -fzero-initialized-in-bss the default for
> gfortran.
Actually, no. I checked with a wrong version of the com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Thomas Koenig changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
--- Comment #3 from Thomas Koenig ---
Reduced test case:
program main
call bar(i)
end program main
subroutine foo
entry bar(i)
end subroutine foo
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Sat Apr 6 14:16:01 2019
New Revision: 270182
URL: https://gcc.gnu.org/viewcvs?rev=270182&root=gcc&view=rev
Log:
2019-04-06 Thomas Koenig
PR fortran/89981
* resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
Thomas Koenig changed:
What|Removed |Added
Summary|[8/9 Regression] gfortran |[8 Regression] gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #15 from Thomas Koenig ---
Author: tkoenig
Date: Sat Apr 6 22:10:28 2019
New Revision: 270184
URL: https://gcc.gnu.org/viewcvs?rev=270184&root=gcc&view=rev
Log:
2019-04-06 Thomas Koenig
PR fortran/87352
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89987
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89987
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904
Thomas Koenig changed:
What|Removed |Added
CC||srinath.parvathaneni at arm
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89939
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89939
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Thu Apr 11 20:14:27 2019
New Revision: 270292
URL: https://gcc.gnu.org/viewcvs?rev=270292&root=gcc&view=rev
Log:
2019-04-11 Thomas Koenig
PR translation/89939
* fron
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89939
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun Apr 14 11:26:18 2019
New Revision: 270350
URL: https://gcc.gnu.org/viewcvs?rev=270350&root=gcc&view=rev
Log:
2019-04-14 Thomas Koenig
Backport from trunk
PR fortran/8998
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Currently, testing libgomp takes a loong time because it lacks parallelization.
It would really help the testing speeds (or keep people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #16 from Thomas Koenig ---
Author: tkoenig
Date: Sun Apr 14 12:17:42 2019
New Revision: 270351
URL: https://gcc.gnu.org/viewcvs?rev=270351&root=gcc&view=rev
Log:
2019-04-14 Thomas Koenig
PR fortran/87352
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #17 from Thomas Koenig ---
Author: tkoenig
Date: Sun Apr 14 12:27:44 2019
New Revision: 270352
URL: https://gcc.gnu.org/viewcvs?rev=270352&root=gcc&view=rev
Log:
2019-04-14 Thomas Koenig
PR fortran/87352
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #18 from Thomas Koenig ---
The quadratic behavior is gone, but the very large stack usage is not
fixed yet.
Looking further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #19 from Thomas Koenig ---
Comment on attachment 44718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44718
Affected module and example main program
The only way at the moment would be to change
program testprog
use testmod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #21 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #19)
> Comment on attachment 44718 [details]
> Affected module and example main program
>
> The only way at the moment would be to change
>
> program testprog
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52307
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35775
--- Comment #3 from Thomas Koenig ---
We now get
$ cat tailcall.c
void bar(void);
void baz(void);
void foo(int a)
{
if (a)
bar();
else
baz();
}
$ gcc -S -Os tailcall.c
$ cat tailcall.s
.file "tailcall.c"
.text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448
--- Comment #9 from Thomas Koenig ---
With current trunk, I get
$ gfortran od.c odopen.f90
$ ./a.out
c_odopen
odopen
unit=8
$ gfortran od.c odopen.f90
$ ./a.out
c_odopen
odopen
unit=8
$
which looks correct.
So, I'm going to commit a te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448
--- Comment #10 from Thomas Koenig ---
Author: tkoenig
Date: Sun Apr 14 20:15:48 2019
New Revision: 270354
URL: https://gcc.gnu.org/viewcvs?rev=270354&root=gcc&view=rev
Log:
2019-04-14 Thomas Koenig
PR fortran/85448
* gfortran.dg/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Fortran statements are translated into trees (as seen with
-fdump-tree-original). I would help if there was a flag which
allowed inspecting values of individual variables and stepping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
Thomas Koenig changed:
What|Removed |Added
Keywords||internal-improvement
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
It would be useful to implement a __builtin_warning function
to delay a warning which may be removed later by dead code
elimination. One application could be PR48655, where
||tkoenig at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #4 from Thomas Koenig ---
With gcc-9, gcc-8 and trunk I get
/tmp/ccyyPrsg.s: Assembler messages:
/tmp/ccyyPrsg.s:121: Error: unrecognized symbol type ""
/tmp/ccyyPrsg.s:121: E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
--- Comment #5 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #4)
> With gcc-9, gcc-8 and trunk I get
To be more precise, with a current gcc-9 snapshot:
$ gfortran -c pr61968.f90
/tmp/ccqFh8vs.s: Assembler messages:
/tmp/ccqFh8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
--- Comment #7 from Thomas Koenig ---
Hmm... some analysis. This is a strange piece of code...
interface
subroutine test_lib (a, len) bind(C, name="test")
use iso_c_binding, only: c_size_t
!GCC$ ATTRIBUTES NO_ARG_CHECK :: a
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #8 from Thomas Koenig ---
Index: interface.c
===
--- interface.c (Revision 270622)
+++ interface.c (Arbeitskopie)
@@ -2989,7 +2989,8 @@
polymorphic formal
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The fix for PR 87689 (ABI violation on POWER) has led to problems
with what some C programs expect as the Fortran calling convention
to be.
It seems that many C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Thomas Koenig changed:
What|Removed |Added
CC||toon at moene dot org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #4 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #3)
> Ooof!
>
> (Just for the record, I don't think we should revert to the previous
> behavior. Whatever we do should be robust in the face of LTO etc.)
I concur.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #6 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Currently, I am leaning towards using an option with a mandatory
> > warning (no way to turn it off) which does
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Came across this when looking at PR 90329. This is with recent trunk.
$ cat foo.f90
subroutine foo() BIND(C)
end subroutine
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat bar.f90
subroutine bar(c,d) BIND(C)
character (len=*) c
character (len=2) d
end
$ ~/Gcc/9-bin/gcc/f951 bar.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #3 from Thomas Koenig ---
(In reply to Paul Thomas from comment #2)
> This is already fixed on my working branch.
>
> This used to be the error message:
>
> Character argument ‘c’ at (1) must be length 1 because procedure ‘bar’ is
>
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #5 from Thomas Koenig ---
Hi Paul,
> I am sure that the array part is OK. Otherwise, why have a type code for
> strings?
It
18.5 The source file ISO_Fortran_binding.h
18.5.1 Summary of contents
The source file ISO_Fortran_bind
1501 - 1600 of 3746 matches
Mail list logo
