https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121466
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
Thomas Koenig changed:
What|Removed |Added
CC||dml2011 at free dot fr
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121466
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
Thomas Koenig changed:
What|Removed |Added
Keywords|needs-stdcheck |
--- Comment #28 from Thomas Koenig --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-stdcheck
--- Comment #26 from Tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #25 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #24)
> On Thu, 17 Jul 2025, anlauf at gcc dot gnu.org wrote:
> > So if FOO is a wrapper subroutine that calls MPI_I*, one needs to find all
> > of them in the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #18 from Thomas Koenig ---
(In reply to Richard Biener from comment #17)
> I had the impression we are talking about a legacy (F77) code base here and
> we need to honor the constraints of that language. That means limited ways
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #15 from Thomas Koenig ---
(In reply to anlauf from comment #14)
> (In reply to Thomas Koenig from comment #13)
> > I think we have quite a few bad choices here, each with different drawbacks.
> > I don't think we should do nothing,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #13 from Thomas Koenig ---
I think we have quite a few bad choices here, each with different drawbacks.
I don't think we should do nothing, or pessimize existing code.
Hmm... what about adding an option which sets ASYNCHRONOUS on ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121047
--- Comment #2 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #1)
> This is most likely a won't fix. Do you if there is an errata issued for
> this yet?
I haven't seen anything that addresses that. This may or may not be
covered
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There is a blog post at
https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-intel-13th-14th-gen-cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
--- Comment #4 from Thomas Koenig ---
I reran the tests on current trunk and did not see the
poly-int failure. Maybe it was fixed in the meantime.
Here are the failures that I am seeing now, with current trunk (duplicates
removed):
./../trunk/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120609
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120691
--- Comment #3 from Thomas Koenig ---
Hm, strange.. I get
x1/x2 %DDf
This is with
GNU C Library (Ubuntu GLIBC 2.39-0ubuntu8.4) stable release version 2.39.
with
gcc (GCC) 16.0.0 20250530 (experimental)
Unrelated / configuration error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2025-05-31 00:00:00 |2025-6-13
Known to fail|16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
--- Comment #4 from Thomas Koenig ---
Looking at
$ cat save.f90
program memain
implicit none
character(len=:), allocatable, save :: s1
s1 = 'ABC'
if (s1(3:3) /= 'C') stop 1
end program memain
$ cat nosave.f90
program memain
implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Thomas Koenig changed:
What|Removed |Added
Summary|[15/16 Regression] |[15/16 Regression]
|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Thomas Koenig changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
--- Comment #5 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #4)
> You mean before 15.2? I guess I could.
Yes, before 15.2 :-)
Please do, it would be appreciated to have better debugging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355
Thomas Koenig changed:
What|Removed |Added
Summary|[15/16 Regression] Type |[15 Regression] Type
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #2 from Thomas Koenig ---
I am AFK this week, will look at this next week. Thanks for the workaround,
Harald, this makes it quite clear what is going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There is currently no way of testing the output of -fc-prototypes and
-fc-prototypes-external, which makes it much easier for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119928
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163
--- Comment #2 from Thomas Koenig ---
Patch at https://gcc.gnu.org/pipermail/fortran/2025-May/062123.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93563
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669
--- Comment #6 from Thomas Koenig ---
Created attachment 61066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61066&action=edit
Patch which sets the function attribute
This should fix the issue.
I am actually not quite sure if the new er
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #4 from Thomas Koenig ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119419
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119419
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211
--- Comment #6 from Thomas Koenig ---
(In reply to Sam James from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Added PR 119308, "Hello World" does not work on Power.
>
> I don't consider that a release blocker, personally, as i
||tkoenig at gcc dot gnu.org
--- Comment #4 from Thomas Koenig ---
Added PR 119308, "Hello World" does not work on Power.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
[Bug 119308] Cobol ICE on "hello world" on POWER in
rs6000_output_function_epilogue
ty: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Thought I'd give gcobol a spin on POWER.
For the "Hello, world" program faithfully copied from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
--- Comment #3 from Thomas Koenig ---
And a dummy argument should not be global, either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2025-03-08
Ever confirmed|0
|enhancement
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119074
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119049
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
Thomas Koenig changed:
What|Removed |Added
Summary|ice in |[15 Regression] ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
--- Comment #5 from Thomas Koenig ---
Reduced test case:
MODULE lmdif_module
CONTAINS
SUBROUTINE fdjac2 (fcn, m, n, x, fvec, fjac, ldfjac, iflag, &
epsfcn, wa)
END SUBROUTINE fdjac2
SUBROUTINE lmdif (fcn, m, n,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119074
--- Comment #3 from Thomas Koenig ---
Maybe a warning is in order (under control of a
suitable variable).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119074
--- Comment #2 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #1)
> Hmm... an interesting question:
>
> Does
>
> subroutine foo(f,n)
> external f
> if (n .eq. 1) call f(1)
> if (n .eq. 2) call f(1,2)
> end
>
> comply?
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119074
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-stdcheck
--- Comment #1 from Thom
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2025-03-02
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
Thomas Koenig changed:
What|Removed |Added
Keywords||diagnostic, needs-stdcheck
--- Comment
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
module x
abstract interface
subroutine foo() bind(c)
end subroutine foo
end interface
end module x
subroutine foo(a)
real
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Looking at PR119049, it surprised me that we do not have a formal
argument list check for
subroutine foo (f)
external :: f
dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2025-02-27
Status|UNCONFIRMED |ASSIGNED
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Original test case by Jürgen Bausa.
The following cases are mishandled with -fc-prototypes-external:
SUBROUTINE FCN (JAC)
EXTERNAL JAC
INTEGER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #13 from Thomas Koenig ---
(In reply to anlauf from comment #12)
> So what now?
>
> Ask J3 for an opinion?
Why not?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #8 from Thomas Koenig ---
(In reply to anlauf from comment #7)
> (In reply to Thomas Koenig from comment #6)
> > I think the code is valid.
> >
> > A named scalar Fortran variable is interoperable if and only if its type and
> > typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|needs-stdcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #8 from Thomas Koenig ---
... or rather, the calculation needs to be done with the
contents of x->_data and not with x directly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #7 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #6)
After looking at the tree dump and some debugging, it is clear that
the error happens on the callee side.
If the callee has a type as dummy argument, it has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #5 from Thomas Koenig ---
The discussion on the J3 mailing list seems to indicate that
this is actually invalid, but nobody else catches it
(and the restriction is also silly).
Maybe we should just downgrade the error to a warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #4 from Thomas Koenig ---
Hm, maybe I am misunderstanding the standard here, or it says something
that was not intentional...
We accept
program memain
interface
subroutine lower () bind(c,name="foo")
end subroutine lowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Thomas Koenig changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Ever conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #1 from Thomas Koenig ---
> Since vector
> functions can have much larger ULP errors, using them by default with -O2
> seems excessive.
"can have"? Is this indeed the case? I would consider this to be
a bug in the implementation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #10 from Thomas Koenig ---
What does the OpenMP standard say about I/O in partallel exexution?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #6 from Thomas Koenig ---
This bug depends on the dummy argument being a class.
Here's a somewhat shortened version:
program simple
implicit none
type :: matrix
integer :: nRows
end type matrix
type(matrix),dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 113997, which changed state.
Bug 113997 Summary: Bogus 'Warning: Interface mismatch in global procedure'
with C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #12 from Thomas Koenig ---
One additional point. Using -fdump-fortran-original on
the original test case, one finds
symtree: 'Bar' || symbol: 'bar'
type spec : (UNKNOWN 0 C_INTEROP)
attributes: (DERIVED P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #2 from Thomas Koenig ---
(In reply to Richard Biener from comment #1)
> Is that with --enable-maintainer-mode?
Yes (they would not be written out otherwise).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84386
--- Comment #4 from Thomas Koenig ---
(In reply to kargls from comment #3)
> Perhaps, you have a local change in your git repository.
I just compiled the wrong test case, that's all :-)
||tkoenig at gcc dot gnu.org
Component|fortran |tree-optimization
--- Comment #5 from Thomas Koenig ---
Maybe a middle end problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84386
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
||tkoenig at gcc dot gnu.org
Keywords|accepts-invalid |diagnostic
Severity|normal |enhancement
--- Comment #5 from Thomas Koenig ---
The code is invalid, but hard to diagnose (and it is
not a constraint).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66182
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2015-08-30 00:00:00 |2025-2-17
--- Comment #3 from Thomas Koe
||tkoenig at gcc dot gnu.org
--- Comment #9 from Thomas Koenig ---
Still current...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45057
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2010-08-06 21:21:08 |2025-2-17
--- Comment #1 from Thomas Koe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-stdcheck
--- Comment #9 from Thom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
Thomas Koenig changed:
What|Removed |Added
Keywords|needs-stdcheck |
--- Comment #8 from Thomas Koenig ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-stdcheck
--- Comment #7 from Thom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 118862, which changed state.
Bug 118862 Summary: UBSAN: shift exponent too large since
r15-7345-gc2a0ee58865c5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118862
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118862
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
--- Comment #15 from Thomas Koenig ---
(In reply to john.harper from comment #14)
> The comma between A and F is still required by F2023 constraint C1302,
> and gfortran 14.2.0 still compiles and runs the test program omitting it
> even if the -s
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2025-02-16
Ever confirmed|0 |1
CC||tkoenig at gcc dot gnu.org
Blocks||32630
1 - 100 of 3780 matches
Mail list logo
