[Bug c++/70387] New: -fnon-call-exceptions has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70387
Bug ID: 70387
Summary: -fnon-call-exceptions has no effect
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jwjagersma at gmail dot com
Target Milestone: ---
I wrote some code to trap a hardware exception, and transfer control to a
signal handler which throws a C++ exception.
From the documentation, I believe '-fnon-call-exceptions' (and/or
'-fasynchronous-unwind-tables') should allow me to do this, but it doesn't
work.
It appears that gcc doesn't consider that non-call instructions may throw, and
silently omits the try/catch block around it. The exception is only caught when
the trapped instruction appears in a (non-inlined) function, or inbetween two
function calls.
--- Output from 'gcc -v':
Using built-in specs.
COLLECT_GCC=D:\msys64\usr\local\djgpp\i586-pc-msdosdjgpp\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/usr/local/djgpp/lib/gcc/../../libexec/gcc/i586-pc-msdosdjgpp/5.3.0/lto-wrapper.exe
Target: i586-pc-msdosdjgpp
Configured with: ../gnu/gcc-5.30/configure --host= --build=x86_64-w64-mingw32
--target=i586-pc-msdosdjgpp --program-prefix=i586-pc-msdosdjgpp-
--prefix=/usr/local/djgpp --disable-nls --disable-plugin --disable-lto
--enable-lto --enable-libquadmath-support
--with-gmp=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--with-mpfr=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--with-mpc=/home/JW/build-djgpp/build/djcross-gcc-5.3.0/tmpinst
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: single
gcc version 5.3.0 (GCC)
--- Example code: (implementation details omitted)
void throw_exception()
{
throw std::runtime_error("Division by zero!");
}
__attribute__((noinline))
void try_div0()
{
cout << 1 / 0 << endl;
}
void nop() { asm(""); }
int main()
{
// this class traps a hardware exception (division by zero, in this case)
and calls the supplied lambda function.
exception_wrapper div0_exc { 0, [] (exception_frame* frame, bool)
{
// only handle exceptions that occured in our own code
if (frame->address.segment != get_cs()) return false;
// sub , 4;
frame->stack.offset -= 4;
// get pointer to []
auto* stack = reinterpret_cast(frame->stack.offset);
// mov [], ;
*stack = frame->address.offset;
// resume at throw_exception()
frame->address.offset =
reinterpret_cast(throw_exception);
return true;
} };
try
{ // thrown from inside a function, this exception is caught.
try_div0();
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
try
{ // thrown inbetween two function calls, this exception is caught.
nop();
cout << 1 / 0 << endl;
nop();
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
try
{ // throws, but is NOT CAUGHT!
cout << 1 / 0 << endl;
}
catch (std::exception& e) { cout << "oops: " << e.what() << endl; }
}
[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 Gladkov Dmitry changed: What|Removed |Added CC||gladkovdmitry17 at yandex dot ru --- Comment #4 from Gladkov Dmitry --- The same has been seen by me in gcc 4.9.2 on SLES 12. The __cancel_routine variable is never modifed, but I see the following: error: variable __cancel_routine might be clobbered by "longjmp" or "vfork" [-Werror=clobbered] #define ThreadCleanUpPush_m(func,arg) pthread_cleanup_push((func),\ Please, provide any workaround for the problem.
[Bug c++/70386] New: ICE with -Wall on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70386
Bug ID: 70386
Summary: ICE with -Wall on valid code on x86_64-linux-gnu in
verify_ctor_sanity, at cp/constexpr.c:2232
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current GCC trunk with
-Wall on x86_64-linux-gnu in both 32-bit and 64-bit modes.
This is a regression from 5.3.x.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160323 (experimental) [trunk revision 234418] (GCC)
$
$ g++-trunk small.cpp
$ g++-5.3 -Wall small.cpp
$
$ g++-trunk -Wall small.cpp
small.cpp: In function ‘int main()’:
small.cpp:14:20: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2232
return (cp () == d);
^
0x845875 verify_ctor_sanity
../../gcc-source-trunk/gcc/cp/constexpr.c:2232
0x852643 cxx_eval_bare_aggregate
../../gcc-source-trunk/gcc/cp/constexpr.c:2257
0x84d924 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3699
0x851fa9 cxx_eval_component_reference
../../gcc-source-trunk/gcc/cp/constexpr.c:1954
0x84e2dc cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3670
0x8538f9 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:3947
0x8565bc maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4135
0x8565bc maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4156
0x779c36 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:5096
0x77b747 cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc-source-trunk/gcc/cp/typeck.c:4729
0x623d3a build_new_op_1
../../gcc-source-trunk/gcc/cp/call.c:5782
0x624d4e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:5827
0x766322 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc-source-trunk/gcc/cp/typeck.c:3866
0x740946 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8923
0x7410a0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9055
0x743979 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9222
0x73504e cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4878
0x736816 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6690
0x73f95c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:7988
0x7401b7 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8665
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
---
struct A { void f () {} };
struct B : public A {};
struct C : public A {};
struct D : public B, public C {};
typedef void (C::*cp) ();
typedef void (D::*dp) ();
int
main ()
{
cp c = &A::f;
dp d = c;
return (cp () == d);
}
[Bug ipa/70366] [6 Regression] chromium fails to build with LTO due to segfault in ipa-inline-transform.c:inline_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70366 --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- Created attachment 38076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38076&action=edit patch Hi, The attached patch suggested by Richard fixes the chromium build. It passes bootstrap+test on x86_64-unknown-linux-gnu and cross-tested on arm*-*-* and aarch64*-*-*. The patch however regresses libstdc++ for arm-none-eabi: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/234391-70366/arm-none-eabi/diff-libstdc++-rh60-arm-none-eabi-arm-cortex-a9-default.txt Looking at the logs there isn't much information: compiler exited with status 1 FAIL: 25_algorithms/partial_sort/moveable.cc (test for excess errors) Excess errors: exit status is 1 WARNING: 25_algorithms/partial_sort/moveable.cc compilation failed to produce executable The complete log is at: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/234391-70366/arm-none-eabi/libstdc++-rh60-arm-none-eabi-arm-cortex-a9-default.log.xz I don't have much ideas on how to proceed. I am trying to reduce the test-case, and reproduce the above regression locally and will get back if I find more information. Thanks, Prathamesh
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug c++/62212] [4.9/5/6 Regression] ICE compiling template function with array reference parameter whose size depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- A fix: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01357.html
[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235 --- Comment #10 from Jerry DeLisle --- Created attachment 38075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38075&action=edit A patch for testing Please test this patch as much as possible. I think I have it right, but one can never tell so independent testing helps. I must say this was a PITA to figure out.
[Bug c++/70385] New: Lambda capture by reference of const reference fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70385
Bug ID: 70385
Summary: Lambda capture by reference of const reference fails
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nikb at bougalis dot net
Target Milestone: ---
Consider the following minimal MCVE:
const int& test()
{
int const static i = 0;
return i;
}
int
main()
{
auto square = [&j = test()]()
{
};
return 0;
}
The expectation here is that `pays` will be a `const int&`. Clang successfully
compiles this code (along with a warning about j being unused) but gcc fails to
compile with an interesting error:
error: binding 'const int' to reference of type 'int&' discards qualifiers
&j = test()
~^~
This is clearly wrong. I believe that the correct behavior would be for `j` to
be a `const int&`.
We can simplify the example a bit more. The following code successfully
compiles and appears to do the "right" thing on both clang and gcc:
int
main()
{
int const i = 0;
auto test = [&i]()
{
};
test();
return 0;
}
The following code compiles and does the "right" thing in clang, but not in
gcc, where compilation fails:
int
main()
{
int const i = 0;
auto test = [&j = i]()
{
};
test();
return 0;
}
[Bug c++/70384] New: Unhelpful warnings on invalid initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70384
Bug ID: 70384
Summary: Unhelpful warnings on invalid initializations
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at magfr dot user.lysator.liu.se
Target Milestone: ---
Created attachment 38074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38074&action=edit
ex.cpp
Consider the following source (ex.cpp):
void f(int&);
void g(long t) {
f(t);
}
Compiling this gives the error
ex.cpp: In function 'void g(long int)':
ex.cpp:3:5: error: invalid initialization of non-const reference of type 'int&'
from an rvalue of type 'int'
f(t);
^
ex.cpp:1:6: note: initializing argument 1 of 'void f(int&)'
void f(int&);
^
and I think that error message is unhelpful.
invalid initialization of non-const reference of type 'int&' from an rvalue of
type 'int'
While this is true in some sense - the long input gets converted to an rvalue
int that isn't feasible as an argument to f - I still think the error message
in 4.4.6 was more helpful when it comes to correcting the error:
invalid initialization of reference of type ‘int&’ from expression of type
‘long int’
so, would it be possible to type the original type as the source type?
For reference clang++ (3.7.0) outputs
candidate function not viable: no known conversion from 'long' to 'int &' for
1st argument
and that is also helpful when it comes to fixing the problem.
[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69604 --- Comment #8 from Harald Anlauf --- Independent of the modification in comment #7, there is an issue with wrong code for the native complex type. Consider: program p complex :: z[*], w = 1 real:: x[*], y = 2 type t complex :: c real:: r end type t type(t) :: u[*], v !--- Using derived types: v% c = 42 v% r = 42 u = v! OK print *, u print *, v u = t(w, y) ! OK print *, u print *, t(w, y) !--- Using native types: z = (1.0, 0.0) ! Bad result w = (1.0, 0.0) print *, w, z ! z = w! ICE x = y z = y! Bad result print *, y, x, z end Running this code gives: ( 42.000, 0.) 42.000 ( 42.000, 0.) 42.000 ( 1., 0.) 2. ( 1., 0.) 2. ( 1., 0.) ( 3.36311631E-44, -1.02218151) 2. 2. ( 3.36311631E-44, -1.02218151) Looking at the dump tree, the assignments to the native complex z are converted to SAVE_EXPR = __complex__ (1.0e+0, 0.0); SAVE_EXPR = COMPLEX_EXPR ; while I do not see anything like this for the assignment of the derived type instances.
[Bug c++/70383] New: Bogus error when attempting to capture a reference to function by copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70383
Bug ID: 70383
Summary: Bogus error when attempting to capture a reference to
function by copy
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Repro:
void meow() {
void purr();
void (&f)() = purr;
[f]{};
}
Per [expr.prim.lambda]/15, capturing a reference to a function by copy should
result in an unnamed data member that is also a reference to a function. GCC
instead complains:
prog.cc: In function 'void meow()':
prog.cc:4:6: error: field 'meow()' invalidly declared
function type
[f]{};
^
[Bug target/70381] On powerpc, -mfloat128 is on by default for all VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70381 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Meissner --- Fixed in subversion id 234441.
[Bug tree-optimization/42046] missed optimization (a?b|1:b&~1) where b is a load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42046 Michael Bruck changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Bruck --- 5.2.1 with -Ofast produces ldr r2, .L5 ldr r3, [r2] cmp r0, #0 orrne r3, r3, #1 biceq r3, r3, #1 str r3, [r2] bx lr I'll mark it as fixed. There might be some trick to reduce the core logic (cmp/orrne/biceq) further, but that wasn't my issue.
[Bug c++/70347] [5 Regression] default member initializer not picked up by union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70347 Patrick Palka changed: What|Removed |Added Summary|[5/6 Regression] default|[5 Regression] default |member initializer not |member initializer not |picked up by union |picked up by union --- Comment #5 from Patrick Palka --- Fixed for gcc 6 so far.
[Bug c++/70332] [5 Regression] ICE on x86_64-linux-gnu in tsubst_copy, at cp/pt.c:13887
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70332 Patrick Palka changed: What|Removed |Added Summary|[5/6 Regression] ICE on |[5 Regression] ICE on |x86_64-linux-gnu in |x86_64-linux-gnu in |tsubst_copy, at |tsubst_copy, at |cp/pt.c:13887 |cp/pt.c:13887 --- Comment #3 from Patrick Palka --- Fixed for gcc 6 so far.
[Bug c++/70347] [5/6 Regression] default member initializer not picked up by union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70347 --- Comment #4 from Patrick Palka --- Author: ppalka Date: Wed Mar 23 21:08:32 2016 New Revision: 234443 URL: https://gcc.gnu.org/viewcvs?rev=234443&root=gcc&view=rev Log: Fix PR c++/70347 (default member initializer not picked up by union) gcc/cp/ChangeLog: PR c++/70347 * typeck.c (process_init_constructor_union): If the initializer is empty, use the union's NSDMI if it has one. gcc/testsuite/ChangeLog: PR c++/70347 * g++.dg/cpp1y/nsdmi-union1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-union1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70332] [5/6 Regression] ICE on x86_64-linux-gnu in tsubst_copy, at cp/pt.c:13887
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70332 --- Comment #2 from Patrick Palka --- Author: ppalka Date: Wed Mar 23 21:02:34 2016 New Revision: 234442 URL: https://gcc.gnu.org/viewcvs?rev=234442&root=gcc&view=rev Log: Fix PR c++/70332 (ICE due to aggregate initialization of NSDMI) gcc/cp/ChangeLog: PR c++/70332 * pt.c (tsubst_copy) [PARM_DECL]: Handle the use of 'this' in an NSDMI that's part of an aggregrate initialization. gcc/testsuite/ChangeLog: PR c++/70332 * g++.dg/cpp1y/nsdmi-aggr5.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug target/70381] On powerpc, -mfloat128 is on by default for all VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70381 --- Comment #1 from Michael Meissner --- Author: meissner Date: Wed Mar 23 20:33:28 2016 New Revision: 234441 URL: https://gcc.gnu.org/viewcvs?rev=234441&root=gcc&view=rev Log: 2016-03-23 Michael Meissner PR target/70381 * config/rs6000/rs6000-cpus.def (ISA_2_6_MASKS_SERVER): Do not set -mfloat128 here. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-cpus.def
[Bug c++/70382] New: Attribute not supported on bit-field declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70382
Bug ID: 70382
Summary: Attribute not supported on bit-field declarations
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron.ballman+gcc at gmail dot com
Target Milestone: ---
The following code produces a reject-valid diagnostic:
struct test {
unsigned d [[]] : 1;
};
main.cpp:2:17: error: function definition does not declare parameters
unsigned d [[]] : 1;
^
[class.bit]p1 (in part):
A member-declarator of the form
identifieropt attribute-specifier-seqopt: constant-expression
specifies a bit-field; its length is set off from the bit-field name by a
colon. The optional attribute-specifierseq appertains to the entity being
declared.
MSVC and Clang both accept.
[Bug target/69773] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "assign_by_spills"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69773 --- Comment #5 from Uroš Bizjak --- (In reply to Chengnian Sun from comment #4) > (In reply to Uroš Bizjak from comment #3) > > Another issue with hard registers that live accros insn with single-reg > > constraint. > > > > *** This bug has been marked as a duplicate of bug 70023 *** > > Hi, > > This bug was reported nearly 20 days earlier than PR70023. Should that > report be labeled duplicate of this bug report instead? No, this one is a special case (it explicitly uses hard reg) of the general problem. So, the canonical PR is 70023.
[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023 --- Comment #8 from Uroš Bizjak --- (In reply to Qirun Zhang from comment #7) > (In reply to Uroš Bizjak from comment #6) > > *** Bug 69773 has been marked as a duplicate of this bug. *** > > PR69773 was reported and confirmed more than one month ago. The two bugs > share the same stack trace. IMHO, it should not be a duplicate. Please read Comment #2. The insn is different, but the problem is the same.
[Bug libstdc++/70379] c99_classification_macros_c++98.cc failing with newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70379 --- Comment #1 from Jonathan Wakely --- Is this also the cause of PR 70176 ?
[Bug libstdc++/70176] Regression with C++03 Issue cstdio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70176 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 --- Comment #5 from Michael Meissner --- The intention of the "j" operand is to provide an alternative that can easily set the floating point value to 0 via XXLXOR. If decimal64 0.0 is not all 0 bits, then we shouldn't allow that alternative. Something like: (define_mode_attr "zero" [(SF "j") (DF "j") (TF "j") (IF "j") (KF "j") (SD "wn") (DD "wn") (TD "wn")]) And then replace the "j" in :FMOVE32, :FMOVE64, and :FMOVE128 move patterns with . Fortunately, since rs6000_emit_move doesn't do anything special for decimal constants, and always loads them up, you don't have to edit that function. The "wn" constraint will always be NO_REGS. It is made for use in mode_iterators and mode_attrs for this type of case.
[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P2 --- Comment #13 from Jeffrey A. Law --- Essentially this is the same problem we have with DOM using context sensitive equivalences to copy propagate into subgraphs, but in CSE. I'm increasingly of the opinion that such equivalences DOM find should be used for simplification only, not for copy propagation. That opinion would apply for CSE as well. I'm not sure if we can put the pieces in place for gcc-6, but I think that's the direction we ought to be going. The alternative would be to do some kind of range splitting. What we'd want to know is do we have a context sensitive equivalency and would splitting the range in the dominated subgraph result in a graph that is more easily/better colorable. In this case, the subgraph creates all the conflicts so it's an obvious split point, but I'm not sure how easily we could generalize that. Either way I don't think this should be a release blocking issue. Moving to P2, but keeping the target gcc-6.
[Bug c++/70001] [5 Regression] Infinity compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70001 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Wed Mar 23 18:55:38 2016 New Revision: 234439 URL: https://gcc.gnu.org/viewcvs?rev=234439&root=gcc&view=rev Log: PR c++/70001 * constexpr.c (cxx_eval_vec_init_1): Reuse CONSTRUCTOR initializers for 1..max even for multi-dimensional arrays. Call unshare_expr on it. * g++.dg/cpp0x/constexpr-70001-4.C: New test. * g++.dg/cpp1y/pr70001.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70001-4.C trunk/gcc/testsuite/g++.dg/cpp1y/pr70001.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug libgcc/70363] PowerPC __float128 to long double doesn't link if built with an assember without ISA 3.0 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70363 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Meissner --- Fixed in subversion id 234408.
[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70323 --- Comment #9 from Jakub Jelinek --- One part fixed, the -Wall part still broken.
[Bug c++/70376] OpenMP taskloop construct fails to instantiate copy constructor(same as Bug 48869)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70376 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/70381] New: On powerpc, -mfloat128 is on by default for all VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70381 Bug ID: 70381 Summary: On powerpc, -mfloat128 is on by default for all VSX systems Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- The file config/rs6000/rs6000-cpus.def enables -mfloat128 for ISA 2.06 (power7). However, the emulator library in libgcc is only built on Linux systems. In addition, glibc has not been modified to support __float128 at this time. In the GCC 6.0 time frame, -mfloat128 should not be set by default on power7/power8 systems. In GCC 7.0, the default to enable -mfloat128 should be set on the OSes that build the emulator or have the hardware support for IEEE 128-bit floating point.
[Bug c++/69315] [6 Regression] ICE in finish_function with constexpr and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69315 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/70323] [6 regression] missing error on integer overflow in constexpr function result converted to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70323 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Mar 23 18:45:26 2016 New Revision: 234438 URL: https://gcc.gnu.org/viewcvs?rev=234438&root=gcc&view=rev Log: PR c++/70323 * constexpr.c (cxx_eval_constant_expression): Diagnose overflow on TREE_OVERFLOW constants. * g++.dg/cpp0x/constexpr-70323.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-70323.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70376] OpenMP taskloop construct fails to instantiate copy constructor(same as Bug 48869)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70376 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Mar 23 18:42:19 2016 New Revision: 234437 URL: https://gcc.gnu.org/viewcvs?rev=234437&root=gcc&view=rev Log: PR c++/70376 * cp-gimplify.c (genericize_omp_for_stmt): Don't walk OMP_FOR_CLAUSES for OMP_TASKLOOP here. (cp_genericize_r): Handle OMP_TASKLOOP like OMP_TASK, except do call genericize_omp_for_stmt instead of cp_walk_tree on OMP_BODY. * testsuite/libgomp.c++/pr70376.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr70376.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/libgomp/ChangeLog
[Bug c++/69315] [6 Regression] ICE in finish_function with constexpr and templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69315 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Mar 23 18:36:25 2016 New Revision: 234436 URL: https://gcc.gnu.org/viewcvs?rev=234436&root=gcc&view=rev Log: PR c++/69315 * cp-tree.h (defer_mark_used_calls, deferred_mark_used_calls): Remove. * decl.c (defer_mark_used_calls, deferred_mark_used_calls): Remove. (finish_function): Don't set or test them. * decl2.c (mark_used): Don't handle defer_mark_used_calls. * g++.dg/cpp0x/constexpr-69315.C: New test. * g++.dg/cpp0x/variadic122.C: Change one dg-warning into dg-bogus. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-69315.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/variadic122.C
[Bug c++/70029] [6 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70344 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70344 --- Comment #4 from Jason Merrill --- Author: jason Date: Wed Mar 23 18:23:04 2016 New Revision: 234434 URL: https://gcc.gnu.org/viewcvs?rev=234434&root=gcc&view=rev Log: PR c++/70344 * constexpr.c (cxx_eval_call_expression): Catch invalid recursion. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-recursion2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug target/70367] ice in extract_constrain_insn, at recog.c:2190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70367 --- Comment #4 from David Binderman --- (In reply to Jakub Jelinek from comment #3) > And what exactly is your "recent gcc trunk", if it is after or before the > PR70300 fix. Before. I downloaded the latest version Last Changed Author: ktkachov Last Changed Rev: 234422 Last Changed Date: 2016-03-23 10:39:10 + (Wed, 23 Mar 2016) and the problem seems fixed to me.
[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- New option added.
[Bug c++/69884] [6 Regression] warning: ignoring attributes on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69884 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Wed Mar 23 17:51:56 2016 New Revision: 234433 URL: https://gcc.gnu.org/viewcvs?rev=234433&root=gcc&view=rev Log: PR c++/69884 * c.opt (Wignored-attributes): New option. * pt.c (canonicalize_type_argument): Use OPT_Wignored_attributes. * doc/invoke.texi: Document -Wignored-attributes. * g++.dg/warn/Wignored-attributes-1.C: New test. * g++.dg/warn/Wignored-attributes-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wignored-attributes-1.C trunk/gcc/testsuite/g++.dg/warn/Wignored-attributes-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #36 from Manuel López-Ibáñez --- (In reply to Bernd Schmidt from comment #35) > I don't think guesswork will be very helpful in practice with a corrupted > #line structure, and errors of this nature shouldn't really occur anyway > outside of artificial testcases. I'm leaning towards either something like > > 69650.c:4:55: warning: file "fish" unexpectedly reentered > > or simply > > 69650.c:4:55: warning: line directive ignored due to incorrect nesting According to the manual, these are linemarkers (line directives are less expressive): https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html warning: linemarker ignored because file unexpectedly reentered ? I know, bike-shedding... :)
[Bug c++/70380] New: SFINAE error with constexpr expressions referencing a non-const variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70380
Bug ID: 70380
Summary: SFINAE error with constexpr expressions referencing a
non-const variable
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following program attempts to use SFINAE to choose between two overloads of
a function template. Whether one or the other overload is viable depends on
whether or not an expression used in its declaration is a core constant
expression. I believe the program is valid as is (with the invalid lines
commented out) and should be accepted. However, GCC 6 and all versions before
it rejects it. (Clang rejects it as well, due to what I think is also a bug.)
$ cat t.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -xc++ t.cpp
int x;
struct A {
constexpr A (bool b) : m (b ? 42 : x) { }
constexpr int foo () const { return m; }
int m;
};
struct B {
constexpr B (bool b) : m (b ? x : 42) { }
constexpr int bar () const { return m; }
int m;
};
// constexpr int a0 = A (false).foo (); // not constant, rejected
constexpr int a1 = A (true).foo ();// valid, accepted
constexpr int b0 = B (false).bar (); // valid, accepted
// constexpr int b1 = B (true).bar ();// not constant, rejected
template
int f (int (*)[A (X).foo ()] = 0) { return !X; }
template
int f (int (*)[B (X).bar ()] = 0) { return X; }
constexpr int f0 = f<0>();// valid, rejected
constexpr int f1 = f<1>();// valid, rejected
t.cpp:26:24: error: call to non-constexpr function ‘int f(int
(*)[(B)(X).B::bar()]) [with bool X = false]’
constexpr int f0 = f<0>();// valid, rejected
^~
t.cpp:27:24: error: call to non-constexpr function ‘int f(int
(*)[(A)(X).A::foo()]) [with bool X = true]’
constexpr int f1 = f<1>();// valid, rejected
^~
[Bug c++/70344] [6 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu in adjust_temp_type, at cp/constexpr.c:1078
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70344 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #35 from Bernd Schmidt --- I don't think guesswork will be very helpful in practice with a corrupted #line structure, and errors of this nature shouldn't really occur anyway outside of artificial testcases. I'm leaning towards either something like 69650.c:4:55: warning: file "fish" unexpectedly reentered or simply 69650.c:4:55: warning: line directive ignored due to incorrect nesting
[Bug libstdc++/70379] New: c99_classification_macros_c++98.cc failing with newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70379 Bug ID: 70379 Summary: c99_classification_macros_c++98.cc failing with newlib Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andre.simoesdiasvieira at arm dot com Target Milestone: --- 26_numerics/headers/cmath/c99_classification_macros_c++98.cc fails for newlib on arm-none-eabi with the following errors (clipped the error messages to only include a few): src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:38:16: error: macro "isgreater" requires 2 arguments, but only 1 given src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:40:21: error: macro "isgreaterequal" requires 2 arguments, but only 1 given src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:42:13: error: macro "isless" requires 2 arguments, but only 1 given src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:44:18: error: macro "islessequal" requires 2 arguments, but only 1 given src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:46:20: error: macro "islessgreater" requires 2 arguments, but only 1 given src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c++98.cc:48:18: error: macro "isunordered" requires 2 arguments, but only 1 given This new failure is due to a change that has been made to newlib where -std=c++98 no longer includes the C99 math functions from math.h whereas gnu++98 still does. This leads to _GLIBCXX98_USE_C99_MATH not being declared at configuration time, since this is set by testing a compilation with -std=c++98. This macro is the macro used in cmath to know whether the C99 math functions are present, if so it needs to undefine the ones that are macros. This test uses -std=gnu++98, which will have these macros defined and _GLIBCXX98_USE_C99_MATH not set which leads us to the errors above. This is now also an issue with at least gcc-5.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #34 from Manuel López-Ibáñez --- (In reply to Bernd Schmidt from comment #33) > It does mean LC_LEAVE, but AFAICT the filename is the file being returned to. > > Including a file called "t.h" from "v.c" gives this after -E: > > # 1 "t.h" 1 > int t; > # 2 "v.c" 2 Then, I agree the error doesn't make any sense. My assumption of how the filename in the directive was being used was completely wrong. But then in case of error, one cannot really tell which file was going to be left. However, one could detect which file we are suppose to enter, like in: # 1 "test.c" # 1 "a.h" 1 # 1 "b.h" 1 int a; # 1 "c.h" 2 # 2 "test.c" 2
[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023 --- Comment #7 from Qirun Zhang --- (In reply to Uroš Bizjak from comment #6) > *** Bug 69773 has been marked as a duplicate of this bug. *** PR69773 was reported and confirmed more than one month ago. The two bugs share the same stack trace. IMHO, it should not be a duplicate.
[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
--- Comment #11 from Jeffrey A. Law ---
So given the conflicts during IRA I can't see a way for IRA to do a better job.
Essentially the key allocno/pseudo wants hard reg 0 to avoid the spillage, but
it also conflicts with hard reg 0.
Prior to CSE1 we have the following key statements:
(insn 15 14 16 2 (set (reg/v/f:SI 116 [ ])
(reg:SI 0 r0)) j.c:23 748 {*thumb1_movsi_insn}
(nil))
[ ...
(jump_insn 19 18 20 2 (set (pc)
(if_then_else (ne (reg/v/f:SI 117 [ line ])
(reg/v/f:SI 116 [ ]))
(label_ref:SI 36)
(pc))) j.c:25 756 {cbranchsi4_insn}
(int_list:REG_BR_PROB 8987 (nil))
-> 36)
[ ... ]
(insn 21 20 22 3 (set (reg:SI 0 r0)
(reg/v/f:SI 117 [ line ])) j.c:25 748 {*thumb1_movsi_insn}
(nil))
[ ... ]
(insn 31 30 36 3 (set (reg/v/f:SI 116 [ ])
(reg:SI 0 r0)) j.c:25 748 {*thumb1_movsi_insn}
(nil))
[ ... ]
(insn 28 27 29 3 (set (reg:SI 1 r1)
(reg/v/f:SI 117 [ line ])) j.c:25 748 {*thumb1_movsi_insn}
(nil))
[ ... ]
(insn 37 39 38 4 (set (reg/i:SI 0 r0)
(reg/v/f:SI 116 [ ])) j.c:26 748 {*thumb1_movsi_insn}
(nil))
(insn 38 37 0 4 (use (reg/i:SI 0 r0)) j.c:26 -1
(nil))
Of particular interest is that r116 is not live-in to bb3. If you do the full
analysis, it can be shown that r116 does not conflict with r0 before cse1. And
that's key because to get the code we want r116 needs to be assigned to r0.
cse (like DOM) has the ability to look at a equality conditional and propagate
equivalences into the true or false arm. ANd if we look at insn 19, we've got
a equality conditional between r117 and r116 which will set up an equivalence
between r116 and r117 for bb3.
So in bb3, cse1 will change the initial assignment from:
(insn 21 20 22 3 (set (reg:SI 0 r0)
(reg/v/f:SI 117 [ line ])) j.c:25 748 {*thumb1_movsi_insn}
(nil))
to:
(insn 21 20 22 3 (set (reg:SI 0 r0)
(reg/v/f:SI 116 [ ])) j.c:25 748 {*thumb1_movsi_insn}
(nil))
Which makes r116 live-in for bb3. But note that it doesn't change insn 28
(yet).
forwprop then comes along and changes insn 28 to look like:
(insn 28 27 29 3 (set (reg:SI 1 r1)
(reg/v/f:SI 116 [ ])) j.c:25 748 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg/v/f:SI 116 [ ])
(nil)))
Now r116 is both live-in to bb3 and conflicts with r0 within bb3.
At which point we have lost.
I've got a couple things I want to poke at... But nothing that I think has a
high probability of success.
[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164 --- Comment #12 from Jeffrey A. Law --- Slight correction. I was looking at the wrong part of the dump when I said cse1 didn't change insn 28. It is cse1 that changes insn 28. So this is strictly an issue with the transformations cse1 makes.
[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164 --- Comment #10 from Vladimir Makarov --- (In reply to Jeffrey A. Law from comment #9) > I think that's a fair characterization. The extra copy emitted by the older > compiler gives the allocator more freedom. With coalescing getting more > aggressive, the copy is gone and the allocator's freedom is reduced. > > I'll try to have a look at what the allocator is doing, but I doubt it's > realistically something that can be addressed in this release cycle. I am agree. It will be probably hard to fix in IRA on this stage. Coalescing is a controversial thing. Therefore there are so many coalescing algorithms. I've tried a lot of them when I worked on global RA. Finally, I found that implicit coalescing worked the best. The word `implicit` means that we propagate hard register preferences (through copies, including implicit ones for two-operand constraints) from already assigned pseudos to unassigned ones. When it is possible to assign the same hard register, we do it and remove the copies. Otherwise, we still can assign a hard register which might be impossible after we explicitly coalesced two pseudos. Only LRA does explicit coalescing for pseudos assigned to memory as we have no constraints on # stack slots and memory-memory moves are expensive and require additional hard reg. I guess probably this sort of PR could be fixed if we had live-range splitting in any place not only on the loop borders. But it might create other PRs if it makes a wrong decisions :) Unfortunately, it is all about heuristics. They can work successfully in one case and do bad things in another case. The performance of credible benchmarks should be a criterion.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #33 from Bernd Schmidt --- It does mean LC_LEAVE, but AFAICT the filename is the file being returned to. Including a file called "t.h" from "v.c" gives this after -E: # 1 "t.h" 1 int t; # 2 "v.c" 2
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #32 from Manuel López-Ibáñez --- (In reply to David Malcolm from comment #31) > I may have been wrong in my earlier question on the mailing list; doesn't > the flag value of 2 mean "LC_LEAVE"? (is the filename meant to refer to the > file being left, or the file being entered? am new to this part of libcpp) This is my understanding as well: https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html That is, it means "leaving fish returning to 69650.c". If there is not previous enter "fish" directive, there is a problem. An empty file means, leaving whatever file we last entered. If there is no previous enter file directive at all (# N "whatever" 1), then there is also a problem. One cannot leave the main file. It should be easy to play with the line directives to trigger both types of error.
[Bug target/69773] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "assign_by_spills"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69773 Chengnian Sun changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #4 from Chengnian Sun --- (In reply to Uroš Bizjak from comment #3) > Another issue with hard registers that live accros insn with single-reg > constraint. > > *** This bug has been marked as a duplicate of bug 70023 *** Hi, This bug was reported nearly 20 days earlier than PR70023. Should that report be labeled duplicate of this bug report instead? Thanks.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #31 from David Malcolm ---
(In reply to Bernd Schmidt from comment #30)
> I'm just using CPP_W_NONE in the patch I'm testing and that seems to work.
>
> Regarding the error message, here's what we'll get:
>
> 69650.c:4:55: warning: file "fish" left but not entered
> # 9 "fish" 2 /* { dg-error "left but not entered" } */
>
> The problem is that the file we'd be leaving is 69650.c, as shown by the
> warning's location. "fish" AFAICT is the file we'd be switching to.
I may have been wrong in my earlier question on the mailing list; doesn't the
flag value of 2 mean "LC_LEAVE"? (is the filename meant to refer to the file
being left, or the file being entered? am new to this part of libcpp)
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #13 from amker at gcc dot gnu.org --- Simple summary. The test case provided in this PR is resolved by the two patches, but the problem still exists if the first function in compilation unit triggers the issue. This is because x86's inconsistent behavior of PIC_OFF_REG, discussed at https://gcc.gnu.org/ml/gcc/2016-02/msg00040.html Maybe this will be addressed in next stage 1. If we go deeper in IVOPT, we may be able to model that symbol PIC offset requires an additional register for m32. But this will be a target dependent issue, for example x86_64 may not have this issue. We then need a backend hook to get this information. But register pressure computation is far from a fine grain model anyway...
[Bug c/70378] [5.3] inconsistant warnings with -Wconversion for different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378 --- Comment #1 from Daniel Starke --- No warning was observed when using g++ instead of gcc.
[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70348 --- Comment #5 from Nathan Sidwell --- the intended current implementation is to treat 'sum' as firstprivate. however, putting in an explicit firstprivate causes another different ICE (in lower_oacc_reductions) -- regardless of whether 'sum' is a parameter, or a local (initialized) variable. Clearly at least two other bugs lurk.
[Bug c/70378] New: [5.3] inconsistant warnings with -Wconversion for different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378
Bug ID: 70378
Summary: [5.3] inconsistant warnings with -Wconversion for
different types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Tested with GCC 4.4.3 and 5.3.0 whereas 5.3.0 was configured as
Configured with: ../../src/gcc-5.3.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
--with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.12.2
--with-cloog=/usr/new-gcc/lib/cloog-0.18.3 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
#include
#include
#include
#define PARSE(Type) \
do { \
const char * a = str; \
Type b = 0; \
while (*a != 0) { \
b = (Type)((b * 10) + (Type)(*a) - '0'); \
a++; \
} \
printf(#Type " = %u\n", (unsigned int)b); \
} while (0)
int main() {
const char * str = "123";
PARSE(int8_t);
PARSE(int16_t);
PARSE(int32_t);
PARSE(int64_t);
PARSE(uint8_t);
PARSE(uint16_t);
PARSE(uint32_t);
PARSE(uint64_t);
PARSE(unsigned int);
PARSE(unsigned);
return EXIT_SUCCESS;
}
This code only produces a warning for uint32_t when compiled with -Wconversion:
test.c:10:24: warning: conversion to 'uint32_t {aka unsigned int}' from 'char'
may change the sign of the result [-Wsign-conversion]
b = (Type)((b * 10) + (Type)(*a) - '0'); \
^
test.c:25:2: note: in expansion of macro 'PARSE'
PARSE(uint32_t);
uint32_t was defined as:
typedef unsigned uint32_t;
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #30 from Bernd Schmidt ---
I'm just using CPP_W_NONE in the patch I'm testing and that seems to work.
Regarding the error message, here's what we'll get:
69650.c:4:55: warning: file "fish" left but not entered
# 9 "fish" 2 /* { dg-error "left but not entered" } */
The problem is that the file we'd be leaving is 69650.c, as shown by the
warning's location. "fish" AFAICT is the file we'd be switching to.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #29 from Manuel López-Ibáñez --- (In reply to Bernd Schmidt from comment #26) > Also, let's keep in mind the issue David found - "left but not entered" > seems like a misleading message, something like "unexpectedly reentered" > seems to fit better. But the linemaker is an invalid "leaving file" marker. So the error is that we are leaving a file that we have not entered. Perhaps I'm misunderstanding what you mean?
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #28 from Manuel López-Ibáñez --- (In reply to Richard Biener from comment #25) > Yes, Bernd's patch still works then. I'd prefer this at this stage. > There doesn't seem to be any CPP_W_* that fits though. Do you need one? Perhaps -Wcpp? Or -Wpreprocessed? I think it should be a warning enabled by default.
[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70370
--- Comment #7 from Richard Biener ---
Testcase for inout that now will error with the patch (but also ICEd before).
_Complex float foo (_Complex float f)
{
__asm__ ("" : "+r" (__real f));
return f;
}
> ./cc1 -quiet t.c -fdump-tree-all
t.c: In function ‘foo’:
t.c:3:3: error: invalid lvalue in asm output 0
__asm__ ("" : "+r" (__real f));
^~~
The !allows-mem case needs to verify we have a proper gimple register type
as well of course. The following seems to work
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 234415)
+++ gcc/gimplify.c (working copy)
@@ -5191,6 +5205,33 @@ gimplify_asm_expr (tree *expr_p, gimple_
ret = tret;
}
+ if (!allows_mem)
+ {
+ if (! is_gimple_reg_type (TREE_TYPE (TREE_VALUE (link
+ {
+ error ("invalid lvalue in asm output %d", i);
+ ret = GS_ERROR;
+ }
+ else
+ {
+ tree tem = create_tmp_reg (TREE_TYPE (TREE_VALUE (link)));
+ tree ass;
+ if (is_inout)
+ {
+ ass = build2 (MODIFY_EXPR, TREE_TYPE (tem),
+ tem, unshare_expr (TREE_VALUE (link)));
+ gimplify_and_add (ass, pre_p);
+ }
+ ass = build2 (MODIFY_EXPR, TREE_TYPE (tem),
+ TREE_VALUE (link), tem);
+ gimplify_and_add (ass, post_p);
+
+ TREE_VALUE (link) = tem;
+ /* create and gimplify TREE_VALUE (link) = reg on post_p. */
+ tret = GS_OK;
+ }
+ }
+
vec_safe_push (outputs, link);
TREE_CHAIN (link) = NULL_TREE;
[Bug rtl-optimization/70164] [6 Regression] Code/performance regression due to poor register allocation on Cortex-M0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164 --- Comment #9 from Jeffrey A. Law --- I think that's a fair characterization. The extra copy emitted by the older compiler gives the allocator more freedom. With coalescing getting more aggressive, the copy is gone and the allocator's freedom is reduced. I'll try to have a look at what the allocator is doing, but I doubt it's realistically something that can be addressed in this release cycle.
[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70370
--- Comment #6 from Richard Biener ---
So we have !allows_mem here which we can only handle if !is_inout by
emitting a store in the post-queue like
__asm__("" : "=r" tem_1);
__real f = tem_1;
The following works for me (otherwise untested sofar - eventually
the is_inout case needs to be adjusted as we have code for that below
as well).
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 234415)
+++ gcc/gimplify.c (working copy)
@@ -5182,9 +5196,26 @@ gimplify_asm_expr (tree *expr_p, gimple_
if (!allows_reg && allows_mem)
mark_addressable (TREE_VALUE (link));
- tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
- is_inout ? is_gimple_min_lval : is_gimple_lvalue,
- fb_lvalue | fb_mayfail);
+ if (!allows_mem)
+ {
+ if (is_inout)
+ tret = GS_ERROR;
+ else
+ {
+ tree tem = create_tmp_reg (TREE_TYPE (TREE_VALUE (link)));
+ tree ass = build2 (MODIFY_EXPR, TREE_TYPE (tem),
+TREE_VALUE (link), tem);
+ gimplify_and_add (ass, post_p);
+
+ TREE_VALUE (link) = tem;
+ /* create and gimplify TREE_VALUE (link) = reg on post_p. */
+ tret = GS_OK;
+ }
+ }
+ else
+ tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
+ is_inout ? is_gimple_min_lval : is_gimple_lvalue,
+ fb_lvalue | fb_mayfail);
if (tret == GS_ERROR)
{
error ("invalid lvalue in asm output %d", i);
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #12 from amker at gcc dot gnu.org --- The above two patches actually doesn't fix the problem, but I think it covers the problem by bringing back the old behavior. So Ilya, could you please check that status of the regression? Thanks. If it disappears, maybe we can degrade it to P3? Thanks, bin
[Bug ipa/70348] [6 Regression][openacc] ICE in visit_ref_for_mod_analysis, at ipa-prop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70348
Thomas Schwinge changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #4 from Thomas Schwinge ---
Martin, thanks for the initial analysis.
Nathan CCed for your information; here is a reduced test case (which hopefully
still exhibits the original problem):
void foo (int sum)
{
#pragma acc parallel reduction(+:sum)
;
}
The ICE goes away when adding a data clause, such as copy(sum).
When changing sum from a formal parameter to an (initialized) local variable,
without adding a data clause, there is no ICE, but a "warning: 'sum' is used
uninitialized in this function [-Wuninitialized]". (This probably correct
given the current implementation, which requires you to specify a data clause
in addition to a reduction clause.)
We're currently clarifying with the OpenACC technical committee whether a
reduction clause actually implies a data clause.
[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- The reason for the ICE is that __PRETTY_FUNCTION__/__FUNCTION__/__func__ are TREE_STATIC (artificial) VAR_DECLs in the context of the corresponding constexpr function, because of the TREE_STATIC we don't want to remap it, and constexpr.c calls copy_fn with NULL cfun (most other callers of inlining APIs have cfun non-NULL and usually cfun->decl matching id->dst_fn). For the ICE, I guess we can do something like: --- gcc/tree-inline.c.jj2016-03-16 18:50:47.0 +0100 +++ gcc/tree-inline.c 2016-03-23 16:27:08.723926525 +0100 @@ -614,9 +614,11 @@ remap_decls (tree decls, vec DINFO_LEVEL_TERSE) && !DECL_IGNORED_P (old_var) But, that is insufficient, as e.g. for the #c8 testcase we then get unresolved external symbol, because the definition of the static var is never emitted.
[Bug middle-end/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70370
Richard Biener changed:
What|Removed |Added
Target|aarch64 |
Status|NEW |ASSIGNED
Component|c |middle-end
Version|unknown |6.0
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
I think it's ok to use __real/__imag as lvalue. The ICE is odd, it appears
after ipa-pure-const (pass_nothrow).
Ah, but the ASM misses virtual operands after into-SSA thus this looks like
an operand scanner issue.
Target independent testcase:
_Complex float foo (_Complex float f)
{
__asm__ ("" : "=r" (__real f));
return f;
}
the issue is you need a memory constraint to use a memory input here or
rather the issue is we fail to properly gimplify this.
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #11 from amker at gcc dot gnu.org --- Author: amker Date: Wed Mar 23 15:26:43 2016 New Revision: 234430 URL: https://gcc.gnu.org/viewcvs?rev=234430&root=gcc&view=rev Log: PR tree-optimization/69042 * params.def (PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND): Increase the parameter from 30 to 40. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug tree-optimization/69042] [6 regression] Missed optimization in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69042 --- Comment #10 from amker at gcc dot gnu.org --- Author: amker Date: Wed Mar 23 15:24:20 2016 New Revision: 234429 URL: https://gcc.gnu.org/viewcvs?rev=234429&root=gcc&view=rev Log: PR tree-optimization/69042 * tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Add IV cand for use with constant offset stripped in base. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug c++/70347] [5/6 Regression] default member initializer not picked up by union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70347 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- NSDMI consideration during aggregate initialization of a union does not seem to be implemented.
[Bug target/70321] [6/7 Regression] STV generates less optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321 Jakub Jelinek changed: What|Removed |Added Target Milestone|6.0 |7.0 Summary|[6 Regression] STV |[6/7 Regression] STV |generates less optimized|generates less optimized |code|code --- Comment #12 from Jakub Jelinek --- Ok, deferring the rest for GCC 7.
[Bug c++/70377] New: "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70377
Bug ID: 70377
Summary: "unexpected AST" and "confused by earlier errors,
bailing out" from throw in simple constexpr fn
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling this code:
#include
#include
#include
template
constexpr size_t simple_find(const std::array &arg_array,
const int&arg_value
) {
for (size_t ctr = 0; ctr != N; ++ctr) {
if ( arg_array[ ctr ] == arg_value ) {
return ctr;
}
}
throw std::out_of_range( "" );
}
static constexpr std::array some_ints { { 10, 11 } };
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
static_assert( simple_find( some_ints, 11 ) == static_cast( 1 ), "" );
int main() { }
...under -std=c++14 gives:
a.cpp:19:1: error: non-constant condition for static assertion
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
^
a.cpp:19:27: error: ‘constexpr size_t simple_find(const std::array&,
const int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’
called in a constant expression
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
^
a.cpp:6:18: note: ‘constexpr size_t simple_find(const std::array&,
const int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’ is
not usable as a constexpr function because:
constexpr size_t simple_find(const std::array &arg_array,
^
a.cpp:6:18: sorry, unimplemented: unexpected AST of kind loop_expr
a.cpp:6: confused by earlier errors, bailing out
I think the code is valid C++14. Even if not, I doubt you want the errors seen
above.
The code compiles cleanly if the throw statement is replaced with 'return 0;'.
I'm seeing this issue on g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010. I've also
tried it on http://melpon.org/wandbox and I think the issue is still there on a
recent 6.0.0 HEAD.
Thanks very much.
[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-23 Ever confirmed|0 |1 --- Comment #6 from Eric Botcazou --- > So, I'm not worried that the optimization is broken for Sparc (it does the > right thing for long), but I'm not sure I know the best way to work around > this for your target. swapping int for long would also help HPPA. HPPA chose > to skip the test entirely. That might also be right for Sparc. > > What do you think? See what Jeff did for the sibling gcc.dg/ifcvt-5.c test under PR rtl-opt/69942.
[Bug c++/70376] OpenMP taskloop construct fails to instantiate copy constructor(same as Bug 48869)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70376 --- Comment #1 from Jakub Jelinek --- Created attachment 38073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38073&action=edit gcc6-pr70376.patch Untested fix.
[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414 --- Comment #4 from jnorris at gcc dot gnu.org --- Author: jnorris Date: Wed Mar 23 14:38:55 2016 New Revision: 234428 URL: https://gcc.gnu.org/viewcvs?rev=234428&root=gcc&view=rev Log: PR libgomp/69414 * oacc-mem.c (delete_copyout, update_dev_host): Fix device address. * testsuite/libgomp.oacc-c-c++-common/update-1.c: Additional tests. * testsuite/libgomp.oacc-c-c++-common/update-1-2.c: Likewise. * testsuite/libgomp.oacc-fortran/update-1.f90: New file. Added: trunk/libgomp/testsuite/libgomp.oacc-fortran/update-1.f90 Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-mem.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1.c
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #27 from rguenther at suse dot de --- On Wed, 23 Mar 2016, bernds at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 > > --- Comment #26 from Bernd Schmidt --- > Also, let's keep in mind the issue David found - "left but not entered" seems > like a misleading message, something like "unexpectedly reentered" seems to > fit > better. Sure, though that part is not a regression (only the LTO ICE is for some reason)
[Bug c++/57433] Local classes have an associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57433
Roman Perepelitsa changed:
What|Removed |Added
CC||roman.perepelitsa at gmail dot
com
--- Comment #1 from Roman Perepelitsa ---
Here's another example:
template void Bar(T t) { Foo(t); }
template void Foo(T) {}
void Test() {
Bar([]{});
}
Clang rejects this code (expected behaviour), gcc accepts it (unexpected
behaviour). Gcc erroneously finds Foo() by ADL.
A more elaborate example:
namespace n1 {
template void Foo(T) {}
auto F = []{};
auto G = []{ return []{}; }();
} // namespace n1
namespace n2 {
void Test() {
Foo(n1::F); // gcc and clang accept
Foo(n1::G); // gcc accepts, clang rejects
}
} // namespace n2
F is a lambda defined in namespace scope of n1. When Test() calls Foo(n1::F),
n1::Foo() is found via ADL. Nothing surprising here.
Now, G is also a lambda from n1 but it's defined locally, in a function. When
gcc resolves Foo(n1::G), it finds n1::Foo() by ADL, but clang doesn't.
We can use structs instead of lambdas and the effect will be the same. We also
can use regular non-template functions:
namespace n1 {
struct S {};
auto MakeQ = []{ struct Q {}; return Q(); };
using Q = decltype(MakeQ());
void Foo(S) {}
void Foo(Q) {}
} // namespace n1
namespace n2 {
void Test() {
Foo(n1::S()); // gcc and clang accept
Foo(n1::Q()); // gcc accepts, clang rejects
}
} // namespace n2
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #26 from Bernd Schmidt --- Also, let's keep in mind the issue David found - "left but not entered" seems like a misleading message, something like "unexpectedly reentered" seems to fit better.
[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749 Rainer Orth changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Rainer Orth --- (In reply to James Greenhalgh from comment #4) > Hi, sorry I missed this. I need to write a better filter for bugs I'm CCed > on, I'll work on that. No worries here. > I guess it is those subregs down from DImode to SImode. Sure enough, if we > swap int for long in this testcase, we get the expected expansion and the > expected number of true changes made. > > So, I'm not worried that the optimization is broken for Sparc (it does the > right thing for long), but I'm not sure I know the best way to work around > this for your target. swapping int for long would also help HPPA. HPPA chose > to skip the test entirely. That might also be right for Sparc. > > What do you think? That's probably best for Eric (Cc'ed) to say. Thanks. Rainer
[Bug c++/70376] OpenMP taskloop construct fails to instantiate copy constructor(same as Bug 48869)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70376 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-23 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #25 from Richard Biener --- (In reply to Manuel López-Ibáñez from comment #23) > (In reply to rguent...@suse.de from comment #22) > > Maybe we can put the error under some new flag though. > > Does Bernd's patch still work if we just warn instead of error? I still > think doing this in the caller is the sane thing to do. Yes, Bernd's patch still works then. I'd prefer this at this stage. There doesn't seem to be any CPP_W_* that fits though.
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 --- Comment #4 from Alan Modra --- Created attachment 38072 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38072&action=edit tentative patch This hasn't been tested much, apart from verifying that the testcase compiles. I also find that I don't get the expected xxlxor with -funsafe-math-optimizations. Hmm, that might be because the wn constraint is no_regs at the moment.
[Bug c++/70376] New: OpenMP taskloop construct fails to instantiate copy constructor(same as Bug 48869)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70376
Bug ID: 70376
Summary: OpenMP taskloop construct fails to instantiate copy
constructor(same as Bug 48869)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: bbenin at gmail dot com, jakub at gcc dot gnu.org,
jason at gcc dot gnu.org, rguenth at gcc dot gnu.org,
rth at gcc dot gnu.org
Depends on: 48869
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #48869 +++
template
struct A
{
A() { }
A(const A&) { }
void foo() { }
};
int
main ()
{
A a;
#pragma omp taskloop
for (int i = 0; i < 64; i++)
a.foo();
return 0;
}
$ .../gcc/xg++ -B .../gcc/ -fopenmp -o pr48869 pr48869.C -B
.../x86_64-pc-linux-gnu/libgomp/ -L .../x86_64-pc-linux-gnu/libgomp/.libs/ -L
.../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
/tmp/ccMYsukb.o: In function `main._omp_cpyfn.1':
pr48869.C:(.text+0xcc): undefined reference to `A::A(A const&)'
collect2: error: ld returned 1 exit status
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
[Bug 48869] [4.5 Regression] OpenMP task construct fails to instantiate copy
constructor(same as Bug 36523)
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #24 from Richard Biener --- Created attachment 38071 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38071&action=edit alternate patch Good question - I attached mine and will check.
[Bug c/70370] ICE in execute_todo, at passes.c:2003 when using __real__ or __imag__ as lvalue in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70370 --- Comment #4 from Christophe Lyon --- An old message from Richard Henderson seems to mean that __real__ and __imag__ shouldn't be used as lvalues: https://gcc.gnu.org/ml/gcc/2004-04/msg00521.html
[Bug target/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70356 --- Comment #5 from Jakub Jelinek --- I guess we need to wait on Kirill for the reason why the test has been added. It could be that it has been assembled badly, and then dg-do assemble is completely reasonable. Or it could be added for other reasons.
[Bug target/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70356
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> Seems this test is the only one in gcc.target/i386 that has
> dg-require-effective-target above dg-do.
> Can you please try:
> --- gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c 2016-01-28
> 22:02:17.029720615 +0100
> +++ gcc/testsuite/gcc.target/i386/avx-vextractf128-256-5.c 2016-03-22
> 19:18:25.946107764 +0100
> @@ -1,5 +1,5 @@
> -/* { dg-require-effective-target avx512f } */
> /* { dg-do assemble { target { ! ia32 } } } */
> +/* { dg-require-effective-target avx512f } */
> /* { dg-options "-O2 -mavx512f" } */
>
> #include
>
> ?
This causes both 32 and 64-bit tests to become UNSUPPORTED because
/bin/as cannot assemble avx512f insns. I don't think that's what this
test intends, though: it's one of very few assemble tests, with no
indication that assembler output is of any relevance. I think the test
should rather be turned into a compile test and the
dg-require-effective-target dropped because it's irrelevant then.
There's most likely more space for cleanup in gcc.target/i386 in this
area: several compile tests with dg-require-effective-target checks for
ISA extensions which don't seem relevant as those checks check if the
insns can be assembled, and some dg-do assemble tests with no indication
why assembly would matter...
Rainer
[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64971 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #7 from ktkachov at gcc dot gnu.org --- Confirmed on an aarch64 cross
[Bug target/70052] ICE compiling _Decimal128 test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Canonical dfp 0.0 is not all-zero bits in any mode due to the exponent bias. I think that makes the "j" constraint broken for dfp, since it tests for the canonical 0.0 but the insns load an all-zero bit pattern. What's happening with the testcase is that the init-regs pass is providing a zero for an undefined variable (insn 82 16 17 2 (set (reg/v:TD 155 [ zz ]) (const_double:TD 0.0 [0x0.0p+0])) /src/tmp/pr70052.c:14 -1 (nil)) This gets split post-reload using rs6000_split_multireg_move, the const_double:TD 0.0 being processed by simplify_gen_subreg into two DD constants with the same bit patterns as the halves of the TD constant. Problem is that the two DD constants are DD 0E-12 and DD 0E-398 neither of which is exactly the same as DD 0.0. I don't think we can change dfp 0.0 to be all-zero bits, because the current bit pattern is produced by the hardware for 0.0, except possibly when -funsafe-math-optimizations. (Exponent can be extracted, reg stored to memory then bits examined.)
[Bug tree-optimization/70372] [6 Regression] ICE: in wide_int_to_tree, at tree.c:1488 with -fno-tree-fre and v2ti vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70372 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug target/70356] gcc.target/i386/avx-vextractf128-256-5.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70356 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- [...] > But, avx-vextractf128-256-5.c has: > dg-require-effective-target avx512f, so wonder what is the problem. > Does the order of dg-do vs. dg-require-effective-target matter? It does indeed: as one can see in dg.exp (dg-do), an dg-process-target S (selected) result from a target selector overrides a previous value in dg-do-what as set e.g. by dg-require-effective-target. Rainer
[Bug tree-optimization/70251] Wrong code with -O3 -march=skylake-avx512.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251 --- Comment #14 from Richard Biener --- Author: rguenth Date: Wed Mar 23 13:40:50 2016 New Revision: 234427 URL: https://gcc.gnu.org/viewcvs?rev=234427&root=gcc&view=rev Log: 2016-03-23 Richard Biener PR middle-end/70251 * match.pd (A + (B vcmp C ? 1 : 0) -> A - (B vcmp C)): Adjust mode compatibility check. (A - (B vcmp C ? 1 : 0) -> A + (B vcmp C)): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug tree-optimization/70341] [4.9/5/6 Regression] Code size increase due to earlier switch case lowering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70341 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-23 CC||ramana at gcc dot gnu.org Component|target |tree-optimization Summary|Code size increase on ARM |[4.9/5/6 Regression] Code |cortex-m3 for switch|size increase due to |statements |earlier switch case ||lowering. Ever confirmed|0 |1 Known to fail||6.0 --- Comment #3 from Ramana Radhakrishnan --- Confirmed.
[Bug target/69773] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "assign_by_spills"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69773 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Uroš Bizjak --- Another issue with hard registers that live accros insn with single-reg constraint. *** This bug has been marked as a duplicate of bug 70023 ***
[Bug rtl-optimization/70374] [5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1428 (unable to find a register to spill) with -march=core2 -fno-split-wide-types -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70374 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Uroš Bizjak --- Another issue with hard registers that live accros insn with single-reg constraint. *** This bug has been marked as a duplicate of bug 70023 ***
[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fno-sched-critical-path-heuristic -fschedule-insns -m8bit-idiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023 Uroš Bizjak changed: What|Removed |Added CC||helloqirun at gmail dot com --- Comment #6 from Uroš Bizjak --- *** Bug 69773 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fno-sched-critical-path-heuristic -fschedule-insns -m8bit-idiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70023 --- Comment #5 from Uroš Bizjak --- *** Bug 70374 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058 --- Comment #21 from Jeffrey A. Law --- Author: law Date: Wed Mar 23 13:20:16 2016 New Revision: 234425 URL: https://gcc.gnu.org/viewcvs?rev=234425&root=gcc&view=rev Log: PR tree-optimization/64058 * tree-ssa-coalesce.c (struct coalesce_pair): Add new field CONFLICT_COUNT. (struct ssa_conflicts): Move up earlier in the file. (conflicts_, var_map_): New static variables. (initialize_conflict_count): New function to initialize the CONFLICT_COUNT field for each conflict pair. (compare_pairs): Lazily initialize the conflict count and use it as the first tie-breaker. (sort_coalesce_list): Add new arguments conflicts, map. Initialize and wipe conflicts_ and map_ around the call to qsort. Remove special case for 2 coalesce pairs. * bitmap.c (bitmap_count_unique_bits): New function. (bitmap_count_bits_in_word): New function, extracted from bitmap_count_bits. (bitmap_count_bits): Use bitmap_count_bits_in_word. * bitmap.h (bitmap_count_unique_bits): Declare it. Modified: trunk/gcc/ChangeLog trunk/gcc/bitmap.c trunk/gcc/bitmap.h trunk/gcc/tree-ssa-coalesce.c
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #23 from Manuel López-Ibáñez --- (In reply to rguent...@suse.de from comment #22) > Maybe we can put the error under some new flag though. Does Bernd's patch still work if we just warn instead of error? I still think doing this in the caller is the sane thing to do.
