https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99515
Bug ID: 99515
Summary: gcc fails to build on Darwin 20.3.0
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99515
--- Comment #1 from Jürgen Reuter ---
Maybe I add this information which was put out right ahead of the error
messages:
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g " "CXXFLAGS=-g "
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2"
"INSTAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99515
Jürgen Reuter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
Bug ID: 99545
Summary: [11.0 regression] ICE in gfc_trans_assignment
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #1 from Jürgen Reuter ---
Obviously, it would be great if that regression doesn't make it into the 11.1
official release. [As it is with debug flags, that would be less dramatic than
with default flags]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #3 from Jürgen Reuter ---
Created attachment 50362
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50362&action=edit
First (large) reproducer to play with, reducing atm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #5 from Jürgen Reuter ---
I'm also reducing it right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #6 from Jürgen Reuter ---
Voila, here is a short reproducer:
module commands
implicit none
private
type, abstract :: range_t
integer :: step_mode = 0
integer :: n_step = 0
end type range_t
type, extends (range_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #7 from Jürgen Reuter ---
It actuallys is the -fcheck=mem part that triggers the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #13 from Jürgen Reuter ---
I confirm that with that patch our code compiles again, however, more or less
all functionality fails because of runtime errors about
Fortran runtime error: Pointer actual argument '' is not associated.
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Bug ID: 99602
Summary: [11 regression] runtime error: pointer actual argument
not associated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #1 from Jürgen Reuter ---
Created attachment 50389
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50389&action=edit
First (large) reproducer to play with, reducing atm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99545
--- Comment #15 from Jürgen Reuter ---
Paul, thanks for the quick response, I opened a new one, PR99602. Please close
this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #2 from Jürgen Reuter ---
Created attachment 50391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50391&action=edit
Short reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Jürgen Reuter changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Jürgen Reuter changed:
What|Removed |Added
Attachment #50391|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #5 from Jürgen Reuter ---
Created attachment 50393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50393&action=edit
New short reproducer, this time consistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #6 from Jürgen Reuter ---
Actually, the last example missed a line that I overeagerly deleted too much.
This one is the correct reproducer:
module m
implicit none
private
public :: m_t
type :: m_t
private
end type m_t
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #7 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #3)
> Here is a shorter reproducer, and this time it is the -fcheck=pointer that
> leads to the problem. I was able to reproduce this to 80 lines, leading to
> the erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #9 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #8)
>
> Paul
$ gfortran -fcheck=pointer repro.f90
reuter@Manwe:~/local/packages/whizard/trunk/_build_flags/RT_20210315$ ./a.out
At line 38 of file repro.f90
Fortran r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #10 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #9)
> (In reply to Paul Thomas from comment #8)
>
> >
> > Paul
>
> $ gfortran -fcheck=pointer repro.f90
> reuter@Manwe:~/local/packages/whizard/trunk/_build_flags/R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Jürgen Reuter changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #15 from Jürgen Reuter ---
(In reply to anlauf from comment #14)
> (In reply to Jürgen Reuter from comment #13)
> > Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at
> > it as well :D
>
> LGTM. It's by Paul.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #20 from Jürgen Reuter ---
Looks like there is still one more case. One of our unit tests is still failing
with this patch. I will report more soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #21 from Jürgen Reuter ---
Created attachment 50427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50427&action=edit
remaing false positive detection (long test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #22 from Jürgen Reuter ---
Created attachment 50428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50428&action=edit
bit smaller reproducer, not yet ideal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #23 from Jürgen Reuter ---
Created attachment 50429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50429&action=edit
first ok-ish reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #24 from Jürgen Reuter ---
Please have a look at my final reproducer. Is that feasible?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #25 from Jürgen Reuter ---
Created attachment 50430
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50430&action=edit
reproducer for another model pointer, final for 2021-03-19-03:22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #26 from Jürgen Reuter ---
Created attachment 50431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50431&action=edit
Single file reproducer, 7505 lines, no input files any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #27 from Jürgen Reuter ---
Created attachment 50432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50432&action=edit
down to 6800 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #29 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #28)
> (In reply to Jürgen Reuter from comment #27)
> > Created attachment 50432 [details]
> > reproducer, down to 6800 lines
>
> Hi Juergen,
>
> Stop! Yesterday's fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #31 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #30)
> Created attachment 50442 [details]
> Patch that "fixes" all versions of the problem.. so far :-)
>
> Hi Juergen,
>
> I think that this one does the job... it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #32 from Jürgen Reuter ---
Ready for merge?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #34 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #33)
> (In reply to Jürgen Reuter from comment #32)
> > Ready for merge?
>
> Hi Juergen,
>
> Daytime work intervened. I will submit to the list today.
>
Great!
> T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #36 from Jürgen Reuter ---
I can confirm that the push by Paul, 297363774e6a5dca2f46a85ab086f1d9e59431ac,
does fix all compilations and tests in our code and test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
Bug ID: 97865
Summary: MACOSX_DEPLOY_TARGET needs to be updated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #2 from Jürgen Reuter ---
(In reply to Eric Gallager from comment #1)
> This should probably handled by upstream libtool
Indeed I reported this to libtool as well, and I was not the first apparently.
How do you include this? In our c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #4 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #3)
> I didn't have x86 Big Sur until the weekend - still working through things.
>
> 1/
>
> The change you have keeps the default as $wl-undefined ${wl}dynamic_lookup,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #6 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #5)
> I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and
> have been looking into other issues.
>
> Note that the libgfortran directory throws up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #9 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Jürgen Reuter from comment #4)
>
> It's OK to need it (there are legitimate design reasons to do so) - however
> where that need exists, the -Wl,-und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #14 from Jürgen Reuter ---
If there is a git branch or so, I could also test it on my system with our code
whether this works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #16 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #15)
> (In reply to Jürgen Reuter from comment #14)
> > If there is a git branch or so, I could also test it on my system with our
> > code whether this works as expecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #17 from Jürgen Reuter ---
Iain, as I wrote below your changes seem not sufficient, I will recheck when I
build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it seems
that there are some things where you missed the dyna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #23 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> -
>
> * I found that there was one incorrect case in libgfortran (where there is a
> direct reference to **env
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
Bug ID: 98016
Summary: Host association problem
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
--- Comment #2 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #1)
> gcc-Version 11.0.0 20201112 (experimental) [master revision
> d33bc98f5bc:79fa060941e:87b7d45e358e4df93b6a93b2e7a55b123ea76f5d] (GCC)
>
> Can you confirm that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
--- Comment #3 from Jürgen Reuter ---
Ah wait, the version I committed works, the original version from c.l.f. still
fails, because it uses implicit typing, so not real :: y(3)
and real :: y(n), but
dimension y(3)
$ cat clf_20201126.f90
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #26 from Jürgen Reuter ---
Any news? I did not test the patch you posted in your last comment, but only
the one from your git repo. Under the assumption that this is identical to the
patch here, it works. So apparently libfortran and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #29 from Jürgen Reuter ---
(In reply to CVS Commits from comment #28)
> The master branch has been updated by Iain D Sandoe :
>
> https://gcc.gnu.org/g:1352bc88a0525743c952197fb2db6e4f8c091cde
>
> commit r11-5758-g1352bc88a0525743c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
Bug ID: 100340
Summary: Bootstrap fails with Clang 12.0.5 (XCode 12.5)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #1 from Jürgen Reuter ---
After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang
clang-1205.0.22.9, bootstrap doesn't work any more:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #2 from Jürgen Reuter ---
I just check, with --disable-bootstrap, gcc compiles to the end. Just the
checksums of the object files for bootstrap between stage 2 and 3 don't agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #4 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #3)
> Confirmed.
Merci, Dominique. Would you actually advise to compile without bootstrap and
start using gcc, or wait until the reason for the bootstrap failu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #8 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #6)
>
> 1. (re-)install xcode 12.4 command line tools and select them for use
> 2. disable debug comparison in the bootstrap ( --without-build-config )
Just to report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881
--- Comment #5 from Jürgen Reuter ---
I checked again, and I don't see any issues any more. There might still be some
memory leaks, I haven't checked. Would it make sense to close this one and open
a new report in case there is a definite reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206
--- Comment #4 from Jürgen Reuter ---
Still present in v12.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
--- Comment #5 from Jürgen Reuter ---
(In reply to ygal klein from comment #4)
>)
>
> Thank you for the reply.
>
> After posting the bug report - I saw that implementing (inout) as your
> number 1 suggestion - dodges the problem - though as yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
Bug ID: 106720
Summary: gcc does not compile with XCode 13.4.1 / clang 13.1.6
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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
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=107253
Bug ID: 107253
Summary: gcc does not compile with XCode 14.0.1 / clang 14.0.0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104164
Bug ID: 104164
Summary: Bogus warning issued by -Wsurprising
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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=103115
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Comme
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=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=87980
--- Comment #7 from Jürgen Reuter ---
Is anybody ever looked into this? Any updates?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
--- Comment #8 from Jürgen Reuter ---
The actual workaround that I'm using (the code is from of our stale branches
which recently became active again) is:
[...]
subroutine qn_string_set (qns, col)
class(qn_string_t), intent(inout) :: qns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102304
Bug ID: 102304
Summary: Internal compiler error: in gen_lowpart_general,
rtlhooks.c: 57
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102968
Bug ID: 102968
Summary: macOS Monterey not yet supported in configure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
Bug ID: 102992
Summary: Piping in a file does no longer work on macOS Monterey
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #1 from Jürgen Reuter ---
Using a C program compiled with the same version (recent trunk with the fix by
Iain Sandoe for Monterey) leads to a program that can pipe to a file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #4 from Jürgen Reuter ---
The problem is not related to XCode 13.1 which appeared at roughly the same
time. On Big Sur with XCode 13.1 still all works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #5 from Jürgen Reuter ---
I checked that the assembler code on macOS Big Sur and Monterey is identical
(up to the date in the .ident line). So either the assembler works differently,
or one of the routines from the libgfortran (_gfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #9 from Jürgen Reuter ---
I also tried that for a Fortran program ./a.out | less (pipe to less) works.
It's just the redirection that does not work. I'm waiting for the compilation
to check whether gfortran 11.2 from Macports shares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #10 from Jürgen Reuter ---
Reassuringly, the gfortran 11.2 from Macports has the same problem as the
gfortran 12.0.0 installed by hand: no redirecting into files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #12 from Jürgen Reuter ---
I'm not an expert on the I/O system, but could it be that the unit to which the
stdout of a compiled Fortran program goes does not provide the unit that the
redirect function (now) expects under macOS 12?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Comme
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
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=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=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 #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 #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=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
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 #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=100340
--- Comment #12 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #11)
> > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it
> > has the fixes?)
>
> not yet checked - but if someone has time I'd like to know
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=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=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=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 #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 #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 #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 #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=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=109209
Bug ID: 109209
Summary: [13.0 regression] erroneous error on assignment of
alloctables
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 226 matches
Mail list logo
