https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #14 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Thu Nov 22 06:14:47 2018
New Revision: 266366
URL: https://gcc.gnu.org/viewcvs?rev=266366=gcc=rev
Log:
libphobos/ChangeLog:
2018-11-22 Johannes Pfau
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704
--- Comment #16 from Eric Gallager ---
(In reply to Iain Sandoe from comment #15)
> Author: iains
> Date: Wed Aug 22 12:12:46 2018
> New Revision: 263768
>
> URL: https://gcc.gnu.org/viewcvs?rev=263768=gcc=rev
> Log:
> Make the gcc-ar,nm, strip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88145
Bug ID: 88145
Summary: ICE: unrecognizable insn (mffs) targeting 32-bit BE
FPU-less powerpc CPUs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #5 from Arseny Solokha ---
And if my guess that the problem is somehow related to the handling of FPU-less
cores in the rs6000 and powerpcspe backends is correct, than I see whan might
be another manifestation of that issue:
%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
--- Comment #1 from Andrew Pinski ---
I think one of the reasons why it has not been removed is there is still code
out there that uses this syntax.
If anything we should add a warning about it first if we are going to remove
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37760
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88141
--- Comment #1 from Joshua Morrison ---
I should also add that my installation of MSYS2 is up-to-date, including the
installation of texinfo. This is what makeinfo outputs when you pass it -V:
$ makeinfo -V
texi2any (GNU texinfo) 6.5
Copyright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
Bug ID: 88144
Summary: remove long-obsolete syntax for designated
initializers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88123
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #17 from Vladimir Makarov ---
I've reproduced it. Clearly, it is some bug in LRA conflict calculation. I
will be working on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #4 from Arseny Solokha ---
(In reply to rguent...@suse.de from comment #3)
> The
> powerpc64[le]-linux crosses insist that -mcpu=860 requires a 64bit CPU...
Which is strange, as 860 is a 32-bit CPU w/o FPU (perhaps a key here?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53182
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Eric Botcazou ---
>> Anybody should be able to reproduce this problem. My guess is a logic error.
>
> I'm not sure whether we still support the native assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Eric Botcazou changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88143
Bug ID: 88143
Summary: gfortran crashes with an internal compiler error
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #12 from Tom de Vries ---
Created attachment 45063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45063=edit
combined patch
> Can you attach one single patch from trunk?
Patch combining:
- Updated patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118
--- Comment #6 from Tiago Macarios ---
Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=39731
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88122
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 21 22:42:09 2018
New Revision: 266360
URL: https://gcc.gnu.org/viewcvs?rev=266360=gcc=rev
Log:
PR c++/88122
* method.c (maybe_explain_implicit_delete): If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87386
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 21 22:41:07 2018
New Revision: 266359
URL: https://gcc.gnu.org/viewcvs?rev=266359=gcc=rev
Log:
PR c++/87386
* parser.c (cp_parser_primary_expression): Use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #16 from Gary Mills ---
I have a clue now. I built gcc-7 on OI-SPARC with the GNU assembler. The
build
was successful. xgcc worked, without the ICE. Clearly the ICE only happens
when gcc-7 is configured with the native assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80506
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83140
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
--- Comment #10 from emsr at gcc dot gnu.org ---
I'll look at updating the pedantic warn patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88142
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88142
Bug ID: 88142
Summary: [9 Regression] ICE in lto_warn at ipa-devirt.c:1020
since r265519
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #32 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 21 20:45:59 2018
New Revision: 266357
URL: https://gcc.gnu.org/viewcvs?rev=266357=gcc=rev
Log:
PR rtl-optimization/85925
* gcc.c-torture/execute/20181120-1.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #11 from Ian Lance Taylor ---
Sorry, I've gotten confused. Can you attach one single patch from trunk?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #18 from Segher Boessenkool ---
Your "trivial rewrite" does not work at all (you didn't modify "h").
It isn't trivial to avoid this warning at all, which was half of my point.
The other half is that we should not warn that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:18:45 2018
New Revision: 266356
URL: https://gcc.gnu.org/viewcvs?rev=266356=gcc=rev
Log:
PR middle-end/88129
* function.c (expand_function_end): Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667
--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:09:56 2018
New Revision: 266355
URL: https://gcc.gnu.org/viewcvs?rev=266355=gcc=rev
Log:
PR target/85667
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88118
--- Comment #5 from Marc Glisse ---
"An implementation is allowed to omit a call to a replaceable global allocation
function" (not any operator new) so I am not sure DECL_IS_OPERATOR_NEW is the
right test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88141
Bug ID: 88141
Summary: Issues with texinfo when building GCC r266351 in MSYS2
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Wed Nov 21 18:40:55 2018
New Revision: 266353
URL: https://gcc.gnu.org/viewcvs?rev=266353=gcc=rev
Log:
PR libstdc++/88111 Make maximum block size depend on size_t width
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88113
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88113
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Nov 21 18:40:37 2018
New Revision: 266352
URL: https://gcc.gnu.org/viewcvs?rev=266352=gcc=rev
Log:
PR libstdc++/88113 use size_type consistently instead of size_t
On 16-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
Bug ID: 88140
Summary: [9 Regression] ICE: verify_gimple failed since r266325
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86899
--- Comment #3 from Jakub Jelinek ---
block_may_fallthru on:
try
{
return = 0;
if (0)
{
return = 0;
}
}
finally
{
A::~A ();
}
suggests that it may fall thru, because generally it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #23 from joseph at codesourcery dot com ---
And, yes, at least one extra bit in emin is needed for that sticky
rounding code to work (because the user's source code may have a decimal
constant that is slightly over half the least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #22 from joseph at codesourcery dot com ---
On Wed, 21 Nov 2018, rguenther at suse dot de wrote:
> /* Nonzero value, possibly overflowing or underflowing. */
> mpfr_init2 (m, SIGNIFICAND_BITS);
> inexact =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86899
--- Comment #2 from Jakub Jelinek ---
Doesn't seem to be a real regression to me, we've only stopped warning about
this with -Wreturn-type -fsanitize=thread in r254437 and started again in
r255403, that is less than month and no releases have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88139
Bug ID: 88139
Summary: ICE in get_c_type_name, at
fortran/dump-parse-tree.c:3047
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88138
Bug ID: 88138
Summary: ICE in gfc_arith_concat, at fortran/arith.c:1007
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83953
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #2 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
--- Comment #8 from Jakub Jelinek ---
As a workaround, you can use -mstack-protector-guard=global on these targets
(together with -fstack-protector{,-all,-strong,-explicit}).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644
--- Comment #5 from Jakub Jelinek ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c7 for more details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Wed Nov 21 17:32:19 2018
New Revision: 266351
URL: https://gcc.gnu.org/viewcvs?rev=266351=gcc=rev
Log:
PR lto/87957
* g++.dg/lto/odr-1_0.C: Extend by mismatched enum.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #9 from Jan Hubicka ---
Author: hubicka
Date: Wed Nov 21 17:31:19 2018
New Revision: 266350
URL: https://gcc.gnu.org/viewcvs?rev=266350=gcc=rev
Log:
PR lto/87957
* tree.c (fld_decl_context): Break out from ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85644
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137
Bug ID: 88137
Summary: BACKTRACE seems to have a memory leak
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #17 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #16)
> Something as trivial as this
>
> ===
> void h(int (*)(void));
> void f(int x)
> {
> int g(void) { return x; }
> h(g);
> }
> ===
>
> will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #10 from Tom de Vries ---
(In reply to Tom de Vries from comment #9)
> Created attachment 45059 [details]
> Second followup patch
>
> > [ OTOH, that's a memory leak in the fail
> > case, but corresponds to unused memory in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
--- Comment #9 from Steve Kargl ---
On Wed, Nov 21, 2018 at 08:59:08AM -0800, Steve Kargl wrote:
> On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
> >
> > --- Comment #6 from Thomas Koenig ---
> > The type has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
--- Comment #8 from Steve Kargl ---
On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
>
> --- Comment #6 from Thomas Koenig ---
> The type has SEQUENCE, so I think this should actually work... or did I miss
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867
Mihail Ionescu changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867
--- Comment #3 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Nov 21 16:50:37 2018
New Revision: 266348
URL: https://gcc.gnu.org/viewcvs?rev=266348=gcc=rev
Log:
2018-11-21 Mihail Ionescu
gcc/
PR target/87867
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87393
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87393
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 21 16:42:34 2018
New Revision: 266347
URL: https://gcc.gnu.org/viewcvs?rev=266347=gcc=rev
Log:
PR c++/87393
* parser.c (cp_parser_linkage_specification): Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87839
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 21 16:41:03 2018
New Revision: 266346
URL: https://gcc.gnu.org/viewcvs?rev=266346=gcc=rev
Log:
PR target/87839
* config/aarch64/atomics.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
--- Comment #7 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #6)
> The type has SEQUENCE, so I think this should actually work... or did I miss
> something here?
It does seem to be not well defined. The preprocessor will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87393
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88111
--- Comment #4 from Jonathan Wakely ---
(In reply to Jozef Lawrynowicz from comment #3)
> Your patch fixes the build, thanks.
Great, thanks for checking it.
I'll come up with a fix for Bug 88113 before I commit anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #16 from Segher Boessenkool ---
Something as trivial as this
===
void h(int (*)(void));
void f(int x)
{
int g(void) { return x; }
h(g);
}
===
will already do. *Anything* that needs trampolines will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #9 from Tom de Vries ---
Created attachment 45059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45059=edit
Second followup patch
> [ OTOH, that's a memory leak in the fail
> case, but corresponds to unused memory in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Tom de Vries changed:
What|Removed |Added
Attachment #45057|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468
--- Comment #6 from Jeffrey A. Law ---
More correctly, jump threading is duplicating a switch in which there's an
outgoing edge marked as EDGE_IGNORE. That duplicate has EDGE_IGNORE set, but
isn't in the cleanup queue. Thus it leaks into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #7 from Tom de Vries ---
Created attachment 45057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45057=edit
Followup patch
> [ Btw, note that if we move the u and pu allocations to before read_abbrevs,
> we can read the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87921
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87895
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87844
Richard Biener changed:
What|Removed |Added
Target Milestone|7.4 |---
Summary|[7/8/9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88122
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87446
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #2 from Ville Voutilainen ---
This is not just a Qt problem. I will write a proposal to undeprecate this
deprecation for C++20 before the next committee meeting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87366
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88122
--- Comment #3 from Jakub Jelinek ---
Actually no, I think the const_p computation is ok, it is only relevant for
const vs. non-const copy ctor or const vs. non-const copy assignment, right?
So I think my patch is the right thing here.
E.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #3 from rguenther at suse dot de ---
On Wed, 21 Nov 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #2 from Arseny Solokha ---
> Sure, will paste it tomorrow. In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88122
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #6 from Tom de Vries ---
Created attachment 45055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45055=edit
Updated patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> Comment on attachment 45048 [details]
> Proposed patch
>
> >@@ -1476,6 +1483,15 @@ build_address_map (struct backtrace_stat
> >backtrace_alloc (state,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136
--- Comment #1 from Richard Biener ---
We've been there before with -Wexpansion-to-defined though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88112
--- Comment #12 from rguenther at suse dot de ---
On Wed, 21 Nov 2018, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88112
>
> --- Comment #11 from Eric Botcazou ---
> (> So short of avoiding the streaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877
Renlin Li changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 191 matches
Mail list logo
