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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107266
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
|--- |FIXED
CC||tkoenig at gcc dot gnu.org
--- Comment #6 from Thomas Koenig ---
Yes, this is fixed. I think we can close this.
||32630
CC||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
(In reply to Tobias Burnus from comment #6)
> (In reply to sandra from comment #5)
> > Jose's test case for this issue is still failing.
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84591
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #7 from Thomas Koenig ---
Seems to be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #36 from Thomas Koen
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Thomas Koenig ---
Fixed with the commit, I'd say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116829
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #13 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
|RESOLVED
CC||tkoenig at gcc dot gnu.org
--- Comment #5 from Thomas Koenig ---
Closing, then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118862
--- Comment #7 from Thomas Koenig ---
Created attachment 60505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60505&action=edit
Patch that should fix the issue
I think the attached patch, based on Jakub's patch, should fix the
issue. I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
Thomas Koenig changed:
What|Removed |Added
Blocks||63426
Target|
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I wanted to build a usbsan checking compiler on a big machine, and ran
../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran
--with-build-config=bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #10 from Thomas Koenig ---
Fixed with r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #9 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #8)
> Hmm.. .the type should not be BT_UNKNOWN.
>
> Reduced test caes:
>
> SUBROUTINE CGET24
> EXTERNAL CSLECT
> LOGOCAL CSLECT
>
> CALL CGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #8 from Thomas Koenig ---
Hmm.. .the type should not be BT_UNKNOWN.
Reduced test caes:
SUBROUTINE CGET24
EXTERNAL CSLECT
LOGOCAL CSLECT
CALL CGEESX(CSLECT)
IF (CSLECT() KNTEIG = KNTEIG + 1
CALL
||2025-02-15
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #7 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #6)
> I forgot to mention this is a good hint for Thomas regarding how to tweak
> the previous fix.
Yes, if the argument is of unknown type, the test can be skipped,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118862
--- Comment #6 from Thomas Koenig ---
> I'll take a look.
Found it, will probably submit tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118862
--- Comment #5 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #4)
> Completely untested.
This regresses in unsigned_43.f90, on the test case
unsigned(kind=1) :: x, r1, r2, r3, r4
unsigned(kind=1) :: n
x = 0u_1
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #3 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #1)
> Most likely this code should be using wide_int instead of HOST_WIDE_INT here.
> To support 128 bit integers.
>
> I suspect this could cause wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
--- Comment #9 from Thomas Koenig ---
Should be fixed by
https://gcc.gnu.org/g:cdb4d27a4c2786cf1b1b0eb1872eac6a5f931578
(I'll wait for closing this until it is confirmed that Lapack
builds again).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
--- Comment #8 from Thomas Koenig ---
This works:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index fdde84db80d..eee5520ad93 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -5822,7 +5822,14 @@ gfc_ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118845
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=96909
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97123
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96909
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
||tkoenig at gcc dot gnu.org,
||vehre at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
Works on master now, I suspect as a result of Andre's recent work.
Can we close this?
1 - 100 of 3745 matches
Mail list logo
