while (ih < 1)
^
0xc967cf crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/toplev.c:325
0x15d36dd xstrdup
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/libiberty/xstrdup.c:33
0xba6b9e json::string::s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
Bug ID: 86635
Summary: [avr] Miscompilation with __memx and libgcc float
function __gtsf2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
Senthil Kumar Selvaraj changed:
What|Removed |Added
Target||avr
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #14 from The Written Word
---
Adding -bnoquiet to the linker command-line I get:
(ld): halt 4
(ld): setopt r/o->w
(ld): setopt nortl
(ld): setopt nortllib
(ld): setopt symbolic:-1
(ld): setfflag 4
(ld): savename ./shr.o
(ld): fileli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559
--- Comment #4 from The Written Word
---
gcc-7.3.0 exhibits the same problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #13 from The Written Word
---
(In reply to The Written Word from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > Created attachment 44406 [details]
> > Undefine macros for long double math functions
> >
> > Does thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
--- Comment #12 from Alan Modra ---
gcc.c-torture/compile/pr72802.c failed for me (likely with -mcpu=power9) with
the version of gcc I happened to have at the time I developed the patch in #c5.
I'm not sure now whether it was to demonstrate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630
--- Comment #1 from The Written Word
---
AIX 6.1 exhibits a similar error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86633
Bug ID: 86633
Summary: invalid with rvalue references
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
--- Comment #3 from Ketan ---
Example execution output:
Compile and run with -O1
Out14[0] = 0.00
Out14[1] = 0.00
Out14[2] = 0.00
Out14[3] = 0.00
Out14[4] = 0.00
Out14[5] = 0.00
Out15[0] = 75.00
Out15[1] = 75.00
O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
--- Comment #2 from Ketan ---
Created attachment 44419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44419&action=edit
Reproduction Files
Contents of archive
- compile.sh : Compiles and runs code in -O0 (correct result), -O3 (incorrect
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
--- Comment #1 from Ketan ---
Will add attachment in a moment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86632
Bug ID: 86632
Summary: Incorrect value copied into output array with -O3
ftree-loop-vectorize
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063
--- Comment #16 from Martin Sebor ---
I opened bug 86631 for the failing tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631
Bug ID: 86631
Summary: [9 Regression] missing -Walloc-size-larger-than on
ILP32 hosts
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86630
Bug ID: 86630
Summary: gcc/graphite.c build failure on AIX 5.2 and 5.3
Product: gcc
Version: 5.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86629
--- Comment #2 from kargl at gcc dot gnu.org ---
This is fixed by
svn merge -r 262910:262909 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
Martin Sebor changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86629
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
--- Comment #8 from Martin Sebor ---
Author: msebor
Date: Sun Jul 22 21:09:32 2018
New Revision: 262923
URL: https://gcc.gnu.org/viewcvs?rev=262923&root=gcc&view=rev
Log:
PR bootstrap/86621 - 'alloca' bound is unknown in tree-vect-slp.c:1437:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86629
Bug ID: 86629
Summary: error: 'alloca' bound is unknown breaks bootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #49 from The Written Word
---
(In reply to Sergei Trofimovich from comment #48)
> I suggest filing a new bug report with details of what/how does not compile
> anymore. Perhaps it's easy to tweak.
Ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #3 from Marc Glisse ---
We already simplify some simple cases like x*t/t -> x in match.pd. Larger cases
are for a pass like reassoc. In this particular case, we could also imagine
somehow noticing that (x*y)*z is better reassociated a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #48 from Sergei Trofimovich ---
(In reply to The Written Word from comment #47)
> This patch caused a regression on HP-UX/IA between gcc-4.9.3 and gcc-4.9.4.
> Reverting the patch makes the build on this platform succeed for 4.9.4.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52509
--- Comment #5 from Jonathan Wakely ---
No objections from me. I'm not sure how representative of real C++ code the
bits in libstdc++.so are anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
The Written Word changed:
What|Removed |Added
CC||bugzilla-gcc@thewrittenword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919
--- Comment #37 from The Written Word
---
(In reply to The Written Word from comment #36)
> I can build 4.9.3 on HP-UX 11.31/IA but not 4.9.4. So, looks like something
> changed to break the build in 4.9.4.
I reverted the patch for PR60465 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
--- Comment #5 from Alexander Monakov ---
Yeah, looks like a change that was done on gcc-7 trunk and got backported,
appearing in 6.3 and 5.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82063
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Andrew Pinski changed:
What|Removed |Added
Severity|enhancement |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Andrew Pinski changed:
What|Removed |Added
Target|x86_64 |x86_64 aarch64-*-*
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #2 from Dávid Bolvanský ---
Something/0 is undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Bug ID: 86628
Summary: Missed simplification of division
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #41 from Eric Gallager ---
(In reply to Iain Sandoe from comment #40)
> Created attachment 44417 [details]
> Patch series to enable copying of early debug data.
>
>
> 1. Sorry about the long absence, equally long story...
Welcome b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
--- Comment #7 from Jakub Jelinek ---
Yes, but I certainly disagree with that, especially enabling a code-style
warning by default.
tree-vect-slp.c uses alloca 3 times, the warning is only in one spot, all of
them are bound, because the vectoriz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
--- Comment #2 from Chris Elrod ---
Created attachment 44418
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44418&action=edit
Code to reproduce slow vectorization pattern and unnecessary loads & stores
(Sorry if this goes to the bottom ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005
--- Comment #40 from Iain Sandoe ---
Created attachment 44417
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44417&action=edit
Patch series to enable copying of early debug data.
1. Sorry about the long absence, equally long story...
2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Alexander Monakov changed:
What|Removed |Added
Summary|Inefficient division of |[6/7/8/9 Regression] Signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040
--- Comment #5 from Georg-Johann Lay ---
Created attachment 44416
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44416&action=edit
C test case for movmem
The movmem from ASes __flash1 ... __flash5 is also affected. As the place to
fix I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
--- Comment #1 from Thomas Koenig ---
Originally found by profiling Fortran code like
integer(16) :: i, j
...
j = i/2
and wondering why this took so long :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627
Bug ID: 86627
Summary: Inefficient division of 128-bit ints by small constant
integers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70167
--- Comment #6 from Jonathan Wakely ---
It looks like r247793 fixed an ICE for:
#include
struct A{int i;};
struct B{};
struct C:A,B{};
struct V {std::vector m;};
V v{{C{{1},{;
It doesn't look obviously related, so do we want to add that te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86625
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86621
--- Comment #5 from Jakub Jelinek ---
Before the changes, -Walloca-larger-than wasn't enabled by default,
warn_alloca_limit (and warn_vla_limit) defaulted to 0, which means
e.g. pass_walloca::gate in the second pass would return false.
Note, neit
51 matches
Mail list logo
