https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
--- Comment #1 from Iain Sandoe ---
I am not sure that a VLA can be used in a coroutine (neither can alloca, if I
remember correctly) [so not sure that this is ICE on valid, it could be ICE on
invalid]
Either way, we should not ICE from it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #20 from Iain Sandoe ---
I am testing a patch series (expected to push a github copy today if that
testing goes OK) including an implementation of comment #9.
However, IFF the jit build does not honour --without-build-config, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84257
--- Comment #9 from Iain Sandoe ---
(In reply to Eric Gallager from comment #8)
> the MacPorts project applies the following patch to work around this issue:
> https://github.com/macports/macports-ports/commit/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #15 from Iain Sandoe ---
(In reply to Chris Jones from comment #14)
> Apologies, typo above. I meant to say the --without-build-config workaround
> no longer works with 11.2.0
OK.. I plan to do a Darwin/macOS 11.2 patch set this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
Iain Sandoe changed:
What|Removed |Added
Summary|Weird memory corruption |[9/10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-linux-gnu,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #11 from Iain Sandoe ---
(In reply to Matt Thompson from comment #10)
> Query from someone who I believe just encountered this trying to build 11.2
> on macOS 11.5.1 with XCode 12.5: What is the best method to work around this
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616
--- Comment #4 from Iain Sandoe ---
(In reply to Matt Jacobson from comment #3)
> As it happens, I'm targeting the NeXT v2 runtime, but I'm *not* actually
> targeting Darwin. So `flag_next_runtime` is just 1 for me--not an OS
> version value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #10 from Iain Sandoe ---
(In reply to Mosè Giordano from comment #6)
> Created attachment 51038 [details]
> Patch to fix the reported issue
>
> Please find attached a patch to fix the reported issue. I replaced the
> bashism +=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #9 from Iain Sandoe ---
(In reply to Martin Liška from comment #8)
> Sure, but I would like to first speak Iain who added the code.
> What do you think about the patch?
hm, sorry for introducing the bash-ism, the change LGTM but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Summary|[10/11/12 Regression] used |[10 Regression] used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93758
--- Comment #5 from Iain Sandoe ---
(In reply to Mojca Miklavec from comment #4)
> I'm sorry, I forgot about this ticket. I can confirm that building (version
> 11.1) in fact works on all macOS versions at the moment
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
--- Comment #10 from Iain Sandoe ---
*** Bug 101420 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420
--- Comment #12 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Avi Kivity from comment #10)
> > Reproduces on trunk:
> this looks like a dup of PR 96056 - but I am happy to check the reduced case.
erm PR 98056
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420
--- Comment #11 from Iain Sandoe ---
(In reply to Avi Kivity from comment #10)
> Reproduces on trunk:
>
> #7 0x00b439af in cp_build_modify_expr (loc=1376651745,
> lhs=0x7f0c55c12c60, modifycode=, rhs=0x7f0c55e63ee0,
> complain=) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420
--- Comment #6 from Iain Sandoe ---
(In reply to Avi Kivity from comment #5)
> How does one ask gcc to generate a backtrace on ICE?
It produces one when libbacktrace is available, not aware of needing to do
anything special; is there any other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101420
--- Comment #4 from Iain Sandoe ---
(In reply to Avi Kivity from comment #3)
> Adding Iain since the ICE happens in a coroutine. Meanwhile my desktop is
> reducing the testcase.
do you have a backtrace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #11 from Iain Sandoe ---
(In reply to Indu Bhagat from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to Iain Sandoe from comment #8)
> > > we are now left with (where I suspect that the remaining fails are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> we are now left with (where I suspect that the remaining fails are an
> artefact of the way in which Darwin represents offsets instead of
> relocations in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #8 from Iain Sandoe ---
we are now left with (where I suspect that the remaining fails are an artefact
of the way in which Darwin represents offsets instead of relocations in DWARF
debug sections):
Running target unix/-m64
Running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #5 from Iain Sandoe ---
(In reply to Richard Biener from comment #4)
> It might make sense to provide targets a means to opt-out of CTF/BTF support
> and thus diagnose -gctf as unsupported on them.
In the short-term, I've got fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #3 from Iain Sandoe ---
(In reply to Indu Bhagat from comment #2)
> I see that .section directive needs a different semantic for Darwin. The
> DWARF debug_info section, for example, appears as:
>
> .section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
--- Comment #15 from Iain Sandoe ---
@dave
Perhaps you could post the patch at C#12 for review (it would be useful to get
this cleared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243
--- Comment #2 from Iain Sandoe ---
(In reply to Victor Burckel from comment #1)
> May be similar to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401
I agree this is likely to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
Iain Sandoe changed:
What|Removed |Added
CC||greed at ispsystem dot com
--- Comment #9
||iains at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Iain Sandoe ---
thanks for the report, this is already tracked in the mentioned PR
*** This bug has been marked as a duplicate of bug 98056 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #4 from Iain Sandoe ---
(In reply to Nils Gladitz from comment #3)
> Thanks for looking into this!
just speculation so far ...
> Any idea what the potential implications are?
Not yet.
> I assume I can't just ignore the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #2 from Iain Sandoe ---
hmm.
__D.9984.3.4 means that this is a frame variable that is a 'promoted' temporary
(promoted because its lifetime had to be extended across a suspend point by
copying it into the frame).
So, I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100897
--- Comment #3 from Iain Sandoe ---
(In reply to Leonard von Merzljak from comment #2)
> (In reply to Iain Sandoe from comment #1)
> Thank you for your comment. I tried it out and can confirm that I don't get
> a stack-overflow anymore if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100897
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850
--- Comment #4 from Iain Sandoe ---
(In reply to Vlad from comment #3)
> My bad. It's actually a UB. The lambda lifetime is just over by the moment
> of resumption of the co-routine.
(oddly enough) we were discussing thia in a BSI meeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #9 from Iain Sandoe ---
JFTR the Apple OSS folks comment:
"I checked with the clang team — it appears this was an unintentional
consequence of an upstream change: https://reviews.llvm.org/D75203. This
difference between debug vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #53 from Iain Sandoe ---
on macOS 10.15 (Darwin19) with r12-637-g56103737 comparing unpatched / patched.
-WARNING: 29_atomics/atomic_float/wait_notify.cc execution test program timed
out.
-FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #6 from Iain Sandoe ---
yet another permutation:
This one keeps the const-ness of the contents, but provides a CTOR.
Note the we build some of the gcov stuff with a C compiler and therefore this
has to be conditional on C++.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #52 from Iain Sandoe ---
(In reply to lucier from comment #51)
> /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/29_atomics/
> atomic_integral/wait_notify.cc -std=gnu++2a -pthread
> -fdiagnostics-plain-output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #50 from Iain Sandoe ---
(In reply to lucier from comment #49)
> > > Running
> > > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/
> > > conformance.exp ...
> > > WARNING: program timed out.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #17 from Iain Sandoe ---
to complete the set:
/src-local/gcc-master/configure
--prefix=/opt/iains/x86_64-apple-darwin20/gcc-12-0-0
--build=x86_64-apple-darwin20
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #48 from Iain Sandoe ---
(In reply to lucier from comment #47)
> I downloaded
> [Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline
> 2254b3233b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #5 from Iain Sandoe ---
(In reply to Jason Merrill from comment #3)
> (In reply to Jason Merrill from comment #2)
> > (In reply to Iain Sandoe from comment #1)
> > > I am by no means an expert at reading standardese - and it might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #4 from Iain Sandoe ---
great, that does simplify things - and means that a useful error can be
diagnosed from a mismatched type between g_r_o/g_r_o_o_a_f and the coroutine
ramp return value.
The statement about phasing of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #4 from Iain Sandoe ---
for the record the patch in comment #3 allowed bootstrap to succeed on Darwin12
with clang 3.4-based Xcode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
--- Comment #1 from Iain Sandoe ---
I am by no means an expert at reading standardese - and it might be that I'm
not alone, (library writers might have made the same assumption) but it seems
to me that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #16 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #15)
> One thing that e.g. changed is that there is now a newer version of Apple
> Clang.
XCode 12.5 is broken, with compare-debug error : see PR100340 (already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #14 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #13)
> The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
> debug output, I see that Spack inserts a "-march=skylake" command line
> option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #11 from Iain Sandoe ---
I also tried on a xeon w machine with darwin19 (macOS 10.15), where it detects
skylake-avx512 (which is a reasonable description, although possibly
cascadelake would be slightly more accurate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #10 from Iain Sandoe ---
build of 11.1 on macOS11 with no patches and default options
$ ./gcc/xgcc -Bgcc /source/test/general/empty-main.c -S -fverbose-asm
head -5 empty-main.s
# GNU C17 (GCC) version 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #8 from Iain Sandoe ---
(In reply to Richard Biener from comment #7)
> (In reply to Iru Cai from comment #6)
> > I've checked host_detect_local_cpu() in gcc/config/i386/driver-i386.c. GCC
> > detects x86 host CPU micro architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #12 from Iain Sandoe ---
(In reply to Richard Biener from comment #11)
> Created attachment 50759 [details]
> updated patch
>
> Fixed missing setting of wi.stmt in lower_emutls_phi_arg
I regstrapped r12-248+ first patch (I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #10 from Iain Sandoe ---
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x0001016a4bb3 cc1`::gimple_code(g=0x) at
gimple.h:1782
1779 static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #3 from Iain Sandoe ---
Alan Modra posted the following alternate patch (which I will test with a
clang-3.5 bootstrap):
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 97d6f3863cb..cc3b1b6d666 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #7 from Iain Sandoe ---
of course, this could be exposing some prexisting problem (but i did check that
the previous revision did not show the problem). -fno-ipa-ra makes no
difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #6 from Iain Sandoe ---
master @r12-438 doesn't fail compare debug (maybe some later change masks this)
I think this will reproduce on a stage 1..
reduced:
a;
_Thread_local b;
c() {
long d = b;
a = 0;
b = 0;
}
cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #4 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Richard Biener from comment #2)
> > Doesn't reproduce on x86_64-linux with bootstrapping with in-tree mpfr 4.1.0
>
> it might well be some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #3 from Iain Sandoe ---
(In reply to Richard Biener from comment #2)
> Doesn't reproduce on x86_64-linux with bootstrapping with in-tree mpfr 4.1.0
it might well be some corner-case, but Darwin is PIC by default, so it might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #46 from Iain Sandoe ---
Created attachment 50737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50737=edit
trial patch for testing
looking at the way other ports handle things like use of registers in veneers
etc. it seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #45 from Iain Sandoe ---
the i386 backend code already sets :
TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true unconditionally.
So, it seems that it might be necessary to find some way to adjust
CALL_INSN_FUNCTION_USAGE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
--- Comment #1 from Iain Sandoe ---
this happens with mpfr-4.x sources and not with mpfr-3.1.6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
Iain Sandoe changed:
What|Removed |Added
Keywords||build
Target|
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 50725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50725=edit
tarball with asm, objects and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #7 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #6)
> (In reply to Richard Biener from comment #5)
> > Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to
> > optimizing?). To rule out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #6 from Iain Sandoe ---
(In reply to Richard Biener from comment #5)
> Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to
> optimizing?). To rule out compare-debug issues also try
> --without-build-config
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
--- Comment #6 from Iain Sandoe ---
(In reply to anlauf from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > gcc304 is the Apple M1 machine. The GCC support there is highly
> > experimental and not in master -- please note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269
--- Comment #1 from Iain Sandoe ---
Created attachment 50705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50705=edit
patch under test
It doesn't seem that the rationale for the changes in r12-35/36 is captured
anywhere I could find -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2021-04-26
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
With the fix at r12-50-ga44895ce7ffbc26b4d765c40b5b346f8c9a9b762 applied,
bootstrap still fails for a 32b host with a 64b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
--- Comment #1 from Iain Sandoe ---
Created attachment 50669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50669=edit
Patch that works around the clang issue/bug
this is against GCC-11.1rc2, but not likely to need much/any amendment for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #44 from Iain Sandoe ---
unfortunately, wider testing showed sanitiser fails - so this has been reverted
for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Iain Sandoe changed:
What|Removed |Added
Host||x86_64-darwin12,
|
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
using CC=clang and CXX="clang++ -stdlib=libc++" which is needed to get C++11
support.
In file inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Target Milestone|10.4|8.5
--- Comment #42 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #41 from Iain Sandoe ---
(In reply to Richard Biener from comment #40)
> (In reply to Richard Biener from comment #39)
> > (In reply to Iain Sandoe from comment #38)
> > > (In reply to Richard Biener from comment #37)
> > > > Oh,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #38 from Iain Sandoe ---
(In reply to Richard Biener from comment #37)
> Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem
> to reproduce the issue with the reduced testcase (I seee no call to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #36 from Iain Sandoe ---
(In reply to Richard Biener from comment #35)
> Which means another possible candidate for the "bug" is darwin_binds_local_p
yeah... see below.
> > > .. but something similar must apply to PLT and targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #32 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #31)
> (In reply to Richard Biener from comment #30)
> > (In reply to Iain Sandoe from comment #29)
> > > what is also somewhat peculiar is that replacing the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #31 from Iain Sandoe ---
(In reply to Richard Biener from comment #30)
> (In reply to Iain Sandoe from comment #29)
> > what is also somewhat peculiar is that replacing the first function in the
> > reduced test case with "extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #29 from Iain Sandoe ---
what is also somewhat peculiar is that replacing the first function in the
reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes the
code-gen for the second function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #28 from Iain Sandoe ---
reduced test case:
___UTF_8_put(char *a, int b) {
char *c = a;
int bytes;
if (b <= 15)
bytes = 2;
else if (b <= 255)
bytes = 4;
else if (b <= 4095)
bytes = 5;
else
bytes = 6;
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin19.6.0 |x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
--- Comment #4 from Iain Sandoe ---
(In reply to Ignacio Fernández Galván from comment #3)
> If it helps, this happens in gcc304 from
> https://cfarm.tetaneutral.net/machines/list/, but not in gcc80
gcc304 is the Apple M1 machine. The GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #22 from Iain Sandoe ---
so it looks like the contents of r10 are being trashed by the call to
___UTF_8_put (the first call goes through the dylib lazy symbol resolution and
that leaves r10 with a value pointing to some mutex).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #21 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #19)
> (In reply to lucier from comment #18)
> > I can't see to build mainline on this machine, it fails with
> Yeah, there have been some patches pushed in early to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #20 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #17)
> (In reply to lucier from comment #16)
> > I have figured out how to build and then run the app in lldb to reliably
> > reproduce the error.
> I will try later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #19 from Iain Sandoe ---
(In reply to lucier from comment #18)
> I can't see to build mainline on this machine, it fails with
>
> ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier
> 'TARGET_ISA_64BIT'
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #15 from Iain Sandoe ---
I have to try and figure out a way to be able to reproduce the run-time error.
Yes, the assembler output is different between 10.2 and 10.3 - but that insn is
not apparently in error (and I checked that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #11 from Iain Sandoe ---
(In reply to lucier from comment #10)
> (In reply to Iain Sandoe from comment #8)
> > (In reply to lucier from comment #7)
> > > (In reply to Iain Sandoe from comment #6)
> > >
> > > > yes please - also the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #8 from Iain Sandoe ---
(In reply to lucier from comment #7)
> (In reply to Iain Sandoe from comment #6)
>
> > yes please - also the original source, if that's OK?
>
> It's highly macrofied C code with a lot of "includes"; is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #6 from Iain Sandoe ---
(In reply to lucier from comment #5)
> I didn't have this trouble with 10.2 or 9.3; should I add these to the
> "Known to work" field?
yes please - also the original source, if that's OK?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #4 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #3)
> please could you check the uploaded assembly file, it seems to be truncated?
Ignore that - decompressor glitch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #1 from Iain Sandoe ---
I think that this issue is already fixed in the released 10.3 branch and in
master (will shortly become GCC11). Please could you try one of those?
$ ./gcc-10/gcc-10/bin/g++ -std=c++20 -fcoroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-darwin, i686-darwin
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
On the RC1 for 10.3
=== libstdc++ Summary ===
# of unexpected failures51
of the form
Excess errors:
/src-local
701 - 800 of 2693 matches
Mail list logo
