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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #14 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=112861
--- Comment #5 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=112506
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Gaius Mulley from comment #7)
> > I doubt the m2date and testclock are related to filesystem case (but I could
> > be wrong) as I've built gcc on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
--- Comment #6 from Iain Sandoe ---
FWIW. testing on i686-darwin9 and x86_64-darwin14 with
case-preserving-non-case-sens shows these fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #8 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #7)
> I doubt the m2date and testclock are related to filesystem case (but I could
> be wrong) as I've built gcc on a gnu-linux jfs filesystem (case preserving
> case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-01-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed|2023-11-13 00:00:00 |2024-1-27
--- Comment #5 from Iain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #5 from Iain Sandoe ---
(In reply to Rainer Orth from comment #4)
> On macOS 11, everything is still fine. On macOS 14, there's progress:
> The remaining failures fall into two categories:
>
> FAIL: obj-c++.dg/encode-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #11 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> > --- Comment #9 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #8)
> >> Again tested on macOS 11 (unchanged) and 14. On the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #9 from Iain Sandoe ---
(In reply to Rainer Orth from comment #8)
> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
> failures
> to find libatomic.1.dylib have been traded for
>
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #7 from Iain Sandoe ---
Created attachment 57202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57202=edit
patch under test
works on x86_64 Sonoma with XC CLT 15.1
testing more widely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
--- Comment #9 from Iain Sandoe ---
(In reply to Florian Weimer from comment #8)
> Which version of the manual page are you looking at?
>
> https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems
> pretty clear about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
--- Comment #7 from Iain Sandoe ---
(In reply to Florian Weimer from comment #6)
> Sorry, pthread_cleanup_push is purely scope-based, like the existing
> handler. It cannot be used to push a handler to some unscoped cleanup
> function list that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
--- Comment #5 from Iain Sandoe ---
(In reply to Florian Weimer from comment #4)
> (In reply to Iain Sandoe from comment #3)
> > for platforms using pthreads as the underlying resource, then perhaps we can
> > do this without thread_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
--- Comment #3 from Iain Sandoe ---
for platforms using pthreads as the underlying resource, then perhaps we can do
this without thread_atexit (which I do not see in many places) by using
pthread_cleanup_push ()
not sure if gthr.h abstracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #14 from Iain Sandoe ---
Created attachment 57182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57182=edit
patch under test
this is what I'm testing
- these functions are removed from libgcc.a and added to libgcc_eh.a
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150
--- Comment #3 from Iain Sandoe ---
on darwin we also get (all with the same diagnostic - about a leaked fd)
I can report them separately if you like - but it seems likely to be a common
cause:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Target|hppa64-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #5 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> > --- Comment #3 from Iain Sandoe ---
> > OK. So I realise the reason you see this and I wasn't: I have the habit of
> > installing before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #3 from Iain Sandoe ---
OK. So I realise the reason you see this and I wasn't: I have the habit of
installing before running the testsuite. When I test uninstalled, then I get
the issue.
... the subsequent work reveals that we are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #1 from Iain Sandoe ---
which Xcode version produces this?
on Darwin23 with XC15.1 I get clean obj-c++ results
(but we should omit the duplicates anyway)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #1 from Iain Sandoe ---
this appears to be fixed; I get clean fortran testsuite results on (x86_64)
Darwin21 and Darwin23. Please could you check and either close this or post
your Xcode version, configure line and OS version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #13 from Iain Sandoe ---
(In reply to Florian Weimer from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > Or put it in libgcc_eh.a and libgcc_s.so.1?
>
> Yes, that's what I came up with as well (conceptually, not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #10 from Iain Sandoe ---
it is an optimisation, yes - but as Richi points out, if we change this it will
affect ABI - so it is ideal to do this before the first release that includes
it?
- IIUC Jakub's suggestion:
- remove the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #3 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 57087 [details]
> gcc14-pr113402.patch
>
>
> Though, I wonder if we also shouldn't rename those symbols, having __builtin_
> prefix in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #5 from Iain Sandoe ---
Sorry, my intended design was not stated very clearly.
1. IIUC, the objective is to have only one instance of these symbols in the
dynamically-linked program.
2. One way to ensure that is to make it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #3 from Iain Sandoe ---
(In reply to Florian Weimer from comment #2)
> Weak symbols have no meaning for ELF DSOs, so this wouldn't work for
> libgcc_s on ELF targets. Instead we automatically link against dynamic
> libgcc_s if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #1 from Iain Sandoe ---
this seems a somewhat similar dilemma to the emulated TLS case.
Perhaps:
provide a weak definition of these in a CRT (which is used for -static-libgcc)
and weaken the defs in libgcc_s so that mixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #24 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #23)
> (In reply to Andrew Pinski from comment #22)
> > (In reply to Sergey Fedorov from comment #21)
> > > Any chance of having it fixed in gcc14?
> >
> > It is too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #12 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #10)
> BTW, yet another option would be to just
> LIBM=
> case $host in
> *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
> # These
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #11 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #10)
> BTW, yet another option would be to just
> LIBM=
> case $host in
> *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*)
> # These
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #8 from Iain Sandoe ---
I propose to test the patch at comment #2 as a step to restore the original
behaviour. It would be nice to make the libm use configurable (as per
libgfortran or libstdc++) as a separate issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #6 from Iain Sandoe ---
I cannot peak for the others, but Darwin does not need '-lm' because it is part
of libc [libSystem] (adding -lm actually symlinks to libSystem and alters the
effective library order on the link line so I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #3 from Iain Sandoe ---
(In reply to Andreas Schwab from comment #1)
> How did that work before r14-4825-g6a6d3817afa02b?
I suppose, unconditional adding of '-lm' is not a problem to the affected bare
metal targets but using the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #2 from Iain Sandoe ---
r14-4825-g6a6d3817afa02b, (adding @rpath support) was not intended to change
the behaviour of libc handling, but as noted a rebase error left that in
(probably because both changes acted on the link).
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #3 from Iain Sandoe ---
with a case sensitive source partition on x86_64-darwin12, (I think these have
also been reported, but cannot find the pR right now):
=== gm2 tests ===
Running target unix
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #2 from Iain Sandoe ---
is your file system "default" (i.e. case-preserving-case-insensitive) on the
source code volume?
If so, those fails look suspiciously similar to the ones I see - reposted in
PR111627.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Component|libstdc++ |target
--- Comment #2 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928
--- Comment #6 from Iain Sandoe ---
(In reply to Dimitar Dimitrov from comment #4)
> If I remove the "AC_CHECK_LIBM" line from libquadmath/configure.ac, and
> re-generate autoconf there, then the build passes.
>
> I don't understand why that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928
--- Comment #3 from Iain Sandoe ---
(In reply to Dimitar Dimitrov from comment #2)
> I confirm that build works fine with r14-4820-g11f50716eee812, no maintainer
> mode, for pru and arm targets.
>
> I'm using x86_64-pc-linux-gnu build and host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111928
--- Comment #1 from Iain Sandoe ---
I'm trying to reproduce this, (and could be making some mistake) but I seem to
see
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111920
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111920
Bug ID: 111920
Summary: [14 Regression] encode-{8,9,10}.mm internal compiler
error: in tsubst_expr, at cp/pt.cc:21533
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
--- Comment #5 from Iain Sandoe ---
for the record an __fp16 implementation works as expected;
* when the target does not support +fp16, the code-gen promotes to float and
does the multiply with __mulsc3
* when the target supports +fp16, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
--- Comment #2 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #1)
> This could either be wrong code for not doing the promotion or just missing
> the libgcc functions (which could be implemented as doing the promotion).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
Bug ID: 111876
Summary: aarch64: Wrong code for bf16 complex mul/div when the
target has +fp16 support.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Maybe something like:
> > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> > index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Bug ID: 111867
Summary: aarch64: Wrong code for bf16 literal load when the
arch support +fp16
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111628
Bug ID: 111628
Summary: D: concurrency.d hangs on macOS 13 (Ventura) and 14
(Sonoma).
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2023-9-28
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627
Bug ID: 111627
Summary: modula2: Excess test fails with a
case-preserving-case-insensitive source tree.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
--- Comment #3 from Iain Sandoe ---
(In reply to Martin Jambor from comment #2)
> (In reply to Iain Sandoe from comment #1)
> > As a matter of record, we do not really support cross-compilers targeting an
> > unknown Darwin version (the idea of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2023-09-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #11 from Iain Sandoe ---
(In reply to Michael Duggan from comment #9)
> More data:
> The coroutine actor is marked as artificial in
> coro_build_actor_or_destroy_function. As a result, it is completely ignored
> by gcov. In gcov's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111481
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Francois-Xavier Coudert from comment #3)
> > > Clang: 14.0.0 build 1400
> > > CLT: 14.2.0.0.1.1668646533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Francois-Xavier Coudert from comment #3)
> > Clang: 14.0.0 build 1400
> > CLT: 14.2.0.0.1.1668646533
>
> ah, it seems the vfcmulcph insn, at least, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> Clang: 14.0.0 build 1400
> CLT: 14.2.0.0.1.1668646533
ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and it
gives the error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
--- Comment #2 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #1)
> This seems like a bug in darwin's assembler as all of those registers are
> distinct ...
indeed, it does look that way - what version of Xcode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
--- Comment #19 from Iain Sandoe ---
(In reply to François Dumont from comment #17)
> (In reply to Iain Sandoe from comment #15)
Your proposed patch for the friend issue does fix the libstdc++ cases for my
Darwin patchset.
> > many of the c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
--- Comment #18 from Iain Sandoe ---
for changes to libstdc++ or the FE I usually run "make check-c++" which does
the library (plus the libgomp and itm deps) and the FE.
My guess is that the FE is referencing something that needs to have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
--- Comment #16 from Iain Sandoe ---
(In reply to François Dumont from comment #14)
> Good news then.
>
> On my side I only had some failures due to a faulty friend declaration in
> gnu-versioned-namespace mode in for which I've submitted a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to François Dumont from comment #10)
> > > > This is
101 - 200 of 950 matches
Mail list logo
