https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69634
--- Comment #5 from Alexandre Oliva ---
Created attachment 37606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37606&action=edit
Patch I'm testing to fix the bug
REG_N_CALLS_CROSSED's computation didn't always disregard debug insns, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69634
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69704
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32122
Andrew Pinski changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69704
Bug ID: 69704
Summary: goto *42 is not diagnosed
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69631
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #12 from Michael Meissner ---
On Fri, Feb 05, 2016 at 11:57:05PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
>
> Bill Schmidt changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
--- Comment #5 from ktkachov at gcc dot gnu.org ---
I suspected as such.
I'll try to dig deeper next week
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68541
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68541
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Fri Feb 5 23:49:08 2016
New Revision: 233191
URL: https://gcc.gnu.org/viewcvs?rev=233191&root=gcc&view=rev
Log:
PR tree-optimization/68541
* gimple-ssa-split-paths.c: Incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #10 from Bill Schmidt ---
Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
nested inside a PLUS isn't handled. I'm not sure if this is a deficiency in
regrename.c, or whether the definition of fusion_gpr_loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
--- Comment #2 from Eric Fiselier ---
@Andrew The in-class diagnostics are pretty good. My concern is that users
outside the class cannot name the conversion operator. I don't think they care
that "A" changes meaning *within* B.
I don't think an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #9 from Bill Schmidt ---
Finally got back to this for a bit. I've tracked the problem down to the
register renaming pass. I suspect it's having trouble with the
fusion_gpr_load_di pattern:
(insn 452 236 243 19 (set (reg:DI 9 9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69703
Bug ID: 69703
Summary: char16_t conversions broken in filesystem::path
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69643
Richard Henderson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #15 from Thomas Koenig ---
(In reply to David Malcolm from comment #14)
> Is there any way to do multiline comments in gfortran?
>
> Am attempting to write expected output like this:
>
> ! { dg-begin-multiline-output "" }
> EXPECTED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
--- Comment #1 from Andrew Pinski ---
I think this should be diagnose differently in that A changes meanings inside
the class.
That is if we used:
operator A () const noexcept { return {}; }
We get the following error message:
t9.cc:8:12: error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702
Bug ID: 69702
Summary: excessive stack usage with -fprofile-arcs
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #1 from bastian.beisc...@rwth-aachen.de ---
This is a list of all the missing values of the __GLIBCXX__ macro
4.7.3 20130411
4.7.4 20140612
4.8.0 20130322
4.8.1 20130531
4.8.2 20131016
4.8.3 20140522
4.8.4 20141219
4.8.5 20150623
4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69701
Bug ID: 69701
Summary: "v.operator T()" incorrectly parsed if "v.T()"
present.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69700
Bug ID: 69700
Summary: [C++14] constexpr incorrectly implies const
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007
--- Comment #5 from Harald Anlauf ---
The patch of comment #4 appears to be easily extendible to reject
arrays as loop variables (I hope I got this right):
Index: gcc/fortran/match.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69662
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69662
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Fri Feb 5 22:27:37 2016
New Revision: 233190
URL: https://gcc.gnu.org/viewcvs?rev=233190&root=gcc&view=rev
Log:
PR c++/69662 - -Wplacement-new on allocated one element array members
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
Bug ID: 69699
Summary: libstdc++ ABI documentation is out of date
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69668
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
Bug ID: 69698
Summary: [meta-bug] flexible array members
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69643
--- Comment #3 from Richard Henderson ---
Author: rth
Date: Fri Feb 5 22:05:17 2016
New Revision: 233189
URL: https://gcc.gnu.org/viewcvs?rev=233189&root=gcc&view=rev
Log:
PR c/69643
* tree.c (tree_nop_conversion_p): Do not strip casts into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007
--- Comment #4 from Harald Anlauf ---
(In reply to Tobias Schlüter from comment #3)
> Just for the fun of it, another confusing way this error message appears:
> $ cat t3.f90
> character c(5)
>
> do c=2,3
> end do
>
> END
> $ gfortran t3.f90
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69697
Bug ID: 69697
Summary: incorrect initialization of static flexible array
members
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
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=66089
--- Comment #13 from Mikael Morin ---
Author: mikael
Date: Fri Feb 5 21:41:15 2016
New Revision: 233188
URL: https://gcc.gnu.org/viewcvs?rev=233188&root=gcc&view=rev
Log:
Fix fortran scalar elemental dependency mishandling
PR fortran/6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46459
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 5 21:13:43 2016
New Revision: 233187
URL: https://gcc.gnu.org/viewcvs?rev=233187&root=gcc&view=rev
Log:
PR rtl-optimization/69691
* lra-eliminations.c (move_plus_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
--- Comment #4 from Mike Liang ---
I see. With -fsignalling-nans the 004t.gimple at -O1 is generated as I
expected and all is well. Thanks for you help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69668
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68126
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #11 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #7 from Martin Liška ---
Reduced test case:
$ g++ -O2 -rdynamic -flto tc1.ii tc2.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #5 from Martin Liška ---
Created attachment 37600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37600&action=edit
tc1.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #6 from Martin Liška ---
Created attachment 37601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37601&action=edit
tc2.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805
--- Comment #15 from kelvin at gcc dot gnu.org ---
On my macbook, g++ (Apple LLVM version 7.0.2 (clang-700.1.81), Target:
x86_64-apple-darwin15.3.0), the test program does compile successfully.
For Martin's simplified example, it produces the fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #14 from David Malcolm ---
Is there any way to do multiline comments in gfortran?
Am attempting to write expected output like this:
! { dg-begin-multiline-output "" }
EXPECTED OUTPUT TO GO HERE
! { dg-end-multiline-output "" }
If n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69628
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69628
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 5 19:39:48 2016
New Revision: 233186
URL: https://gcc.gnu.org/viewcvs?rev=233186&root=gcc&view=rev
Log:
PR c++/69628
* charset.c (cpp_interpret_charconst): Clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
Uroš Bizjak changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69696
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69696
Bug ID: 69696
Summary: incorrect initialization of block-scope flexible array
members
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #4 from David Malcolm ---
(FWIW, the test case seems to run to completion if I remove the assert in
comment #1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #3 from David Malcolm ---
A more minimal reproducer for these insane line numbers:
$ cat test.C
# 9 "" 2
not_a_type a;
# With recent trunk:
$ gcc -c test.C
line-map.c: file "" left but not entered
test.C:1048537:1: error: ‘not_a_typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #2 from David Malcolm ---
Looking at the LTO data creation, by putting a breakpoint in cc1plus on
lto_output_location to see the values that are written, I see that the
bogus-looking location is coming from this ordinary map. It has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #3 from Bernd Schmidt ---
Something like this maybe? Tries to determine if too large a fraction of blocks
are only reachable by computed jumps in a large function (which I'm guessing is
what triggers the compile time issues).
diff --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665
Szókovács Róbert changed:
What|Removed |Added
CC||szo at szo dot hu
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #13 from Jason Merrill ---
Author: jason
Date: Fri Feb 5 17:52:07 2016
New Revision: 233183
URL: https://gcc.gnu.org/viewcvs?rev=233183&root=gcc&view=rev
Log:
Make issues similar to PR c++/68948 fail loudly.
* seman
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #19 from Jeffrey A. Law ---
Created attachment 37599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37599&action=edit
Testcase for the testsuite
My best attempt at pulling together the right dg-markers for this test.
mips.exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #15 from Andrew Pinski ---
(In reply to Jim Wilson from comment #14)
> Andrew Pinski wrote the patch to fix the ICE. I was expecting him to submit
> it.
I will be doing it later today. Got distracted by some Linux performance
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #2 from H.J. Lu ---
Created attachment 37598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37598&action=edit
A patch
It is a backend bug. We need to add
; Used by STV to load a DI into an xmm register.
(define_insn "*movdi_to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282
--- Comment #14 from Jim Wilson ---
Andrew Pinksi wrote the patch to fix the ICE. I was expecting him to submit
it.
He also pointed out that the code with the patch is inefficient, and can be
optimized by adding some patterns to the aarch64 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #32 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
>
> Thus a "fix" for the case where treating a[i] as a[0] is the issue
> would be
>
> Index: gcc/tree-dfa.c
> ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
Bug ID: 69695
Summary: slice of an array retains pointer attribute
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fastjar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #18 from Jeffrey A. Law ---
Richi,
The patch fixes both the original testcase as well as the reduced testcase.
The difficultly I see is building a reliable test for the regression suite.
Parsing RTL dumps looking for the right as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #18 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Feb 5 16:24:06 2016
New Revision: 233180
URL: https://gcc.gnu.org/viewcvs?rev=233180&root=gcc&view=rev
Log:
Add a testcase for PR target/69677
PR target/69677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #13 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> Created attachment 37594 [details]
> Updated tentative patch
>
> This patch builds, and runs target-libgomp with -flto -flto-partition=1to1
> -fno-toplevel-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
--- Comment #4 from Marcel Böhme ---
Here is my preliminary analysis:
The function demangle_args (cplus-dem.c:4424) parses the (crafted) mangled
function args from the binary. In line 4452, r is read from mangled. In line
4491, we enter a loop wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #17 from Jeffrey A. Law ---
I've got enough state on this BZ and remember just enough MIPS that I can
verify behaviour with a cross.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #6 from Jonathan Wakely ---
(In reply to wipedout from comment #5)
> Here the compiler just enforces people to add parentheses so that they
> accidentally put them wrong and then the compiler is happy and the code is
> buggy.
Yes, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69251
Bug 69251 depends on bug 69277, which changed state.
Bug 69277 Summary: [6 Regression] ICE mangling a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
--- Comment #4 from Jakub Jelinek ---
I think the bug is in move_plus_up, as that function transforms:
(subreg:SI (plus:DI (reg/f:DI 20 frame)
(const_int 16 [0x10])) 0)
into:
(plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0)
(co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
--- Comment #5 from wipedout at yandex dot ru ---
Here the compiler just enforces people to add parentheses so that they
accidentally put them wrong and then the compiler is happy and the code is
buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #11 from Patrick Pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #12 from Patrick Palka ---
Created attachment 37596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37596&action=edit
better fix for gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66999
sshannin at gmail dot com changed:
What|Removed |Added
CC||sshannin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
--- Comment #6 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Feb 5 14:41:00 2016
New Revision: 233177
URL: https://gcc.gnu.org/viewcvs?rev=233177&root=gcc&view=rev
Log:
gcc/
2016-02-05 Ilya Enkovich
PR target/69369
Rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #12 from Bernd Schmidt ---
err, with -fPIC in the CFLAGS was what I was going to say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #11 from Bernd Schmidt ---
FWIW that passes bootstrap & regtest on x86_64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #11 from Jakub Jelinek ---
BTW, can you see if the cse.c one-liner has significant effect on say SPEC2k6
with -mavx512* options? If yes, then either we need some help from the RA to
deal with this, or perhaps the one-liner should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> Created attachment 37594 [details]
> Updated tentative patch
>
> This patch builds, and runs target-libgomp with -flto -flto-partition=1to1
> -fno-toplevel-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69694
Bug ID: 69694
Summary: type incomplete depending if constructing function is
templated
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948
--- Comment #10 from Patrick Palka ---
Author: ppalka
Date: Fri Feb 5 14:36:44 2016
New Revision: 233176
URL: https://gcc.gnu.org/viewcvs?rev=233176&root=gcc&view=rev
Log:
Fix PR c++/68948 (wrong code generation due to invalid constructor call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #13 from Richard Biener ---
It would be interesting to see whether FDO also shows the regression (I only
have a non-march=native FDO tester and the non-march=native tester doesn't show
the regression already). Because it might be tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #12 from Richard Biener ---
Key assembly difference seems to be extra reg-reg copies around a loop. But
maybe
perf lies to me (the description cites fsettle as the real offender but perf
points me to inl1130). As I can reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #1 from Ilya Enkovich ---
We should be able to revert r233167 if this issue is fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #17 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #16)
> That doesn't mean that incorrect register fill RA bug should't be fixed
> during stage-4. Do we have a small testcase that exposes it?
I submitted PR69693 for RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
Bug ID: 69693
Summary: Wrong mode is used to load spilled register
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #25 from Alexander Fomin ---
Good new, thank you!
Sent to ML.
1 - 100 of 166 matches
Mail list logo
