[Bug tree-optimization/23384] escaped set should be flow sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81776 --- Comment #10 from Martin Sebor --- As a data point, Clang manages to optimize at least the simple case in bug 81788 as expected. No other compiler I've tested does (IBM XLC, Intel ICC, Visual Studio, or Sun/Oracle Studio).
[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81776 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=23384 --- Comment #1 from Martin Sebor --- See also bug 23384 for a related limitation.
[Bug tree-optimization/23384] escaped set should be flow sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 --- Comment #9 from Martin Sebor --- As a data point, Clang manages to optimize at least the simple case in bug 81788 as expected. No other compiler I've tested does (IBM XLC, Intel ICC, Visual Studio, or Sun/Oracle Studio).
[Bug tree-optimization/81788] address of a local variable escapes too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81788 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- Dupe of bug 23384 sounds right. The aliasing pass is documented as flow insensitive so I suspected this was a known limitation. Thanks for confirming that. *** This bug has been marked as a duplicate of bug 23384 ***
[Bug tree-optimization/23384] escaped set should be flow sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- *** Bug 81788 has been marked as a duplicate of this bug. ***
[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81784 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #1 from Andrew Pinski --- Confirmed on aarch64-linux-gnu.
[Bug c++/81789] New: CWG1687 performed too soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81789
Bug ID: 81789
Summary: CWG1687 performed too soon
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider this reduced example taken from StackOverflow
(https://stackoverflow.com/questions/45602368/correct-behavior-of-built-in-operator-candidates-of-the-overload-resolution-in-t):
struct X { X(int*); };
struct Y { operator double(); };
int operator+(X, int);
int main() {
int{(int*)0 + Y()};
}
gcc compiles it fine. But the built-in operator, operator+(int*, std::ptrdiff_t
) should be a better match and selected by overload resolution and THEN, as a
result of CWG 1687, the expression should be considered ill-formed. However, it
appears that gcc pre-rejects that overload first and instead picks the provided
operator+().
clang does the opposite, preferring the builtin operator and then not rejecting
it, so this program fails to compile, but for the wrong reason (due to not
being able to convert int* to int).
[Bug c/81687] Compiler drops label in OpenMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81687 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Aug 10 00:33:20 2017 New Revision: 251019 URL: https://gcc.gnu.org/viewcvs?rev=251019&root=gcc&view=rev Log: PR c/81687 * omp-low.c (omp_copy_decl): Don't remap FORCED_LABEL or DECL_NONLOCAL LABEL_DECLs. * tree-cfg.c (move_stmt_op): Don't adjust DECL_CONTEXT of FORCED_LABEL or DECL_NONLOCAL labels. (move_stmt_r) : Adjust DECL_CONTEXT of FORCED_LABEL or DECL_NONLOCAL labels here. * testsuite/libgomp.c/pr81687-1.c: New test. * testsuite/libgomp.c/pr81687-2.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr81687-1.c trunk/libgomp/testsuite/libgomp.c/pr81687-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/tree-cfg.c trunk/libgomp/ChangeLog
[Bug tree-optimization/81788] address of a local variable escapes too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81788 --- Comment #1 from Andrew Pinski --- Dup of bug 23384 I think.
[Bug tree-optimization/81788] New: address of a local variable escapes too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81788
Bug ID: 81788
Summary: address of a local variable escapes too early
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is similar to bug 81776.
It seems that the alias analysis considers the address of a local variable to
escape if a call to an unknown function is made after the latter variable has
been declared, that takes the address of another local variable even if the
variable isn't used until after the call.
Clang emits optimal code for both functions below (though other compilers
suffer the same limitation).
$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c
void f (void*);
void g0 (void)
{
int a = 123;
f (&a);
int b = 456;
if (b != 456) // can never be true
__builtin_abort (); // eliminated
f (&b);
}
void g1 (void)
{
int a = 123;
int b = 456;
f (&a);
if (b != 456) // can never be true
__builtin_abort (); // not eliminated
f (&b);
}
;; Function g0 (g0, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)
g0 ()
{
int b;
int a;
[100.00%] [count: INV]:
a = 123;
f (&a);
b = 456;
f (&b);
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return;
}
;; Function g1 (g1, funcdef_no=1, decl_uid=1822, cgraph_uid=1, symbol_order=1)
g1 ()
{
int b;
int a;
int b.1_1;
[100.00%] [count: INV]:
a = 123;
b = 456;
f (&a);
b.1_1 = b;
if (b.1_1 != 456)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
f (&b);
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return;
}
[Bug libstdc++/81751] [5/6/7/8 Regression]__basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 Jonathan Wakely changed: What|Removed |Added Known to work||3.4.2 Summary|__basic_file::sync() may|[5/6/7/8 |flush _all_ files |Regression]__basic_file::sy ||nc() may flush _all_ files Known to fail||3.4.4, 5.4.0, 6.3.0, 7.1.0 --- Comment #8 from Jonathan Wakely --- Fixed on trunk so far.
[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81643 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #6 from Steve Ellcey --- This is caused by adding the predict statement in finish_goto_label (c/c-typeck.c). I tried to modify the test case to generate an Ltb label again but could not do it. I put an abort in aarch64_gen_far_branch for anytime an Ltb label was generated but after doing a bootstrap and a full testsuite run never hit the abort. I tried writing a new testsuite from scratch but again, could not generate an Ltb label. I am thinking that maybe we should just remove the Ltb check from the test case.
[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #11 from Segher Boessenkool --- Fixed on trunk.
[Bug target/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 --- Comment #5 from Segher Boessenkool --- Fixed on trunk for rs6000; backports pending.
[Bug target/79391] sh ICE in in eligible_for_delay, at config/sh/sh.md:564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79391 --- Comment #2 from Joel Sherrill --- It builds on the gcc head and the 7 branch now. Should we just go ahead and close this or does it matter when it was fixed?
[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423 --- Comment #10 from Segher Boessenkool --- Author: segher Date: Wed Aug 9 21:52:30 2017 New Revision: 251011 URL: https://gcc.gnu.org/viewcvs?rev=251011&root=gcc&view=rev Log: This time with the file added. Testcase for PR81423 gcc/testsuite/ PR rtl-optimization/81423 * gcc.c-torture/execute/pr81423.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr81423.c
[Bug c++/81787] New: `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787 Bug ID: 81787 Summary: `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8 Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: b.r.longbons at gmail dot com Target Milestone: --- This worked with 4.7, but fails with 4.8 through 7.1. Original reports on StackOverflow: https://stackoverflow.com/questions/10932479/in-gcc-how-to-mute-the-fpermissive-warning https://stackoverflow.com/questions/45600368/how-to-supress-a-fpermissive-error-using-modern-gcc
[Bug target/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Wed Aug 9 21:08:33 2017 New Revision: 251005 URL: https://gcc.gnu.org/viewcvs?rev=251005&root=gcc&view=rev Log: rs6000: Use SAVE_MULTIPLE only if we restore what it saves (PR80938) We can have SAVE_MULTIPLE while we do not have REST_MULTIPLE. If the inline restore does not restore all registers, the CFI for the save and restore can conflict if things are shrink-wrapped. We could restore all registers that are saved (not ideal), or emit the CFI notes to say we did (which will work fine, but is also not so great); instead, let's not save the registers that are unused. PR target/80938 * config/rs6000/rs6000.c (rs6000_savres_strategy): Don't use SAVE_MULTIPLE if not all the registers that saves, should be saved. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Wed Aug 9 21:05:45 2017 New Revision: 251004 URL: https://gcc.gnu.org/viewcvs?rev=251004&root=gcc&view=rev Log: Testcase for PR81423 gcc/testsuite/ PR rtl-optimization/81423 * gcc.c-torture/execute/pr81423.c: New testcase. Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 --- Comment #3 from David Binderman --- (In reply to Martin Liška from comment #2) > Confirmed, started with r250048. Still going wrong, nearly a month later. Revision 250983 seems to demonstrate the problem.
[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #5 from Jason Merrill --- (In reply to Jason Merrill from comment #4) > Modified: > branches/gcc-7-branch/gcc/cp/ChangeLog > branches/gcc-7-branch/gcc/cp/pt.c Reverted for now, as 7.2 is frozen.
[Bug tree-optimization/81786] New: local restricted pointer can be relied on in alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81786
Bug ID: 81786
Summary: local restricted pointer can be relied on in alias
analysis
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I've been looking for opportunities to improve code generation by relying on
explicit guarantees about aliasing properties that commonly hold but that GCC
cannot otherwise rely on due to the lack of contextual information. For
instance, it's common for a function that takes a non-const pointer argument
(say Q) to modify the object it points to (say X), then call some other
function (say FOO), and then read X's value again via *Q. Unless GCC knows the
semantics of FOO it must assume that every call to it changes the value of X,
even though it's quite rare in practice for that to happen. It would be nice
to be able to express this guarantee to GCC to let it generate more efficient
code.
As it turns out, according to the C aliasing rules, locally declaring a
restrict-qualified pointer P as a copy of an unknown pointer Q (such as a
function argument) can be used to express the guarantee that the object X the
pointers point to isn't modified during P's lifetime. (This is 6.7.3.1, p4.)
So with this simple notation, GCC could rely on this guarantee to optimize the
program below as indicated in the comments. Note that neither functions need
to make use of the restrict qualifier in its interface. This is helpful
because relatively few functions do.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
void foo (void);
void bar (int *q)
{
int* restrict p = q;
*p = 123;
foo (); // must not modify *P
if (*p != 123) // cannot be true
__builtin_abort (); // can be eliminated
}
int x;
void baz (void)
{
x = 789;
bar (&x);
}
;; Function bar (bar, funcdef_no=0, decl_uid=1817, cgraph_uid=0,
symbol_order=0)
bar (int * q)
{
int _1;
[100.00%] [count: INV]:
*q_2(D) = 123;
foo ();
_1 = *q_2(D);
if (_1 != 123)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
return;
}
;; Function baz (baz, funcdef_no=1, decl_uid=1822, cgraph_uid=1,
symbol_order=2)
baz ()
{
int _2;
[100.00%] [count: INV]:
x = 123;
foo ();
_2 = x;
if (_2 != 123)
goto ; [0.04%] [count: 0]
else
goto ; [99.96%] [count: INV]
[0.04%] [count: 0]:
__builtin_abort ();
[99.96%] [count: INV]:
return;
}
[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #4 from Jason Merrill --- Author: jason Date: Wed Aug 9 20:17:55 2017 New Revision: 251001 URL: https://gcc.gnu.org/viewcvs?rev=251001&root=gcc&view=rev Log: PR c++/81525 - wrong constant value with generic lambda * pt.c (tsubst_decl) [VAR_DECL]: Avoid clobbering auto. (tsubst_copy) [VAR_DECL]: Handle auto. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/pt.c
[Bug c++/67054] Constructor inheritance with non-default constructible members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67054 --- Comment #6 from Jason Merrill --- Author: jason Date: Wed Aug 9 20:17:47 2017 New Revision: 251000 URL: https://gcc.gnu.org/viewcvs?rev=251000&root=gcc&view=rev Log: PR c++/67054 - Inherited ctor with non-default-constructible members * method.c (walk_field_subobs) Consider member initializers (NSDMIs) when deducing an inheriting constructor. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/inh-ctor29.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/method.c
[Bug c++/81398] Complaining about 'partial specialization of '...' after instantiation' in c++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81398 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- This is the result of DR 150/P0522R0.
[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78603 --- Comment #7 from jcmvbkbc at gcc dot gnu.org --- *** Bug 67586 has been marked as a duplicate of this bug. ***
[Bug target/67586] xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67586 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- *** This bug has been marked as a duplicate of bug 78603 ***
[Bug target/78860] ICE in compilation for MIPS with -mpaired-single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78860 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||clm at codesourcery dot com, ||echristo at gmail dot com, ||marxin at gcc dot gnu.org, ||matthew.fortune at imgtec dot com Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Adding port maintainers.
[Bug target/64546] m32c ICE at calls.c:3638 compiling newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64546 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started in between 4.9 and 5.
[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed Aug 9 19:21:49 2017 New Revision: 250999 URL: https://gcc.gnu.org/viewcvs?rev=250999&root=gcc&view=rev Log: PR c++/81525 - wrong constant value with generic lambda * pt.c (tsubst_decl) [VAR_DECL]: Avoid clobbering auto. (tsubst_copy) [VAR_DECL]: Handle auto. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug target/67586] xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67586 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce with cross-compiler, is it reproducible on x86_64-linux-gnu?
[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67638 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it reproducible with cross compiler? Which options do you use?
[Bug target/67643] [SH] ICE with ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||aoliva at gcc dot gnu.org, ||kkojima at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||olegendo at gcc dot gnu.org Known to work||4.9.0 Ever confirmed|0 |1 Known to fail||5.4.0 --- Comment #1 from Martin Liška --- Confirmed, 4.9 looks fine, while 5 is affected by the ICE. Adding port maintainers.
[Bug target/68834] ICE: in decompose_normal_address, at rtlanal.c:6086 with -O2 -fPIC --param=sched-autopref-queue-depth=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68834 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Known to work||7.1.0, 8.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, it's connected to haifa scheduler. Fixed on trunk in r239105 as we switched to LRA. It's probably broken since the problematic param was introduced.
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #13 from H.J. Lu --- (In reply to Mike Lothian from comment #12) > Created attachment 41960 [details] > si_shader objdumps We need a small testcase in C.
[Bug libgomp/68033] OpenMP: ICE with teams distribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #2 from Martin Jambor ---
Below is a slightly more reduced testcase, crashes with gcc -S -fopenmp.
From what I have gathered so far, we would like to issue an error from
the gimplifier about a non sharing of an artificial temporary variable
that has not DECL_NAME and thus segfault.
void lud_omp(float *a, int size)
{
int i,j,k;
float sum;
for (i=0; i
[Bug c/81785] New: Segmentation fault for signed overflow in index expression when -fwrapv is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81785
Bug ID: 81785
Summary: Segmentation fault for signed overflow in index
expression when -fwrapv is enabled
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: willwalker26 at gmail dot com
Target Milestone: ---
Created attachment 41961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41961&action=edit
reproduction preprocessed file
gcc version 4.9.2 (Debian 4.9.2-10)
Target: x86_64-linux-gnu
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O0' '-fwrapv' '-mtune=generic'
'-march=x86-64'
Compiling the c file (see the attached preprocessed file):
% gcc -O0 -fwrapv repro.c
Execution results in:
% ./a.out
Segmentation fault
I also tried with varied levels of optimization to the same results. It looks
like 4.7.x and earlier versions of gcc work as expected.
The offending code segment is:
unsigned int k;
unsigned int i;
i = 0U;
k = 2147483648U;
while (k < 2147483658U) {
y[i] = x[(int)k - (int)2147483611];
k++;
i++;
}
What I was hoping to happen, is to have (int)k wrap to some large negative
value and the following signed subtraction wrap to a small positive value in
the range [37,46]. Note the arrays for x and y are length 100.
I am aware that signed overflow is not defined in C, but was hoping that using
the -fwrapv compiler option would let this through.
Note, hoisting out the index expression results in the expected execution,
e.g.:
tmp = (int)k - (int)2147483611;
y[i] = x[tmp];
[Bug libstdc++/81359] [7 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81359 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Component|c++ |libstdc++ Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[7/8 Regression] bogus |[7 Regression] bogus error: |error: constructor required |constructor required before |before non-static data |non-static data member for |member for ‘Foo::Bar::test’ |‘Foo::Bar::test’ has been |has been parsed |parsed --- Comment #4 from Jason Merrill --- I've adjusted the compiler to accept this on trunk, but the change is too invasive for the GCC 7 branch. I'm changing the component to libstdc++ so that library folks can consider a library approach for the branch.
[Bug c++/81359] [7/8 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81359 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed Aug 9 18:32:02 2017 New Revision: 250994 URL: https://gcc.gnu.org/viewcvs?rev=250994&root=gcc&view=rev Log: PR c++/81359 - Unparsed NSDMI error from SFINAE context. * init.c (get_nsdmi): Add complain parm. * typeck2.c (digest_nsdmi_init): Add complain parm. (process_init_constructor_record): Pass complain to get_nsdmi. * pt.c (maybe_instantiate_noexcept): Add complain parm, return bool. * method.c (get_defaulted_eh_spec): Add complain parm. Pass it into synthesized_method_walk. (synthesized_method_walk): Adjust. (walk_field_subobs): Pass complain to get_nsdmi. (defaulted_late_check): Skip other checks if deleted. * decl2.c (mark_used): Pass complain to maybe_instantiate_noexcept. * call.c (build_aggr_conv): Pass complain to get_nsdmi. * parser.c (defarg_location): New. * error.c (location_of): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae59.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/error.c trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi10.C
[Bug target/67694] ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67694 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed for GCC 6 and 7.
[Bug libstdc++/79820] std::ifstream sets errno to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #9 from Jonathan Wakely --- Fixed for GCC 8.
[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- I have a patch (for rs6000).
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Aug 9 17:52:10 2017 New Revision: 250993 URL: https://gcc.gnu.org/viewcvs?rev=250993&root=gcc&view=rev Log: PR libstdc++/81751 don't call fflush(NULL) PR libstdc++/79820 PR libstdc++/81751 * config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)): Call fflush on the stream instead of calling sync() while _M_cfile is null. Restore original value of errno. * testsuite/ext/stdio_filebuf/char/79820.cc: New. * testsuite/ext/stdio_filebuf/char/81751.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.cc
[Bug libstdc++/79820] std::ifstream sets errno to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Wed Aug 9 17:52:10 2017 New Revision: 250993 URL: https://gcc.gnu.org/viewcvs?rev=250993&root=gcc&view=rev Log: PR libstdc++/81751 don't call fflush(NULL) PR libstdc++/79820 PR libstdc++/81751 * config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)): Call fflush on the stream instead of calling sync() while _M_cfile is null. Restore original value of errno. * testsuite/ext/stdio_filebuf/char/79820.cc: New. * testsuite/ext/stdio_filebuf/char/81751.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/basic_file_stdio.cc
[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80618 --- Comment #14 from Martin Liška --- *** Bug 80503 has been marked as a duplicate of this bug. ***
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Confirmed, it's dup. *** This bug has been marked as a duplicate of bug 80618 ***
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #12 from Mike Lothian --- Created attachment 41960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41960&action=edit si_shader objdumps
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #11 from Mike Lothian --- So a lot of the segfaults I see are in si_shader so I thought I'd compile Mesa with and without BMI and compare the onjdumps of the two .o files CFLAGS="-O2 -march=native -pipe -mno-bmi -m32" CXXFLAGS="-O2 -march=native -pipe -mno-bmi -m32" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=bfd -m32" ./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/mesa- --htmldir=/usr/share/doc/mesa-/html --libdir=/usr/lib32 --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --enable-nine --disable-debug --enable-dri3 --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-libunwind --enable-valgrind=no --enable-llvm-shared-libs --with-dri-drivers=,swrast,i965 --with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm --enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau --disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers --disable-glx-read-only-text --disable-gallium-osmesa CFLAGS="-O2 -march=native -pipe -m32" CXXFLAGS="-O2 -march=native -pipe -m32" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=bfd -m32" ./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/mesa- --htmldir=/usr/share/doc/mesa-/html --libdir=/usr/lib32 --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --enable-nine --disable-debug --enable-dri3 --enable-egl --enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-libunwind --enable-valgrind=no --enable-llvm-shared-libs --with-dri-drivers=,swrast,i965 --with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm --enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau --disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers --disable-glx-read-only-text --disable-gallium-osmesa Were my configure options, and LLVM was compiled with -mno-bmi I'm attaching the dumps
[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81784 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-09 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81753 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Segher Boessenkool --- (In reply to Martin Liška from comment #4) > I can confirm it works ;) Should I send the patch and install it? Please send the patch for review.
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #2 from Andreas Schwab --- No, it doesn't. It only made it possible to call the builtin from the frontend.
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 --- Comment #6 from Jonathan Wakely --- Or just call fflush(__file) directly: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00673.html
[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Ever confirmed|0 |1 --- Comment #4 from Alexander Monakov --- I agree that simd loop in the presented testcase is mishandled, but fwiw the original for-5.c testcase should not exhibit this issue with loop counter wraparound; the root cause must have been different in the original failure you were seeing.
[Bug c++/81767] Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |FIXED Target Milestone|--- |8.0
[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79565
--- Comment #2 from H.J. Lu ---
Created attachment 41959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41959&action=edit
A patch
I got
[hjl@gnu-6 pr79565]$ cat x.i
typedef float a __attribute__ ((__vector_size__ (16)));
a b, d;
int __attribute__ ((__vector_size__ (2 * sizeof (int c;
void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
[hjl@gnu-6 pr79565]$ make x.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o x.s x.i
x.i: In function ‘e’:
x.i:4:17: error: ‘__builtin_ia32_cvtpi2ps’ needs isa option -m32 -msse -mmmx
void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
^~
make: *** [Makefile:21: x.s] Error 1
[hjl@gnu-6 pr79565]$ cat y.i
typedef short v4hi __attribute__ ((__vector_size__ (4 * sizeof (short;
v4hi a, b, c;
void
foo (void)
{
a = __builtin_ia32_psubusw (b, c);
}
[hjl@gnu-6 pr79565]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o y.s y.i
y.i: In function ‘foo’:
y.i:6:7: error: ‘__builtin_ia32_psubusw’ needs isa option -m32 -mmmx
a = __builtin_ia32_psubusw (b, c);
^
make: *** [Makefile:21: y.s] Error 1
[hjl@gnu-6 pr79565]$
[Bug c++/81767] Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767 Antony Polukhin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Antony Polukhin --- Yep, feature was already implemented in r248483
[Bug testsuite/81784] New: [8 regression] gcc.dg/compare2.c fails starting with r250984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81784 Bug ID: 81784 Summary: [8 regression] gcc.dg/compare2.c fails starting with r250984 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- The recent change to the test case gcc.dg/compare2.c doesn't seem to work quite right. At least not on powerpc64 where it fails on both BE and LE (tested on power8). spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Wsign-compare -S -o compare2.s /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] output is: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f': /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other operand [-Wsign-compare] PASS: gcc.dg/compare2.c case 1 (test for bogus messages, line 12) PASS: gcc.dg/compare2.c case 2 (test for bogus messages, line 13) PASS: gcc.dg/compare2.c case 3 (test for bogus messages, line 16) PASS: gcc.dg/compare2.c case 4 (test for bogus messages, line 17) PASS: gcc.dg/compare2.c case 5 (test for bogus messages, line 20) PASS: gcc.dg/compare2.c case 6 (test for warnings, line 21) PASS: gcc.dg/compare2.c case 7 (test for bogus messages, line 24) PASS: gcc.dg/compare2.c case 8 (test for warnings, line 25) PASS: gcc.dg/compare2.c case 9 (test for bogus messages, line 28) PASS: gcc.dg/compare2.c case 10 (test for bogus messages, line 29) PASS: gcc.dg/compare2.c case 11 (test for bogus messages, line 32) PASS: gcc.dg/compare2.c case 12 (test for bogus messages, line 33) PASS: gcc.dg/compare2.c case 13 (test for bogus messages, line 36) PASS: gcc.dg/compare2.c case 14 (test for warnings, line 37) PASS: gcc.dg/compare2.c case 15 (test for bogus messages, line 40) PASS: gcc.dg/compare2.c case 16 (test for warnings, line 41) PASS: gcc.dg/compare2.c case 17 (test for bogus messages, line 44) PASS: gcc.dg/compare2.c case 18 (test for bogus messages, line 45) PASS: gcc.dg/compare2.c case 19 (test for bogus messages, line 48) FAIL: gcc.dg/compare2.c case 20 (test for warnings, line 49) PASS: gcc.dg/compare2.c case 21 (test for bogus messages, line 52) PASS: gcc.dg/compare2.c case 22 (test for bogus messages, line 53) PASS: gcc.dg/compare2.c case 23 (test for bogus messages, line 56) FAIL: gcc.dg/compare2.c case 24 (test for warnings, line 57) FAIL: gcc.dg/compare2.c (test for excess errors) Excess errors: /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning: operand of ?: changes signedness from 'int' to 'unsigned int' due to unsignedness of other
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 --- Comment #1 from Segher Boessenkool --- Is this a dup of PR80618? That is fixed on all branches already.
[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81586 --- Comment #6 from David Binderman --- (In reply to Martin Sebor from comment #5) > Patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01866.html Did this patch ever get into trunk gcc ? I have some evidence that gcc trunk revision 250947 doesn't have it.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #12 from DIL --- Could you please tell me if there is a way I can check whether the dissociated unlimited polymorphic pointer (class(*), pointer), which is set to NULL, is indeed set to a clean state internally? That is, could you please tell me the size and structure of the internal representation of a class(*) pointer and what the proper values of those components would be when the pointer is set to NULL()? I am still trying to understand why the sourced allocate() statement sees that pointer as ALLOCATED. Basically, I want to inspect the internal state of the class(*) NULL pointer to make sure that the problem indeed occurs inside the sourced allocate() statement. Thanks!
[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79565 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- (In reply to Martin Liška from comment #0) > All releases I have suffer from: > > Clang is also broken, ICC work for that test-case. What does ICC generate with -mno-mmx -O0?
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #10 from Mike Lothian --- Unfortunately it also depends on LLVM not just Mesa which makes it a much bigger target for figuring this out
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #9 from Alexander Monakov --- A (potentially simpler) alternative is to use sequential builds (make without -j) and bisect by index of compiled source file, i.e. have a wrapper script around gcc that uses some global counter to pass -mno-bmi to first N compiler invocations.
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751
--- Comment #5 from Volker Wehrs ---
I'm sorry but I ignored the first if-clause in sys_open(). That if-clause makes
sure there is no open file referenced by the __basic_file, otherwise sys_open()
fails.
Then the sync() is called before the new __file is set, so in the current
implementation sync() can only see a _M_cfile set to NULL. Thus sync() is wrong
here.
Note that currently the new file (in __file) is implicitly flushed by the call
to fflush("NULL"), i.e. "flush all". So the new file should be sync'd
explicitly.
So sys_open() might look like this:
__basic_file*
__basic_file::sys_open(__c_file* __file, ios_base::openmode)
{
__basic_file* __ret = NULL;
if (!this->is_open() && __file)
{
_M_cfile = __file;
_M_cfile_created = false;
__ret = this;
this->sync();
}
return __ret;
}
[...]
int
__basic_file::sync()
{
int __err;
do
__err = fflush(_M_cfile);
while ( __err && errno == EINTR );
return __err;
}
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #8 from Alexander Monakov --- Mike, you can start by preparing two build trees, one with faulty mesa compiled with -march=native, the other with working-fine mesa compiled with -march=native -mno-bmi. You should be able to collect: - .o files from each tree, and - link commands from build logs and be able to re-link mesa libraries by hand and verify they still exhibit the same behavior (one fails, the other doesn't). >From there you can proceed by building "hybrid" libraries by taking a set of good .o files and a complementary set of bad .o files. This will allow you to find a single .o file that makes the library behave wrongly. More explanation and a helper script for bisecting is available at https://gcc.gnu.org/wiki/Analysing_Large_Testcases At that point please share your status (once you're down to one file there's no generic recipe, you'd have to get creative).
[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938 Segher Boessenkool changed: What|Removed |Added Target|powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*, ||powerpc*-*-* --- Comment #2 from Segher Boessenkool --- Also fails on powerpc*-linux (it needs -Os -fPIC -m32 -g). It gets a conflict in the CFI for the hard frame pointer.
[Bug c++/2082] g++ defines _GNU_SOURCE by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2082 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Resolution|FIXED |WONTFIX --- Comment #11 from Eric Gallager --- (In reply to Jonathan Wakely from comment #10) > Should this be WONTFIX rather than FIXED? I think FIXED is the default for > "closed" from the old gnatweb system, but this was not fixed. > > Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make > it a dup of Bug 11196. From reading the previous comments it looks like WONTFIX is indeed more accurate than FIXED, so I'm changing the status to that for now. Bug 11196 looks like a more specific instance of this one so I'd say if one's going to be marked a duplicate of the other, it should probably be the other way around.
[Bug target/77953] [MIPS] ice: insn does not satisfy its constraints - __bswapsi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77953 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can't reproduce on x86_64-linux-gnu cross compiler. Is it reproducible?
[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > I don't see this any longer.
>
> I think I might've seen this before, but I'll have to double-check the next
> time I bootstrap to make sure
The warnings I get from gengtype-lex.c when bootstrapping are now:
../../gcc/gengtype-lex.l: In function ‘int yylex(const char**)’:
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
*yy_cp = '\0'; \
~~~^~~
../../gcc/gengtype-lex.l:116:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
*yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
^ ~~~
../../gcc/gengtype-lex.l:113:1: note: here
"~" |
^~~~
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
*yy_cp = '\0'; \
~~~^~~
../../gcc/gengtype-lex.l:133:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
^
../../gcc/gengtype-lex.l:131:1: note: here
"ENUM_BITFIELD"{WS}?"("{WS}?{ID}{WS}?")" {
^~~~
...which is no longer in a comment, but it still seems like there's some wrong
location information involved. Separate issue or the same thing?
[Bug target/78643] [5/6/7/8 Regression] ICE in convert_move, at expr.c:230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE in convert_move, at |[5/6/7/8 Regression] ICE in |expr.c:230 |convert_move, at expr.c:230 Ever confirmed|0 |1 Known to fail||8.0 --- Comment #1 from Martin Liška --- Confirmed, started with r220609.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643#
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Martin Liška changed: What|Removed |Added CC||eager at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r248540: commit 707a69dfb56a2976e2b5c010f0e5cb2ac9905a07 (refs/bisect/bad) Author: eager Date: Sat May 27 18:29:40 2017 + Revert: 2016-01-21 Ajit Agarwal See https://gcc.gnu.org/ml/gcc/2017-05/msg00221.html. * config/microblaze/microblaze.h (FIXED_REGISTERS): Update in macro. (CALL_USED_REGISTERS): Update in macro. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248540 138bc75d-0d04-0410-961f-82ee72b054a4 Can you please Agit take a look?
[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79810 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from H.J. Lu --- (In reply to Martin Liška from comment #1) > Fixed on trunk in r246161. Do you plan Uros to backport it? Should have been fixed on all branches. *** This bug has been marked as a duplicate of bug 80019 ***
[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80019 --- Comment #6 from H.J. Lu --- *** Bug 79810 has been marked as a duplicate of this bug. ***
[Bug target/48227] "rep ret" generated for -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227 --- Comment #5 from Matt Godbolt --- Seems to have been fixed in 4.9
[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79987 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Taking, I've got a patch.
[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||egallager at gcc dot gnu.org Blocks||24639 Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed that GCC warns here Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Martin Liška changed: What|Removed |Added Status|WAITING |NEW
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #3 from Martin Liška --- Created attachment 41958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41958&action=edit Minimal test-case
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #8 from Martin Liška --- *** Bug 80214 has been marked as a duplicate of this bug. ***
[Bug target/80214] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80214 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 79890 ***
[Bug c/81783] New: -Wtautological-compare could do better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81783
Bug ID: 81783
Summary: -Wtautological-compare could do better
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
This example code doesn't warn with -Wtautological-compare:
int f(int a)
{
if ((a & 0x10) == 10)
return 1;
return 0;
}
clang warns like this:
Wtautological-compare-1.c:5:17: warning: bitwise comparison always evaluates to
false [-Wtautological-compare]
if ((a & 0x10) == 10)
~~~^
[Bug c++/2082] g++ defines _GNU_SOURCE by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2082 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11196 --- Comment #10 from Jonathan Wakely --- Should this be WONTFIX rather than FIXED? I think FIXED is the default for "closed" from the old gnatweb system, but this was not fixed. Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make it a dup of Bug 11196.
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 --- Comment #16 from Jonathan Wakely --- See https://sourceware.org/bugzilla/show_bug.cgi?id=21326 and https://sourceware.org/bugzilla/show_bug.cgi?id=21327 for the changes to glibc that are needed before we can change anything in GCC.
[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81695 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- I think I won't backport this, so closing.
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #2 from Sergio Prado --- Created attachment 41957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41957&action=edit Pre-processed file from rtcm2_json.c compiled with -E option Here is the pre-processed file.
[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782 Marek Polacek changed: What|Removed |Added Target Milestone|--- |7.2 Summary|Yet another |[7/8 Regression] Yet |-Wmaybe-uninitialized false |another |positive with empty array |-Wmaybe-uninitialized false ||positive with empty array --- Comment #1 from Marek Polacek --- Started with commit 4d2b9d1e3c794a05c00708035519290e920768e8 Author: rguenth Date: Thu Mar 2 13:42:05 2017 + 2017-03-02 Richard Biener PR tree-optimization/79345 PR c++/42000 * tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit param and abort the walk, returning -1 if it is hit. (walk_aliased_vdefs): Take a limit param and pass it on. * tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param, defaulting to 0 and return a signed int. * tree-ssa-uninit.c (struct check_defs_data): New struct. (check_defs): New helper. (warn_uninitialized_vars): Use walk_aliased_vdefs to warn about uninitialized memory. * fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid bogus uninitialized warning. (fixed_convert_from_real): Likewise. * g++.dg/warn/Wuninitialized-7.C: New testcase. * c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized. * gcc.dg/uninit-pr19430-2.c: Add expected warning. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245840 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug middle-end/81782] New: Yet another -Wmaybe-uninitialized false positive with empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81782
Bug ID: 81782
Summary: Yet another -Wmaybe-uninitialized false positive with
empty array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
I hope this isn't a duplicate of one of the many similar PRs. This one happens
with -O0. Also, if you remove the (int) cast, the warning disappears, because
then we get rid of the if conditional.
$ ./cc1 -quiet w.c -Wall
w.c: In function ‘foo’:
w.c:8:22: warning: ‘empty_array[i]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
ret = empty_array[i];
~~~^~~
int
foo (void)
{
char empty_array[] = { };
int i, ret = 0;
for (i = 0; i < (int) (sizeof (empty_array) / sizeof (empty_array[0])); i++)
ret = empty_array[i];
return ret;
}
[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||marxin at gcc dot gnu.org Known to work||6.4.0 Summary|ICE in |[7/8 Regression] ICE in |__builtin_update_setjmp_buf |__builtin_update_setjmp_buf |expander|expander Ever confirmed|0 |1 Known to fail||7.1.0, 8.0 --- Comment #1 from Martin Liška --- Confirmed. Started with your commit r246720.
[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79810 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Known to work||7.1.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #1 from Martin Liška --- Fixed on trunk in r246161. Do you plan Uros to backport it?
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751
--- Comment #4 from Jonathan Wakely ---
But there is an open FILE and it might have pending writes or ungetc'd data
that should be flushed. I think that's why it's there. Consider:
FILE* f = std::fopen("81751.txt", "w+");
std::fwrite("Some words.", 1, 10, f);
__gnu_cxx::stdio_filebuf buf(f, std::ios::in|std::ios::out, BUFSIZ);
int c = buf.sgetc();
If the constructor doesn't flush then the read performed by sgetc will follow
the write without an intervening seek or flush, which is undefined behaviour.
The constructor taking a file descriptor creates a new FILE using fdopen, so
there are no buffered writes on the stream, and a flush isn't needed.
[Bug debug/79953] ICE in expand_debug_locations when attribute target is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79953 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, all releases I have ICE. (gdb) p debug_rtx(val) (mem/c:V32QI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -32 [0xffe0])) [0 x+0 S32 A256]) $4 = void (gdb) p mode $5 = BLKmode Problem is probably that nehalem does not have -mavx2 enabled and it's enabled in the source code via target attribute.
[Bug c++/81781] consexpr pointer comparsion error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81781
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-08-09
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Confirmed. Reduced:
template struct I { static constexpr int value = N; };
template constexpr int I::value;
static constexpr bool x = &I<5>::value == &I<10>::value;
ce.cc:5:40: error: ‘((& I<5>::value) == (& I<10>::value))’ is not a constant
expression
static constexpr bool x = &I<5>::value == &I<10>::value;
~^
[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81233 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed. Further improvements are possible.
[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81233 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Wed Aug 9 11:28:22 2017 New Revision: 250985 URL: https://gcc.gnu.org/viewcvs?rev=250985&root=gcc&view=rev Log: PR c/81233 * c-typeck.c (pedwarn_init): Make the function take a variable list. Call emit_diagnostic_valist instead of pedwarn. (convert_for_assignment): Unroll the PEDWARN_FOR_ASSIGNMENT macro. Print the relevant types in diagnostics. * diagnostic-core.h (emit_diagnostic_valist): Add declaration. * diagnostic.c (emit_diagnostic): Add a comment. (emit_diagnostic_valist): New function. * gcc.dg/diagnostic-types-1.c: New test. * gcc.dg/assign-warn-1.c: Update warning messages. * gcc.dg/assign-warn-2.c: Likewise. * gcc.dg/c90-const-expr-5.c: Likewise. * gcc.dg/c99-const-expr-5.c: Likewise. * gcc.dg/conv-2.c: Likewise. * gcc.dg/init-bad-7.c: Likewise. * gcc.dg/overflow-warn-1.c: Likewise. * gcc.dg/overflow-warn-2.c: Likewise. * gcc.dg/overflow-warn-3.c: Likewise. * gcc.dg/overflow-warn-4.c: Likewise. * gcc.dg/pointer-array-atomic.c: Likewise. * gcc.dg/pr26865.c: Likewise. * gcc.dg/pr61162-2.c: Likewise. * gcc.dg/pr61162.c: Likewise. * gcc.dg/pr67730-2.c: Likewise. * gcc.dg/pr69156.c: Likewise. * gcc.dg/pr70174.c: Likewise. * objc.dg/proto-lossage-4.m: Likewise. Added: trunk/gcc/testsuite/gcc.dg/diagnostic-types-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-1.c trunk/gcc/testsuite/gcc.dg/assign-warn-2.c trunk/gcc/testsuite/gcc.dg/c90-const-expr-5.c trunk/gcc/testsuite/gcc.dg/c99-const-expr-5.c trunk/gcc/testsuite/gcc.dg/conv-2.c trunk/gcc/testsuite/gcc.dg/init-bad-7.c trunk/gcc/testsuite/gcc.dg/overflow-warn-1.c trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c trunk/gcc/testsuite/gcc.dg/overflow-warn-3.c trunk/gcc/testsuite/gcc.dg/overflow-warn-4.c trunk/gcc/testsuite/gcc.dg/pointer-array-atomic.c trunk/gcc/testsuite/gcc.dg/pr26865.c trunk/gcc/testsuite/gcc.dg/pr61162-2.c trunk/gcc/testsuite/gcc.dg/pr61162.c trunk/gcc/testsuite/gcc.dg/pr67730-2.c trunk/gcc/testsuite/gcc.dg/pr69156.c trunk/gcc/testsuite/gcc.dg/pr70174.c trunk/gcc/testsuite/objc.dg/proto-lossage-4.m
[Bug c++/81750] Calling generic lambda with no parameter fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81750 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Indeed, thanks, Tim. *** This bug has been marked as a duplicate of bug 64095 ***
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Jonathan Wakely changed: What|Removed |Added CC||d25fe0be at outlook dot com --- Comment #6 from Jonathan Wakely --- *** Bug 81750 has been marked as a duplicate of this bug. ***
[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- (In reply to Florian Weimer from comment #1) > Could we turn calls to regparam (3) functions into noplt calls? Some > additional mechanics are probably needed if the address of such a function > is taken. Yes, we can make regparam (3) to imply __attribute__ ((noplt)) with -finstrument-control-flow -mcet. It should work.
[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80503 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||amodra at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/80700] [7/8 Regression] ICE: Bus error (on SPE target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-09 CC||bergner at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[8 Regression] ICE: Bus |[7/8 Regression] ICE: Bus |error (on SPE target) |error (on SPE target) Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r244609.
[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780 --- Comment #1 from Florian Weimer --- Could we turn calls to regparam (3) functions into noplt calls? Some additional mechanics are probably needed if the address of such a function is taken.
