https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #9 from Thomas Koenig ---
The segfault occurs at
35res => c_()
according to gdb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #8 from Thomas Koenig ---
Stepping through the assembly, the segfaulting instruction is
"blr x3", which jumps to a NULL pointer, with predictable results:
│165 // proc_ptr_51.f90:30: end module f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
--- Comment #7 from Thomas Koenig ---
Created attachment 46475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46475&action=edit
Assembly for test case on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #28 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #27)
> >
> > I think that's reasonably easy to do for LTO. We'd want to keep
> > the default boolean_type_node size BOOLEAN_TYPEs separate but
> > can glob larger ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #5 from Thomas Koenig ---
(In reply to ktkachov from comment #4)
> LTO'ing libgfortran aside, how much work would it be to teach the scalarizer
> to at least elide the temporary arrays in expressions like:
> A(:) = minloc(...) ?
> I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sat Jun 8 13:50:42 2019
New Revision: 272082
URL: https://gcc.gnu.org/viewcvs?rev=272082&root=gcc&view=rev
Log:
2019-06-08 Thomas Koenig
Tomáš Trnka
PR fortran/90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #6 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Good analysis, and this is indeed the correct fix.
>
> OK. I thought that perhaps get_formal_from_actual_arglist()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744
--- Comment #4 from Thomas Koenig ---
(In reply to Tomáš Trnka from comment #3)
> I'm not sure how to fix this properly, but the following one-liner seems to
> work for me:
>
> --- a/gcc/fortran/trans-types.c
> +++ b/gcc/fortran/trans-types.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #25 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #24)
> Hi,
> actually it won't help since C has only one bool type and not bools in
> different sizes (why would one need that?).
"Because it's in the Fortran language
||2019-06-05
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
I see this too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #21 from Thomas Koenig ---
(In reply to Jan Hubicka from comment #20)
> OK, the mismatched declaration types are:
> void (struct array01_integer(kind=4) &, float & restrict,
> logical(kind=4) *)
> and
> void (struct gfc_array_i4 * r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #19 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #15)
Btw, I wonder what happens at
> the call boundary inside a single fortran module where
> the caller passes a dim[2] array to a subroutine
> handling arbitra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #18 from Thomas Koenig ---
Created attachment 46451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46451&action=edit
Preprocessed source of library file for LTO mismatch
Hi,
here is a test case (preprocessed source from libgfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #12 from Thomas Koenig ---
In libgfortran, we have
#define GFC_ARRAY_DESCRIPTOR(type) \
struct {\
type *base_addr;\
size_t offset;\
dtype_type dtype;\
index_type span;\
descriptor_dimension dim[];\
}
and then later
typede
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #9 from Thomas Koenig ---
Created attachment 46446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446&action=edit
LTO tree dump from simple test case
So, I tried out a simple program:
$ cat minloc.f90
program main
real, di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #6 from Thomas Koenig ---
So, I played around with this a little. By putting in
-flto and -ffat-lto-binaries into CFLAGS, FFLAGS and LDFLAGS
into the Makefile in the libgfortran build directory, it is
possible to build an LTO-enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
--- Comment #5 from Thomas Koenig ---
One thing we would also have to tackle is GFC_LOGICAL arguments.
C only has one bool type, which is (for gcc) equivalent to
logical(kind=1). We might just get by with
typedef enum { _zero=1, _one=1 } GFC_L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #50 from Thomas Koenig ---
Author: tkoenig
Date: Sun Jun 2 15:18:22 2019
New Revision: 271844
URL: https://gcc.gnu.org/viewcvs?rev=271844&root=gcc&view=rev
Log:
2019-06-02 Thomas Koenig
PR fortran/90539
* trans-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||2019-06-01
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Another, not mutually exclusive approach would be to make libgfortran LTO
clean so the more complex minloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #47 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #46 from Thomas Koenig ---
Let's see if the failures go away (they should) and also what the
performance impact is now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #45 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 29 20:30:45 2019
New Revision: 271751
URL: https://gcc.gnu.org/viewcvs?rev=271751&root=gcc&view=rev
Log:
2019-05-29 Thomas Koenig
PR fortran/90539
* gfortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Keywords||patch, wrong-code
--- Comment #44 from T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46427|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #41 from Thomas Koenig ---
Just noticed that this causes a regression in
gfortran.fortran-torture/execute/arrayarg.f90 , but only at certain
optimization levels.
Oh well... need to look some more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Attachment #46420|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #38 from Thomas Koenig ---
So, I finally have a self-contained test case:
module t2
implicit none
contains
subroutine foo(a)
real, dimension(*) :: a
end subroutine foo
end module t2
module t1
use t2
implicit none
contai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #37 from Thomas Koenig ---
Hm, with that patch, there still seems to be a failure in netcdf :-(
I will keep looking (possibly some small problem with the patch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #36 from Thomas Koenig ---
... which should be
Index: testsuite/gfortran.dg/internal_pack_21.f90
===
--- testsuite/gfortran.dg/internal_pack_21.f90 (Revision 271629)
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #35 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #34)
> Created attachment 46420 [details]
> Patch which includes a check for being contiguous
>
> This patch looks like it could do the job. I'll have to work a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #34 from Thomas Koenig ---
Created attachment 46420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46420&action=edit
Patch which includes a check for being contiguous
This patch looks like it could do the job. I'll have to wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #32 from Thomas Koenig ---
Hi Martin,
this
3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
looks like the culprit (or rather, where gfortran currently
generates wrong code). This is consistent with the problem seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #30 from Thomas Koenig ---
Hi,
what I mean is if you use "up" several times and list the
source of the calling routines, do you encounter something like
call foo([1.0, 2.0, 3.0, 4.0])
or
call foo((/1.0, 2.0, 3.0, 4.0/))
?
Th
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #28 from Thomas Koenig ---
https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports
the same symptoms for netcdf-fortran-4.4.5, presumably due
to the same issue.
I'll try to fix that one and then see if the SPEC fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|Boostrap failure
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #26 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 26 14:02:51 2019
New Revision: 271630
URL: https://gcc.gnu.org/viewcvs?rev=271630&root=gcc&view=rev
Log:
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #22 from Thomas Koenig ---
I've been trying out some things, and I cannot construct a failing
test case.
A sane way to build such an interface would be
cat tst.f90
module x
use, intrinsic :: iso_c_binding, only : c_double
impli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #21 from Thomas Koenig ---
OK, if the callee is a C function... what is its declaration
on the Fortran side? Is there any interface, bind(c) or otherwise?
I suppose there must be something, otherwise nf_put_vara_double would
have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #19 from Thomas Koenig ---
Thanks.
A bit more:
What are the declarations of the actual srgument,
of the dummy argument (on the callee side),
and what is the argument in the call list?
Ill try to construct a test case tonight then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #16 from Thomas Koenig ---
Hi Martin,
Is this for the slowdown or for the wrong-code issue?
To get another view, from a gdb seesion of the compiler:
call debug(expr)
call debug(fsym)
a look at expr->symtree->n.sym (I think call de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #13 from Thomas Koenig ---
I'm afraid the tree dumps will not help a lot - I know what they
look like before and after, but I don't know what is wrong with it.
I would therefore ask you to reduce the test case, maybe starting
with th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90563
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.4
Summary|[9/10 Regression]
||2019-05-21
CC||tkoenig at gcc dot gnu.org
Resolution|DUPLICATE |---
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Summary|Out of bounds error when|[9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #3 from Thomas Koenig ---
I think I have an idea what might be the problem.
Does the code do something like
call foo(a)
...
subroutine foo(a)
real, dimension(:) :: a
call bar(a,size(n))
...
subroutine bar
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #2 from Thomas Koenig ---
I am a bit surprised at this, that the library version
of packing seems to be faster than the inlined one.
Or maybe some argument is now packed which should not be.
Increased code size is sort of expected,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #9 from Thomas Koenig ---
Hi Steve,
what I meant is that
Program main
Integer(kind=1) :: n
n = 1
End
should not warn with -fno-range-check -Wall, and it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #2 from Thomas Koenig ---
Hm, another question: Which gfortran version do you use?
If your version is _really_ old, it might not yet have
the -Wno-conversion flag.
||2019-05-19
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
With your test case, I get
$ gfortran a.f90
a.f90:32:24:
32 | byte b2 / '
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #7 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #5)
> > Any need for a new test on top of those included in the revision?
>
> PING!
I c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 11:26:20 2019
New Revision: 271379
URL: https://gcc.gnu.org/viewcvs?rev=271379&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/78290
* gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 11:24:17 2019
New Revision: 271378
URL: https://gcc.gnu.org/viewcvs?rev=271378&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/88821
* ChangeLog: Add f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294
Thomas Koenig changed:
What|Removed |Added
Resolution|FIXED |INVALID
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #9 from Thomas Koenig ---
(In reply to Fred Krogh from comment #8)
> My apologies for posting this. In my original code the program just quit at
> the point of the test. I tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 10:21:06 2019
New Revision: 271377
URL: https://gcc.gnu.org/viewcvs?rev=271377&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/88821
* expr.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #36 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 19 08:22:41 2019
New Revision: 271376
URL: https://gcc.gnu.org/viewcvs?rev=271376&root=gcc&view=rev
Log:
2019-05-19 Thomas Koenig
PR fortran/90329
* invoke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #30 from Thomas Koenig ---
Hi Jakub,
> Untested workaround that isn't a too big hammer. This should just avoid
> tail calls in functions where the hidden string arguments for
> character(len=constant) dummy arguments are passed part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968
--- Comment #9 from Thomas Koenig ---
Author: tkoenig
Date: Fri May 10 20:14:22 2019
New Revision: 271076
URL: https://gcc.gnu.org/viewcvs?rev=271076&root=gcc&view=rev
Log:
2019-05-10 Thomas Koenig
PR fortran/61968
* interface.c (com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #24 from Thomas Koenig ---
Author: tkoenig
Date: Thu May 9 17:40:30 2019
New Revision: 271038
URL: https://gcc.gnu.org/viewcvs?rev=271038&root=gcc&view=rev
Log:
2019-05-09 Thomas Koenig
Backport from trunk
PR fortran/903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Thu May 9 17:40:30 2019
New Revision: 271038
URL: https://gcc.gnu.org/viewcvs?rev=271038&root=gcc&view=rev
Log:
2019-05-09 Thomas Koenig
Backport from trunk
PR fortran/9035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Thomas Koenig changed:
What|Removed |Added
See Also||https://github.com/Referenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #22 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 8 21:55:13 2019
New Revision: 271018
URL: https://gcc.gnu.org/viewcvs?rev=271018&root=gcc&view=rev
Log:
2019-05-08 Thomas Koenig
PR fortran/90351
PR fortran/90329
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
--- Comment #1 from Thomas Koenig ---
Author: tkoenig
Date: Wed May 8 21:55:13 2019
New Revision: 271018
URL: https://gcc.gnu.org/viewcvs?rev=271018&root=gcc&view=rev
Log:
2019-05-08 Thomas Koenig
PR fortran/90351
PR fortran/90329
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 14:01:51 2019
New Revision: 270883
URL: https://gcc.gnu.org/viewcvs?rev=270883&root=gcc&view=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
* frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 13:53:24 2019
New Revision: 270882
URL: https://gcc.gnu.org/viewcvs?rev=270882&root=gcc&view=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
* gfortran.
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
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
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
>
: 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
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
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
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
Thomas Koenig changed:
What|Removed |Added
CC||toon at moene dot org
--- Comment #1 fro
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
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
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
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
||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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90237
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
Thomas Koenig changed:
What|Removed |Added
Keywords||internal-improvement
Target Milestone|
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=85448
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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=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=52307
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1001 - 1100 of 3598 matches
Mail list logo
