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
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following ICE appear in gfortran 14.1. and goes back to at least gfortran
9.4. The reproducer is somne 80 lines.
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
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Some changes in gcc/gfortran between ca. June 10 and June 17, 2024 now leeds to
segmenation faults in our application (Whizard v3.1.4, c.f.
http
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.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Between ca. March 18 and March 25, a regression has been introduced into the
gfortran 14.0.1 code, which makes the following valid
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
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 57136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57136&action=edit
Reproducer, 154 lines
Very
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This is probably known (then it can be marked as duplicate), but let me report
it nevertheless. The following code
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
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This seems to be a very recent problem: last week (as of July 10) the bootstrap
did still work with the gcc master, and now it is failing, cf. below.
That
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,
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 7
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=7&action=edit
Reproducer
The attached code (which I believe to be valid F2018) lea
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
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 55490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55490&action=edit
reproducer
The following reproducer leads to an ICE which I see already with gfortran
11.3.
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
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Hi,
let me open up an issue already. I believe there was a regression introduced in
gcc between June 11 and June 19, as our CI with a git-clone built gcc worked
last week, and fails
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.
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Hi,
let me open up an issue already. I believe there was a regression introduced in
gfortran between June 11 and June 19, as our CI with a git-clone built
gcc/gfortran worked last week
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #5 from Jürgen Reuter ---
This could be either this commit
commit d7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas
Date: Sat Mar 18 07:56:23 2023 +
/Fortran
I think, it is NOT this one:
commit 5889c7bd46a45dc07ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #4 from Jürgen Reuter ---
Here is the promised reproducer, which fails even when not using submodules:
$ gfortran -c reproducer.f90
reproducer.f90:69:4:
69 | history_new(1:s) = res_set%history(1:s)
|1
Error: Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #3 from Jürgen Reuter ---
Created attachment 54713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54713&action=edit
Promised short reproducer, 73 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #2 from Jürgen Reuter ---
Created attachment 54712
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54712&action=edit
Second, single-file reproducer, still 6295 lines
Still further reducing, stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #1 from Jürgen Reuter ---
Created attachment 54710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54710&action=edit
First still pretty large reproducer
I will provide a smaller reproducer soon.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Some commit between last week and now, so between March 12 and March 19, has
created a regression, so gfortran throws a (presumably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #13 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #12)
.
>
> Next, I guess I'll pick up the xc 14.2 release.
Sorry, my bad, I misplaced the position of the argument
BOOT_CFLAGS, I erroneously (like for configure, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #10 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #9)
> (I don't have a macOS13 setup yet, limited hardware available here)
>
> ... so, if it is not fixed in the Xcode 14.x releases, we'll have to work
> around it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #8 from Jürgen Reuter ---
What is the status of this problem? I checked with Darwin 22.2 and XCode 14.2,
and the problem still persists with the Git master, cf. below. Is there a
workaround for the moment? Will this be resolved befor
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The linking during bootstrap on Darwin 21.6.0 with Xcode 14.0.1 chokes on the
error message below, the configure line has been:
../configure --prefix=/usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
Jürgen Reuter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
--- Comment #2 from Jürgen Reuter ---
Hi Jakub,
this is the compilation command:
g++ -std=c++11 -I../../libcpp -I. -I../../libcpp/../include -I./../intl
-I../../libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings
-Wmissing-format-attrib
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Trying to compile the full gcc on Darwin x86_64 (not M1, darwin-arm64, not
checked yet), the gcc 13.0.0 (git clone as of today) fails to compile with the
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The code below (using iso_varying_string and a child module in the same module
gives a bogus warning from -Wsurprsing
reproducendum.f90:110:6:
110 | use diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #35 from Jürgen Reuter ---
Now that macOS 12.1 is out (and XCode 13.2) could someone please check whether
the problem has been solved from the side of the Darwin kernel?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #6 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #5)
> I can confirm the ICE with current trunk both on x86_64 and
> on POWER.
>
> x86_64:
>
> $ gfortran -v
> Es werden eingebaute Spezifikationen verwendet.
> COLLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #31 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #29)
> (In reply to Francois-Xavier Coudert from comment #28)
> I've posted a fix for this (it is the fix for darwin21 DTORs in general)
> however CAVEAT : there is No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #24 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Jürgen Reuter from comment #22)
> > (In reply to Thomas Koenig from comment #20)
> > > (In reply to Iain Sandoe from comment #16)
> > > > (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #22 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #20)
> (In reply to Iain Sandoe from comment #16)
> > (In reply to Thomas Koenig from comment #14)
>
> There is always the reason of not breaking compatibility, a q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #21 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #19)
> (In reply to Jürgen Reuter from comment #18)
>
> > write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0
>
> Hmm, was this actually the string that you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #18 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #13)
> Here is a complete strace of a "Hello, world" program on Linux, compiled
> with -static-libgfortran (to remove some of the shared library loading :-)
> and exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #8 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #6)
> Created attachment 51716 [details]
> gfortran appearance of the ICE
Just for completeness, this example needs to be compiled with -O2, while
-O0 and -O1 work fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #6 from Jürgen Reuter ---
Created attachment 51716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51716&action=edit
gfortran appearance of the ICE
1 - 100 of 701 matches
Mail list logo
