https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-06-29
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #1 from Iain Sandoe ---
The problem with fixing this is that I cannot reproduce it; we are still trying
to determine if there's some dependency on environment - or maybe something
bizarre like the installed version of some utility li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #2 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #1)
> NOTE: my compiler builds and tests do not include any macports or homebrew
> components. The only additional content in my PATH is 1) texinfo-6.7 2)
> dejagnu and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
--- Comment #3 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port - but leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
--- Comment #2 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port, leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
--- Comment #2 from Iain Sandoe ---
fixed on trunk, not sure if we need to back port, leaving open for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
--- Comment #5 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #4)
> the latter seems OK to me - mind proposing a patch?
I am planning on doing some rework on the ramp code-gen in the (very) near
future - so can pick this up on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #8 from Iain Sandoe ---
(In reply to Eric Gallager from comment #7)
> Well ok, could someone send me a binary x86_64 build of GCC for darwin20
> with Ada support that they can bootstrap with successfully, then, so that I
> can get ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021
--- Comment #10 from Iain Sandoe ---
(In reply to Eric Gallager from comment #9)
> Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that
> I need to set GNATLINK in my environment, too, besides just GNATMAKE and
> GNATBIND.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115660
--- Comment #5 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #4)
> this PR was fixed by r14-8437-g44868e7298de50 (fix for PR c++/109227).
>
> iain, jason, should we backport that patch? (and resolve that PR?)
seems reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
--- Comment #18 from Iain Sandoe ---
Created attachment 59340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59340&action=edit
patch under test
The coroutines implementation (intentionally) did not include support for ({})
which is an ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
--- Comment #5 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> I'm leaning towards reversion of the r15-4290 and partial reversion of
> r15-4286 (Makefile.in bits and some genmatch.cc bits) and reimplementing
> whatever libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117114
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> I am actively working on this (hypothesis is that it is related to use of
> statement expressions)
The original no longer ICEs with my current patch set, the reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506
--- Comment #3 from Iain Sandoe ---
Created attachment 59334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59334&action=edit
Updated patch addressing review comments
To be retested and posted - please test if you have time,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #17 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #11 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117110
Iain Sandoe changed:
What|Removed |Added
Keywords||build
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116980
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116607
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117364
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #16 from Iain Sandoe ---
let's move the Sparc bug to a new one (PR117364) since it's not directly
related to this fix at all (just triggered by the test case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117364
Bug ID: 117364
Summary: [12/13/14/15 Regression][coroutines] Use of
triggers an ICE on spare
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117364
--- Comment #3 from Iain Sandoe ---
(In reply to Eric Botcazou from comment #2)
> > This does not seem morally different from NVRO.
>
> Yes, that's perfectly fine.
>
> > At present, I do not have a handle on where the actual issue is - since
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116607
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117441
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #9 from Iain Sandoe ---
(In reply to kargls from comment #8)
> (In reply to Iain Sandoe from comment #7)
>
> /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack
> (because the .note.GNU-stack section is executabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #7 from Iain Sandoe ---
OK, so trying to understand if there is still an issue with trampolines ( as
noted before, AFAIU gfortran has been using trampolines for a very long time,
so one might expect to have seen fallout before ).
1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117431
Bug ID: 117431
Summary: [contracts] contracts on lambdas are sometime ignored
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117431
Iain Sandoe changed:
What|Removed |Added
Keywords||c++-contracts
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117435
Bug ID: 117435
Summary: [contracts] capture of a function parm in a lambda in
a contract does not work
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #11 from Iain Sandoe ---
(In reply to kargls from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to kargls from comment #8)
> > > (In reply to Iain Sandoe from comment #7)
> > >
> >
> > > /usr/local/bin/ld:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #5 from Iain Sandoe ---
(In reply to Richard Biener from comment #4)
> The executable stack thing happens when a trampoline is required to handle
> the nested function. Optimization will sometimes elide the nested function
> call vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #9 from Iain Sandoe ---
(In reply to rguent...@suse.de from comment #8)
> On Sat, 9 Nov 2024, iains at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
> >
> > Iain Sandoe changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
--- Comment #11 from Iain Sandoe ---
(In reply to rguent...@suse.de from comment #10)
> On Mon, 11 Nov 2024, iains at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
> >
> > --- Comment #9 from Iain Sandoe ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117553
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-11-13
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #12 from Iain Sandoe ---
hmm .. this is initialising the ramp return object (which is a handle) and when
I look at the to and from trees they seem to have the requisite alignment (the
from value is a return from operator new). I'm a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #13 from Iain Sandoe ---
looking like a GTY issue:
(gdb) p target->u.fld[1]->rt_mem
$7 = (mem_attrs *) 0xafafafaf
(gdb) p target->u.fld[1]->rt_mem->align
that seems to be the tell-tale value for a free ptr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #14 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #13)
> looking like a GTY issue:
>
> (gdb) p target->u.fld[1]->rt_mem
> $7 = (mem_attrs *) 0xafafafaf
> (gdb) p target->u.fld[1]->rt_mem->align
>
> that seems to be the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #16 from Iain Sandoe ---
FAOD:
- The current patch is to remove at macOS-15
- I have tested on systems that need to keep the lib
- FX is testing on macOS 15.
* I have already pushed the dependent patch that limits the libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #7 from Iain Sandoe ---
Created attachment 59177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59177&action=edit
patch for GCC-14 (***untested)
this is against the current darwin gcc-14 branch - it is completely untested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #9 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #8)
> (In reply to Iain Sandoe from comment #2)
> > Created attachment 59176 [details]
> > Patch under test
>
> Does not apply to upstream GCC. I think it nee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116237
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #1 from Iain Sandoe ---
yeah..
the compiler will not (for some several revisions) actually refer to
libgcc_s.1.dylib - it is only there to support existing built exes from older
compilers.
Probably dropping it after macOS 14 is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #4 from Iain Sandoe ---
(In reply to Chris Jones from comment #3)
> CN you prepare a version of the patch for the current gcc14 release ?
I guess you tried applying the attached patch and it does not ?
you mean for the Arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #11 from Iain Sandoe ---
Indeed, all of this is well-known;
NOTE: there is no change proposed for any OS < macOS 15.
We actually bumped our libgcc_s version some time ago because GCC has for a
while now been pulling the unwinder di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #14 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #12)
> Created attachment 59179 [details]
> Drop removed unwind symbols
>
> This implements what I referred to as my preferred option in comment 10. It
> should apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
Bug ID: 116853
Summary: [Regression 15] Bootstrap fails on *-darwin* after
r15-3859-g63a598deb0c9
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #4 from Iain Sandoe ---
(In reply to Rainer Orth from comment #3)
> The patch also broke Solaris bootstrap; will report that separately.
likewise *-darwin* (also have a report in preparation).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #21 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #20)
> Created attachment 59189 [details]
> Patch for macOS 14/Xcode 16
>
> (In reply to GCC Commits from comment #19)
> > The master branch has been updated by Iain D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #7 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > > #if defined(__has_feature) && __has_feature(modules)
> >
> > This is a bug. If __has_feature is _not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775
--- Comment #6 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> So, e.g. co_await_find_in_subtree/await_statement_expander/find_any_await
> and maybe other coroutines.cc cp_walk_tree callbacks could use some helper
> for CALL_E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853
--- Comment #4 from Iain Sandoe ---
fixed on Darwin, if it also works for Solaris then please feel free to close
the BZ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2024-09-28 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880
--- Comment #5 from Iain Sandoe ---
Created attachment 59220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59220&action=edit
patch under test
Here is what I'm testing - if you have a chance to test it in your scenario
that would be great
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777
--- Comment #7 from Iain Sandoe ---
as noted in several places; the long-term solution for Darwin (in general since
there's an installed /usr/lib/libstdc++.6.dylib even on modern systems) - is
for use to use an inline namespace for libstdc++ (al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-10-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #28 from Iain Sandoe ---
Folks - we all want ponies...
... but remember this is a toolchain - it is quite complex; expecting any
random permutation of things that you happen to choose to DTRT will probably
disappoint you.
Xcode doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #25 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > OK. I don't want to argue about the details / usability etc. etc. ( but note
> > that __symbols are for the implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #23 from Iain Sandoe ---
(In reply to Mark Mentovai from comment #22)
> (In reply to Iain Sandoe from comment #21)
> > Thta is quite surprising - since the SDK should reflect the symbols exported
> > by the libraries installed on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809
--- Comment #30 from Iain Sandoe ---
(In reply to Chris Jones from comment #29)
> Iains, I was not trying to suggest with my last post what you should
> support, that is entirely up to you and we are very grateful for what you do
> do.
>
> I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116490
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117478
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-11-07
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117478
--- Comment #4 from Iain Sandoe ---
-ObjC is not exactly clang-specific - AFAIR it was supported by Apple gcc-4.x
as well,
Perhaps we can support it as a driver flag (which is used as shorthand for -x
objective-c)
I'm short of time at the mome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117478
--- Comment #6 from Iain Sandoe ---
fine with fixing it upstream - but also OK with trying to be compatible (esp.
with facilities that were present for ≈ 20 years, if those are not to intrusive
to arrange).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #5 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #4)
> Thanks. If so,
Looking at the generated code (input to the coroutine lowering) it seems highly
likely that this results from the use of a statement expression co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #3 from Iain Sandoe ---
with my local patches (which I will ping this week) I see:
$ ./gcc/xg++ -Bgcc -std=c++2c
/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/pr117231.C -o t
./t
1
2
3
So this is possibly a non-obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
Iain Sandoe changed:
What|Removed |Added
Summary|ld warning about executable |Nested function use gives a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117478
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857
--- Comment #9 from Iain Sandoe ---
(In reply to Gleb Mazovetskiy from comment #8)
> > The warning was changed to an error by default for GCC 14
>
> Ah, makes sense, thanks for explaining. I'm guessing it went unnoticed
> because the failure co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834
--- Comment #9 from Iain Sandoe ---
(In reply to Gleb Mazovetskiy from comment #8)
> > If you want to make progress, and help keep it alive, then the best way is
> > to test regularly - in this case you need to bisect to find what change
> > c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117834
--- Comment #7 from Iain Sandoe ---
(In reply to Eric Gallager from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > This is not going to be fixed. Mac OS X 10.4 has not been supported for
> > years now as GCC. At least update to Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857
--- Comment #11 from Iain Sandoe ---
(In reply to Eric Gallager from comment #10)
> I think just ensuring that -D__DARWIN_UNIX03=1 is always passed to the
> preprocessor ought to be enough...
You can try it .. but the Darwin SDK headers are fie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857
--- Comment #12 from Iain Sandoe ---
it looks like this ...
#if !defined(__DARWIN_UNIX03)
#if defined(_APPLE_C_SOURCE) || defined(_XOPEN_SOURCE) ||
defined(_POSIX_C_SOURCE) || defined(__LP64__)
#if defined(_NONSTD_SOURCE)
#error "Can't define b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117857
--- Comment #13 from Iain Sandoe ---
so, in this case, it might work - and we could probably arrange to set that
flag by default for darwin8 (and maybe 9) on 32b hosts [64b is always UNIX03
already].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118237
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #6 from Iain Sandoe ---
(In reply to Sam James from comment #5)
> Unfortunately, it looks like the fixes weren't enough and the crashes are
> back when dropping -fno-range-for-ext-temps.
ack
does https://gcc.gnu.org/bugzilla/show_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #16 from Iain Sandoe ---
I wonder if this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897 is of any
relevance?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #19 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #17)
> Note, even the D {} temporary goes into function local vars rather than in
> the narrower scope.
hmm. This might be an underlying problem, the coroutines code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #24 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #23)
> Or could we try to walk all the cleanups queued at the end of the range-for
> and pushdecl any temporaries mentioned in there if they don't have DECL_NAME
> yet?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #21 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #20)
> Note, even just
> But in the range-for case, the lifetime of those temporaries doesn't end at
> the end of the statement but is until the end of the range for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #16
1001 - 1100 of 1299 matches
Mail list logo
