https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #17 from Iain Sandoe ---
however, the opover.o mismatch is a symptom - rather than the cause.
If all the objects for the D FE are built by D, then that would tend to point
to miscompilation of something in common code (that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #14 from Iain Sandoe ---
(In reply to Richard Biener from comment #13)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Richard Biener from comment #8)
> > > I've pushed a fix for PR115137, it's likely this fixes also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #9 from Iain Sandoe ---
(In reply to Richard Biener from comment #8)
> I've pushed a fix for PR115137, it's likely this fixes also this bug.
unfortunately, not; at least, on my fastest x86 machine (AVX512) - the fail is
the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
--- Comment #7 from Iain Sandoe ---
I have not tested on solaris - hopefully that is OK too.
However, I will comment that it maybe built but there are cats regressions (1)
on x86_64, (2) on i686-darwin17 (many) on i686-darwin9. No idea what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #7 from Iain Sandoe ---
additional notes:
1. jamming -std=c++11 into stage2 and 3 cxxflags did not make any difference (I
was wondering if some c++17 copy elision thing might have changed the number of
temporaries).
2. still there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
--- Comment #5 from Iain Sandoe ---
as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17.
I do not known whether that means the issue is actually fixed by recent Ada
commits, or that it's now just become latent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-darwin |x86_64-darwin, x86_64-linux
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #4 from Iain Sandoe ---
so I am comparing the output of compiling gcc/d/dmd/opover.d with the stage1
and stage2 compilers.
Using -fdump-tree-all.
the .005t.original outputs are the same
the .006t.gimple outputs already have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
--- Comment #3 from Iain Sandoe ---
(In reply to rguent...@suse.de from comment #2)
> > Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org
> > :
> >
> > where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154
> >
> > At
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
Bug ID: 115138
Summary: [15 Regression] Bootstrap compare-debug fail after
r15-580-gf3e5f4c58591f5
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
Iain Sandoe changed:
What|Removed |Added
Build|i386-pc-solaris2.11 |i386-pc-solaris2.11,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113
Bug ID: 115113
Summary: [15 Regression] Ada bootstrap fails for i686-darwin.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115077
Bug ID: 115077
Summary: bootstrap fails with in-tree isl-0.25/6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #58 from Iain Sandoe ---
As far as I can tell, (at least on targets with TLS support) since the
variables __once_callable and __once_call have a single instance per thread,
the current implementation does not support nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> I happened to do an AIX build on cfarm119 - and looking at this, not sure
> why AIX is failing; although the LTO is handled in a different way in AIX,
> there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #7 from Iain Sandoe ---
I happened to do an AIX build on cfarm119 - and looking at this, not sure why
AIX is failing; although the LTO is handled in a different way in AIX, there
are actually no instances of "ascii" in the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #31 from Iain Sandoe ---
(In reply to Liviu Ionescu from comment #30)
> (In reply to Dimitry Andric from comment #29)
> > ... fixes system.h which is also included by gcov.cc
>
> ok, great.
>
> > Which version of gcc were you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114982
Bug ID: 114982
Summary: [15 Regression] New test
g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Bug ID: 114663
Summary: Several contracts test cases fail with
-fsanitize=undefined -fsanitize-trap
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Pierre-Emmanuel Patry from comment #2)
> While you are at it, it would be useful to add a link to the rust langauge
> specification (like there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
--- Comment #8 from Iain Sandoe ---
A secondary comment - the wiring up of the built-ins that allocate/deallocate
trampoline entries makes the underlying mechanism opaque to the middle end
consumer.
So, although the current example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #26 from Iain Sandoe ---
NOTE: I adjusted the PR lines in the commit header so that the commits get
reflected on the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #11 from Iain Sandoe ---
(In reply to Jason Merrill from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > > So I am actually asking if the extension actually has any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #7 from Iain Sandoe ---
however:
1) it is not in the gnu:: namespace the tests just have it as [[ ]].
2) I do not think that the standard has anything to say about how entities at
file scope are ordered in memory (many/most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #4 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #5 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101718
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #23 from Iain Sandoe ---
(In reply to Gerald Pfeifer from comment #22)
> (In reply to Dimitry Andric from comment #21)
> > Indeed, please merge both commits:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #20 from Iain Sandoe ---
This is fixed on trunk, but is needed on open release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297
--- Comment #3 from Iain Sandoe ---
this seems to have been fixed by r14-6423-g02f562484c1752, does it need back
porting? or should we close?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #10 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #16 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #15)
> (In reply to Peter Bergner from comment #12)
> > (In reply to Sergey Fedorov from comment #11)
> > > (In reply to GCC Commits from comment #10)
> > > > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626
--- Comment #7 from Iain Sandoe ---
now that boehm-gc is no longer in tree
what should we do with this?
I suppose there could be some more sophisticated top-level configuration
(similar to GMP et. al.) which determines if there's a suitable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818
Bug 42818 depends on bug 41596, which changed state.
Bug 41596 Summary: handling of library-related options by g++spec.c causes a
failure when generating pch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #31 from Iain Sandoe ---
what is the current situation with this
- what input are we waiting for?
- is the problem now cleared for powerpc64-freebsd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590
Iain Sandoe changed:
What|Removed |Added
Build|x86_64-apple-darwin1[5678] |x86_64-apple-darwin1[56789]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #12 from Iain Sandoe ---
what input is this waiting for at the moment?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #9 from Iain Sandoe ---
I think this is fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin20 |*-darwin*
Component|testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #5 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> The question is: will this reveal new issues in other tests that weren't
> running before. I'm starting a new regtest and will post the results here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> Jakub has posted a patch in the linker PR (thanks!).
>
> But there remains a darwin bug. The test in check_effective_target_shared
> actually works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #1 from Iain Sandoe ---
note Darwin's linker does not, by default permit symbols to be undefined. If
the test case requires allowing undefined symbols to complete, then either we
need to specify them thus:
-Wl,-U,_XXX (for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #15 from Iain Sandoe ---
(In reply to Dimitry Andric from comment #14)
> (In reply to Iain Sandoe from comment #13)
> > (In reply to Francois-Xavier Coudert from comment #11)
> > > Starting with Xcode 15.3 and the SDK for macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #13 from Iain Sandoe ---
fixed on trunk, intending to backport it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #6 from Iain Sandoe ---
I'm still finding this a bit confusing.
- we have not altered the code in this area (at least not the Darwin parts)
during the gcc-14 cycle.
- apparently, it works with previous Xcode versions/SDKs
- from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #4 from Iain Sandoe ---
Created attachment 57501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57501=edit
without PCH
As Andrew says, the differences are in the debug info (it might even only be in
the order of the debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #3 from Iain Sandoe ---
Created attachment 57500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57500=edit
with PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #5 from Iain Sandoe ---
The manual currently says:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched for header
files dur- ing preprocessing. If dir begins with ‘=’ or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #3 from Iain Sandoe ---
so .. if i follow your discussion correctly - neither clang nor gcc finds it
because it's incorrectly quoted (is that an SDK issue?).. or?
We do have control, IIRC, about adding the frameworks search path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #1 from Iain Sandoe ---
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers
should be a symlink to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #26 from Iain Sandoe ---
but from your initial post it's also guarded by:
#ifndef __has_cpp_attribute
#define __has_cpp_attribute(x) 0
#endif
so it will always be 0 for clang in C mode, since that does not define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #22 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #21)
> > --- Comment #19 from fxcoudert at gmail dot com > com> ---
> The only issue left (the gcc.dg/framework-1.c failure) so far seems to
> be an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #2)
> This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS
> 14.3).
> I am attaching the preprocessed source.
>
> The code from CFData.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #2 from Iain Sandoe ---
if there are lots of symbols that need to be undefined .. then one can use an
undefined symbols file.
Of course, it does not work if we do not know the symbol names at build-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #1 from Iain Sandoe ---
yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my
guess is that this is an anachronism from the ld_classic (v1) days.
We can tell the linker it's OK for a symbol to be undefined -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #1 from Iain Sandoe ---
let me see if we're adding an extra in the Darwin specs that is covered
elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some
time to sync the ones in darwin.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #1 from Iain Sandoe ---
which actual SDK is this?
you should be able to look at the SDKsettings.plist in the root of the SDK, if
there's any need to discriminate versions with the same name.
(and is it possible to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #7 from Iain Sandoe ---
(In reply to Sebastian "spaetz" Spaeth from comment #5)
> I fully understand that nobody wants to invest time into fixing this. What
> would be nice though, is if this were really just a missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #11 from Iain Sandoe ---
looking at n2176 - C18 there is no mention of __has_c*
looking at n3047 - C23 there is mention only of __has_c_attribute
OTOH, there is no prohibition in declaring __has_cpp_attribute (c.f. an actual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #10 from Iain Sandoe ---
indeed, it seems clang does not define __has_cpp_attribute for -std=c11 c
compilations, whereas GCC does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> perhaps this is also a clang regression - for Jakub's example with Xcode
> 15.1 :
(xcode clang, that is, I did not test with upstream clang yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #5 from Iain Sandoe ---
perhaps this is also a clang regression - for Jakub's example with Xcode 15.1 :
$ clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
master-wip-short-queue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #9 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Sergey Fedorov from comment #6)
> > (In reply to Andrew Pinski from comment #0)
> > > This is the new bug for PR 19405. Keeping track of that we no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
--- Comment #1 from Iain Sandoe ---
the intent was not to enable this feature for platforms we could not test.
but libgcc/config.host has "aarch64*-*-linux*" so we have inadvertently enabled
it for aarch64-linux-musl.
assuming linux-musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Component|pch |c++
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-02-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Bug ID: 113970
Summary: [14 Regression] pch/system-{1,2}.C fails on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: needs-bisection, wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin21 |x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562
Bug 108562 depends on bug 105755, which changed state.
Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-02-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Component|c++ |other
Keywords|wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
--- Comment #1 from Iain Sandoe ---
the problem is that liberty is using the value set by posix_spawnp for pid.
but:
(darwin):
The argument pid is a pointer to a pid_t variable to receive the pid of
the spawned process; if this is NULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Bug ID: 113957
Summary: [14 Regression] bad-mapper-1.C hangs on all Darwin.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #5 from Iain Sandoe ---
AFAICT, this was fixed on trunk by r14-6721-gd31c54c7da7661 (which seems to
have a reference to the PR so not sure why it did not show up here).
I think we need this on any open branch which we want to work
1 - 100 of 950 matches
Mail list logo