https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95918
--- Comment #14 from Thomas Koenig ---
Because the version in bugzilla is set to 10.0, so I assumed it occurred there,
too.
Even better if it is not there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95743
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #3 from Thomas Koenig ---
The problem is in the hash, only a single bit seems to be different:
+++ mod1.f90.004t.original 2020-06-30 07:14:25.582667830 +
@@ -105,7 +105,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
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=96018
--- Comment #7 from Thomas Koenig ---
I can not test at the moment, that will have to wait for a few days.
A general comment:
In Fortran, functions exist to return a value. C-style „return an error status“
fit rather badly to the language, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #8 from Thomas Koenig ---
Comment on attachment 48817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48817
Minimal example to demonstrate the issue.
Hm, I cannot reproduce this because I do not have the hdf5 library
installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29670
Bug 29670 depends on bug 27318, which changed state.
Bug 27318 Summary: gfortran should warn if a interface does not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27318
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #12 from Thomas Koenig ---
I don't have a debuggable source here at the moment, but I think there
may be a problem with implicit_pure, which was either introduced by
a patch in the range that Dominique provided (maybe for PR 85599?),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #13 from Thomas Koenig ---
In the last comment I meant -fdump-fortran-original, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #14 from Thomas Koenig ---
Created attachment 48852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48852&action=edit
Patch which ought to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92913
--- Comment #4 from Thomas Koenig ---
The first part has now been fixed with the fix for PR 27318,
r11-1814-gcc9a9229285a26ac12bc8de53237ce9c4d42f867 .
The second test case, where interfaces are checked vs. interfaces,
subroutine sub_1()
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #3 from Thomas Koenig ---
(In reply to kargl from comment #2)
> I won't comment on the questionable programming idiom of placing
> a common block in a module, which kind of defeats the niceties of
> a module.
If somebody wants to tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #6 from Thomas Koenig ---
What we have here is, in gfc_check_externals0,
(gdb) call debug(def_sym->formal)
|| symbol: '_formal_0'
type spec : (INTEGER 4)
attributes: (VARIABLE ARTIFICIAL DUMMY)
|| symbol: '_formal_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #7 from Thomas Koenig ---
Two things: We should not warn about INTENT mismatches when
we artificially generate the prototypes, and we should set a
valid gfc_locus.
Both done with the attached patch.
diff --git a/gcc/fortran/fronten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #10 from Thomas Koenig ---
... and thanks for the timely bug report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96122
Thomas Koenig changed:
What|Removed |Added
Blocks||37336
--- Comment #3 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998
--- Comment #2 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #1)
> Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
> gfc_typename)?
Yes.
> If yes, AFAIU the code the odd access to gfc_typenam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
Thomas Koenig changed:
What|Removed |Added
Keywords|needs-bisection |patch
--- Comment #15 from Thomas Koenig
|happening in previous |9.2/9.2.1 not happening in
|gfortran versions |previous gfortran versions
Target Milestone|--- |9.4
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
--- Comment #5 from Thomas Koenig ---
A somewhat smaller test case, which of course does nothing useful,
but still reproduces the ICE:
module mo_a
implicit none
type t_b
integer :: n = 0
integer :: nr = 0
character, pointer ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
Thomas Koenig changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #10 from Thomas Koenig ---
(In reply to AJM from comment #8)
> If you really need to know, on the C side there is a struct with fields that
> match the order and size of the variables in the common statement / module
> declaration. I
dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-07-16
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following is not flagged:
DOUBLE PRECISION X (1000)
DOUBLE PRECISION A
INTEGER NCP
NCP = 10
CALL XYZ (NCP, X, X (NCP + 1))
CALL XYZ (NCP, X (NCP+1
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
$ cat foo.f90
module f_global_vars_m
use, intrinsic :: iso_c_binding, sp => c_float, dp => c_double
implicit none
real(dp), bind(c) :: one= 1.0_dp, four= 4.0_dp ! Er
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92628
--- Comment #5 from Thomas Koenig ---
Any progress in this direction? Should we revisit PR 67202
(maybe do this in trans-*), or maybe even it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #49 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #48)
> Forgive me, I wasn't aware of this oversight which may have turned away
> people who could fix this for the past 6 years.
That didn't happen :-)
Unfortunate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #50 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #49)
> The second loop:
>
> .L3:
> leaq8(%rsp), %rdi
> callintent_in_
> movl%ebx, 8(%rsp)
> addl$1, %ebx
> cmpl$12,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96220
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504#c19 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
--- Comment #21 from Thomas Koenig ---
(In reply to Tiziano Müller from comment #19)
> I have yet another (more complicated) case, but this time not reproducible
> with gcc-7.5, only with 9 and 10:
This is a different issue. I have opened PR 96
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
Summary|Reallocation on assignment |[10/11 Regression]
|us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
Target Milestone|9.4 |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
--- Comment #3 from Thomas Koenig ---
Let's see what bisection brings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
Thomas Koenig changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96312
--- Comment #5 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #4)
> so it is likely that this patch just started issuing a warning
> for a pre-existing bug in the front end.
That is indeed the case. Grepping for tmp in the modc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
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=96319
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
What's checked at runtime in do_check_4.f90
PROGRAM test
IMPLICIT NONE
INTEGER :: i
DO i=1,100
CALL do_some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96469
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=96469
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
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=96556
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
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: ---
Created attachment 49095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49095&action=edit
config.log from failed attempt
Current master is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
--- Comment #1 from Thomas Koenig ---
(And yes, I did run contrib/gcc_update)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
--- Comment #2 from Thomas Koenig ---
Checking out master instead of the branch I was on "fixed" things.
So, I guess may just be random timestamps in git, which do not
get updated correctly with contrib/gcc_update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Thomas Koenig ---
The loop
for (a = 20; a; a++) {
increases a, which is a char, beyond its value range, and then tests
against zero.
This is undefined behavior.
N4659
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following program is wrongly rejected. I don't find anything
wrong with it from my reading of the F2018 sta
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following two programs are functionally equivalent:
$ cat v1.f90
program main
implicit none
integer, parameter :: ip = selected_int_kind(15)
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97181
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
--- Comment #1 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
CC||koenigni at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84613
Bug 84613 depends on bug 84487, which changed state.
Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 84487, which changed state.
Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #5 from Thomas Koenig ---
Still having no luck trying to find out which patch made this
error not appear on trunk. I think this may actually depend
on the version of the bootstrapping compiler :-(
In the meantime, here is the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
Component|fortran |middle-end
Summary|[8 regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #7 from Thomas Koenig ---
I had thought that this patch
Index: trans-decl.c
===
--- trans-decl.c(Revision 277486)
+++ trans-decl.c(Arbeitskopie)
@@ -1911
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92133
--- Comment #4 from Thomas Koenig ---
Author: tkoenig
Date: Sun Nov 3 22:33:53 2019
New Revision: 277760
URL: https://gcc.gnu.org/viewcvs?rev=277760&root=gcc&view=rev
Log:
2019-11-03 Thomas Koenig
PR fortran/92133
* trans-decl.c (gf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Mon Nov 4 07:39:21 2019
New Revision: 277766
URL: https://gcc.gnu.org/viewcvs?rev=277766&root=gcc&view=rev
Log:
2019-11-04 Thomas Koenig
PR fortran/92113
* ChangeLog: Fix P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92133
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #9 from Thomas Koenig ---
https://gcc.gnu.org/viewcvs?rev=277760&root=gcc&view=rev should have been for
this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361
--- Comment #3 from Thomas Koenig ---
Fortran has no concept of a varargs call. It is an error to call a procedure
with
a different number or type of arguments (unless there is an explicit interface
and the dummy arguments are optional or ...). S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92361
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=92321
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Sat Nov 9 14:54:19 2019
New Revision: 278003
URL: https://gcc.gnu.org/viewcvs?rev=278003&root=gcc&view=rev
Log:
Commit symbol for external BLAS routine when translating MATMUL to *GEMM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321
Thomas Koenig changed:
What|Removed |Added
Summary|[9/10 Regression] GCC 9.2.0 |[9 Regression] GCC 9.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321
--- Comment #7 from Thomas Koenig ---
Author: tkoenig
Date: Sun Nov 10 09:34:42 2019
New Revision: 278014
URL: https://gcc.gnu.org/viewcvs?rev=278014&root=gcc&view=rev
Log:
Commit symbol for external BLAS routine when translating MATMUL to *GEMM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92321
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #10 from Thomas Koenig ---
Author: tkoenig
Date: Sun Nov 10 11:19:13 2019
New Revision: 278015
URL: https://gcc.gnu.org/viewcvs?rev=278015&root=gcc&view=rev
Log:
Put vtab into RO section, same for __def_init if it contains an initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Sun Nov 10 12:07:56 2019
New Revision: 278018
URL: https://gcc.gnu.org/viewcvs?rev=278018&root=gcc&view=rev
Log:
Put vtab into RO section, same for __def_init if it contains an initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #7 from Thomas Koenig ---
(In reply to anlauf from comment #6)
> Something like the following fixes the testcase, but leads to regressions
> elsewhere in the testsuite (e.g. direct_io_{9,10}.f):
You've found the right spot, I think.
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #8 from Thomas Koenig ---
Hope you don't mind if I take this.
||2019-11-23
CC||tkoenig at gcc dot gnu.org
Target Milestone|9.4 |9.3
Summary|[Regression 9] Warning with |[9 Regression] Warning with
|character and optimisation |character and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sat Nov 23 15:19:19 2019
New Revision: 278647
URL: https://gcc.gnu.org/viewcvs?rev=278647&root=gcc&view=rev
Log:
Add test case for PR 92442.
2019-11-23 Thomas Koenig
PR for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2018-01-05 00:00:00 |2019-11-24
--- Comment #6 from Thomas Ko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #22 from Thomas Koen
||tkoenig at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #11 from Thomas Koenig ---
(In reply to Lionel GUEZ from comment #10)
> (In reply to kargl from comment #9)
> > Fortran 2018 has declared FORALL to be an obsolescent featu
||2019-11-24
CC||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
||2019-11-24
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Maybe "bad code" isn't such a bad description of this...
I wonder if people would comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #10 from Thomas Koenig ---
Author: tkoenig
Date: Sun Nov 24 19:16:23 2019
New Revision: 278659
URL: https://gcc.gnu.org/viewcvs?rev=278659&root=gcc&view=rev
Log:
Fix EOF handling for arrays.
2019-11-23 Thomas Koenig
Haral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
Thomas Koenig changed:
What|Removed |Added
Target Milestone|10.0|8.4
Summary|[8/9/10 Regressio
201 - 300 of 3746 matches
Mail list logo
