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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many libphobos tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many obj-c++ tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Most gdc|Most gdc tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #4 from Iain Sandoe ---
Created attachment 57378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=edit
patch under test
This implements the common case for an i386 trampoline (and, in this respect,
matches the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #3 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #2)
> Guess an ia32 implementation would be even better, shouldn't be that hard.
I have a draft on one of my machines, I'll post it here tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #1 from Iain Sandoe ---
I was looking at making an i686 impl.
but we could also do as you suggest for gcc-14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #10 from Iain Sandoe ---
automake if is limited to testing a single variable, so we have to introduce an
AM_CONDITIONAL to say the OS is DARWIN (we did not seem to have one already,
but I could have missed something else usable).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #7 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > Maybe:
> >
> > ifneq ($(filter %-darwin%,${host_alias}),)
>
> ${target_os} instead maybe?
I'll give that a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
--- Comment #11 from Iain Sandoe ---
(In reply to Rainer Orth from comment #10)
> Patch posted.
FWIW Darwin is, indeed, also affected and I have patches in progress to resolve
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> /* If it isn't always lock free, don't generate a result. */
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> values one can get out of this built-in are "true" and "defer to run-time"
>
> ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #3 from Iain Sandoe ---
extern pure nothrow @nogc @safe bool __atomic_always_lock_free(uint,
shared(const(void))*);
extern pure nothrow @nogc @safe bool __atomic_is_lock_free(uint,
shared(const(void))*);
perhaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Bug ID: 113772
Summary: [14 Regression] atomic.d compile error since recent
upstream imports.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #8 from Iain Sandoe ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Jon, what about Iain's question whether it isn't a bug we use constexpr on
> > the ctor even in C++11 mode?
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #1 from Iain Sandoe ---
I suppose the trivial fix is s/constexpr/const/ (but maybe there's something
more elegant).
If we agree that this is c++14 - only, then maybe we should have a separate bug
that we accept this for c++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Bug ID: 113763
Summary: [14 Regression] build fails with clang++ host compiler
because aarch64.cc uses C++14 constexpr.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #4 from Iain Sandoe ---
Created attachment 57318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57318=edit
gimple for 179t.vect
now there's a mem at the start of bb3 with the label following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #3 from Iain Sandoe ---
Created attachment 57317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57317=edit
gimple for 179t.ifcvt
the label seems OK here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #1 from Iain Sandoe ---
..
(gdb) p debug_tree(current_function_decl)
>
SI
size
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xf5b5d008
arg-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Bug ID: 113750
Summary: [14 Regression] ICE in vect building
gcc/m2/gm2-libs/NumberIO.mod
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
--- Comment #3 from Iain Sandoe ---
I suppose we are going to have to consider back porting this, if we want to
avoid the same problems on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #8 from Iain Sandoe ---
I suppose we are going to have to consider back porting this (and the fixes for
data layout), if we want to avoid the same problems on open branches.
1 - 100 of 924 matches
Mail list logo
