https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265
Bug ID: 91265
Summary: new breakage for g++.dg/cpp0x/pr82560.C
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52477
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91266
Bug ID: 91266
Summary: [10 regression] acats cd2a31a fails for 32b hosts.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91266
Iain Sandoe changed:
What|Removed |Added
Target||i686-pc-linux-gnu,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
Bug ID: 91267
Summary: [10 regression] SEGV in value_range_base::equal_p
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330
--- Comment #14 from Martin Jambor ---
Author: jamborm
Date: Fri Jul 26 08:44:51 2019
New Revision: 273825
URL: https://gcc.gnu.org/viewcvs?rev=273825&root=gcc&view=rev
Log:
[PR 89330] Remove non-useful speculations from new_edges
2019-07-26 M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
--- Comment #6 from Jaydeep Chauhan ---
(In reply to Martin Liška from comment #5)
> (In reply to Jaydeep Chauhan from comment #4)
> > Hello,
> >
> > With latest trunk issue is not reproducible for all three
> > case(clastb_1.c,clastb_4.c,clastb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91210
--- Comment #3 from Martin Marko ---
Any suggestion to fix/workaround this?
Building GCC 8.3 works fine on this machine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91210
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Component|libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #2 from David Binderman ---
Reduced C source code is
a, b;
c(f) {
char *d, *e;
while (d) {
if (f)
if (e)
g();
h(e - (d + a));
b = e - d;
d = i();
}
}
Problem seems to occur between revisions 27375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91268
Bug ID: 91268
Summary: [10 Regression] adaint.c:38: warning: "_REENTRANT"
redefined
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #12 from Marc Glisse ---
(In reply to Florian Weimer from comment #11)
> GCC on ELF provides defined address ordering for separate objects via linker
> ordering and section attributes. I think part of these extensions is that
> it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517
--- Comment #4 from Tamar Christina ---
Author: tnfchris
Date: Fri Jul 26 13:13:48 2019
New Revision: 273827
URL: https://gcc.gnu.org/viewcvs?rev=273827&root=gcc&view=rev
Log:
AArch64: Make processing less fragile in config.gcc
Due to config.gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91242
--- Comment #7 from Steve Ellcey ---
(In reply to Martin Liška from comment #5)
> (In reply to Jaydeep Chauhan from comment #4)
> > Hello,
> >
> > With latest trunk issue is not reproducible for all three
> > case(clastb_1.c,clastb_4.c,clastb_6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #3 from David Binderman ---
Revision 273775 seems ok, so range is now [273775, 273800].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #4 from David Binderman ---
Revision 273788 seems ok, so range is now [273788, 273800].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #105 from C. Heide ---
It looks like that's already disabled on ia64 in 8.3 (I don't see any .text.hot
or .text.unlikely sections in any executables so far), which has the following:
ia64.c:
> /* Always default to .text section until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #5 from David Binderman ---
Revision 273794 seems broken, so range is now [273788, 273794].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91265
--- Comment #2 from Marek Polacek ---
Started with r273791.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91267
--- Comment #6 from David Binderman ---
Revision 273791 seems ok, so range is now [273791, 273794].
The culprit seems to be
r273792 | rguenth | 2019-07-25 11:25:13 +0100 (Thu, 25 Jul 2019) | 64 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #106 from dave.anglin at bell dot net ---
On 2019-07-26 12:25 p.m., cameron.heide at betasystems dot com wrote:
>> #1 0x0657fda0 in remove (var=) at
>> ../../gcc/var-tracking.c:507
>> #2 hash_table::~hash_table (this=> out>,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91264
--- Comment #3 from Marek Polacek ---
Another:
struct X {
int j;
constexpr X() : j(0) { }
};
struct Y {
X x;
constexpr Y() : x{} { }
};
constexpr void
g ()
{
constexpr Y y{};
Y *p = const_cast(&y);
p->x.j = 99;
}
static_assert((
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #107 from C. Heide ---
Thanks for the tips; I don't do a lot of assembly-level debugging in GDB.
It looks like it fails almost immediately upon entering the remove function:
> Breakpoint 1, variable_hasher::remove (var=0x0) at
> /bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178
--- Comment #8 from Vsevolod Livinskiy ---
It looks like the fix doesn't handle all of the cases. I still can see similar
bugs on the trunk.
Reproducer:
int a[100][70304];
int b[100];
void c() {
for (int d = 2; d < 4; d++)
for (int e = 2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91258
--- Comment #6 from seurer at gcc dot gnu.org ---
Digging in to the details of the compilation a bit the error occurs when
collect2 calls ld as part of lto. There is a lot of differences in the
assembler output in the lto stuff before/after r2737
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91258
--- Comment #5 from seurer at gcc dot gnu.org ---
Created attachment 46629
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46629&action=edit
diff of assembler output before and after r273783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #108 from dave.anglin at bell dot net ---
On 2019-07-26 3:13 p.m., cameron.heide at betasystems dot com wrote:
>> 2c: 08 00 00 50 br.call.sptk.many b0=20
>> <_ZN15variable_hasher6removeEP8variable+0x20>
> wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53345
Eric Gallager changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77481
Eric Gallager changed:
What|Removed |Added
CC||mikestump at comcast dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40864
Eric Gallager changed:
What|Removed |Added
CC||iains at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53943
Eric Gallager changed:
What|Removed |Added
CC||iains at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #109 from C. Heide ---
_ZN15variable_hasher6removeEP8variable is just this same function, located at
0x6d777a0; I didn't realize at first that the objdump disassembly wasn't
showing me the actual relocation unless I specify '-r', in w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
Eric Gallager changed:
What|Removed |Added
CC||nicola.pero@meta-innovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #110 from dave.anglin at bell dot net ---
On 2019-07-26 5:36 p.m., cameron.heide at betasystems dot com wrote:
>> Relocation section
>> '.rela.gnu.linkonce.t._ZN15variable_hasher6removeEP8variable' at offset
>> 0x1594b8 contains 1 en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #1 from Sergei Trofimovich ---
Created attachment 46630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46630&action=edit
bug.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
Bug ID: 91269
Summary: sparc64-gcc fails to build glibc (-fcall-used-g6) on
niagara4: Assembler messages: Error: Illegal operands
Product: gcc
Version: 9.1.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #2 from Sergei Trofimovich ---
$ sparc64-unknown-linux-gnu-gcc -O2 -fno-stack-protector -fcall-used-g6
-mcpu=niagara4 -c bug.c -o bug.o
bug.c: In function 'c':
bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #3 from Sergei Trofimovich ---
$ sparc64-unknown-linux-gnu-gcc -S -O2 -fno-stack-protector -fcall-used-g6
-mcpu=niagara4 -c bug.c -o bug.S
bug.c: In function 'c':
bug.c:13:8: warning: assignment to 'char *' from 'int' makes pointer fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #4 from Sergei Trofimovich ---
> Commenting out line '145 std %f9, [%fp+1999]' does not make
> error disappear. Line numbers are probably skewed.
Oh, it's because I used ';' as a comment. Commenting out with '#' makes th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85137
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
Matt Turner changed:
What|Removed |Added
CC||mattst88 at gmail dot com
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #6 from Matt Turner ---
(In reply to Matt Turner from comment #5)
> With -mcpu=niagara4 and *without* -fcall-used-g6 it compiles fine.
Also doesn't occur with -O1 or -mno-lra.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269
--- Comment #7 from Matt Turner ---
(In reply to Sergei Trofimovich from comment #4)
> > Commenting out line '145 std %f9, [%fp+1999]' does not make
> > error disappear. Line numbers are probably skewed.
>
> Perhaps 1999 is too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #111 from C. Heide ---
(In reply to dave.anglin from comment #110)
> Okay, this is problem linkonce sections. I think we need to figure out why
> ia64_hpux_function_section
> isn't working. Maybe try return text_section in ia64_hpux
48 matches
Mail list logo
