https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90135
Bug ID: 90135
Summary: std::map::at incorrectly included in C++03 mode
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #83 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #81)
> LLVM worked, so I think there are enough green lights now for committing
> this fix.
yeah, I had a few tests of my own to complete.
So - fixed on trunk
back por
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #12 from Richard Biener ---
(In reply to Ian Lance Taylor from comment #11)
> Fixed, I hope.
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90135
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90135
--- Comment #2 from Jonathan Wakely ---
FWIW, these days a proposal to add new member functions would almost certainly
not be handled as a defect report, and would require a proposal to add it to
the next revision of the standard. But things were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #1 from Richard Biener ---
So the assembler error is for code trying to handle
/* Do relax(). */
{
...
/* Most horrible, but gcc may give us some exception data that
is impossible to assemble, of the form
.ali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90135
--- Comment #3 from Andrew Gaul ---
I understand; thank you for sharing this background.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #2 from Richard Biener ---
Created attachment 46192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46192&action=edit
preprocessed source
With a cross to rx-elf
> ./configure --enable-languages=c,c++,lto --target=rx-elf --with-
t "GCC: (GNU) 9.0.1 20190418 (experimental) [trunk revision
269411]"
if I remove the .balign it assembles. Knowing nothing about RX I can't
say if this is to be solved in the assembler or the compiler but I note
that GCC 8 didn't align and the only backend change done for GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #4 from Richard Biener ---
That is, r262804 or more likely r262375 (not yet confirmed). This currently
causes sub-package FAILs for our GCC 9 package builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136
Bug ID: 90136
Summary: [d] Merge UDAs between function prototype and
definitions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136
Iain Buclaw changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #63 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.
That shouldn't be difficult, I've create PR d/90136 to keep track of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
--- Comment #3 from Richard Biener ---
I guess the basic issue again that we warn for unreachable code. Note
libdecnumber is barely maintained and quite a big mess...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90137
Bug ID: 90137
Summary: Using declaration (constructor inheritance) prevents
overriding
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Thu Apr 18 10:28:21 2019
New Revision: 270438
URL: https://gcc.gnu.org/viewcvs?rev=270438&root=gcc&view=rev
Log:
PR translation/79183
* gimple-ssa-sprintf.c (format_direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90137
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90137
--- Comment #2 from Konstantin Shegunov ---
Yes, this is the error I get.
What should happen instead is that compilation succeeds. Having the following
as declaration in using.h:
class DerivedPrivate;
class Derived final : public Base
{
public:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
Martin Liška changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #7 from rguenther at suse dot de ---
On Thu, 18 Apr 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
>
> Martin Liška changed:
>
>What|Removed |Added
>
--enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --with-tune=native
Thread model: posix
gcc version 9.0.1 20190418 (experimental) [trunk revision 270435] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90138
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #8 from Richard Biener ---
Btw, passing -relax to the assembler makes it assemble OK, producing
Disassembly of section P:
<_copy>:
0: ef 2e mov.l r2, r14
2: 61 0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90138
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #9 from Martin Liška ---
(In reply to rguent...@suse.de from comment #7)
> On Thu, 18 Apr 2019, marxin at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
> >
> > Martin Liška changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Thu Apr 18 12:02:40 2019
New Revision: 270441
URL: https://gcc.gnu.org/viewcvs?rev=270441&root=gcc&view=rev
Log:
2019-04-18 Richard Biener
PR debug/90131
* tree-cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #10 from Richard Biener ---
So it looks like gas does without -relax simply use bne.s which when used
explicitely results in
valarray.s: Assembler messages:
valarray.s:9: Error: jump not 3..10 bytes away (is 2)
a bne.s is one byte l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #11 from Richard Biener ---
Iff 'bne' is supposed to auto-"relax" then it is a GAS issue indeed.
Target maintainers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #64 from Bernd Edlinger ---
Okay, using Ian's suggestion I've got this now:
Index: libphobos/libdruntime/gcc/deh.d
===
--- libphobos/libdruntime/gcc/deh.d (revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #35 from Segher Boessenkool ---
Peter's patch solves this particular problem, but not the PR unfortunately.
I finally understand Jakub's comment 30. This patch solves the PR (also
without Peter's patch):
===
diff --git a/gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #36 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #35)
> Peter's patch solves this particular problem, but not the PR unfortunately.
>
> I finally understand Jakub's comment 30. This patch solves the PR (als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #84 from Zaak ---
Ian, Jurgen, et al.,
Thanks for your hard work getting the patch created and validated!
I'm a mac Homebrew maintainer, and was hoping to get a patch into the GCC-8
formula sooner rather than later as this Xcode reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Apr 18 12:29:56 2019
New Revision: 270442
URL: https://gcc.gnu.org/viewcvs?rev=270442&root=gcc&view=rev
Log:
Fix two ubsan failures (PR85164)
Two fixes for UB when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #10 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Apr 18 12:30:36 2019
New Revision: 270443
URL: https://gcc.gnu.org/viewcvs?rev=270443&root=gcc&view=rev
Log:
Fix UB in int_const_binop
When testing PR 85164, the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #37 from Segher Boessenkool ---
Yes, it is a balancing act. Which option works better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139
Bug ID: 90139
Summary: ICE in emit_block_move_hints, at expr.c:1601
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90138
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #38 from Wilco ---
(In reply to Segher Boessenkool from comment #37)
> Yes, it is a balancing act. Which option works better?
Well the question really is what is bad about movsi_compare0 that could be
easily fixed?
The move is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820
Bug 80820 depends on bug 81616, which changed state.
Bug 81616 Summary: Update -mtune=generic for the current Intel and AMD
processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #85 from fink at snaggledworks dot com ---
(In reply to Zaak from comment #84)
> Ian, Jurgen, et al.,
>
> Thanks for your hard work getting the patch created and validated!
>
> I'm a mac Homebrew maintainer, and was hoping to get a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
--- Comment #3 from Christophe Lyon ---
Sorry Martin I didn't noticed you were looking at this PR.
I've attached a small patch that checks whether %< has a "word" character
immediately before, rather than a space; otherwise it warns in cases whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #6 from Tony E Lewis ---
(also posted to the libc++ equiv: https://bugs.llvm.org/show_bug.cgi?id=35235)
Thanks to everyone involved in libc++, libstdc++ and wg21 for all work on this.
This makes sense to me. When the world is awash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #7 from Jonathan Wakely ---
(In reply to Tony E Lewis from comment #6)
> Do the changes arising from issue 3031 take retrospective effect on previous
> standards?
Yes.
> If not, is there an issue with libc++ / libstdc++ not adhering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #8 from Tony E Lewis ---
As far as I can see on Godbolt, this is now fixed in trunk. I'm happy for this
issue to be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
Jonathan Wakely changed:
What|Removed |Added
Known to work||8.2.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
--- Comment #8 from Tony E Lewis ---
That makes sense. Thanks for the quick and clear response.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159
--- Comment #5 from Marek Polacek ---
The warning is taking place in the front end, long before inlining/cprop has
run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139
--- Comment #1 from Jakub Jelinek ---
I'd say this is a tree-outof-ssa.c bug, in elim_create it calls get_temp_reg on
a SSA_NAME which has VECTOR_TYPE with one SFmode element, and as SPARC backend
doesn't have V1SFmode, it has BLKmode. Creating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #39 from Segher Boessenkool ---
On a linux kernel defconfig build it increases code size by 0.567%.
That seems a bit much :-(
The peephole only recognises
mov rA,rB
cmp rB,#0
and not
mov rA,rB
cmp rA,#0
or
cmp rB,#0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #40 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #39)
> On a linux kernel defconfig build it increases code size by 0.567%.
> That seems a bit much :-(
>
> The peephole only recognises
>
> mov rA,rB
> cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #86 from Zaak ---
> (In reply to fink from comment #85)
>
> Zaak,
> I have patches for Fink for gcc5-gcc8 release tarballs. I'm waiting for the
> gcc5 build to finish before I make a public commit, which should be tonight.
Thanks! I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #41 from Segher Boessenkool ---
(In reply to Wilco from comment #38)
> Well the question really is what is bad about movsi_compare0 that could be
> easily fixed?
"Easily fixed"... There is no such thing here.
Because it is a parall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #42 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #40)
> The question is what the code size differences would be with those changes
> (i.e. how often does it help not to have *movsi_compare0 make RA decisions
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90139
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #43 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #40)
> The question is what the code size differences would be with those changes
> (i.e. how often does it help not to have *movsi_compare0 make RA decisions
> worse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
--- Comment #5 from Jason Mancini ---
But bootstrap-O3 is a documented target, which is equivalent to BOOT_CFLAGS='-g
-O3', per https://gcc.gnu.org/install/build.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045
--- Comment #12 from Jeffrey A. Law ---
Nick has indicated this is a gas bug. Tracking via:
https://sourceware.org/bugzilla/show_bug.cgi?id=24464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #44 from Jakub Jelinek ---
Well, it requires that the RA looks specially for this kind of pattern and if
it ends up being a noop move, nothing simplifies the pattern again back to
normal comparison, and as Segher noted, it can negativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132
--- Comment #6 from Jakub Jelinek ---
Even in that case, several times in the past we've just decided to recommend
--disable-werror in those cases instead of adding too ugly workarounds for some
warnings (while for the default we always add worka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85414
Bug 85414 depends on bug 90095, which changed state.
Bug 90095 Summary: [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #87 from Iain Sandoe ---
(In reply to Zaak from comment #86)
> > (In reply to fink from comment #85)
> >
> > Zaak,
> > I have patches for Fink for gcc5-gcc8 release tarballs. I'm waiting for the
> > gcc5 build to finish before I make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |clyon at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #65 from Jakub Jelinek ---
Created attachment 46198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46198&action=edit
gcc9-pr89093.patch
So, can we converge to a single patch that does everything? Attached is
completely unteste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90140
Bug ID: 90140
Summary: Compiler incorrectly rejects use of pure functions in
DIMENSION attribute of procedure dummy arguments.
Product: gcc
Version: 8.3.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16798
--- Comment #9 from Segher Boessenkool ---
With all three patches together (Peter's, mine, Jakub's), I get a code size
increase of only 0.047%, much more acceptable. Now looking what that diff
really *is* :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90141
Bug ID: 90141
Summary: Missing test case for ambiguous -gdwarf command line
options
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90142
Bug ID: 90142
Summary: contrib/download_prerequisites uses test ==
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #46 from Segher Boessenkool ---
With all three patches together (Peter's, mine, Jakub's), I get a code size
increase of only 0.047%, much more acceptable. Now looking what that diff
really *is* :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90143
Bug ID: 90143
Summary: Add NetBSD in configure.ac
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #66 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #65)
> Created attachment 46198 [details]
> gcc9-pr89093.patch
>
> So, can we converge to a single patch that does everything? Attached is
> completely untested com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90144
Bug ID: 90144
Summary: Use portable test(1) in isl/configure
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90145
Bug ID: 90145
Summary: Wrong comment in float2.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 5 Apr 2019, tom at honermann dot net wrote:
> To be clear, the position I'm suggesting is that we add support for something
> like these:
We (GCC) don't control printf; the format c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90146
Bug ID: 90146
Summary: Add support for NetBSD
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90147
Bug ID: 90147
Summary: Support OpenBSD
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #47 from Wilco ---
(In reply to Segher Boessenkool from comment #46)
> With all three patches together (Peter's, mine, Jakub's), I get a code size
> increase of only 0.047%, much more acceptable. Now looking what that diff
> really *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87554
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #88 from Iain Sandoe ---
unless some problem shows up, this is what I will commit to 8.3 (limited
checking only).
https://github.com/iains/gcc-8-branch/commit/235ccac0aeb941c860c1e469a645ab9a90c9eca2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90141
--- Comment #1 from Roland Illig ---
While here, the "%> %<" was probably a mistake by a recent mass update to
surround command line options with quotes. That program didn't take into
account that the two options %<-gdwarf -g%s%> form a group tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90142
--- Comment #1 from Jonathan Wakely ---
Please send patches to the mailing list, not to bugzilla:
https://gcc.gnu.org/contribute.html#patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
Bug ID: 90148
Summary: Closing quote in wrong position in plugin.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: transla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
--- Comment #22 from Jonathan Wakely ---
I'm tempted to just rip out this stuff entirely, and go back to only offering
the strong exception safety guarantee for trivially copyable types, and so
variants would only be never-valueless if all altern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #48 from Segher Boessenkool ---
With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
That does not fix this PR though :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #49 from Segher Boessenkool ---
(In reply to Wilco from comment #47)
> (In reply to Segher Boessenkool from comment #46)
> > With all three patches together (Peter's, mine, Jakub's), I get a code size
> > increase of only 0.047%, much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #50 from Segher Boessenkool ---
The insn is
(insn 7 3 8 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 0 r0 [116])
(const_int 0 [0])))
(set (reg/v:SI 4 r4 [orig:112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #51 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #50)
> The insn is
>
> (insn 7 3 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 0 r0 [116])
> (c
1 - 100 of 192 matches
Mail list logo
