https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #8 from Jürgen Reuter ---
(In reply to anlauf from comment #7)
> (In reply to Jürgen Reuter from comment #6)
> > Created attachment 59993 [details]
> > Reproducer
>
> Thanks for the reproducer. I can confirm the ICE after r15-6408,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #6 from Jürgen Reuter ---
Created attachment 59993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59993&action=edit
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #5 from Jürgen Reuter ---
Here is the reproducer:
module lexers
implicit none
private
public :: lexer_t
public :: lexer_init
type :: keyword_list_t
private
end type keyword_list_t
type :: lexer_t
private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #3 from Jürgen Reuter ---
Thanks for the quick action. I will be back at a computer on the 27th. Then I
will
report a reproducer and test the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
Bug ID: 118179
Summary: [15.0 regression] ICE in gimplify
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
--- Comment #10 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #9)
> Thanks for your forebearance, Juergen. Not only is the regression fixed but
> a much better fix for PR84674 has resulted.
>
> Regards
>
> Paul
Thanks, Paul, ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
--- Comment #7 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #6)
> (In reply to Paul Thomas from comment #5)
> > Created attachment 59711 [details]
> > Fix for this PR
>
> Hi Juergen,
>
> Are you in a position to check this patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #17 from Jürgen Reuter ---
(In reply to GCC Commits from comment #16)
> The master branch has been updated by Paul Thomas :
>
> https://gcc.gnu.org/g:8278d9551df610179fca114808a7e6e62bab3d82
>
> commit r15-5674-g8278d9551df610179fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #15 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #14)
> (In reply to Jürgen Reuter from comment #13)
> > (In reply to Paul Thomas from comment #12)
> > > Created attachment 59694 [details]
> > > Fix for this PR
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
--- Comment #3 from Jürgen Reuter ---
Potential commits that introduced the regression:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=dd6dbbb5111fba960ad0ee7999a225783e0ae80e
(deals with overridable procedures)
https://gcc.gnu.org/git/?p=gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
--- Comment #2 from Jürgen Reuter ---
Here is the reproducer:
module m1
implicit none
private
public :: t1
type, abstract :: t1
end type t1
end module m1
module t_base
use m1, only: t1
implicit none
private
public :: t_t
ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
--- Comment #1 from Jürgen Reuter ---
Created attachment 59696
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59696&action=edit
Reproducer, 70 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #13 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #12)
> Created attachment 59694 [details]
> Fix for this PR
>
> Hi Juergen and Harald,
>
> Mea culpa once again! @Harald: Your pin pointing with the .diff allowed me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #11 from Jürgen Reuter ---
(In reply to anlauf from comment #9)
> The shortened reproducer fails for me at runtime not only on 15-trunk, but
> on 14-branch too, and with same backtrace, so if we have a regression,
> it should be on 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768
Bug ID: 117768
Summary: [15.0 regression] ICE in diagnostic_impl (?)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
Jürgen Reuter changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #4 from Jürgen Reuter ---
There are two left-over use statements for modules parser and variables which
need to be taken out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #3 from Jürgen Reuter ---
Comment on attachment 59688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59688
Shorter reproducer
>module iso_varying_string
> implicit none
> integer, parameter, private :: GET_BUFFER_LEN = 1
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #2 from Jürgen Reuter ---
This is a shorter reproducer:
1 module iso_varying_string
2implicit none
3integer, parameter, private :: GET_BUFFER_LEN = 1
4
5type, public :: varying_string
6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #1 from Jürgen Reuter ---
Created attachment 59688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59688&action=edit
Shorter reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
Bug ID: 117763
Summary: [15.0 regression] segmentation fault through
allocatable char arrays (?)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117664
--- Comment #2 from Jürgen Reuter ---
(In reply to Sam James from comment #1)
> GCC trunk now defaults to -std=gnu23. C23 removes unprototyped functions, so
> `void foo()` now means `void foo(void)`.
Thanks, Sam, for the immediate reply. Is tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117664
Bug ID: 117664
Summary: [15 regression] incompatible pointer type
[-Wincompatible-pointer-types]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86468
--- Comment #12 from Jürgen Reuter ---
(In reply to Andre Vehreschild from comment #11)
> Patch proposed: https://gcc.gnu.org/pipermail/fortran/2024-August/060882.html
> Waiting for review.
Hi Andre,
great to see you back in action for gcc/gfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
--- Comment #3 from Jürgen Reuter ---
Oops, sorry, I had to hurry and closed the laptop. I didn't think that the
issue got already submitted. Here is the reproducer.
gfortran -c state_matrices.f90
state_matrices.f90:76:23:
76 | t2 = t3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
--- Comment #2 from Jürgen Reuter ---
Created attachment 58703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58703&action=edit
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
Bug ID: 115983
Summary: ICE on valid code in gfc_is_nodesc_array, at
fortran/trans-types.cc:
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #28 from Jürgen Reuter ---
Richard, unfortunately the fix (it seems it was committed to gcc git master on
last Friday) did not fix our problem yet. The original test case still
segfaults:
Backtrace for this error:
#0 0x7f36f52a3a6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #27 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #26)
> (In reply to Richard Biener from comment #24)
> > (In reply to Jürgen Reuter from comment #23)
> > > Created attachment 58486 [details]
> > > Shorter reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #26 from Jürgen Reuter ---
(In reply to Richard Biener from comment #24)
> (In reply to Jürgen Reuter from comment #23)
> > Created attachment 58486 [details]
> > Shorter reproducer
> >
> > This is a shorter reproducer, two files of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #25 from Jürgen Reuter ---
(In reply to Richard Biener from comment #24)
> (In reply to Jürgen Reuter from comment #23)
> > Created attachment 58486 [details]
> > Shorter reproducer
> >
> > This is a shorter reproducer, two files of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #23 from Jürgen Reuter ---
Created attachment 58486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58486&action=edit
Shorter reproducer
This is a shorter reproducer, two files of a few hundred lines each. It seems
that the pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #19 from Jürgen Reuter ---
Created attachment 58476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58476&action=edit
First independent reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #17 from Jürgen Reuter ---
(In reply to Richard Biener from comment #16)
> (In reply to Jürgen Reuter from comment #15)
> > I fund the culprit commit in the gcc master, it is:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #15 from Jürgen Reuter ---
I fund the culprit commit in the gcc master, it is:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1fe55a1794863b5ad9eeca5062782834716016b2
by Richard Biener on the tree-optimization. Now I will try helping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #14 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #13)
> The daily bump in the morning of Friday, June 14,
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=028cd77db322d21312680c9a0a7c30565854f577
> shows the segm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #13 from Jürgen Reuter ---
The daily bump in the morning of Friday, June 14,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=028cd77db322d21312680c9a0a7c30565854f577
shows the segmentation fault, so the culprit comment must have happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #11 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #10)
> (In reply to Jürgen Reuter from comment #9)
> > Also at the daily bump shortly after midnight morning of June 11,
> > https://gcc.gnu.org/git/?p=gcc.git;a=comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #10 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #9)
> Also at the daily bump shortly after midnight morning of June 11,
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=097bc0aebaed58c11c738ea61da723cca950e5b1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #9 from Jürgen Reuter ---
Also at the daily bump shortly after midnight morning of June 11,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=097bc0aebaed58c11c738ea61da723cca950e5b1
the reproducer still runs fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #8 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #6)
> (In reply to kargls from comment #5)
> > (In reply to Jürgen Reuter from comment #4)
> > > Created attachment 58462 [details]
> > > Input file that triggers the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #7 from Jürgen Reuter ---
First data point:
after the commit from Uros,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8bb6b2f4ae19c3aab7d7a5e5c8f5965f89d90e01
at Sun, 9 Jun 2024 10:09:13
all was still fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #6 from Jürgen Reuter ---
(In reply to kargls from comment #5)
> (In reply to Jürgen Reuter from comment #4)
> > Created attachment 58462 [details]
> > Input file that triggers the test case with segmentation fault
> >
> > This test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #4 from Jürgen Reuter ---
Created attachment 58462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58462&action=edit
Input file that triggers the test case with segmentation fault
This test case needs Whizard 3.1.4 to be downlo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
--- Comment #2 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #1)
> what options are you using to compile the source?
> Does it work at -O0?
You are right: the problem doesn't appear for -O0. Our defaults are the libtool
default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528
Bug ID: 115528
Summary: [15 regression] segmentation fault in legacy F77 code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
--- Comment #1 from Jürgen Reuter ---
I suspect this commit here,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c0398e65347def316700911a51ca8b4ec0a411
but not totally certain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Bug ID: 114475
Summary: [14.0 Regression] Regression with iso_c_binding and
submodules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
--- Comment #3 from Jürgen Reuter ---
(In reply to anlauf from comment #2)
> The following patch fixes the reduced testcase for me, as well as the
> full testcase in comment#0:
>
> diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-arr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
Bug ID: 113471
Summary: [14 regression] wrong array bound check failure on
valid code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112460
Bug ID: 112460
Summary: ICE with parameterized derived types (incorrect code,
should be rejected)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #56 from Jürgen Reuter ---
What do we do now? We know the offending commit, and the commit that fixed (or
"fixed") it. Closing? Do we understand what happened here, so why it went wrong
and why it got fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #55 from Jürgen Reuter ---
Actually, according to my testing, the last commit where the gfortran produced
failing code,
ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f
(Aldy Hernandez A single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #54 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.
Wildly speculating, it would be this commit maybe,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #53 from Jürgen Reuter ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed" it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #50 from Jürgen Reuter ---
How to proceed here? Since almost exactly a month the current gcc git master
doesn't show this problem anymore, from our CI I can deduce that the version on
July 3rd still failed, while the version on July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110698
Bug ID: 110698
Summary: Bootstrap fails with [-Werror=unused-but-set-variable]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691
--- Comment #1 from Jürgen Reuter ---
Created attachment 55560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55560&action=edit
Shorter reproducer that gives bogus entries.
This shorter reproducer gives (with gfortran 11.3) bogus output,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691
Bug ID: 110691
Summary: Segmentation fault on valid F2018 code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #4 from Jürgen Reuter ---
Created attachment 55526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55526&action=edit
Minimal reproducer, also as attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #3 from Jürgen Reuter ---
Here is a mininal reproducer:
module process_mci
implicit none
private
public :: process_mci_entry_t
type :: process_mci_entry_t
integer :: i_mci = 0
integer, dimension(:), allocatable ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
Jürgen Reuter changed:
What|Removed |Added
Known to fail||11.3.0
--- Comment #2 from Jürgen Reute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #1 from Jürgen Reuter ---
Created attachment 55525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55525&action=edit
Simpler reproducer in a single file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #49 from Jürgen Reuter ---
(In reply to anlauf from comment #48)
> (In reply to anlauf from comment #47)
> > However, when I use -O2 together with an -march= flag, the code works.
> > I've tested -march=sandybridge, -march=haswell, -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #46 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
>
> I will give more information in a comment, this contains 3 files and a
> Makefile.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #45 from Jürgen Reuter ---
Created attachment 55492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492&action=edit
Smaller stand-alone reproducer
I will give more information in a comment, this contains 3 files and a
Makefil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
Bug ID: 110576
Summary: ICE on compilation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #44 from Jürgen Reuter ---
(In reply to anlauf from comment #43)
> Mabye the fprem issue was a red herring from the beginning, pointing to a
> problem in a different place.
>
> I recompiled each module in a loop with -O0 until the F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #42 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #41)
>
> 0x04f5dc90 is pseudo NaN:
> Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat
> this as a Signaling Not a Number. The 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #38 from Jürgen Reuter ---
At the moment unfortunately too busy to provide a smaller reproducer (which
also still has a small dependency on a dynamic library), but one more info:
inserting the explicit operations instead of the intri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #29 from Jürgen Reuter ---
(In reply to anlauf from comment #28)
> Update: recompiling that file with 13-branch fails for me, too.
> Playing with the one-line patch for pr86277 makes no difference, fortunately.
>
> Compiling the fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #26 from Jürgen Reuter ---
(In reply to anlauf from comment #25)
> Unfortunately, there is no main.f90, which is needed to build whizard.
>
Indeed, sorry, cf. below
> The Makefile needs to be modified to take into account that pyt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #24 from Jürgen Reuter ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #22 from Jürgen Reuter ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.
Indeed, I think you are right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #19 from Jürgen Reuter ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #17 from Jürgen Reuter ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #16 from Jürgen Reuter ---
It seems that it is this function where the NaNs appear:
function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #14 from Jürgen Reuter ---
Did anybody manage to reproduce this?
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make,
cd tests/functional_tests
make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #13 from Jürgen Reuter ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #12 from Jürgen Reuter ---
Any idea which commit could cause such an issue? At least I now understand that
in our program the random number object gets undefined and produces NaNs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Jürgen Reuter changed:
What|Removed |Added
Component|tree-optimization |fortran
Keywords|wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #10 from Jürgen Reuter ---
*** Bug 110326 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
Jürgen Reuter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
--- Comment #2 from Jürgen Reuter ---
Closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
--- Comment #1 from Jürgen Reuter ---
This should be closed as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #9 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jürgen Reuter from comment #7)
> > The problem seems really connected to optimization, if I compile our code
> > with -g -O0 or -g -O1, everything w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #7 from Jürgen Reuter ---
The problem seems really connected to optimization, if I compile our code with
-g -O0 or -g -O1, everything works ok. Next, I will try to check why it is
actually failing (my guess, unconfirmed yet, is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #5 from Jürgen Reuter ---
(In reply to anlauf from comment #4)
> Jürgen,
>
> I'm afraid we need a reproducer. Or can you bisect the regression further?
In principle, I could. But I just undid this commit of yours which is just one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
Bug ID: 110326
Summary: [gcc 14.0 regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #3 from Jürgen Reuter ---
I redid this change here:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index
e1c75e9fe0266d760b635f0dc7869a00ce53bf48..e7c51bae052b1e0e3a60dee35484c093d28d4653
100644 (file)
--- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Jürgen Reuter changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #1 from Jürgen Reuter ---
It looks like there were no specific changes in the fortran backend or the
libgfortran but a lot of optimization in the middle-end. Maybe that is
responsible for this issue. Need to see what is going on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Bug ID: 110311
Summary: [gfortran 14.0 regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #16 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #14)
> For the record, the fix is:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 1d973d12ff1..1a03e458d99 100644
> --- a/gcc/fortran/resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #10 from Jürgen Reuter ---
(In reply to Tobias Burnus from comment #8)
> The debugger shows for the example in comment 4 for the line
>
>69 | history_new(1:s) = res_set%history(1:s)
>
> the following expression:
>
> (gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #9 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #4)
>
> module subroutine t3_set_expand (res_set)
> class(t3_set_t), intent(inout) :: res_set
> type(t3_t), dimension(:), allocatable :: history_new
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #7 from Jürgen Reuter ---
It looks like it is NOT Harald's and Tobias' commit,
https://github.com/gcc-mirror/gcc/commit/901edd99b44976b3c2b13a7d525d9e315540186a
I reverted that one, and still get the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #6 from Jürgen Reuter ---
Actually could be also this commit here:
commit 901edd99b44976b3c2b13a7d525d9e315540186a
Author: Harald Anlauf
Date: Tue Mar 14 20:23:06 2023 +0100
Fortran: rank checking with explicit-/assumed-size
1 - 100 of 196 matches
Mail list logo
