https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
--- Comment #2 from Anders Granlund ---
Thanks for the explanation. That makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
--- Comment #2 from Anders Granlund ---
Thanks for the clarification.
I'll report this bug for clang instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
--- Comment #2 from krux ---
The code is based on
https://github.com/hanickadot/compile-time-regular-expressions/blob/master/include/ctll/fixed_string.hpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176
--- Comment #5 from Martin Sebor ---
I think the question in comment #2 is whether it's possible to get the full
benefit of the latter kind of warnings without relying on the optimizations
being performed that they depend on. There is currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
krux changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from krux ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88534
Bug ID: 88534
Summary: internal compiler error: in
tree_add_const_value_attribute, at dwarf2out.c:20246
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176
Eric Gallager changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
Senthil Kumar Selvaraj changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to David Binderman from comment #6)
> Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90
> on an asan build of gcc trunk revision 267200 and got this:
>
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
Joseph S. Myers changed:
What|Removed |Added
CC||sasho648 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
--- Comment #1 from joseph at codesourcery dot com ---
Types with [*] are definitely complete types; the standard explicitly says
"such arrays are nonetheless complete types". The "'[*]' not in a
declaration" warning is a warning, not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945
--- Comment #7 from Dominique d'Humieres ---
> Not sure this is related, but I tried compiling ./gfortran.dg/pr87945_1.f90
> on an asan build of gcc trunk revision 267200 and got this:
I think it is a duplicate of pr87881.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
--- Comment #1 from joseph at codesourcery dot com ---
I'd say the enum member a is declared by a contained struct-declaration,
not by the declaration itself.
The case of reading the text to allow for a declarator inside a
struct-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Mon Dec 17 22:43:31 2018
New Revision: 267222
URL: https://gcc.gnu.org/viewcvs?rev=267222=gcc=rev
Log:
PR libstdc++/71044 fix off-by-one errors introduced recently
The recent changes
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20181217 (experimental) (GCC)
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #4 from Harald Anlauf ---
Without CONTIGUOUS, I see -O3 brings gcc-9 to the level of gcc-7 or gcc-8:
baseline + -O3 -funroll-loops -fcheck=bounds :
7: 1.57
8: 1.40
9: 1.57
baseline + -O3 -funroll-loops -fcheck=bounds -fno-tree-ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] internal |[8 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870
--- Comment #1 from Peter Bergner ---
Author: bergner
Date: Mon Dec 17 22:07:11 2018
New Revision: 267221
URL: https://gcc.gnu.org/viewcvs?rev=267221=gcc=rev
Log:
gcc/
PR target/87870
* config/rs6000/vsx.md (nW): New mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #3 from Harald Anlauf ---
(In reply to Thomas Koenig from comment #2)
> Strange.
>
> I ran the code (with the data) a few times on my Ryzen 7 home
> system.
>
> Here are some timings (run 10 times):
[snipped]
> Is it possible that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 17 21:54:37 2018
New Revision: 267220
URL: https://gcc.gnu.org/viewcvs?rev=267220=gcc=rev
Log:
PR c++/88410
* cp-gimplify.c (cp_fold) : For offsetof-like folding,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Mon Dec 17 21:49:58 2018
New Revision: 267219
URL: https://gcc.gnu.org/viewcvs?rev=267219=gcc=rev
Log:
PR c++/52321 print note for static_cast to/from incomplete type
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
--- Comment #4 from Pavel Roskin ---
The trivial backport of PR c++/85032 fixes both my testcase and the original
issue with my code. Please include the fix in gcc 7.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
--- Comment #1 from Harald Anlauf ---
Created attachment 45250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45250=edit
Sparse matrix meta-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88533
Bug ID: 88533
Summary: [9 Regression] Higher performance penalty of
array-bounds checking for sparse-matrix vector
multiply
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
--- Comment #3 from Pavel Roskin ---
I ran "git bisect" between gcc 7.1.0 (affected) and gcc 8.1.0 (unaffected).
Following commit fixed the issue:
https://github.com/gcc-mirror/gcc/commit/e0ccd4807edc919735b4d86590b5a9def529f91c
2018-04-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
--- Comment #2 from sasho648 at gmail dot com ---
Related points from the standard:
6.7.9 p3 states:
The type of the entity to be initialized shall be an array of unknown size or a
complete object type that is not a variable length array type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #7 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze:
> mateuszb,
> Please can you provide us the sample file to investigate more on this .
I'm not assembly expert, but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
--- Comment #1 from Andrew Pinski ---
IIRC types defined in sizeof are not exposed to the current scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88532
Bug ID: 88532
Summary: variable has initializer but incomplete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49884
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
--- Comment #3 from Jakub Jelinek ---
Yes, it does. So, shall we emit just PTR always, or have a configure check to
detect this and use PTR if assembler with this support isn't detect, otherwise
whatever it requires newly (is that whatever is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
--- Comment #2 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #1)
> binutils 2.29 doesn't accept the syntax that 2.32 accepts and vice versa.
> Why has it changed incompatibly?
> Shouldn't new binutils accept both forms?
binutils 2.29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514
--- Comment #5 from Jakub Jelinek ---
Created attachment 45248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45248=edit
gcc9-pr88513.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480
Tamar Christina changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > I fixed the std::__cxx11::string case on trunk, the output is now:
>
> Great!
>
> I wonder how this looks now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #6 from Jonny Grant ---
> I imagine you may have found out that this goes away if the "const" is
> removed. So it becomes
> void test_params(string & mystr1, string & out_str)
To add, by this I mean the std:: namespace is visible,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
--- Comment #5 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #4)
> I fixed the std::__cxx11::string case on trunk, the output is now:
Great!
I wonder how this looks now with -std=c++14or -std=c++17
(not sure why I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #6 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 10:20, rguenth at gcc dot gnu.org pisze:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
>
> --- Comment #2 from Richard Biener ---
> Since the patch changes the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #6 from Jonathan Wakely ---
Or just don't offer suggestions for identifiers that might be cut short by
invalid bytes after them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #5 from Richard Earnshaw ---
Tentative patch posted here.
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88480
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
--- Comment #3 from Florian Schornbaum
---
Thank you for your very quick replies!
I'm aware of 88464 (I think this is the recent work you are referring to?), but
this had no effect on the index data type issue I was describing.
Even if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502
--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Dec 17 15:46:20 2018
New Revision: 267204
URL: https://gcc.gnu.org/viewcvs?rev=267204=gcc=rev
Log:
PR target/88502
* internal-fn.def (ACOSH): New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #5 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #4)
[..]
> > "st!ing"
>
> ! is a single byte in UTF-8
Fair enough. Just my idea below.
How about converting those two utf8 bytes, to a marker one byte, to help the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #12 from Jonathan Wakely ---
(In reply to Ivan Godard from comment #4)
> Define an enum of reasons with "success" first, flop the sense of the test
> so that false means coercion was OK (grep to find all calls and put a "!" in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #11 from Eric Gallager ---
(In reply to Marc Glisse from comment #10)
> IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
> optimization level (even at -O3), it has too many false positives that are
> all but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #5 from Jonny Grant ---
Created attachment 45247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45247=edit
C example of this UTF8 not displaying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #14 from Jaydeep Chauhan ---
(In reply to Jaydeep Chauhan from comment #10)
I have tried solve this case using define_split or define_insn_and_split
but i am facing is some issue as per below:
1.It is not possible to combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #4 from Jonny Grant ---
Clang has an appropriate message and displays the UTF8 okay.
GCC just needs to catch up with clang on this one...
#1 with x86-64 clang (trunk)
:8:7: error: non-ASCII characters are not allowed outside of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #3 from Jonny Grant ---
ICC displays the UTF8 ok:
#1 with x86-64 icc 19.0.1
(8): error: unrecognized token
st£ing buf;
^
(8): error: identifier "st" is undefined
st£ing buf;
^
(8): error: expected a ";"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Jonny Grant from comment #0)
> > Hello
> >
> > This is an typo in the word "string", just reporting as perhaps it could
> > show £ correctly, as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #6 from Bill Schmidt ---
Reassociation width should be 4 for this case per the target hook. Kelvin, you
can experiment with rs6000_reassociation_width to see if larger values give you
what you expect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #10 from Jonathan Wakely ---
Untested patch:
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7348,8 +7348,19 @@ build_static_cast (tree type, tree oexpr, tsubst_flags_t
complain)
}
if (complain & tf_error)
-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|5.4.1, 7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> Clang outputs an extra line saying the type is incomplete (which should
> probably be a "note:" but nevermind):
Ha, it is a note, but on my terminal the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
--- Comment #14 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Mon Dec 17 13:49:16 2018
New Revision: 267202
URL: https://gcc.gnu.org/viewcvs?rev=267202=gcc=rev
Log:
DWARF: Don't expand hash table when no insertion is needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88503
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52321
Jonathan Wakely changed:
What|Removed |Added
CC||petschy at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #7 from Jonathan Wakely ---
I don't think this has anything to do with the std::lib anyway (and certainly
not "the STL" which the example doesn't use at all). Most of the differences
between GCC and Clang can be shown by an example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81239
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-06-28 00:00:00 |2018-12-17
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88514
Jakub Jelinek changed:
What|Removed |Added
Attachment #45245|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88520
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #7 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 13:26:50 2018
New Revision: 267201
URL: https://gcc.gnu.org/viewcvs?rev=267201=gcc=rev
Log:
2018-12-17 Senthil Kumar Selvaraj
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #5 from mateuszb at poczta dot onet.pl ---
W dniu 17.12.2018 o 13:52, umesh.kalappa0 at gmail dot com pisze:
> mateuszb,
> Please can you provide us the sample file to investigate more on this .
OK, after work I will investigate more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #3)
> Hi Marc
>
> I agree to useful to have the option to keep on for regular code.
> Perhaps a way just to turn off all expansive output for STL's std namespace?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #4 from Umesh Kalappa ---
mateuszb,
Please can you provide us the sample file to investigate more on this .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88507
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #0)
> Hello
>
> This is an typo in the word "string", just reporting as perhaps it could
> show £ correctly, as it does on line 10 error.
But then you couldn't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
Bug 59002 depends on bug 78986, which changed state.
Bug 78986 Summary: [7/8/9 Regression] template inner classes are not affected
by access specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78986
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823
Jonathan Wakely changed:
What|Removed |Added
CC||michele.caini at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||assemble-failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531
Bug ID: 88531
Summary: Index data types when targeting AVX-512 vectorization
with gather/scatter
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88504
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #6 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 12:07:26 2018
New Revision: 267199
URL: https://gcc.gnu.org/viewcvs?rev=267199=gcc=rev
Log:
2018-12-17 Senthil Kumar Selvaraj
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #3)
> I wonder, for typos if a simple byte compare would be enough? Vary each char
> by 1 letter, or length. This starts to get complicated I know..
The matching code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Bug ID: 88530
Summary: [8/9 Regression] AArch64 Unsupported options passed to
assemblers when it doesn't need to.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253
--- Comment #5 from Senthil Kumar Selvaraj ---
Author: saaadhu
Date: Mon Dec 17 10:50:54 2018
New Revision: 267198
URL: https://gcc.gnu.org/viewcvs?rev=267198=gcc=rev
Log:
Fix PR 88253
gcc/ChangeLog:
PR rtl-optimization/88253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #14 from Jonny Grant ---
Wondering, if there is an implicitly created copy-constructor, can the warning
clarify that? Perhaps there is some attribute or flag set so later code can
know it was implicitly created?
eg output could be:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88464
--- Comment #16 from Moritz Kreutzer ---
I can confirm the fix from my side.
Thanks again!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88521
--- Comment #2 from Richard Biener ---
Since the patch changes the ABI can it be you have library dependences with the
old ABI around?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #10 from Marc Glisse ---
IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
optimization level (even at -O3), it has too many false positives that are all
but impossible to work around (thus violating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529
Bug ID: 88529
Summary: G++ clears the return register on x86_64 when
returning an empty class
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 104 matches
Mail list logo
