https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79939
--- Comment #4 from Tom de Vries ---
Author: vries
Date: Tue Jul 11 07:20:47 2017
New Revision: 250119
URL: https://gcc.gnu.org/viewcvs?rev=250119&root=gcc&view=rev
Log:
Backport "Disable constant pool for nvptx"
2017-07-11 Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80855
--- Comment #4 from Tom de Vries ---
Author: vries
Date: Tue Jul 11 07:20:34 2017
New Revision: 250118
URL: https://gcc.gnu.org/viewcvs?rev=250118&root=gcc&view=rev
Log:
Backport: Add "sorry, target cannot support label values" for nvptx
2017-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
Ah, npeel is set by vect_peeling_hash_get_lowest_cost although the
corresponding dr is not used afterwards. It should be save to get rid of the
npeel parameter since we use the returned peel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #1 from Jakub Jelinek ---
I'm afraid it is unfixable, if you want smaller memory consumption, you either
need smaller routines, or use -fno-sanitize-recover=all, or do multiple builds
with selected subsets of -fsanitize=undefined, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81381
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81381
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #5 from Martin Liška ---
Ok, your patch is definitely needed to properly propagate the builtin
probability to a proper edge. Apart from that I added code that preserves that
probability incombine_predictions_for_bb. Having that we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #6 from Martin Liška ---
Created attachment 41713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41713&action=edit
Semi-working patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81364
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81391
Bug ID: 81391
Summary: Use of parenthesis disables warning about incorrect
size parameter
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #2 from Martin Liška ---
Just for curiosity, I tried to use clang++ 4.0.0 and clang++ pr81387.ii -c -O2
-fsanitize=undefined took me about 180s and memory was ~2.5GB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
--- Comment #4 from Jonathan Wakely ---
(In reply to David Krauss from comment #0)
> basic_filebuf (and therefore fstream) does not allow you to put a write
> operation directly after a read operation, or vice versa. Instead, the write
> and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #7 from Yuri Gribov ---
(In reply to Martin Liška from comment #5)
> Apart from that I added code that preserves
> that probability in combine_predictions_for_bb.
Yes, I did pretty much the same locally)
> But still there's a missin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81390
Bug ID: 81390
Summary: ICE in to_reg_br_prob_base while compiling kernel
Product: gcc
Version: 8.0
Status: WAITING
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81390
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81390
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81391
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2017-7-11
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81391
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
Markus Trippelsdorf changed:
What|Removed |Added
CC||prathamesh3492 at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
--- Comment #7 from Markus Trippelsdorf ---
Also see https://gcc.gnu.org/ml/gcc-regression/2017-07/msg00144.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81369
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81369
amker at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81367
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81365
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=81354
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81355
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81342
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81367
--- Comment #2 from Dominique d'Humieres ---
AFAICT this is fixed in 5.4.1 and 6.4.0:
% gfc5 pr81367.f90
pr81367.f90:5:18:
character(len=f)::fname
1
Error: Scalar INTEGER expression expected at (1)
% gfc5 -v
Using built-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81367
Martin Liška changed:
What|Removed |Added
Known to work||5.1.0, 5.2.0, 6.3.0, 6.4.0
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033
--- Comment #24 from Jan Hubicka ---
I think the patch still need to be updated to correctly handle the symbols
whose names are parethetised which was mentioned on the IRC (weird thing that
seems to be used in objC++ API). That should fix good p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81319
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81271
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2017-7-11
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81367
Dominique d'Humieres changed:
What|Removed |Added
Known to work||5.4.1
--- Comment #4 from Dominiq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81392
Bug ID: 81392
Summary: Improve diagnostics for [[fallthrough]] attribute that
is missing a semicolon
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81367
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
--- Comment #8 from Markus Trippelsdorf ---
Reduced Boost testcase:
struct A;
struct B {
typedef A *type;
};
struct C {
B::type operator->();
};
struct D {
struct F {
F(void(void *), F *, void());
};
template struct J : F {
Fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81364
--- Comment #2 from Marek Polacek ---
C++ doesn't warn. The problem is that we shouldn't warn (in the C FE) when a
guard is followed by '{'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #12 from Jakub Jelinek ---
I've filed https://reviews.llvm.org/D35246 upstream for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81392
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
Bug ID: 81393
Summary: Bootstrap failure on s390x-linux while building libgo
against recent glibc
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80316
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Tue Jul 11 11:52:14 2017
New Revision: 250126
URL: https://gcc.gnu.org/viewcvs?rev=250126&root=gcc&view=rev
Log:
PR libstdc++/80316 make promise::set_value throw no_state error
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81394
Bug ID: 81394
Summary: wrong "useless cast" message in inheriting constructor
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
Bug ID: 81395
Summary: basic_filebuf::overflow recurses and overflows stack
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81271
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80316
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Tue Jul 11 12:38:35 2017
New Revision: 250131
URL: https://gcc.gnu.org/viewcvs?rev=250131&root=gcc&view=rev
Log:
PR libstdc++/80316 make promise::set_value throw no_state error
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80316
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #21 from Martin Liška ---
> The code uses user-level threads (makecontext/setcontext etc). It annotates
> the new stack during the switch, see for example
> https://github.com/scylladb/seastar/blob/master/core/thread.cc#L66.
> Suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81320
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81365
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81348
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81320
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
Bug ID: 81396
Summary: Optimization of reading Little-Endian 64-bit number
with portable code has a regression
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #13 from George R. Goffe ---
Jakub,
I have built gcc with itself... including your mod... That appears to have
worked as well.
George...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386
--- Comment #1 from seurer at gcc dot gnu.org ---
I looked back through the tester logs and noticed that the test case doesn't
always fail and there are two different failures and always with -O3
PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397
Bug ID: 81397
Summary: mistakes in .opt files not detected
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81391
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |7.2
Summary|Use of parenthesi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81365
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #2 from Jonathan Wakely ---
I'm testing this patch:
--- a/libstdc++-v3/include/bits/fstream.tcc
+++ b/libstdc++-v3/include/bits/fstream.tcc
@@ -699,7 +699,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #22 from Martin Liška ---
One more question, would it be possible to somehow attach gdb to the server
which is tested? It will help me to debug where precisely is the stack
poisoned?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #23 from Martin Liška ---
(In reply to Martin Liška from comment #22)
> One more question, would it be possible to somehow attach gdb to the server
> which is tested? It will help me to debug where precisely is the stack
> poisoned?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
Paolo Carlini changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844
Paolo Carlini changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81394
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #6 from rdapp at linux dot vnet.ibm.com ---
Created attachment 41715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41715&action=edit
Tentative patch
Removed the npeel function argument, also removed body_cost_vec and the
corres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #4 from Paolo Carlini ---
Seems weird: -1 means uncommitted (per the comment before _M_set_buffer) and we
also set _M_reading? I don't think we do that anywhere else. But it's a long
time... Note that I clearly remember somebody sugge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
--- Comment #11 from Jonathan Wakely ---
It's a pity you need at least -O2 for the warnings, but I agree we can close it
as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
--- Comment #2 from Marc Glisse ---
bswap was happy dealing with
_2 = MEM[(const unsigned char *)&word];
_3 = (uint64_t) _2;
_4 = MEM[(const unsigned char *)&word + 1B];
_5 = (uint64_t) _4;
_6 = _5 << 8;
_8 = MEM[(const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
Andreas Krebbel changed:
What|Removed |Added
Attachment #41716|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
--- Comment #24 from Martin Liška ---
Just run with current trunk and it works (it fails after a minute in
==13736==ERROR: AddressSanitizer: stack-overflow on address 0x2adb9b406e48 (pc
0x067d8638 bp 0x2adb9b408020 sp 0x2adb9b406e30 T1)
So I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #5 from Jonathan Wakely ---
PR 45708 suggested that _M_reading and _M_writing aren't needed. I haven't
found a patch to implement that, but I haven't looked too hard.
You make a good point that going into uncommitted mode with _M_rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396
--- Comment #3 from Jakub Jelinek ---
I'll have a look at that tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #6 from Paolo Carlini ---
The relevant xsgetn code essentially is an optimization, right? Shouldn't be
too difficult to figure out what would happen in the slow, correct case...
What's wrong with a normal uncommitted case, thus _M_rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
--- Comment #12 from Paolo Carlini ---
Certainly a pity, but I think it's a rather well known issue...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Segher Boessenkool changed:
What|Removed |Added
Attachment #41718|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> This started in 4.6.0 with r87453
It did start with 4.6.0 but that commit was already in 4.5.4 so it can't have
been that one. It seems to be the change to o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #8 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #6)
> The relevant xsgetn code essentially is an optimization, right? Shouldn't be
> too difficult to figure out what would happen in the slow, correct case...
> What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81362
--- Comment #7 from Andreas Schwab ---
This fixes both no-vfa-vect-57.c and no-vfa-vect-61.c for -m64 and -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992
Arseny Solokha changed:
What|Removed |Added
Known to fail||8.0
--- Comment #4 from Arseny Solokha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #11 from Segher Boessenkool ---
The original testcase still ICEs ("smaller reproducer" I never got to fail).
(trunk, no options whatsoever):
81317-1.c: In function 'jsimd_ycc_rgb_convert_altivec':
81317-1.c:184:6: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81269
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81399
Bug ID: 81399
Summary: New test case 27_io/basic_stringstream/assign/81338.cc
fails on powerpc64le
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
Bill Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400
Bug ID: 81400
Summary: Stack smashing not caught by stack protector strong
and allowing me to stack smash
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Andrew Gallagher changed:
What|Removed |Added
CC||andrewjcg at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
--- Comment #12 from Michael Meissner ---
Created attachment 41721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41721&action=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81399
--- Comment #1 from seurer at gcc dot gnu.org ---
I was wrong, it fails at least some of the time on powerpc64 BE too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81399
--- Comment #2 from Jonathan Wakely ---
FWIW it passes on gcc112 in the compile farm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #14 from Segher Boessenkool ---
Created attachment 41722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41722&action=edit
second patch, for the original problem
This one should solve the original problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #3 from Dmitry Babokin ---
Interesting that you've mentioned -fno-sanitize-recover, I haven't realized
that it has effect on the number of basic blocks. But by default I run
"-fsanitize=undefined -fno-sanitize-recover=undefined", so t
1 - 100 of 118 matches
Mail list logo
