https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69254
--- Comment #15 from Jakub Jelinek ---
Created attachment 37463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37463&action=edit
gcc6-pr69254.patch
Updated untested patch, tested so far just on simple testcases (with
-fsanitize=undefined,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69469
Bug ID: 69469
Summary: test case gcc.target/powerpc/vsx-vector-2.c fails on
power starting with r232632
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69408
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69467
--- Comment #3 from Yuri Rumyantsev ---
Richard,
I checked that performance is back with your patch.
Thanks.
2016-01-25 17:50 GMT+03:00 rguenth at gcc dot gnu.org
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69467
>
> Richard Biener chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #5 from Andrey Belevantsev ---
Created attachment 37464
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37464&action=edit
patch for gcc trunk (applies to gcc-5 too)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69327
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #6 from Andrey Belevantsev ---
I've debugged it on gcc-5.1.0 since the picture on trunk is different. Thanks
Jakub for great explanations, it was not easy to get to the root problem.
We speculate an insn (the load in your listing) b
l, I've just tried to run:
$ make profile-build ARCH=x86-64-modern
for gcc --version:
gcc --version
gcc (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]
and:
gcc (GCC) 6.0.0 20160125 (experimental)
and both can build profiled LTO binary.
I had to apply following patch to be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69469
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69469
--- Comment #1 from David Edelsohn ---
Author: dje
Date: Mon Jan 25 16:16:21 2016
New Revision: 232796
URL: https://gcc.gnu.org/viewcvs?rev=232796&root=gcc&view=rev
Log:
PR target/69469
* gcc.target/powerpc/vsx-vector-2.c: Adjust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743
--- Comment #14 from Tyrel Haveman ---
Is there a flag I can add to `configure` or anything else I might be able to do
to work around this issue so that I can get my builds going? Not being able to
build GCC is blocking a lot of other work here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
--- Comment #9 from Uroš Bizjak ---
(In reply to Michael Matz from comment #8)
> Please try https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01875.html
> if possible.
Thanks, will do tomorrow morning (CET).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65189
--- Comment #4 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #2)
> I suspect the handling of dtors happens now after the dump happens.
It happens before that actually, finish_vtbls which in turn eventually calls
build_vtbl_initi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69399
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #5)
> wide-int.h has
> if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> ^^^
>
> This is misco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69399
--- Comment #10 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01780.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707
--- Comment #3 from Dominique d'Humieres ---
> > Confirmed with 4.9.3 and 5.2. This seems to have been fixed on trunk between
> > revision r226476 (2015-08-02, endless compilation) and r227016 (2015-08-19,
> > tests compiled in a fraction of seco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60743
--- Comment #15 from dave.anglin at bell dot net ---
On 2016-01-25 11:18 AM, tyrel at kulshanconcepts dot com wrote:
> Is there a flag I can add to `configure` or anything else I might be able to
> do
> to work around this issue so that I can get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241
--- Comment #8 from Abe ---
Slightly more reduced [2 bytes less? ;-)]...
__attribute__((noreturn))void V(int);
struct R{R(const R&){}};
R f(){V(0);}
R c(){V(0);}
This might be the most-reduced-possible form of this test case.
Experimentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
--- Comment #10 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 25 16:44:30 2016
New Revision: 232798
URL: https://gcc.gnu.org/viewcvs?rev=232798&root=gcc&view=rev
Log:
Avoid including all of in
PR libstdc++/69464
* includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69464
--- Comment #11 from Jonathan Wakely ---
r232798 doesn't fix the bootstrap failure, but it makes including the C++11
version of much less expensive, which is the problem that r232736
was addressing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #63 from Peter Bergner ---
Author: bergner
Date: Mon Jan 25 16:51:20 2016
New Revision: 232799
URL: https://gcc.gnu.org/viewcvs?rev=232799&root=gcc&view=rev
Log:
PR fortran/61831
* gfortran.dg/derived_constructor_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69470
Bug ID: 69470
Summary: [concepts] bogus constrained member class template
redeclared with different access
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69442
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353
Georg-Johann Lay changed:
What|Removed |Added
CC||astralien3000 at yahoo dot fr
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353
Georg-Johann Lay changed:
What|Removed |Added
Keywords||easyhack
Target Milestone|6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #8 from Dominique d'Humieres ---
> Revision 229540 isn't the problem.
At least it exposes the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68199
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> (In reply to Dominique d'Humieres from comment #5)
> > The problem is gone if I revert revision r229540.
>
> A casual perusal on sym in gdb shows that the cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #6 from H.J. Lu ---
The STV p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Jeffrey A. Law changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
Bug ID: 69471
Summary: "-march=native" unintentionally breaks further
-march/-mtune flags
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
--- Comment #14 from paul.richard.thomas at gmail dot com ---
Hi Janus,
Would you be so good as to OK this patch to the list?
Thanks
Paul
On 22 January 2016 at 12:50, janus at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69330
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839
Georg-Johann Lay changed:
What|Removed |Added
CC||karaliusliudas+bugzilla@gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Nick Clifton changed:
What|Removed |Added
Attachment #37064|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241
--- Comment #9 from Abe ---
Further-reduced test case [13 bytes shorter: 76 bytes with 1-byte line
endings]...
[[noreturn]]void V(int);
struct R{R(const R&){}};
R f(){V(0);}
R c(){V(0);}
Additional notes:
* removing "__attribute__((noret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
--- Comment #1 from Jonathan Wakely ---
Some discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg0.html
However ...
(In reply to wavexx from comment #0)
> Since I generally override the default flags in makefiles by appending
> exceptions w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69460
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
--- Comment #5 from Martin Sebor ---
FWIW, while looking into this bug I couldn't find the topic discussed in the
LSB where I would expect this to be specified. I did come across a couple of
sites on the web that gather this type of information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69472
Bug ID: 69472
Summary: [concepts] constraint ignored on constrained member
template of a class template
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
--- Comment #2 from wavexx at thregr dot org ---
On 25/01/16 18:38, redi at gcc dot gnu.org wrote:
> Why would either you or the makefile add something like -march=opteron on a
> haswell host?
>
> Surely the makefile should only add option that m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241
--- Comment #10 from Abe ---
Adding either of the following flags to "-O1" causes the compiler to ICE on the
most-reduced test case; adding any of the other "-f<...>" flags I tested [39 of
them including the following 2] did not enable the ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473
Bug ID: 69473
Summary: system identification macros not documented
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
--- Comment #6 from Martin Sebor ---
I opened bug 69473 to document the macros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69474
--- Comment #1 from Gerhard Steinmetz
---
$ gfortran-5.3.1 -c z1.f90
z1.f90:19:0:
z(1:n) = x([(i, i=n,1,-1)])
^
internal compiler error: Segmentation fault
---
These assignment variants are accepted :
$ cat z2.f90
module m
type t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69474
Bug ID: 69474
Summary: ICE: tree check: expected class ‘expression’, have
‘declaration’ (var_decl) in tree_operand_check, at
tree.h:3504
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524
--- Comment #4 from Gerhard Steinmetz
---
With a recent version the message is now :
$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]
$ gfortran-6 -c z1_imchfe.f90
z1_imchfe.f90:4:0:
fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28366
--- Comment #3 from Martin Sebor ---
What I meant by suboptimal is the eight vector stores when it seems that just
two instructions are needed to save the two vector registers that hold the
arguments like Clang does:
addi 3, 1, -48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69385
--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #14)
> Would you be so good as to OK this patch to the list?
Sure, will do ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/cpp/System-specific-Predefined-Macros.html#System-specific-Predefined-Macros
This manual, being for all systems and machines, cannot tell you what their
names are, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #11 from Jeffrey A. Law ---
Author: law
Date: Mon Jan 25 19:19:09 2016
New Revision: 232802
URL: https://gcc.gnu.org/viewcvs?rev=232802&root=gcc&view=rev
Log:
PR tree-optimization/69196
PR tree-optimization/68398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Mon Jan 25 19:19:09 2016
New Revision: 232802
URL: https://gcc.gnu.org/viewcvs?rev=232802&root=gcc&view=rev
Log:
PR tree-optimization/69196
PR tree-optimization/68398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69475
Bug ID: 69475
Summary: [x32][6]: FTBFS: configure: error: cannot compute
sizeof (long long)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986
--- Comment #13 from H.J. Lu ---
Created attachment 37466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37466&action=edit
A patch
I am testing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68621
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #14 from Jeffrey A. Law ---
Thanks. This is definitely an issue with the changing version #s changing the
ordering in which particular coalescing pairs are tried.
This is most likely coming from this (and related) code in tree-ssa-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69006
--- Comment #2 from David Malcolm ---
v2 patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01915.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69442
--- Comment #10 from Jakub Jelinek ---
Created attachment 37467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37467&action=edit
gcc6-pr69442.patch
Untested fix. Seems the above mentioned commit newly defined REG_EQUAL for
ZERO_EXTRACT lh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69475
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #7 from H.J. Lu ---
Created attachment 37468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37468&action=edit
A patch
Here is a patch. Ilya, can you take care of this? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400
Steve Ellcey changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68400
--- Comment #4 from Steve Ellcey ---
Created attachment 37469
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37469&action=edit
New patch
Here is an alternative patch. The problem is that memory_operand matches any
legal MIPS memory refere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69265
--- Comment #4 from David Malcolm ---
(see also PR 69453, which is related, but different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69476
Bug ID: 69476
Summary: Fail to reconize types with an unrejected static size
attribute as compile time known size type
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69444
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Mon Jan 25 21:37:08 2016
New Revision: 232805
URL: https://gcc.gnu.org/viewcvs?rev=232805&root=gcc&view=rev
Log:
PR target/69444
* config/rs6000/sfp-machine.h: Fix a typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69474
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #6 from Bill Schmidt ---
Backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0x10cfcf74 in reg_save_code(int, machine_mode) [clone .lto_priv.8969]
()
(gdb) bt
#0 0x10cfcf74 in reg_save_code(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> I think I can reproduce it with powerpc64le-linux too (though, have just
> eyeballed assembly, not tried to run it).
> This looks like an IRA or reload problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28366
--- Comment #4 from Bill Schmidt ---
Ah yeah, why are we saving so many copies? That's just ridiculous. Well, we
should keep this around, then, and put it on the list...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69477
Bug ID: 69477
Summary: attribute aligned documentation misleading
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69477
--- Comment #1 from Martin Sebor ---
Created attachment 37470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37470&action=edit
Proposed patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Bill Schmidt from comment #6)
> Backtrace from gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x10cfcf74 in reg_save_code(int, machine_mode) [clone .lto_priv.8969]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69478
Bug ID: 69478
Summary: [4.9/5/6 Regression] std::copy/std::move broken with
trivial move-only types
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69477
Martin Sebor changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69478
--- Comment #1 from TC ---
It seems that the static_assert should check _IsMove and use either
is_copy_assignable<_Tp> or is_move_assignable<_Tp> depending on its value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69473
--- Comment #2 from Martin Sebor ---
The purpose of macros like __linux__ or __linux is to enable users to write
code that's portable to different versions or distributions of the same OS
without necessarily testing it on them all, or even having
||4.9.3, 5.3.0, 6.0
--- Comment #1 from Martin Sebor ---
The failures can be seen in the most recent test results:
Results for 6.0.0 20160125 (experimental) [trunk revision 232800] (GCC)
testsuite on powerpc64-unknown-linux-gnu
https://gcc.gnu.org/ml/gcc-testresults/2016-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69444
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #8 from H.J. Lu ---
After ix86_finalize_stack_realign_flags, there should be no stack
alignment changes. convert_scalars_to_vector shouldn't change stack
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> Created attachment 37466 [details]
> A patch
>
> I am testing this.
This patch is wrong. After ix86_finalize_stack_realign_flags, there should
be no stack alignment chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986
H.J. Lu changed:
What|Removed |Added
Attachment #37466|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #9 from Jakub Jelinek ---
convert_scalars_to_vector (i.e. the stv pass) is before that though, it is
inserted after combine, while ix86_finalize_stack_realign_flags is during
pro_and_epilogue pass after RA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479
Bug ID: 69479
Summary: test case gcc.dg/and-1.c
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #10 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #9)
> convert_scalars_to_vector (i.e. the stv pass) is before that though, it is
> inserted after combine, while ix86_finalize_stack_realign_flags is during
> pro_and_epilog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #11 from H.J. Lu ---
/* Nonzero if function stack realignment estimation is done, namely
stack_realign_needed flag has been set before reload wrt estimated
stack alignment info. */
bool stack_realign_processed;
/* Non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479
Andrew Pinski changed:
What|Removed |Added
Depends on||33512
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65545
--- Comment #2 from joseph at codesourcery dot com ---
No, it's part of libiberty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #12 from H.J. Lu ---
# git grep stack_realign_processed
shows how it is checked.
101 - 200 of 223 matches
Mail list logo
