https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #2 from David Binderman ---
Goes wrong in revision 241727, dated 20161101.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #4 from David Malcolm ---
I'm not able to reproduce the assertion failure, with xgcc (GCC) 7.0.1 20170120
(experimental); on x86_64-pc-linux-gnu.
$ ./xgcc -B. -c /tmp/test.c -Wformat -Wformat-signedness
/tmp/test.c: In function ‘lpfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79246
Bug ID: 79246
Summary: [C++17] with versioned namespace: FAIL:
27_io/manipulators/standard/wchar_t/2.cc (test for
excess errors)
Product: gcc
Version: 7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
Bug ID: 79247
Summary: Race condition on OpenMP reduction variable
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482
--- Comment #4 from Bill Schmidt ---
OK, that explains how we got here. At the moment, the usage of the flag only
matters to the test suite when running on older hardware. On P8, the test
suite uses -mpower8-vector rather than -mvsx -mno-allow-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79248
Bug ID: 79248
Summary: Typo in symtab.c:1032 "byt" instead of "but"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: transl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 19:39:40 2017
New Revision: 244949
URL: https://gcc.gnu.org/viewcvs?rev=244949&root=gcc&view=rev
Log:
PR c++/68727
* cp-tree.def (OFFSETOF_EXPR): Bump number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70607
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 26 19:40:02 2017
New Revision: 244951
URL: https://gcc.gnu.org/viewcvs?rev=244951&root=gcc&view=rev
Log:
PR libstdc++/70607 revert recent changes to
PR libstdc++/70607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #3 from David Binderman ---
Seems ok in revision 240685,so that gives a band of [240685, 241727)
for the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79248
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79247
--- Comment #2 from Paul Romano ---
Thanks for clarifying!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #5 from Jakub Jelinek ---
Slightly cleaned up testcase:
long buf[5];
int bar (void);
int
foo (int x)
{
int y = __builtin_setjmp (buf);
while (x != 3 && x && x && x != 2)
x = bar ();
return y;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
--- Comment #20 from David Malcolm ---
Some other benchmarks spiked at same time (and recovered with the removal of
the bad linemap):
* "doduc" (from 3.5s up to to 4.s)
(with the bad linemap, get_next_line is 15% of the profile (in perf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
--- Comment #21 from David Malcolm ---
(In reply to David Malcolm from comment #19)
[...]
> In particular, repeated accesses to the same source line are more expensive
> that they could be: each time it tries to count forwards from the last
> lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67273
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|dmalcolm at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79244
--- Comment #6 from Jakub Jelinek ---
So here we have (ab) SSA_NAME as lhs and we try to replace it with non-(ab)
SSA_NAME, which isn't supported except for virtual operands.
So, one possibility I see is if lhs is (ab) and var is SSA_NAME that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
Bug ID: 79249
Summary: Lambda call does not create exception handler.
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
--- Comment #2 from Jonathan Wakely ---
Reduced:
template
auto attempt(FnT f)
{
return [f]()
{
try
{
f();
}
catch(...)
{
__builtin_puts("caught");
}
};
}
// More complex behavior does not seem to mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249
--- Comment #3 from Jonathan Wakely ---
Slightly further reduced:
template
auto attempt(FnT f)
{
return [f]()
{
try
{
f();
}
catch(...)
{
__builtin_puts("caught");
}
};
}
// More complex behavior doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79243
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #5 from Dominik Vogt ---
The tests cases from the first message still fail using a cross compiler and
r244951.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
--- Comment #9 from Martin Sebor ---
Author: msebor
Date: Thu Jan 26 21:14:18 2017
New Revision: 244953
URL: https://gcc.gnu.org/viewcvs?rev=244953&root=gcc&view=rev
Log:
PR middle-end/78703 -fprintf-return-value floating point handling incorrec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79250
Bug ID: 79250
Summary: brig/brigfrontend/brig-to-generic.cc: two small
problems
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78690
--- Comment #4 from Jakub Jelinek ---
Another testcase for this:
struct C;
template
struct A
{
struct C { static void bar (); };
};
template
struct B
{
using A::C;
void
foo () { C.bar (); }
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Bug ID: 79251
Summary: PowerPC vec_insert generates store-hit-load if the
element number is variable
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Michael Meissner changed:
What|Removed |Added
Priority|P3 |P5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 21:44:49 2017
New Revision: 244954
URL: https://gcc.gnu.org/viewcvs?rev=244954&root=gcc&view=rev
Log:
PR debug/78835
* dwarf2out.c (prune_unused_types): Mark a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79129
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 26 21:45:57 2017
New Revision: 244955
URL: https://gcc.gnu.org/viewcvs?rev=244955&root=gcc&view=rev
Log:
PR debug/79129
* dwarf2out.c (generate_skeleton_bottom_up)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79129
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
Bug ID: 79252
Summary: Improve code generation of vec_insert on PowerPC ISA
2.07 (i.e. power8)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: enhanceme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
--- Comment #1 from Michael Meissner ---
Created attachment 40595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40595&action=edit
File to show various vector inserts
Compile this file with -O2 -mcpu=power9 (or -O2 -mcpu=power8), and look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
--- Comment #1 from Michael Meissner ---
Created attachment 40594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40594&action=edit
Test case to show the various vec_inserts
Compile this code with -O2 -mcpu=power8, and look at the various
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #6 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #4)
> So, is this now fixed or is further work needed?
A further work is needed. There are a few different problems with the big
endian support. I'll submit more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79253
Bug ID: 79253
Summary: [7 Regression] ICE in tsubst_copy starting with
r243723
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79253
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78896
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #29 from Jakub Jelinek ---
(In reply to Maxim Ostapenko from comment #28)
> > In short, the easiest fix is just to disable the initialization order
> > checking altogether for LTO (by forcing dynamically_initialized = 0 in LTO).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #5 from Arnd Bergmann ---
Created attachment 40596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40596&action=edit
test case with correct whitespace
I thought I had tried it with the source pasted from the bug last time, but
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
--- Comment #10 from Martin Sebor ---
Author: msebor
Date: Thu Jan 26 23:07:02 2017
New Revision: 244956
URL: https://gcc.gnu.org/viewcvs?rev=244956&root=gcc&view=rev
Log:
PR middle-end/78703 - fprintf-return-value floating point handling incorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78703
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #8 from H. Peter Anvin ---
I guess I'm confused why it would not be possible to specify the endianness of
a scalar, or perhaps far more importantly a pointer to a scalar. Other than
that, this feature seems to do 90% of what I was as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #23 from Eric Botcazou ---
Created attachment 40597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40597&action=edit
Tentative fix I'm going to test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #4 from H. Peter Anvin ---
There are a few issues with that:
a) the overflow behavior is inherently different, which is why the inline you
propose doesn't work. Try compiling the attached program, on x86-64 it
produces a call to __u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #1 from H. Peter Anvin ---
Created attachment 40598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40598&action=edit
Source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #2 from H. Peter Anvin ---
Created attachment 40599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40599&action=edit
Preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #3 from H. Peter Anvin ---
Created attachment 40600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40600&action=edit
Assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #4 from H. Peter Anvin ---
My apologies for the three attachments; I incorrectly attached them to the
wrong bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #9 from Eric Botcazou ---
> I guess I'm confused why it would not be possible to specify the endianness
> of a scalar, or perhaps far more importantly a pointer to a scalar. Other
> than that, this feature seems to do 90% of what I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #5 from H. Peter Anvin ---
Created attachment 40601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40601&action=edit
Test case: source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #6 from H. Peter Anvin ---
Created attachment 40602
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40602&action=edit
Test case: preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #7 from H. Peter Anvin ---
Created attachment 40603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40603&action=edit
Test case: assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219
--- Comment #8 from H. Peter Anvin ---
(In reply to Richard Biener from comment #1)
> So you mean DW/W -> W, but that can result in the result being not
> representable?
> What's the desired behavior in this case? Invoking undefined behavior?
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79217
--- Comment #5 from H. Peter Anvin ---
As noted on bug 79219 there are a few issues with simply relying on __int128,
even if 32 bits is the natural "limb" size on a 32-bit architecture.
a) it requires algorithms to be implemented using lengthy (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #10 from H. Peter Anvin ---
It is not. I guess I'd like to modify the request to allow
__attribute__((scalar_storage_order())) to be specified for scalar *pointer*.
That would bring the 90% up to 99% at the very least; the inability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Bug ID: 79254
Summary: basic_string::operator= isn't exception safe
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #17 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #16)
> There are straightforward ways to avoid interspersing code with preprocessor
> conditionals:
Will GCC adopt this approach so that the warning can be enabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this problem; are there any special (configure)
flags I need?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433
--- Comment #12 from Vincent Lefèvre ---
New test case, based on the previous one (just a __builtin_expect added):
int t[1];
int a (void);
int fct (int r, long e, int neg)
{
int d = 0;
if (r == 4)
r = neg ? 3 : 2;
if (__builtin_expect(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #18 from Martin Sebor ---
I don't know the full history behind this particular warning but I think a good
way to find out if it can be adopted by GCC is to see the extent of the changes
required to clean up the code base so it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #2 from Jonathan Wakely ---
Created attachment 40604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40604&action=edit
Untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #3 from Jonathan Wakely ---
That patch is wrong, it also needs this in the catch block to restore the
original allocator:
_M_get_allocator() = __guard._M_alloc;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.9.4
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #6 from Daryl Haresign ---
I guess you don't want _M_copy_assign to be public, either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254
--- Comment #7 from Daryl Haresign ---
I would also be inclined to reverse your Guard: have it take 'this', have an
'activate' method which swaps in the new values, have a 'deactivate' method
which releases the memory, and have its destructor swa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79241
--- Comment #5 from night_ghost at ykoctpa dot ru ---
I'll try to exclude maximum of unneeded code from testcase and then upload it.
101 - 176 of 176 matches
Mail list logo
