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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100901
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373
Bug ID: 100373
Summary: [12 Regression] Darwin, Compare-debug fail after
r12-248-gb58dc0b803057
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269
Bug ID: 100269
Summary: [12 Regression] i686 biarch compiler fails for Darwin
after r12-36.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
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,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Bug ID: 100246
Summary: [11/12 Regression] GCC will not bootstrap with clang
3.4/3.5 [xcode 5/6, Darwin 12/13]
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875
Bug ID: 99875
Summary: [10 Regression] experimental filesystem fails on
Darwin
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
Iain Sandoe changed:
What|Removed |Added
CC||inf17092 at lehre dot
dhbw-stuttga
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99827
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #29 from Iain Sandoe ---
(In reply to Piotr Kubaj from comment #28)
> I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1:
> gmake[4]: Entering directory
> '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc'
> c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
--- Comment #17 from Iain Sandoe ---
ping for closing this - or new information otherwise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #33 from Iain Sandoe ---
Have we now resolved this issue?
All current open branches work OK for me on all Darwin versions from 10.4 -
11.2.
Please update if there is still something to fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96318
Iain Sandoe changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95616
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97587
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95822
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98480
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98704
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 96749, which changed state.
Bug 96749 Summary: [coroutines] unexpected 'warning: statement has no effect
[-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98118
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 99733, which changed state.
Bug 99733 Summary: darwin: missing ':' in error message about munmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656
--- Comment #9 from Iain Sandoe ---
(In reply to Eric Gallager from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > fixed on master
> > e.g.
> > https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669584.html
>
> So... are we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Nils Gladitz from comment #7)
> > (In reply to Nils Gladitz from comment #5)
> > > Apparently when the coroutine happens to be a member function (even a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #8 from Iain Sandoe ---
(In reply to Nils Gladitz from comment #7)
> (In reply to Nils Gladitz from comment #5)
> > Apparently when the coroutine happens to be a member function (even a static
> > one) printing *frame_ptr results in
701 - 800 of 935 matches
Mail list logo
