https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
Thomas Koenig changed:
What|Removed |Added
Keywords||diagnostic, needs-stdcheck
--- Comment
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=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=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=119049
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
|enhancement
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119078
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2025-03-08
Ever confirmed|0
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=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=119078
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|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
dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2025-02-27
Status|UNCONFIRMED |ASSIGNED
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
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).
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 #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=118862
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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 #7 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 ---
||tkoenig at gcc dot gnu.org
--- Comment #9 from Thomas Koenig ---
Still current...
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=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
--- 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
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
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,
||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=118845
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
--- 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
--- 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=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=102368
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|needs-stdcheck
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=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=109322
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Thomas Koenig
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=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=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
Thomas Koenig changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Ever conf
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=119928
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
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
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=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=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=120163
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=120139
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
3701 - 3756 of 3756 matches
Mail list logo
