[Bug c++/67041] New: [C++14] Variable template initialized by call to lambda does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67041
Bug ID: 67041
Summary: [C++14] Variable template initialized by call to
lambda does not compile
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile on GCC trunk:
---
template typename ...Anything
auto variable_template = [] { return 1; }();
int main() {
variable_template;
}
---
The error is
-
prog.cc: In instantiation of 'auto variable_template':
prog.cc:5:5: required from here
prog.cc:2:42: error: use of 'variable_template' before deduction of 'auto'
auto variable_template = [] { return 1; }();
^
prog.cc:2:42: error: use of 'lambda() [with Anything = {}]' before deduction
of 'auto'
-
Live example: http://melpon.org/wandbox/permlink/srH8coYkvigwJSkb
Note that Clang compiles this code fine.
[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02177.html https://gcc.gnu.org/ml/libstdc++/2015-07/msg00068.html
[Bug c/67025] New: Missing aggressive loop optimization warning when -fPIC used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67025
Bug ID: 67025
Summary: Missing aggressive loop optimization warning when
-fPIC used
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Nikola.Veljkovic at imgtec dot com
Target Milestone: ---
The issue here is not that the loop is over optimized, but the fact that the
warning is missing.
Without the warning debugging an issue like this takes much longer.
Source code:
main.c:
#include stdio.h
struct problem {
int*array1[4];
int*array2[4];
};
int* foo() { return 0; }
int main(int argc, int** argv) {
int i;
struct problem p;
for(i = 0; i 8; i++) {
printf(i=%d\n, i);
p.array1[i] = foo();
if(p.array1[i]) return -1;
}
return 0;
}
Compilation (with -fPIC):
$ gcc-5 -O2 -fPIC -o for-test main.c
Compilation (without -fPIC):
$ gcc-5 -O2 -o for-test main.c
main.c: In function ‘main’:
main.c:15:21: warning: iteration 4u invokes undefined behavior
[-Waggressive-loop-optimizations]
p.array1[i] = foo();
^
main.c:13:5: note: containing loop
for(i = 0; i 8; i++) {
Compilation is successful in both cases, but the warning is missing when
compiling with -fPIC.
Execution: The loop executes indefinitely in both cases.
Tested on last week's build of gcc-5.2 release built for mips, and on Ubuntu
14.04 (i686 package) gcc-5.1.
Should be reproducible on any architecture with compiler version 4.9 and above.
I can provide any additional info, if required.
[Bug c++/66555] Fails to warn for if (j == 0 i == i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66555 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Jul 27 12:40:45 2015 New Revision: 226242 URL: https://gcc.gnu.org/viewcvs?rev=226242root=gccview=rev Log: PR c++/66555 PR c/54979 * c-common.c (find_array_ref_with_const_idx_r): New function. (warn_tautological_cmp): New function. * c-common.h (warn_tautological_cmp): Declare. * c.opt (Wtautological-compare): New option. * c-typeck.c (parser_build_binary_op): Call warn_tautological_cmp. * call.c (build_new_op_1): Call warn_tautological_cmp. * pt.c (tsubst_copy_and_build): Use sentinel to suppress tautological compare warnings. * doc/invoke.texi: Document -Wtautological-compare. * c-c++-common/Wtautological-compare-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wtautological-compare-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/pt.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype-54581.C trunk/gcc/testsuite/g++.dg/other/vector-compare.C
[Bug c/54979] no warning for useless comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54979 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Jul 27 12:40:45 2015 New Revision: 226242 URL: https://gcc.gnu.org/viewcvs?rev=226242root=gccview=rev Log: PR c++/66555 PR c/54979 * c-common.c (find_array_ref_with_const_idx_r): New function. (warn_tautological_cmp): New function. * c-common.h (warn_tautological_cmp): Declare. * c.opt (Wtautological-compare): New option. * c-typeck.c (parser_build_binary_op): Call warn_tautological_cmp. * call.c (build_new_op_1): Call warn_tautological_cmp. * pt.c (tsubst_copy_and_build): Use sentinel to suppress tautological compare warnings. * doc/invoke.texi: Document -Wtautological-compare. * c-c++-common/Wtautological-compare-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wtautological-compare-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/pt.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype-54581.C trunk/gcc/testsuite/g++.dg/other/vector-compare.C
[Bug c/54979] no warning for useless comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54979 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Done for GCC 6.
[Bug c++/67017] Mixing init-declarator for variables and functions in declaration with auto type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67017 --- Comment #6 from Anders Granlund anders.granlund.0 at gmail dot com --- Now I got the reply. It seems like the wording of the standard changed with the resolution of this c++ standard core defect: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1265 So the problem is that GCC hasn't implemented this yet.
[Bug c++/66555] Fails to warn for if (j == 0 i == i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66555 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Done for GCC 6.
[Bug libgomp/67027] New: [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67027 Bug ID: 67027 Summary: [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- lean-fortran/build/gcc/testsuite/gfortran1/../../gfortran -Blean-fortran/build/gcc/testsuite/gfortran1/../../ -Blean-fortran/build/x86_64-unknown-linux-gnu/./libgfortran/ src/gcc/testsuite/gfortran.dg/goacc/modules.f95 -fno-diagnostics-show-caret -fdiagnostics-color=never -O -fopenacc -S -o modules.s pid is 3492 -3492 src/gcc/testsuite/gfortran.dg/goacc/modules.f95:22:0: internal compiler error: in gimplify_adjust_omp_clauses_1, at gimp\ lify.c:6797^M 0xd4a82f gimplify_adjust_omp_clauses_1^M src/gcc/gimplify.c:6797^M 0x1e9910a splay_tree_foreach_helper^M src/libiberty/splay-tree.c:242^M 0x1e997a4 splay_tree_foreach^M src/libiberty/splay-tree.c:566^M 0xd4c397 gimplify_adjust_omp_clauses^M src/gcc/gimplify.c:7088^M 0xd507e3 gimplify_omp_workshare^M src/gcc/gimplify.c:7888^M 0xd53ece gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)^M src/gcc/gimplify.c:8932^M 0xd45e0b gimplify_stmt(tree_node**, gimple_statement_base**)^M src/gcc/gimplify.c:5552^M 0xd36b6e gimplify_statement_list^M src/gcc/gimplify.c:1490^M 0xd53cc4 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)^M src/gcc/gimplify.c:8865^M 0xd45e0b gimplify_stmt(tree_node**, gimple_statement_base**)^M src/gcc/gimplify.c:5552^M 0xd3583a gimplify_bind_expr^M src/gcc/gimplify.c:1139^M 0xd52d6e gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)^M src/gcc/gimplify.c:8647^M 0xd45e0b gimplify_stmt(tree_node**, gimple_statement_base**)^M src/gcc/gimplify.c:5552^M 0xd3389e gimplify_and_add(tree_node*, gimple_statement_base**)^M src/gcc/gimplify.c:426^M 0xd338d6 gimplify_and_return_first^M src/gcc/gimplify.c:438^M 0xd5060e gimplify_omp_workshare^M src/gcc/gimplify.c:7846^M 0xd53ece gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)^M src/gcc/gimplify.c:8932^M 0xd45e0b gimplify_stmt(tree_node**, gimple_statement_base**)^M src/gcc/gimplify.c:5552^M 0xd36b6e gimplify_statement_list^M src/gcc/gimplify.c:1490^M 0xd53cc4 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)^M src/gcc/gimplify.c:8865^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See http://gcc.gnu.org/bugs.html for instructions.^M
[Bug rtl-optimization/67028] New: combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 Bug ID: 67028 Summary: combine bug. Different assumptions about subreg in different places. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: renlin at gcc dot gnu.org Target Milestone: --- Created attachment 36067 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36067action=edit test case This is a combine bug manifest on arm target. A test case is attached. The expected output of the test case should be: checksum = 1 However, with the following command line: arm-none-eabi-gcc -march=armv7-a -O3 test.c -specs=rdimon.specs -o a.out the output is: checksum = 0 It generates wrong code when the optimization level is: -O2, -O3, -Os -O0, -O1 works fine.
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #1 from ziebell_marco at posteo dot de --- Created attachment 36068 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36068action=edit build log of tor-0.2.6.10 with gcc-5.2.0
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028
--- Comment #2 from renlin at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #1)
I have a hard time reproducing this. Could you show the generated
assembler code, and say why you think it is a combine bug?
This is my generated asm with this command cc1 -O3 -march=armv7-a test.c
stmfd sp!, {r4, lr}
mov r1, #0
movwr0, #:lower16:.LC0
movtr0, #:upper16:.LC0
bl printf
mov r0, #0
ldmfd sp!, {r4, pc}
In simplify_comparison(), for the following rtx pattern,
and:M1 (subreg:M2 X 0) (const_int C1))
the code will try to permute the SUBREG and AND when WORD_REGISTER_OPERATIONS
is defined and the subreg here is Paradoxical. There is an assumption here: the
upper bits of the subreg should all be zeros.
However, this is not always true. In this particular test case, the AND
operation, which ensures the higher bits are zero, is removed. The register
here has two CONST_INT values in a if-then-else pattern. When further
simplifying this if-then-else pattern, subreg is applied to those two CONST_INT
value.
In simplify_immed_subreg, CONST_INT is always signed extended to a larger mode.
The different assumptions cause the wrong code-generation.
What's more, in the gcc internal documentation, it's written: subregs of
subregs are not supported
However, subreg of subreg pattern will be generated by combine pass, and
simplified by simplify_subreg().
For example:
subreg:SI (subreg:HI reg:SI r10) reg:SI r10
[Bug c/67029] New: gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029
Bug ID: 67029
Summary: gcc-5.2.0 unable to find a register to spill with O3
fsched-pressure fschedule-insns
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ziebell_marco at posteo dot de
Target Milestone: ---
I'm using gcc-5.2.0 with binutils-2.25 on an amd64 maschine.
While compiling the tor program in version 2.6.10 with CFLAS=-O3
-fsched-pressure -fschedule-insns I'm hitting following error:
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./src/ext -Isrc/ext
-I./src/ext/trunnel -I./src/trunnel -I./src/common -Isrc/common
-I./src/ext/trunnel -I./src/trunnel -I./src/or -Isrc/or
-DSHARE_DATADIR=\/usr/share\ -DLOCALSTATEDIR=\/var/lib\
-DBINDIR=\/usr/bin\ -I./src/common -O3 -fsched-pressure
-fschedule-insns -fno-diagnostics-color -fno-lto -fno-use-linker-plugin
-D_FORTIFY_SOURCE=2 -Wall -fno-strict-aliasing -c -o src/or/addressmap.o
src/or/addressmap.c
command-line:0:0: warning: _FORTIFY_SOURCE redefined
built-in: note: this is the location of the previous definition
src/ext/curve25519_donna/curve25519-donna-c64.c: In function
‘curve25519_donna’:
src/ext/curve25519_donna/curve25519-donna-c64.c:451:1: error: unable to find a
register to spill
}
^
src/ext/curve25519_donna/curve25519-donna-c64.c:451:1: error: this is the insn:
(insn 4080 9130 9131 19 (parallel [
(set (reg:TI 9523 [orig:5982 D.4126 ] [5982])
(mult:TI (zero_extend:TI (subreg/j:DI (reg:TI 9523 [orig:5982
D.4126 ] [5982]) 0))
(zero_extend:TI (reg/v:DI 1734 [ r0 ]
(clobber (reg:CC 17 flags))
]) src/ext/curve25519_donna/curve25519-donna-c64.c:128 328
{*umulditi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
src/ext/curve25519_donna/curve25519-donna-c64.c:451: confused by earlier
errors, bailing out
Makefile:2982: recipe for target
'src/ext/curve25519_donna/src_common_libcurve25519_donna_a-curve25519-donna-c64.o'
failed
make[1]: ***
[src/ext/curve25519_donna/src_common_libcurve25519_donna_a-curve25519-donna-c64.o]
Error 1
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) Could you please try whether this patch helps? Trying it out now...
[Bug middle-end/55035] reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 --- Comment #8 from Jeffrey A. Law law at redhat dot com --- There are cases where the compiler can look into the implementation of bar() and make better decisions about how memory objects may be effected. This isn't one of them ;-)
[Bug libstdc++/67011] division by zero in std::exponential_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67011 Matthias Kretz kretz at kde dot org changed: What|Removed |Added CC||kretz at kde dot org --- Comment #3 from Matthias Kretz kretz at kde dot org --- The problem is that (result_type(1) - __aurng()) must never be zero (because std::log might raise FE_DIVBYZERO for std::log(0)). If __aurng() is a distribution guaranteed to exclude result_type(1) then this works fine. AFAIK std::generate_canoncialfloat sometimes generates a 1 (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176). Also, I'm wondering whether the 1 - rng wouldn't reduce the randomness. Consider: std::log(numeric_limitsfloat::min()) - -87.3365478515625 std::log(1.f - nextafter(1.f, 0.f))- -16.635532379150390625 IIUC, the effect of log(1 - rng) is that the distance between random values from std::exponential_distribution is considerable larger than for log(rng).
[Bug libgomp/67027] [gomp4] FAIL: gfortran.dg/goacc/modules.f95 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67027 vries at gcc dot gnu.org changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from vries at gcc dot gnu.org --- Caused by r226237: * gimplify.c (oacc_default_clause): Fallthrough to unspecified handling. Propagate mapping from outer scope.
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-27 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Please attach the preprocessed addressmap.i file.
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #3 from ziebell_marco at posteo dot de --- Created attachment 36069 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36069action=edit build log of tor-0.2.6.10 with gcc-4.9.3 I wanted to note that this is a regression, the project compiles fine with gcc-4.9.3 and is seems similar to this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472
[Bug libgomp/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 cesar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #25 from cesar at gcc dot gnu.org --- Fixed in trunk and gomp-4_0-branch.
[Bug bootstrap/67030] New: [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 Bug ID: 67030 Summary: [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare] Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: mpolacek at gcc dot gnu.org Target Milestone: --- Target: arm I'm getting a bootstrap failure in stage 2 on arm-none-linux-gnueabihf due to the new warning: $SRC/gcc/cfgexpand.c: In function 'long long int expand_one_var(tree, bool, bool)': $SRC/gcc/defaults.h:1156:55: error: self-comparison always evaluates to false [-Werror=tautological-compare] #define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT STACK_BOUNDARY) Seems we need to be a bit smarter when it comes to macro expansions?
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #19 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #18) I'm taking a look into this. RFC here - https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02258.html
[Bug c++/67026] New: GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026
Bug ID: 67026
Summary: GCC incorrectly rejects well-formed constexpr function
definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (proc.cc):
void g() {}
constexpr void f() { return; g(); }
int main() {}
Compile it with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
The following error message is given:
prog.cc: In function 'constexpr void f()':
prog.cc:2:31: error: call to non-constexpr function 'void g()'
constexpr void f() { return; g(); }
^
I expected to get no error message since the program is well-formed.
I have tried this with gcc HEAD 6.0.0 20150726 here:
http://melpon.org/wandbox/permlink/Hd5t7ppNQWFqioUx
For comparison clang accepts the program with no error messages.
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- I have a hard time reproducing this. Could you show the generated assembler code, and say why you think it is a combine bug?
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Could you please try whether this patch helps? diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 6a79b95..9fe9c5e 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -1890,6 +1890,10 @@ warn_tautological_cmp (location_t loc, enum tree_code code, tree lhs, tree rhs) if (TREE_CODE_CLASS (code) != tcc_comparison) return; + if (from_macro_expansion_at (EXPR_LOCATION (lhs)) + || from_macro_expansion_at (EXPR_LOCATION (rhs))) +return; + /* We do not warn for constants because they are typical of macro expansions that test for features, sizeof, and similar. */ if (CONSTANT_CLASS_P (lhs) || CONSTANT_CLASS_P (rhs))
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-27 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Ah, the -march= does the trick. Confirmed.
[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66232 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jul 27 16:24:35 2015 New Revision: 226254 URL: https://gcc.gnu.org/viewcvs?rev=226254root=gccview=rev Log: Add more tests for PR target/66232 PR target/66232 * gcc.target/i386/pr66232-6.c: New tests. * gcc.target/i386/pr66232-7.c: Likewise. * gcc.target/i386/pr66232-8.c: Likewise. * gcc.target/i386/pr66232-9.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr66232-6.c trunk/gcc/testsuite/gcc.target/i386/pr66232-7.c trunk/gcc/testsuite/gcc.target/i386/pr66232-8.c trunk/gcc/testsuite/gcc.target/i386/pr66232-9.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
Testcase:
#define A a
#define B A
#define FOO (A B)
int
main ()
{
int a = 4;
if (FOO)
return 5;
}
[Bug tree-optimization/66868] [5/6 Regression] wrong code generated with -O3 (dead code removal?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Known to fail||5.1.0 --- Comment #11 from Matthias Klose doko at gcc dot gnu.org --- rechecked with a 5.1.0 release tarball, fails with -O3
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to vries from comment #8) FYI, I'm running into this bootstrap failure on x86_64 (r226251): Weird I don't see this myself. ... src/gcc/ipa-devirt.c: In function ‘bool types_same_for_odr(const_tree, const_tree, bool)’: src/gcc/ipa-devirt.c:553:8: error: self-comparison always evaluates to false [-Werror=tautological-compare] != (TYPE_BINFO (type1) == NULL_TREE)) ... 551 if (TREE_CODE (type1) == RECORD_TYPE 552(TYPE_BINFO (type1) == NULL_TREE) 553 != (TYPE_BINFO (type1) == NULL_TREE)) Ok, that's a clear typo; something that this warning is designed to detect. I'm fixing this separately. Thanks for reporting.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to ktkachov from comment #3) Unfortunately still getting the error. Sorry about that. One thing I missed out from the original error message is this note: error: self-comparison always evaluates to false [-Werror=tautological-compare] #define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT STACK_BOUNDARY) $SRC/gcc/cfgexpand.c:1268:7: note: in expansion of macro 'SUPPORTS_STACK_ALIGNMENT' if (SUPPORTS_STACK_ALIGNMENT ^ Don't know if that helps. Actually, that helps. I bet the following works. Mind giving this one a spin? --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -1890,6 +1890,11 @@ warn_tautological_cmp (location_t loc, enum tree_code code, tree lhs, tree rhs) if (TREE_CODE_CLASS (code) != tcc_comparison) return; + if (from_macro_expansion_at (loc) + || from_macro_expansion_at (EXPR_LOCATION (lhs)) + || from_macro_expansion_at (EXPR_LOCATION (rhs))) +return; + /* We do not warn for constants because they are typical of macro expansions that test for features, sizeof, and similar. */ if (CONSTANT_CLASS_P (lhs) || CONSTANT_CLASS_P (rhs))
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jul 27 16:57:15 2015 New Revision: 226255 URL: https://gcc.gnu.org/viewcvs?rev=226255root=gccview=rev Log: PR debug/66468 * dwarf2out.c (gen_inlined_subroutine_die): Check cgraph_function_possibly_inlined_p. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug lto/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Component|debug |lto --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Changing component to LTO, since the bug seems to be with early inlining vs LTO streaming.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-27 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to ktkachov from comment #6) Yes, that seems to work. Bootstrap proceeds from that point i.e. cfgexpand.c compiles. I have to go offline for the day, so I'll have the full bootstrap result tomorrow but from what I can see this is an obvious fix (to my limited C frontend experience) and it would be nice to have it in ASAP to fix arm bootstrap. Thanks, glad to hear that. I'll commit the patch after doing some testing on x86_64 (give me ~2 hours).
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #2) (In reply to Marek Polacek from comment #1) Could you please try whether this patch helps? Trying it out now... Unfortunately still getting the error. One thing I missed out from the original error message is this note: error: self-comparison always evaluates to false [-Werror=tautological-compare] #define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT STACK_BOUNDARY) $SRC/gcc/cfgexpand.c:1268:7: note: in expansion of macro 'SUPPORTS_STACK_ALIGNMENT' if (SUPPORTS_STACK_ALIGNMENT ^ Don't know if that helps.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Marek Polacek from comment #4) (In reply to ktkachov from comment #3) Actually, that helps. I bet the following works. Mind giving this one a spin? Yes, that seems to work. Bootstrap proceeds from that point i.e. cfgexpand.c compiles. I have to go offline for the day, so I'll have the full bootstrap result tomorrow but from what I can see this is an obvious fix (to my limited C frontend experience) and it would be nice to have it in ASAP to fix arm bootstrap. Thanks for the quick response. --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -1890,6 +1890,11 @@ warn_tautological_cmp (location_t loc, enum tree_code code, tree lhs, tree rhs) if (TREE_CODE_CLASS (code) != tcc_comparison) return; + if (from_macro_expansion_at (loc) + || from_macro_expansion_at (EXPR_LOCATION (lhs)) + || from_macro_expansion_at (EXPR_LOCATION (rhs))) +return; + /* We do not warn for constants because they are typical of macro expansions that test for features, sizeof, and similar. */ if (CONSTANT_CLASS_P (lhs) || CONSTANT_CLASS_P (rhs))
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #8 from vries at gcc dot gnu.org --- FYI, I'm running into this bootstrap failure on x86_64 (r226251): ... src/gcc/ipa-devirt.c: In function ‘bool types_same_for_odr(const_tree, const_tree, bool)’: src/gcc/ipa-devirt.c:553:8: error: self-comparison always evaluates to false [-Werror=tautological-compare] != (TYPE_BINFO (type1) == NULL_TREE)) ...
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |target Severity|major |normal
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #4 from ziebell_marco at posteo dot de --- Created attachment 36070 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36070action=edit preprocessed version of addressmap.c
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #20 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Richard Biener from comment #19)
So the question is whether the frontend emits the correct test against zero:
offset = offset * byte_stride;
D.3466 = (void *) array-data;
D.3467 = D.3466;
D.3465 = 8;
D.3469 = 8;
__builtin_memcpy ((void *) transfer.4, (void *)
D.3467, (unsigned long) MAX_EXPR MIN_EXPR D.3469, D.3465, 0);
ptr2 = (struct t4 *) (transfer.4 + offset);
if (ptr2 != 0B)
{
{
integer(kind=4) stat.5;
if (ptr2-k == 0B)
to me it looks like if we really want to test transfer.4 (array-data)
against
zero.
transfer.4 + offset calculates the address of an element of an array.
I believe that if that code is executed, array.data is non-zero, and of course
array.data + offset as well.
I think the the test should check for ptr2%j's nullness before deallocating
ptr2%j, instead of testing ptr2.
With a patch like this:
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..1ff7437 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived,
gfc_component *comp,
cond-block-expr1-ts.kind = gfc_default_logical_kind;
cond-block-expr1-value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
cond-block-expr1-value.function.actual = gfc_get_actual_arglist ();
- cond-block-expr1-value.function.actual-expr = gfc_copy_expr (expr);
+ cond-block-expr1-value.function.actual-expr = gfc_copy_expr (e);
cond-block-expr1-value.function.actual-next = gfc_get_actual_arglist
();
cond-block-next = dealloc;
Unfortunately, it doesn't seem to fix the problem.
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to ziebell_marco from comment #4) Created attachment 36070 [details] preprocessed version of addressmap.c Sorry, I requested the wrong file. What actually is needed is curve25519-donna-c64.i.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #12 from Christian Joensson christian.joensson at gmail dot com --- Still... ../../gcc/ipa-devirt.c: In function ‘bool types_same_for_odr(const_tree, const_tree, bool ’: ../../gcc/ipa-devirt.c:553:8: error: self-comparison always evaluates to false [-Werror=tautological-compare] != (TYPE_BINFO (type1) == NULL_TREE)) ^
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Jul 27 19:09:27 2015 New Revision: 226264 URL: https://gcc.gnu.org/viewcvs?rev=226264root=gccview=rev Log: PR bootstrap/67030 * c-common.c (warn_tautological_cmp): Don't warn for macro expansion. * c-c++-common/Wtautological-compare-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wtautological-compare-2.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed (fingers crossed).
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Thanks. I cannot reproduce the issue.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #13 from Marek Polacek mpolacek at gcc dot gnu.org --- That is fixed as well now.
[Bug bootstrap/67030] [6 Regression] ARM bootstrap failure due to [-Werror=tautological-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67030 --- Comment #14 from Christian Joensson christian.joensson at gmail dot com --- (In reply to Marek Polacek from comment #13) That is fixed as well now. Yep. Thanks.
[Bug c++/67032] New: Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032
Bug ID: 67032
Summary: Geode optimizations incorrectly return -NaN
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joshkel at gmail dot com
Target Milestone: ---
When optimizing for the Geode architecture (-O2 -march=geode), functions may
incorrectly return -NaN instead of the expected result.
Here's a test case. (I apologize for its length; most of my attempts to shorten
it cause the bug to not manifest.)
/* main.cpp */
#include Statistic.h
#include iostream
void acquire_data()
{
Statistic stat;
stat.Accumulate(0);
stat.Accumulate(0);
std::cout stat.Var() std::endl;
std::cout stat.StdDev() std::endl;
}
int main(int, char**)
{
acquire_data();
}
/* Statistic.h */
#define STATISTICH
#include cmath
#include cstdio
#define MY_ASSERT(expr) ((expr) ? (0): std::puts(#expr))
class Statistic
{
public:
Statistic() : mCount(0), mSum(0), mSumSquared(0) {}
void Accumulate(int val);
double Var() const { MY_ASSERT(mCount 0); return mCount == 1 ? 0 :
(mSumSquared - mSum * mSum / mCount) / (mCount - 1); }
double StdDev() const { if (Var() 0.0001) return 0; else return
std::sqrt(Var()); }
private:
unsigned mCount;
double mSum, mSumSquared;
};
#endif
/* Statistic.cpp */
#include Statistic.h
void Statistic::Accumulate(int val)
{
mCount++;
mSum += val;
mSumSquared += double(val) * double(val);
}
The expected output is
0
0
However, when compiled with -O2 -march=geode, the output is
0
-nan
I can reproduce this bug in Ubuntu's g++ 4.9.2 and 5.1.0 and a from-source g++
5.1.0, but not in Ubuntu's g++ 4.8.4 or 4.6.4 or a from-source g++ 4.6.4.
[Bug rtl-optimization/67029] [5/6 regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||vmakarov at gcc dot gnu.org
Component|c |rtl-optimization
Summary|gcc-5.2.0 unable to find a |[5/6 regression] gcc-5.2.0
|register to spill with O3 |unable to find a register
|fsched-pressure |to spill with O3
|fschedule-insns |fsched-pressure
||fschedule-insns
Ever confirmed|0 |1
--- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat curve25519-donna-c64.i
extern void fn2 (char *);
__int128 a, b;
int
fn1 (void)
{
char e[32];
fn2 (e);
b = 9 * (a 1);
return 0;
}
markus@x4 tmp % gcc -O2 -fstack-protector -fschedule-insns -c
curve25519-donna-c64.i
curve25519-donna-c64.i: In function ‘fn1’:
curve25519-donna-c64.i:10:1: error: unable to find a register to spill
}
^
curve25519-donna-c64.i:10:1: error: this is the insn:
(insn 15 42 43 2 (parallel [
(set (reg:TI 104 [orig:97 D.1849 ] [97])
(mult:TI (zero_extend:TI (subreg/j:DI (reg:TI 104 [orig:97
D.1849 ] [97]) 0))
(zero_extend:TI (reg:DI 98
(clobber (reg:CC 17 flags))
]) curve25519-donna-c64.i:8 328 {*umulditi3_1}
(expr_list:REG_DEAD (reg:DI 98)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:TI (zero_extend:TI (subreg:DI (reg:TI 92
[ D.1849 ]) 0))
(const_int 9 [0x9]))
(nil)
curve25519-donna-c64.i:10: confused by earlier errors, bailing out
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|renlin at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- I'm testing a patch.
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #1 from Josh Kelley joshkel at gmail dot com --- I forgot to mention that the buggy behavior can be observed by running the resulting Geode-optimized executable on a standard PC as well as on a Geode.
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 ziebell_marco at posteo dot de changed: What|Removed |Added Attachment #36070|0 |1 is obsolete|| --- Comment #6 from ziebell_marco at posteo dot de --- Created attachment 36071 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36071action=edit preprocessed version of curve25519-donna-c64.c
[Bug c/67029] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67029 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
On July 27, 2015 8:45:41 PM GMT+02:00, mikael at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #20 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to Richard Biener from comment #19)
So the question is whether the frontend emits the correct test
against zero:
offset = offset * byte_stride;
D.3466 = (void *) array-data;
D.3467 = D.3466;
D.3465 = 8;
D.3469 = 8;
__builtin_memcpy ((void *) transfer.4, (void *)
D.3467, (unsigned long) MAX_EXPR MIN_EXPR D.3469, D.3465, 0);
ptr2 = (struct t4 *) (transfer.4 + offset);
if (ptr2 != 0B)
{
{
integer(kind=4) stat.5;
if (ptr2-k == 0B)
to me it looks like if we really want to test transfer.4
(array-data)
against
zero.
transfer.4 + offset calculates the address of an element of an array.
I believe that if that code is executed, array.data is non-zero, and
of course
array.data + offset as well.
Yes but if transfer.4 is null then transfer.4 + offset does not have to be.
Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong.
I think the the test should check for ptr2%j's nullness before
deallocating
ptr2%j, instead of testing ptr2.
With a patch like this:
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..1ff7437 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol
*derived,
gfc_component *comp,
cond-block-expr1-ts.kind = gfc_default_logical_kind;
cond-block-expr1-value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
cond-block-expr1-value.function.actual = gfc_get_actual_arglist ();
- cond-block-expr1-value.function.actual-expr = gfc_copy_expr
(expr);
+ cond-block-expr1-value.function.actual-expr = gfc_copy_expr
(e);
cond-block-expr1-value.function.actual-next =
gfc_get_actual_arglist
();
cond-block-next = dealloc;
Unfortunately, it doesn't seem to fix the problem.
[Bug c/67031] New: avr-gcc internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031
Bug ID: 67031
Summary: avr-gcc internal compiler error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugs at dima dot secretsauce.net
Target Milestone: ---
Created attachment 36072
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36072action=edit
Minimized source to show the failure
Hi. I'm seeing an internal compiler error when building AVR code:
dima@shorty:$ avr-gcc --std=gnu99 -O3 -mmcu=atxmega16e5 -c tst.c -o bleh.o
tst.c: In function 'func2':
tst.c:15:5: warning: implicit declaration of function 'sscanf'
[-Wimplicit-function-declaration]
sscanf(p1, , e, i, h, g, f);
^
tst.c:15:5: warning: incompatible implicit declaration of built-in function
'sscanf' [enabled by default]
tst.c:15:5: warning: passing argument 1 of 'sscanf' makes pointer from
integer without a cast [enabled by default]
tst.c:15:5: note: expected 'const char *' but argument is of type 'int'
tst.c:17:5: warning: passing argument 1 of 'func2' makes integer from
pointer without a cast [enabled by default]
func2(j);
^
tst.c:14:5: note: expected 'int' but argument is of type 'int *'
int func2(int p1) {
^
tst.c: In function 'func':
tst.c:24:9: warning: passing argument 1 of 'func2' makes integer from
pointer without a cast [enabled by default]
func2(a.ppp);
^
tst.c:14:5: note: expected 'int' but argument is of type 'int *'
int func2(int p1) {
^
tst.c:26:1: internal compiler error: in push_reload, at reload.c:1360
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I'm including minimized source to demo this. The compiler I'm using is whatever
is in Debian/unstable now:
dima@shorty:$ dpkg -l gcc-avr
ii gcc-avr 1:4.8.1+Atmel3.4.5-1
amd64 GNU C compiler (cross compiler for avr)
dima@shorty:$ avr-gcc --verbose --version
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.8.1/lto-wrapper
avr-gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++
--prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
--with-system-zlib --enable-long-long --enable-nls --without-included-gettext
--disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '--version'
/usr/lib/gcc/avr/4.8.1/cc1 -quiet -v help-dummy -quiet -dumpbase
help-dummy -auxbase help-dummy -version --version -o /tmp/cceJxgRU.s
GNU C (GCC) version 4.8.1 (avr)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
warning: MPFR header version 3.1.2-p11 differs from library version
3.1.2-p3.
warning: MPC header version 1.0.3 differs from library version 1.0.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '--version'
/usr/lib/gcc/avr/4.8.1/../../../avr/bin/as --version -o /tmp/ccBrSnpW.o
/tmp/cceJxgRU.s
GNU assembler (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `avr'.
COMPILER_PATH=/usr/lib/gcc/avr/4.8.1/:/usr/lib/gcc/avr/4.8.1/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.8.1/:/usr/lib/gcc/avr/:/usr/lib/gcc/avr/4.8.1/../../../avr/bin/
LIBRARY_PATH=/usr/lib/gcc/avr/4.8.1/:/usr/lib/gcc/avr/4.8.1/../../../avr/lib/
COLLECT_GCC_OPTIONS='-v' '--version'
/usr/lib/gcc/avr/4.8.1/collect2 --version -L/usr/lib/gcc/avr/4.8.1
-L/usr/lib/gcc/avr/4.8.1/../../../avr/lib /tmp/ccBrSnpW.o --start-group -lgcc
-lm -lc --end-group
collect2 version 4.8.1
/usr/lib/gcc/avr/4.8.1/../../../avr/bin/ld --version
-L/usr/lib/gcc/avr/4.8.1 -L/usr/lib/gcc/avr/4.8.1/../../../avr/lib
/tmp/ccBrSnpW.o --start-group -lgcc -lm -lc --end-group
GNU ld (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Please attach a *preprocessed* source, as instructed in [1]. [1] https://gcc.gnu.org/bugs/
[Bug middle-end/67035] New: [6 Regression] FAIL: gcc.c-torture/compile/pr54713-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67035 Bug ID: 67035 Summary: [6 Regression] FAIL: gcc.c-torture/compile/pr54713-3.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -w -c -o pr54713-3 .o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr54713-3.c (timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics -show-caret -fdiagnostics-color=never -O0 -w -c -o pr54713-3.o /test/gnu/gcc/gcc /gcc/testsuite/gcc.c-torture/compile/pr54713-3.c In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr54 713-3.c:9:0: /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr54713-1.c: In function ' f1':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr54713-1.c:13:1: internal compiler error: in expand_one_stack_var_1, at cfgexpand.c:1221 libbacktrace could not find executable to open Please submit a full bug report, Breakpoint 1, _ZL22expand_one_stack_var_1P9tree_node (var=0x7ae2bfc8) at ../../gcc/gcc/cfgexpand.c:1221 1221 gcc_assert (byte_align * BITS_PER_UNIT = MAX_SUPPORTED_STACK_ALIGNMENT); (gdb) p byte_align $1 = 128 (gdb) bt Python Exception type 'exceptions.ImportError' Failed to load /home/gnu/lib/python2.7/lib-dynload/itertools.sl: #0 _ZL22expand_one_stack_var_1P9tree_node (var=0x7ae2bfc8) at ../../gcc/gcc/cfgexpand.c:1221 #1 0x004a2940 in _ZL24expand_one_ssa_partitionP9tree_node (var=0x7ae2bfc8) at ../../gcc/gcc/cfgexpand.c:1295 #2 0x004a5e90 in _ZL16expand_used_varsv () at ../../gcc/gcc/cfgexpand.c:1940 #3 0x004bcf84 in _ZN12_GLOBAL__N_111pass_expand7executeEP8function ( this=0x404416d0, fun=0x7ae28068) at ../../gcc/gcc/cfgexpand.c:6084 #4 0x012969a4 in _Z16execute_one_passP8opt_pass (pass=0x404416d0) at ../../gcc/gcc/passes.c:2319 #5 0x01296df0 in _ZL19execute_pass_list_1P8opt_pass (pass=0x404416d0) at ../../gcc/gcc/passes.c:2372 #6 0x01296f14 in _Z17execute_pass_listP8functionP8opt_pass (fn=0x7ae28068, pass=0x4043f240) at ../../gcc/gcc/passes.c:2383 #7 0x0056bd10 in _ZN11cgraph_node6expandEv (this=0x7aeb8000) at ../../gcc/gcc/cgraphunit.c:1920 #8 0x0056cf10 in _ZL15output_in_orderb (no_reorder=false) at ../../gcc/gcc/cgraphunit.c:2158 #9 0x0056dc5c in _ZN12symbol_table7compileEv (this=0x7ae28000) at ../../gcc/gcc/cgraphunit.c:2403 #10 0x0056e020 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x7ae28000) at ../../gcc/gcc/cgraphunit.c:2496 #11 0x0150c9b0 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:569 #12 0x01511b9c in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:2042 ---Type return to continue, or q return to quit--- #13 0x0151224c in _ZN6toplev4mainEiPPc (this=0x7eff06c8, argc=15, argv=0x7eff0554) at ../../gcc/gcc/toplev.c:2143 #14 0x01ec5650 in main (argc=15, argv=0x7eff0554) at ../../gcc/gcc/main.c:39 PREFERRED_STACK_BOUNDARY is 512 bits.
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #4 from Josh Kelley joshkel at gmail dot com --- Created attachment 36074 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36074action=edit Preprocessed Statistic.cpp from test case
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #3 from Josh Kelley joshkel at gmail dot com --- Created attachment 36073 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36073action=edit Preprocessed main.cpp from test case
[Bug sanitizer/66977] -fsanitize=shift may introduce uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66977 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- This works (can't use unshare_expr here), but I'll try to come up with something nicer... diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c index a45755e..f1b6475 100644 --- a/gcc/cp/decl2.c +++ b/gcc/cp/decl2.c @@ -4926,6 +4926,8 @@ build_offset_ref_call_from_tree (tree fn, vectree, va_gc **args, fn = TREE_OPERAND (fn, 1); fn = get_member_function_from_ptrfunc (object_addr, fn, complain); + if (flag_sanitize SANITIZE_SHIFT) + walk_tree (object_addr, copy_tree_r, NULL, NULL); vec_safe_insert (*args, 0, object_addr); }
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords||ra Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-27 CC||ubizjak at gmail dot com, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Found the problem. geode is one of the targets that enable Ym and Yn constraints: (define_register_constraint Ym TARGET_MMX TARGET_INTER_UNIT_MOVES_TO_VEC ? MMX_REGS : NO_REGS @internal Any MMX register, when inter-unit moves to vector registers are enabled.) (define_register_constraint Yn TARGET_MMX TARGET_INTER_UNIT_MOVES_FROM_VEC ? MMX_REGS : NO_REGS @internal Any MMX register, when inter-unit moves from vector registers are enabled.) And ... the compiler generates insns that involve MMX registers. $ ./cc1plus -O2 -march=geode -m32 -dp main.ii $ grep %mm main.s movd%eax, %mm0 # 131 *zero_extendsidi2/6 [length = 3] movq%mm0, (%esp)# 330 *movdi_internal/10 [length = 4] movq%mm0, (%esp)# 333 *movdi_internal/10 [length = 4] movd%eax, %mm0 # 288 *zero_extendsidi2/6 [length = 3] GCC uses many tricks to penalize moves to/from MMX registers. Actually, MMX registers should not be allocated unless absolutely needed, that is the reason that every single constraint involving MMX regs is decorated by * and most of them are penalized by ? and/or !. One of the most important tricks is the one in inline_secondary_memory_needed, where: /* ??? This is a lie. We do have moves between mmx/general, and for mmx/sse2. But by saying we need secondary memory we discourage the register allocator from using the mmx registers unless needed. */ if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)) return true; It looks that with new and improved RA, this trick is not effective any more and delicate balance that prevented MMX regs to be allocated is broken. CC register allocator expert for opinion.
[Bug middle-end/67034] New: [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034 Bug ID: 67034 Summary: [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -w -c -o pr39928-1 .o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c (timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -o pr39928-1.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c: In function ' vq_nbest':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr39928-1.c:6:1: internal compiler error: in emit_move_insn, at expr.c:3552 libbacktrace could not find executable to openPlease submit a full bug report, This is with r226194. gcc_assert (mode != BLKmode (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode)); (gdb) bt Python Exception type 'exceptions.ImportError' Failed to load /home/gnu/lib/python2.7/lib-dynload/itertools.sl: #0 _Z14emit_move_insnP7rtx_defS0_ (x=0x7aebd1f0, y=0x7aebd450) at ../../gcc/gcc/expr.c:3552 #1 0x0092426c in _ZL21assign_parm_setup_regP20assign_parm_data_allP9tree_nodeP20assign_parm_data_one (all=0x7eff0c78, parm=0x7aeb4190, data=0x7eff0d60) at ../../gcc/gcc/function.c:3322 #2 0x00926c5c in _ZL12assign_parmsP9tree_node (fndecl=0x7aeb5080) at ../../gcc/gcc/function.c:3766 #3 0x0092e500 in _Z21expand_function_startP9tree_node (subr=0x7aeb5080) at ../../gcc/gcc/function.c:5192 #4 0x004bd08c in _ZN12_GLOBAL__N_111pass_expand7executeEP8function ( this=0x404416d0, fun=0x7ae28068) at ../../gcc/gcc/cfgexpand.c:6105 #5 0x012969a4 in _Z16execute_one_passP8opt_pass (pass=0x404416d0) at ../../gcc/gcc/passes.c:2319 #6 0x01296df0 in _ZL19execute_pass_list_1P8opt_pass (pass=0x404416d0) at ../../gcc/gcc/passes.c:2372 #7 0x01296f14 in _Z17execute_pass_listP8functionP8opt_pass (fn=0x7ae28068, pass=0x4043f240) at ../../gcc/gcc/passes.c:2383 #8 0x0056bd10 in _ZN11cgraph_node6expandEv (this=0x7aeb7000) at ../../gcc/gcc/cgraphunit.c:1920 #9 0x0056cf10 in _ZL15output_in_orderb (no_reorder=false) at ../../gcc/gcc/cgraphunit.c:2158 #10 0x0056dc5c in _ZN12symbol_table7compileEv (this=0x7ae28000) at ../../gcc/gcc/cgraphunit.c:2403 ---Type return to continue, or q return to quit--- #11 0x0056e020 in _ZN12symbol_table25finalize_compilation_unitEv ( this=0x7ae28000) at ../../gcc/gcc/cgraphunit.c:2496 #12 0x0150c9b0 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:569 #13 0x01511b9c in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:2042 #14 0x0151224c in _ZN6toplev4mainEiPPc (this=0x7eff06c8, argc=15, argv=0x7eff0554) at ../../gcc/gcc/toplev.c:2143 #15 0x01ec5650 in main (argc=15, argv=0x7eff0554) at ../../gcc/gcc/main.c:39 (gdb) p debug_rtx (x) (mem/c:BLK (plus:SI (reg/f:SI 91 virtual-stack-vars) (const_int 8 [0x8])) [0 d+0 S16 A128]) $1 = 10 (gdb) p debug_rtx (y) (mem/c:BLK (reg/v:SI 101) [0 d+0 S16 A128]) $2 = 10 (gdb) p mode $3 = BLKmode
[Bug c++/67033] [c++11] template argument invalid for integral constant expression beginning with address-of expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67033
--- Comment #1 from Ed Catmur ed at catmur dot co.uk ---
Created attachment 36075
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36075action=edit
pr67033.patch
This is kinda ugly.
The problem is that before C++1z, a non-type template argument that evaluates
to the address of or a reference to an object [...] must be expressed as
id-expression [...]; this means that the parser isn't really the place for
this, as the validity of the expression depends on its value:
templateint* p class X {};
int i;
Xi x1; // OK
X((i)) x2; // OK since C++11
templatebool b class Y : Xb ? i : nullptr {}; // OK since C++11 if !b
Xtrue ? i : nullptr x3; // OK since C++1z
The attached patch lets through quite a lot of constructs that are actually
invalid pre-C++1z. A rigorous check would be to annotate the constant
expression to say whether it matches the form allowed in [temp.arg.nontype] and
then on evaluation check whether it is a null pointer constant.
[Bug c++/67033] New: [c++11] template argument invalid for integral constant expression beginning with address-of expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67033
Bug ID: 67033
Summary: [c++11] template argument invalid for integral
constant expression beginning with address-of
expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot co.uk
Target Milestone: ---
templatebool B struct S { };
int x;
Sx == x s;
// error: template argument 1 is invalid
//^
x == x is a valid converted constant expression of type bool.
The problem is that cp_parser_template_argument sees the initial '' and
decides that the non-type template argument must be the address-of operator
applied to an id-expression; when it fails to reach the end of the template
argument it aborts.
This behavior is valid for = C++03, where '' cannot appear in a constant
expression, but C++11 is more relaxed.
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #5 from Josh Kelley joshkel at gmail dot com --- Additional information requested in https://gcc.gnu.org/bugs/: Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/5/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 5.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1) Commands to build files: g++-5 main.cpp -O2 -march=geode -D_GLIBCXX_USE_CXX11_ABI=0 -c -omain.o -save-temps g++-5 Statistic.cpp -O2 -march=geode -D_GLIBCXX_USE_CXX11_ABI=0 -c -oStatistic.o -save-temps g++-5 -otesting main.o Statistic.o -lm
[Bug target/67032] Geode optimizations incorrectly return -NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67032 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Forgot to say that -mno-mmx disables moves to/from MMX regs in your case.
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- GCC does not implement the full C++14 rules for constexpr yet. That is having a return type of void is not implemented yet. It was invalid for C++11 to have a constexpr with void.
[Bug rtl-optimization/67037] New: [4.9 Regression] Wrong code at -O1 and above on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67037
Bug ID: 67037
Summary: [4.9 Regression] Wrong code at -O1 and above on ARM
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: notasas at gmail dot com
Target Milestone: ---
Target: arm-unknown-linux-gnueabi, arm-linux-gnueabihf
Created attachment 36076
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36076action=edit
testcase
The reduced testcase (based on real code from wine sources) crashes:
notaz@evm:/tmp/t$ cc -Wall -O0 testcase.c ./a.out
notaz@evm:/tmp/t$ cc -Wall -O1 testcase.c ./a.out
Segmentation fault
notaz@evm:/tmp/t$ cc -Wall -O2 testcase.c ./a.out
Segmentation fault
notaz@evm:/tmp/t$ cc -Wall -Os testcase.c ./a.out
notaz@evm:/tmp/t$ cc -Wall -O1 testcase.c -mcpu=arm920t -marm ./a.out
Segmentation fault
notaz@evm:/tmp/t$ cc -Wall -O1 testcase.c -mcpu=cortex-a15 ./a.out
Segmentation fault
gcc 4.7.2 and 4.8.2 seem to be ok.
It looks like this chunk
while ((count 1) *s)
{
count--;
*d++ = *s++;
}
is compiled to
add r3, sp, #5312
add r3, r3, #52
ldr r3, [r3]@ count
cmp r3, #1
bls .L6
movwr2, #:lower16:.LANCHOR0
mov r3, #78
movtr2, #:upper16:.LANCHOR0
b .L8
.L18:
ldrhr3, [r2, #2]!
cmp r3, #0
beq .L9
.L8:
add r1, sp, #5312
add r1, r1, #52
ldr r0, [r1]
sub r0, r0, #1
str r0, [r1]
ldr r1, [r3]@ -- crash
cmp r0, #1
strhr3, [r1], #2@ movhi
add r3, sp, #5312
add r3, r3, #48
str r1, [r3]
bne .L18
.L9:
so it thinks r3 contains pointer to count, even though it loaded *s there?
The conditions for this bug seem to be large stack frame that load/store
offsets can't reach and enough register pressure.
[Bug c++/67036] GCC does not warn of throwing destructors in C++11, even when they lack noexcept(false) and std::uncaught_exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67026 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Actually wait. I think this is invalid and clang is incorrect in not rejecting it. Because you have a call to a non constexpr in a constexpr function; does not matter if it is after a return or not.
[Bug c++/67038] New: [c++-concepts] Viable function template despite unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67038
Bug ID: 67038
Summary: [c++-concepts] Viable function template despite
unsatisfied constraints
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
Created attachment 36077
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36077action=edit
Preprocessed test case
r226205 fails to compile this correct program:
#include stl2/iterator.hpp
template stl2::WeakOutputIteratorint I
requires !stl2::WeakInputIteratorI()
constexpr bool dispatch() { return false; }
template stl2::WeakInputIterator I
constexpr bool dispatch() { return true; }
template stl2::WeakOutputIteratorint I
constexpr bool is_weak_out() { return true; }
template stl2::WeakInputIterator I
constexpr bool is_weak_in() { return true; }
int main() {
static_assert(is_weak_outint*());
static_assert(is_weak_inint*());
static_assert(dispatchint*());
}
with error:
~/concept-gcc/bin/g++ -std=gnu++1z -I ~/cmcstl2/include -I
~/cmcstl2/meta/include foo.cpp -c
foo.cpp: In function ‘int main()’:
foo.cpp:19:32: error: call of overloaded ‘dispatch()’ is ambiguous
static_assert(dispatchint*());
^
foo.cpp:5:16: note: candidate: constexpr bool dispatch() [with I = int*]
constexpr bool dispatch() { return false; }
^
foo.cpp:8:16: note: candidate: constexpr bool dispatch() [with I = int*]
constexpr bool dispatch() { return true; }
^
The compiler apparently considers both overloads of dispatch to be viable
despite that the first overload's constraint !stl2::WeakInputIteratorI() is
clearly not satisfied when I is int*.
[Bug c++/67036] New: GCC does not warn of throwing destructors in C++11, even when they lack noexcept(false) and std::uncaught_exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036
Bug ID: 67036
Summary: GCC does not warn of throwing destructors in C++11,
even when they lack noexcept(false) and
std::uncaught_exception
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Compiling under -Wall -Wextra does not produce a warning:
$ cat test-throw.cpp
#include stdexcept
#include iostream
struct useless
{
useless() { std::cout in std::endl; }
~useless() { std::cout out std::endl; throw std::runtime_error(who
knows...); }
};
int main(int argc, char* argv[])
{
useless u;
return argc;
}
$ gcc -O1 -Wall -Wextra -c test-throw.cpp
test-throw.cpp:10:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char* argv[])
^
1 warning generated.
*
Same result with C++11:
$ gcc -std=c++11 -O1 -Wall -Wextra -c test-throw.cpp
test-throw.cpp:10:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char* argv[])
^
1 warning generated.
Microsoft Visual Studio will warn.
*
The warning is useful because it brings attention to a potential sore spot:
throwing during an unwind due to an exception.
Maybe the gap could be turned into a full fledged diagnostic: if the dtor
throws and (1) lacks noexcept(false) under C++11 or (2) and lacks a check for
std::uncaught_exception(), then the warning should be applied aggressively (say
at -Wall). Otherwise, have the throwing destructor generate a warning at -Wall.
Or maybe something else along similar lines...
I can state from experience the Visual Studio warning alerted us to look at a
particular dtor, and it was not checking for !std::uncaught_exception() before
throwing. (It was one of two classes among hundreds that threw, so it was easy
to miss throughout the day).
And as soon as Visual Studio caught it, two people on the team asked why GCC
did not catch it. (GCC is held in higher regard).
[Bug sanitizer/66977] -fsanitize=shift may introduce uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66977
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Another approach would be
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 2ed43be..41f54ac 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -3288,6 +3288,7 @@ get_member_function_from_ptrfunc (tree *instance_ptrptr,
tree function,
idx = build1 (NOP_EXPR, vtable_index_type, e3);
switch (TARGET_PTRMEMFUNC_VBIT_LOCATION)
{
+ int flag_sanitize_save;
case ptrmemfunc_vbit_in_pfn:
e1 = cp_build_binary_op (input_location,
BIT_AND_EXPR, idx, integer_one_node,
@@ -3303,9 +3304,12 @@ get_member_function_from_ptrfunc (tree *instance_ptrptr,
tree function,
e1 = cp_build_binary_op (input_location,
BIT_AND_EXPR, delta, integer_one_node,
complain);
+ flag_sanitize_save = flag_sanitize;
+ flag_sanitize = 0;
delta = cp_build_binary_op (input_location,
RSHIFT_EXPR, delta, integer_one_node,
complain);
+ flag_sanitize = flag_sanitize_save;
if (delta == error_mark_node)
return error_mark_node;
break;
[Bug c++/67036] GCC does not warn of throwing destructors in C++11, even when they lack noexcept(false) and std::uncaught_exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036 --- Comment #1 from Jeffrey Walton noloader at gmail dot com --- I can state from experience the Visual Studio warning alerted us to look at a particular dtor, and it was not checking for !std::uncaught_exception() before throwing. (It was one of two classes among hundreds that threw, so it was easy to miss throughout the day). My bad... this was not clear. There were hundreds of classes, and only two threw in the dtor. The other that threw guarded based on !std::uncaught_exception().
[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66846 --- Comment #4 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 27 23:44:43 2015 New Revision: 226279 URL: https://gcc.gnu.org/viewcvs?rev=226279root=gccview=rev Log: Don't cancel loop tree in parloops 2015-07-28 Tom de Vries t...@codesourcery.com PR tree-optimization/66846 * omp-low.c (expand_omp_taskreg) [ENABLE_CHECKING]: Call verify_loop_structure for child_cfun if !LOOPS_NEED_FIXUP. (expand_omp_target) [ENABLE_CHECKING]: Same. (execute_expand_omp): Reinstate LOOPS_HAVE_SIMPLE_LATCHES if in ssa. [ENABLE_CHECKING]: Call verify_loop_structure for cfun if !LOOPS_NEED_FIXUP. (expand_omp_for_static_nochunk): Handle case that omp_for already has its own loop struct. * tree-parloops.c (create_parallel_loop): Add comment about breaking LOOPS_HAVE_SIMPLE_LATCHES. Record new exit. (gen_parallel_loop): Remove call to cancel_loop_tree. (parallelize_loops): Skip loops that are inner loops of parallelized loops. (pass_parallelize_loops::execute): Clear LOOPS_HAVE_SIMPLE_LATCHES on loop state. [ENABLE_CHECKING]: Call verify_loop_structure. Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/omp-low.c branches/gomp-4_0-branch/gcc/tree-parloops.c
[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 --- Comment #6 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jul 27 23:46:16 2015 New Revision: 226289 URL: https://gcc.gnu.org/viewcvs?rev=226289root=gccview=rev Log: Handle mix/max pointer reductions in parloops 2015-07-28 Tom de Vries t...@codesourcery.com PR tree-optimization/46193 * omp-low.c (omp_reduction_init): Handle pointer type for min or max clause. * gcc.dg/autopar/pr46193.c: New test. * testsuite/libgomp.c/pr46193.c: New test. Added: branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/autopar/pr46193.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/pr46193.c Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/omp-low.c branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #9 from John Buddery jvb at cyberscience dot com --- I should clarify that the workaround above only works fully on 4.9.2 and earlier. From 5.0 onwards, gcc seems to have a problem building 32 bit code for ia64-hpux. It doesn't emit intstructions to properly set the top two bits of pointers after widening, which is required because of the way ia64 segments it's address space. So, you might have better luck with 4.9.2. Or, you might be able to build gcc as a 64 bit executable (though I don't know how to do configure it this way).
[Bug other/61321] demangler crash on casts in template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 63465 has been marked as a duplicate of this bug. ***
[Bug other/63465] Demangler crash (GDB PR 17455)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63465 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 61321 ***
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062 --- Comment #2 from Sujoy ssaraswati at gmail dot com --- This bug is in UNCONFIRMED state. Since I am new to gcc, just wanted to know if one should work for this fix only after it is confirmed.
[Bug target/64400] iq2000-elf: ICE in dwarf2out_var_location, at dwarf2out.c:21266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400 Yaakov Selkowitz yselkowi at redhat dot com changed: What|Removed |Added Version|4.9.2 |5.2.0 --- Comment #1 from Yaakov Selkowitz yselkowi at redhat dot com --- Same issue in 5.2.0; error is now reported at dwarf2out.c:21837.
[Bug c/67040] New: gcc-5.2 fails with flat namespaces on the mac os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67040
Bug ID: 67040
Summary: gcc-5.2 fails with flat namespaces on the mac os
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: balaji at anl dot gov
Target Milestone: ---
gcc-5.2 causes bad library builds on the mac os, when built with flat
namespaces, and with no optimizations.
The following simple program reproduces the problem:
{{{
% cat foo.c
#include stdio.h
void bar(void) { }
void foo(void *s) { bar(); }
}}}
{{{
% cat test.c
#include stdio.h
void foo(void *s);
int main()
{
foo(NULL);
return 0;
}
}}}
{{{
% gcc -dynamiclib foo.c -o libfoo.dylib -Wl,-flat_namespace
% gcc -L. test.c -lfoo
% ./a.out
Segmentation fault: 11
}}}
Either removing the `-Wl,-flat_namespace` option or adding some level of
optimization, such as `-O2` to the library build fixes this issue.
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #6 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Created attachment 36078 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36078action=edit Use unsigned type for inc to have defined left shift
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #7 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- (In reply to Thomas Preud'homme from comment #6) Created attachment 36078 [details] Use unsigned type for inc to have defined left shift Hi Markus, Sorry for the delay, I got busy on some other bugs. Would you mind giving the patch attached to the PR a go? I tried reproducing the issue but couldn't. I did ran the regression testsuite though and it's all good. Best regards.
[Bug fortran/67039] New: Documentation of pseudorandom number intrinsics is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039 Bug ID: 67039 Summary: Documentation of pseudorandom number intrinsics is incorrect Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: spam.brian.taylor at gmail dot com Target Milestone: --- The gfortran documentation for the RANDOM_NUMBER and RANDOM_SEED subroutines indicates that they are part of Fortran 95 and later. In fact, they were included in the Fortran 90 standard. The gfortran documentation for the SRAND subroutine, a GNU extension, includes in the Notes section the following: The Fortran 2003 standard specifies the intrinsic RANDOM_SEED to initialize the pseudo-random numbers generator and RANDOM_NUMBER to generate pseudo-random numbers. The reference here should be to the Fortran 90 standard, not 2003. https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/RANDOM_005fNUMBER.html#RANDOM_005fNUMBER https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/RANDOM_005fSEED.html#RANDOM_005fSEED https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gfortran/SRAND.html#SRAND
[Bug target/66062] under O2 optimization level , aarch64 compiler give informance : internal compiler error: in expand_assignment, at expr.c:4838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66062
Sujoy ssaraswati at gmail dot com changed:
What|Removed |Added
CC||ssaraswati at gmail dot com
--- Comment #1 from Sujoy ssaraswati at gmail dot com ---
(In reply to huangcunjian from comment #0)
Hi,
I can reproduce this on x86_64 as well. The test case as such has an issue
that it does an out of bound access for an array. However, I believe gcc
shouldn't crash in any case. This can be reproduced with a shorter test case as
shown below.
#include stdio.h
#include stdint.h
#include stdlib.h
struct S0 {
unsigned int i : 2;
};
static struct S0 g[5] = {{0}, {1}, {0}, {1}, {0}};
static int64_t idx = 0x979516CD4BBA2AEDLL;
int main()
{
struct S0 l = {0};
g[(idx + 1)] = l;
return g[3].i;
}
$ gcc -O2 small_test.c
small_test.c: In function âmainâ:
small_test.c:15:16: internal compiler error: in expand_assignment, at
expr.c:4721
g[(idx + 1)] = l;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccueDw3V.out file, please attach this to
your bugreport.
[Bug c++/65974] [5/6 Regression] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.3 Keywords||diagnostic Last reconfirmed||2015-07-27 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Bogus |[5/6 Regression] Bogus |deprecated-declarations |deprecated-declarations |warnings for inline |warnings for inline |definitions of deprecated |definitions of deprecated |virtual methods |virtual methods Target Milestone|--- |5.3 Known to fail||5.1.0, 5.2.0, 6.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #19 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #18)
(In reply to Uroš Bizjak from comment #17)
(In reply to Mat Cross from comment #14)
For the record, perhaps it is of interest for me to note that we are
running
into this (cf. PR64230 comment 9) on code like
Program test
Implicit None
Type :: t1
Integer, Allocatable :: i
End Type
Type :: t2
Integer, Allocatable :: i
End Type
Type, Extends (t1) :: t3
Type (t2) :: j
End Type
Type, Extends (t3) :: t4
Integer, Allocatable :: k
End Type
Call s
Print *, 'ok'
Contains
Subroutine s
Class (t1), Allocatable :: x
Allocate (t4 :: x)
End Subroutine
End Program
Since the crash is in bad compiler-generated finalization code (since
4.9),
and given that (if I recall correctly) gfortran is using the Fortran 2008
semantics for entities declared in a main program being implicitly saved,
this is why removing the Deallocate (in the comment 12 example) works -
the
finalizer is never called then.
No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
[...]
I was able to trace dumps down to _.fre2 tree dump, where we have:
bb 12:
# idx_104 = PHI 0(11), idx_122(16)
offset_115 = 0;
ptr2_119 = (struct t3 *) offset_115;
_120 = ptr2_119-j;
This isn't a dereference, it's just an address computation. Iff j
is not at offset zero then of course...
if (_120 != 0B)
goto bb 19;
else
goto bb 22;
bb 19:
_121 = ptr2_119-j.i;
we'll crash right here.
So the question is whether the frontend emits the correct test against zero:
offset = offset * byte_stride;
D.3466 = (void *) array-data;
D.3467 = D.3466;
D.3465 = 8;
D.3469 = 8;
__builtin_memcpy ((void *) transfer.4, (void *) D.3467,
(unsigned long) MAX_EXPR MIN_EXPR D.3469, D.3465, 0);
ptr2 = (struct t4 *) (transfer.4 + offset);
if (ptr2 != 0B)
{
{
integer(kind=4) stat.5;
if (ptr2-k == 0B)
to me it looks like if we really want to test transfer.4 (array-data) against
zero. We do
0x00400b26 +502: cmp$0xfff8,%r15
0x00400b2a +506: je 0x400b42 test+530
= 0x00400b2c +508: mov0x8(%r15),%rdi
and %r15 is zero, so offset is _not_ zero here (but ends up constant
propagated and we optimize the compare - offset seems to be 8).
This can't be right, we have a dereference from zero. If the frontend
produced correct code, then tree-optimization passes made a mess here.
CC Richi.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-27 Known to work||4.9.3 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.3 Summary|ICE: in |[5/6 Regression] ICE: in |verify_loop_structure, at |verify_loop_structure, at |cfgloop.c:1647 (loop with |cfgloop.c:1647 (loop with |header n not in loop tree) |header n not in loop tree) Ever confirmed|0 |1 Known to fail||5.2.0, 6.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. The loop appears after CDDCE1 where a loop with multiple entries becomes one with a single entry. DCE expects cleanup-cfg to fix things but that doesn't do anything and thus doesn't end up fixing up loops. Mine.
[Bug c++/66996] [6 Regression] defined but not used [-Wunused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66996 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, looks correct to me, too.
[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I believe the patch was reverted again.
[Bug bootstrap/66994] [6 Regression] ICE: Segmentation fault during bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66994 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug ipa/67024] New: IPA SRA removes tail-call opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024 Bug ID: 67024 Summary: IPA SRA removes tail-call opportunities Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: jamborm at gcc dot gnu.org Target Milestone: --- In gimple/generic-match.c the main dispatcher gimple_simplify () has tail-calls to workers that might end up not needing one of the parameters. IPA SRA removes those even though the resulting call is now more expensive than with keeping the paramters inplace. An issue might be that tail-call discovery only runs after IPA SRA.
[Bug ipa/67024] IPA SRA removes sibling-call opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 27 Jul 2015, pinskia at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This might be different on other targets. Like say power or aarch64. Or even ia32. Yeah, it always depends on whether a sibling call would be generated in the end or not. Which isn't easy to detect at the time IPA SRA runs.
[Bug ipa/67024] IPA SRA removes sibling-call opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- However, I have just verified that when IPA-CP removes an argument, the sibcall is generated. So basically this seems to be another reason to make IPA-SRA an actual IPA pass. I'll see what I can do.
[Bug target/66780] [4.9 Regression] Compiling with -fstack-protector-strong causes binary to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66780 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Fixed.
[Bug driver/67023] New: g++ does not set preprocessor language to C++ when reading from standard input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67023 Bug ID: 67023 Summary: g++ does not set preprocessor language to C++ when reading from standard input Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- You would expect this to expand the __cplusplus macro: echo __cplusplus | g++ -E - but when reading from standard input the language is automatically set to C, even when using the g++ driver. In contrast, without -E there is no language set automatically and a -x option must be used, which just makes the 'g++ -E -' behaviour even more likely to confuse, as in https://gcc.gnu.org/ml/gcc-help/2015-07/msg00103.html
[Bug ipa/67024] IPA SRA removes sibling-call opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Summary|IPA SRA removes tail-call |IPA SRA removes
|opportunities |sibling-call opportunities
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
For example
struct X { int i; int j[2]; };
static int foo (int k, struct X x)
{
return x.i + x.j[0] + x.j[1];
}
int bar (int k, struct X x)
{
return foo (k, x);
}
Compiled with -O2 -fno-inline (or just make foo large enough):
foo.isra.0:
.LFB2:
.cfi_startproc
movq%rdi, %rax
shrq$32, %rax
addl%eax, %edi
leal(%rdi,%rsi), %eax
ret
bar:
.LFB1:
.cfi_startproc
movq%rsi, %rdi
movl%edx, %esi
jmp foo.isra.0
with -fno-ipa-sra added:
foo:
.LFB0:
.cfi_startproc
movq%rsi, %rax
shrq$32, %rax
addl%eax, %esi
leal(%rsi,%rdx), %eax
ret
bar:
.LFB1:
.cfi_startproc
jmp foo
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #47 from Rainer Orth ro at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #44) Same on sparc.
[Bug ipa/67024] IPA SRA removes sibling-call opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67024 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This might be different on other targets. Like say power or aarch64. Or even ia32.
