https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #4 from Roman Lebedev ---
(In reply to Roman Lebedev from comment #3)
> While there, any advice on how that is supposed to be rewritten?
> Simply adding "shared(begin, len)" makes older gcc's unhappy
> https://godbolt.org/z/gyZBR-
> O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #21 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #19 from Chris Elrod ---
> To add a little more:
> I used inline asm for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
--- Comment #4 from Andrew Pinski ---
The same reason why:
#define mymacro 1
str(mymacro)
stringify(mymacro)
Gives different results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
--- Comment #3 from Arseny Solokha ---
--- mi9qy2yt.cpp2019-01-22 15:51:33.410845340 +0700
+++ tbfkgb7c.cpp2019-01-22 15:51:28.620898102 +0700
@@ -7,7 +7,7 @@
namespace delete_selection {
struct B {
void operator delete(v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
--- Comment #2 from Arseny Solokha ---
I get what you see when I modify the testcase from comment 0 the following way:
--- mi9qy2yt.cpp2019-01-22 15:48:53.473604944 +0700
+++ r9d6mwt2.cpp2019-01-22 15:46:45.567008369 +0700
@@ -1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88924
Martin Liška changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88913
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88913
--- Comment #2 from Yibiao Yang ---
(In reply to Martin Liška from comment #1)
> Fixed on trunk in r247374.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138&root=gcc&view=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR rtl-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86334
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138&root=gcc&view=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138&root=gcc&view=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:10:25 2019
New Revision: 268138
URL: https://gcc.gnu.org/viewcvs?rev=268138&root=gcc&view=rev
Log:
PR rtl-optimization/49429
PR target/49454
PR rtl-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
--- Comment #6 from Jürgen Reuter ---
Still present in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88905
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:11:35 2019
New Revision: 268139
URL: https://gcc.gnu.org/viewcvs?rev=268139&root=gcc&view=rev
Log:
PR target/88905
* optabs.c (add_equal_note): Add op0_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:12:31 2019
New Revision: 268140
URL: https://gcc.gnu.org/viewcvs?rev=268140&root=gcc&view=rev
Log:
PR rtl-optimization/88904
* cfgcleanup.c (thread_jump): Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88905
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE: in|[8 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #5 from Christopher Leonard
---
Is the order at least consistant with x86-32? i.e. if you give a 64-bit input
operand to inline assembly the order is hi:lo? I'm worried this is a bizarre
convention imposed on high endian architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #2 from Richard Biener ---
Created attachment 45489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45489&action=edit
untested patch
forwprop patch I was playing with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #3 from Jakub Jelinek ---
Yeah, I've noticed that already when working on __builtin_convertvector, we
don't really do much TER for the oversized vector SSA_NAMEs and force them into
stack all the time. Wonder if we couldn't do kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
--- Comment #1 from Paolo Carlini ---
The rationale for the change is here:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00623.html I my experience,
accepting such kind of code is really dangerous, because -fpermissive isn't
fine grained thus in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #6 from Andrew Pinski ---
(In reply to Christopher Leonard from comment #5)
> Is the order at least consistant with x86-32? i.e. if you give a 64-bit
> input operand to inline assembly the order is hi:lo? I'm worried this is a
> bizar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #22 from Chris Elrod ---
Okay. I did that, and the time went from about 4.25 microseconds down to 4.0
microseconds. So that is an improvement, but accounts for only a small part of
the difference with the LLVM-compilers.
-O3 -fno-mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #23 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #22 from Chris Elrod ---
> Okay. I did that, and the time went from abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #6 from Nidal Faour ---
Andrew Pinski is right, after chasing this bug with the help of Andrew Burgess
in the file simple-object.c, calling the creat
outfd = creat (dest, 00777);
the creat function wraps the open function but do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
--- Comment #2 from Richard Biener ---
Sandra posted a patch that will probably fix this (out-of-bound shift values).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
--- Comment #2 from Paolo Carlini ---
Also note, further clarifying what I said in the linked messages, that we only
temporarily, for few releases, accepted with -fpermissive such kind of broken
code: before gcc5, -fpermissive suppressed the firs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Devin Hussey changed:
What|Removed |Added
CC||husseydevin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #7 from Uroš Bizjak ---
(In reply to Christopher Leonard from comment #5)
> Is the order at least consistant with x86-32? i.e. if you give a 64-bit
> input operand to inline assembly the order is hi:lo? I'm worried this is a
> bizarre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #5 from Andrew Pinski ---
(In reply to Devin Hussey from comment #4)
> Strangely, this doesn't seem to affect the ARM or aarch64 backends, although
> I am on a December build (specifically Dec 29). 8.2 is also unaffected.
This is due
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 09:47:52 2019
New Revision: 268141
URL: https://gcc.gnu.org/viewcvs?rev=268141&root=gcc&view=rev
Log:
2019-01-22 Nidal Faour
PR lto/88422
* simple-object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 09:49:27 2019
New Revision: 268142
URL: https://gcc.gnu.org/viewcvs?rev=268142&root=gcc&view=rev
Log:
2019-01-22 Nidal Faour
PR lto/88422
* simple-objec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #6 from Andrew Pinski ---
Try using 128 (or 256) and you might see that aarch64 falls down similarly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #8 from Andreas Schwab ---
reg:reg+1 maps to lo:hi on x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #9 from Christopher Leonard
---
(In reply to Andrew Pinski from comment #6)
> Yes the order is always hi:lo (reg:reg+1) on all targets I know of
This is definitely not the natural choice (on any platform: I agree, endianness
is irre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #10 from Christopher Leonard
---
Getting contradictory statements now:
>reg:reg+1 maps to lo:hi on x86.
>On x86, we don't allow register pairs in asm at all.
Not allowing, or printing a warning, is much better behavior than what I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
--- Comment #15 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 09:58:23 2019
New Revision: 268143
URL: https://gcc.gnu.org/viewcvs?rev=268143&root=gcc&view=rev
Log:
PR tree-optimization/88044
* tree-ssa-loop-niter.c (numbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
--- Comment #2 from Richard Biener ---
Huh. We get &itarg1 here from originally (integer(kind=4)) &itarg1. The
stmt we analyze is
if (_4 != _316)
I have a simple patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #7 from Marc Glisse ---
See PR 55266 (and several others).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #8 from Richard Biener ---
You can try the attached patch, it "fixes" the issue on the GIMPLE side but
appearantly the BIT_FIELD_REF stores go a weird path during RTL expansion
and so we end up spilling again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88904
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37398
--- Comment #4 from Dominique d'Humieres ---
> This correctly gives the expected error messages since at least gfortran 5.4.
> Closing as FIXED?
FORALL(i=1:4) a(i) = st3 (i) is still not caught.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #4 from Andreas Krebbel ---
Looks like a problem which was fixed with r265158:
S/390: Fix problem with vec_init expander
gcc/ChangeLog:
2018-10-15 Andreas Krebbel
* config/s390/s390.c (s390_expand_vec_init):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Bug ID: 88971
Summary: Branch optimization inconsistency (missed
optimization)
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
--- Comment #5 from Jan Kossmann ---
You are right, I verified with:
gcc version 9.0.0 20190122 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'test.cpp.o'
'-share
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88948
--- Comment #2 from Uroš Bizjak ---
The problem is with can_assign_to_reg_without_clobbers_p in gcse.c, where we
have:
/* If the test insn is valid and doesn't need clobbers, and the target also
has no objections, we're good. */
if (ic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #24 from Chris Elrod ---
The dump looks like this:
vect__67.78_217 = SQRT (vect__213.77_225);
vect_ui33_68.79_248 = { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0,
1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Bug ID: 88972
Summary: popcnt of limited 128-bit number with unnecessary
zeroing
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #25 from rguenther at suse dot de ---
On Tue, 22 Jan 2019, elrodc at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
>
> --- Comment #24 from Chris Elrod ---
> The dump looks like this:
>
> vect__67.78_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #9 from Devin Hussey ---
(In reply to Andrew Pinski from comment #6)
> Try using 128 (or 256) and you might see that aarch64 falls down similarly.
yup. Oof.
test:
sub sp, sp, #560
stp x29, x30, [sp]
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #4 from Jakub Jelinek ---
Created attachment 45491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45491&action=edit
gcc9-pr88964.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #26 from Chris Elrod ---
> You can try enabling -mrecip to see RSQRT in .optimized - there's
> probably late 1/sqrt optimization on RTL.
No luck. The full commands I used:
gfortran -Ofast -mrecip -S -fdump-tree-optimized -march=nati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950
Matthew Malcomson changed:
What|Removed |Added
Known to fail||5.4.0
--- Comment #5 from Matthew Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #5 from Richard Biener ---
For indirect calls the attributes on the function type pointed to a relevant.
Unioning attributes from the actually called function (if the compiler can
figure that out) can be appropriate depending on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #27 from Chris Elrod ---
g++ -mrecip=all -O3 -fno-signed-zeros -fassociative-math -freciprocal-math
-fno-math-errno -ffinite-math-only -fno-trapping-math -fdump-tree-optimized -S
-march=native -shared -fPIC -mprefer-vector-width=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Bug ID: 88973
Summary: New -Wrestrict warning since r268048
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88862
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Tue Jan 22 11:28:56 2019
New Revision: 268147
URL: https://gcc.gnu.org/viewcvs?rev=268147&root=gcc&view=rev
Log:
2019-01-22 Richard Biener
PR tree-optimization/88862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #5 from Richard Biener ---
Hmm, I wonder if handling FP inductions during interchange causes correctness
issues as well (FP rounding, etc.). Otherwise the patch looks obvious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #4 from Richard Biener ---
LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #6 from Jakub Jelinek ---
In the spot which I'm changing IMHO shouldn't, that + 0.0 really should be
folded (and if not, we should tweak create_iv not to do any addition if
real_zerop). Though of course for other floating point IVs w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
--- Comment #7 from Jakub Jelinek ---
Actually no, with HONOR_SIGNED_ZEROS it shouldn't be optimized out.
So, if we don't have other way how to make distinction between a normal chrec
with step +0.0 and loop invariant var, we should punt at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964
Jakub Jelinek changed:
What|Removed |Added
Attachment #45491|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> rid of, and even at -O3 we do not inline basic_string::basic_string it seems
> (ISTR that is out-of-line in the library):
There's an explicit instantiation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88972
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88971
--- Comment #3 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> This is because it still needs to generate the std::string objects at the
> caller
> site (outside of the if (print)). This involves quite some code to get
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #11 from Uroš Bizjak ---
(In reply to Christopher Leonard from comment #10)
> Getting contradictory statements now:
> >reg:reg+1 maps to lo:hi on x86.
> >On x86, we don't allow register pairs in asm at all.
>
> Not allowing, or print
1 - 100 of 256 matches
Mail list logo
