https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673
--- Comment #20 from Iain Sandoe ---
(In reply to Jason Merrill from comment #19)
> (In reply to Jason Merrill from comment #18)
> > (In reply to Iain Sandoe from comment #16)
> > > + if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #10 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > (In reply to Jakub Jelinek from comment #7)
> > > The last progress I see is Jason's patch review comments in
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #8 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #7)
> The last progress I see is Jason's patch review comments in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671258.html
> Iain, any progress since then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782
--- Comment #20 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #19)
> (In reply to Iain Sandoe from comment #18)
> > (In reply to Sergey Fedorov from comment #17)
> > > (In reply to Iain Sandoe from comment #16)
> > >
> > > Why no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782
--- Comment #18 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #17)
> (In reply to Iain Sandoe from comment #16)
>
> Why not use `llas` (which only needs LLVM) instead of `clang` (which needs
> LLVM + clang)?
> I have seen in some
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=102259
--- Comment #9 from Iain Sandoe ---
(In reply to Jonathan Wakely from comment #8)
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671057.html
>
> It would be great if somebody could test this on macOS and/or FreeBSD to
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=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=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 #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 #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 #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=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=117553
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2024-11-13
Status|UNCONFIRMED
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=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=117478
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
Last reconfirmed||2024-11-07
Assignee|unassigned
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=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=117455
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
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=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 #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=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 #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=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=117431
Iain Sandoe changed:
What|Removed |Added
Keywords||c++-contracts
Last reconfirmed|
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=116607
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=116506
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=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
Status|ASSIGNED|WAITING
--- Comment #11 from Iain Sandoe
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=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
--- 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=117114
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
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=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=117110
Iain Sandoe changed:
What|Removed |Added
Keywords||build
Target Milestone|---
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=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=98935
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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=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=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
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=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=116853
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=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 #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=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
--- 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=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=116237
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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 #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
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 #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=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=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=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 #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 #10 from Iain Sandoe ---
unfortunately, (or ...) I Have not succeeded in reproducing this - so will need
some help to identify what's being done differently from you.
I built: r15-3667-gf5448384a213 (also on my Darwin17+ set, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #8 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #5)
> >> The new test causes a SIGBUS on 32-bit Solaris/SPARC
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #6 from Iain Sandoe ---
(In reply to Rainer Orth from comment #5)
> The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11):
Is this reproducible on any current cfarm machine?
(or, I guess, on a cross?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #7 from Iain Sandoe ---
(In reply to Arsen Arsenović from comment #6)
> I think it'd be okay to just add the testcase as a regression test consider
> this resolved. WDYT, Iain?
yes - if it's no longer reproducible - then adding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
--- Comment #8 from Iain Sandoe ---
(In reply to Artyom Kolpakov from comment #7)
> (In reply to Iain Sandoe from comment #6)
> > fixed on trunk, waiting for possible back-port
>
> I'm not sure if I should write this here, but now a warning has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #10 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110635
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908
Iain Sandoe changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Iain Sandoe
1 - 100 of 1102 matches
Mail list logo
