[Bug sanitizer/63520] New: ICE: in get_biv_step, at loop-iv.c:824 with -fsanitize=undefined on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63520
Bug ID: 63520
Summary: ICE: in get_biv_step, at loop-iv.c:824 with
-fsanitize=undefined on ppc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target: powerpc64-unknown-linux-gnu
trippels@gcc1-power7 libdecnumber % cat decNumber.i
int a;
void
fn1 (void)
{
for (;;)
{
if (a == 1)
break;
a -= 1;
}
}
trippels@gcc1-power7 libdecnumber % gcc -c -fsanitize=undefined -O2 decNumber.i
decNumber.i: In function ‘fn1’:
decNumber.i:11:1: internal compiler error: in get_biv_step, at loop-iv.c:824
}
^
0x105a9b13 get_biv_step
../../gcc/gcc/loop-iv.c:824
0x105a9b13 iv_analyze_biv
../../gcc/gcc/loop-iv.c:913
0x105a9f8b iv_analyze_op
../../gcc/gcc/loop-iv.c:1189
0x105a9e6f iv_analyze_op
../../gcc/gcc/loop-iv.c:1159
0x105aa2cb iv_analyze_expr(rtx_insn*, rtx_def*, machine_mode, rtx_iv*)
../../gcc/gcc/loop-iv.c:969
0x105aa3d3 iv_analyze_expr(rtx_insn*, rtx_def*, machine_mode, rtx_iv*)
../../gcc/gcc/loop-iv.c:1025
0x105aabeb iv_analyze_def
../../gcc/gcc/loop-iv.c:1120
0x105a9df3 iv_analyze_op
../../gcc/gcc/loop-iv.c:1191
0x105ab30b iv_number_of_iterations
../../gcc/gcc/loop-iv.c:2387
0x105ab30b check_simple_exit
../../gcc/gcc/loop-iv.c:2950
0x105ab30b find_simple_exit(loop*, niter_desc*)
../../gcc/gcc/loop-iv.c:2975
0x105ac97f get_simple_loop_desc(loop*)
../../gcc/gcc/loop-iv.c:3056
0x10d8e99f doloop_optimize
../../gcc/gcc/loop-doloop.c:617
0x10d8e99f doloop_optimize_loops()
../../gcc/gcc/loop-doloop.c:745
0x1059f253 execute
../../gcc/gcc/loop-init.c:643
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.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #15) Created attachment 33691 [details] a possible patch The previous patch was buggy, it always generated a PR toggle sequence, even if a mode should be set directly. I've tested the patch, there are some new failures: -m4 -mb: FAIL: g++.dg/torture/type-generic-1.C -O0 execution test FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -O0 FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -Og -g FAIL: gcc.c-torture/execute/complex-6.c -O0 execution test FAIL: gcc.c-torture/execute/gofast.c -O0 execution test FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -Og -g FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/mzero3.c execution, -O0 FAIL: gcc.dg/torture/type-generic-1.c -O0 execution test -m4 -ml: FAIL: g++.dg/torture/type-generic-1.C -O0 execution test FAIL: g++.dg/torture/type-generic-1.C -O1 execution test FAIL: g++.dg/torture/type-generic-1.C -O2 execution test FAIL: g++.dg/torture/type-generic-1.C -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: g++.dg/torture/type-generic-1.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: g++.dg/torture/type-generic-1.C -O3 -fomit-frame-pointer execution test FAIL: g++.dg/torture/type-generic-1.C -O3 -g execution test FAIL: g++.dg/torture/type-generic-1.C -Os execution test FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -O0 FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -Og -g FAIL: gcc.c-torture/execute/complex-6.c -O0 execution test FAIL: gcc.c-torture/execute/conversion.c -O0 execution test FAIL: gcc.c-torture/execute/gofast.c -O0 execution test FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -Og -g FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O0 FAIL: gcc.c-torture/execute/ieee/mzero3.c execution, -O0 FAIL: gcc.dg/pr28796-2.c execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O0 execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O1 execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -O3 -g execution test FAIL: gcc.dg/torture/fp-int-convert-float.c -Os execution test FAIL: gcc.dg/torture/type-generic-1.c -O0 execution test FAIL: gcc.dg/torture/type-generic-1.c -O1 execution test FAIL: gcc.dg/torture/type-generic-1.c -O2 execution test FAIL: gcc.dg/torture/type-generic-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/type-generic-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/type-generic-1.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/type-generic-1.c -O3 -g execution test FAIL: gcc.dg/torture/type-generic-1.c -Os execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O0 execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O1 execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O2 execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -g execution test FAIL: gcc.dg/torture/vec-cvt-1.c -Os execution test
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #19 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #18) (In reply to Oleg Endo from comment #15) Created attachment 33691 [details] a possible patch The previous patch was buggy, it always generated a PR toggle sequence, even if a mode should be set directly. I've tested the patch, there are some new failures: ... No I didn't. That was a patch for PR 63260. Sorry for the noise.
[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #0)
Created attachment 33490 [details]
Proposed patch
The fabs and fneg insns do not require an FPSCR.PR or FPSCR.SZ mode setting
as they operate on the high part of a double register pair. Thus they are
the same for single and double precision
I've tested the proposed patch on sh-sim, there are some new failures:
-m4 -mb:
FAIL: g++.dg/torture/type-generic-1.C -O0 execution test
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -O0
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -Og -g
FAIL: gcc.c-torture/execute/complex-6.c -O0 execution test
FAIL: gcc.c-torture/execute/gofast.c -O0 execution test
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O1
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -Og -g
FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/mzero3.c execution, -O0
FAIL: gcc.dg/torture/type-generic-1.c -O0 execution test
-m4 -ml:
FAIL: g++.dg/torture/type-generic-1.C -O0 execution test
FAIL: g++.dg/torture/type-generic-1.C -O1 execution test
FAIL: g++.dg/torture/type-generic-1.C -O2 execution test
FAIL: g++.dg/torture/type-generic-1.C -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: g++.dg/torture/type-generic-1.C -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: g++.dg/torture/type-generic-1.C -O3 -fomit-frame-pointer execution
test
FAIL: g++.dg/torture/type-generic-1.C -O3 -g execution test
FAIL: g++.dg/torture/type-generic-1.C -Os execution test
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -O0
FAIL: gcc.c-torture/execute/builtins/complex-1.c execution, -Og -g
FAIL: gcc.c-torture/execute/complex-6.c -O0 execution test
FAIL: gcc.c-torture/execute/conversion.c -O0 execution test
FAIL: gcc.c-torture/execute/gofast.c -O0 execution test
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O1
FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -Og -g
FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O0
FAIL: gcc.c-torture/execute/ieee/mzero3.c execution, -O0
FAIL: gcc.dg/pr28796-2.c execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O0 execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O1 execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O3 -fomit-frame-pointer
execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -O3 -g execution test
FAIL: gcc.dg/torture/fp-int-convert-float.c -Os execution test
FAIL: gcc.dg/torture/type-generic-1.c -O0 execution test
FAIL: gcc.dg/torture/type-generic-1.c -O1 execution test
FAIL: gcc.dg/torture/type-generic-1.c -O2 execution test
FAIL: gcc.dg/torture/type-generic-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.dg/torture/type-generic-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/type-generic-1.c -O3 -fomit-frame-pointer execution
test
FAIL: gcc.dg/torture/type-generic-1.c -O3 -g execution test
FAIL: gcc.dg/torture/type-generic-1.c -Os execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O0 execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O1 execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O2 execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -O3 -g execution test
FAIL: gcc.dg/torture/vec-cvt-1.c -Os execution test
This seems to be due to the implementation in GDB.
sim/sh/interp.c:
#define FP_UNARY(n, OP) \
{ \
if (FPSCR_PR) \
{ \
if ((n)
[Bug c++/60664] bool / out of range int comparison warning failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664
--- Comment #3 from David Binderman dcb314 at hotmail dot com ---
(In reply to David Binderman from comment #0)
I've just built gcc trunk with clang and it looks as if producing
a similar warning to clang will flush out five bugs in gcc trunk.
Five is now one.
$ fgrep Wtautological-constant-out-of-range-compare mk.out
../../src/trunk/gcc/expr.c:5230:9: warning: comparison of constant -1 with
expression of type 'unsigned int' is always false
[-Wtautological-constant-out-of-range-compare]
$
if (!SUBREG_CHECK_PROMOTED_SIGN (target,
TYPE_UNSIGNED (TREE_TYPE (exp
{
However, for a build of most of Redhat Linux with clang, there are
about 460 occurrences of this warning, so it still looks to be of
value for the wider world.
[Bug c++/63419] verify_gimple failed: vector CONSTRUCTOR element is not a GIMPLE value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Oct 13 07:58:05 2014 New Revision: 216138 URL: https://gcc.gnu.org/viewcvs?rev=216138root=gccview=rev Log: 2014-10-13 Richard Biener rguent...@suse.de PR tree-optimization/63419 * gimple-fold.h (gimple_convert): New function. * gimple-fold.c (gimple_convert): Likewise. * tree-ssa-pre.c (create_expression_by_pieces): Use gimple_convert to split out required conversions early. * g++.dg/torture/pr63419.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr63419.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug c++/63419] verify_gimple failed: vector CONSTRUCTOR element is not a GIMPLE value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/63521] New: The AArch64 backend doesn't define REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521 Bug ID: 63521 Summary: The AArch64 backend doesn't define REG_ALLOC_ORDER. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org Andrew Pinski reported that we have not defined REG_ALLOC_ORDER for the AArch64 backend. It would be useful during spill cost computations for this to be defined appropriately
[Bug target/63521] The AArch64 backend doesn't define REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||aarch64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-13 Ever confirmed|0 |1
[Bug target/63521] The AArch64 backend doesn't define REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- This corresponds to ticket 4402 in the ARM database.
[Bug ada/63225] ada bootstrap failure when -fno-inline in STAGE1_CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63225 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Oct 13 08:19:45 2014 New Revision: 216139 URL: https://gcc.gnu.org/viewcvs?rev=216139root=gccview=rev Log: PR ada/63225 * uintp.adb (Vector_To_Uint): Move from here to... * uintp.ads (UI_Vector): Make public. (Vector_To_Uint): ...here. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/uintp.adb trunk/gcc/ada/uintp.ads
[Bug ada/63225] ada bootstrap failure when -fno-inline in STAGE1_CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63225 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Oct 13 08:20:30 2014 New Revision: 216140 URL: https://gcc.gnu.org/viewcvs?rev=216140root=gccview=rev Log: PR ada/63225 * uintp.adb (Vector_To_Uint): Move from here to... * uintp.ads (UI_Vector): Make public. (Vector_To_Uint): ...here. Modified: branches/gcc-4_9-branch/gcc/ada/ChangeLog branches/gcc-4_9-branch/gcc/ada/uintp.adb branches/gcc-4_9-branch/gcc/ada/uintp.ads
[Bug ada/63225] ada bootstrap failure when -fno-inline in STAGE1_CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63225 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Oct 13 08:21:19 2014 New Revision: 216141 URL: https://gcc.gnu.org/viewcvs?rev=216141root=gccview=rev Log: PR ada/63225 * uintp.adb (Vector_To_Uint): Move from here to... * uintp.ads (UI_Vector): Make public. (Vector_To_Uint): ...here. Modified: branches/gcc-4_8-branch/gcc/ada/ChangeLog branches/gcc-4_8-branch/gcc/ada/uintp.adb branches/gcc-4_8-branch/gcc/ada/uintp.ads
[Bug ada/63225] ada bootstrap failure when -fno-inline in STAGE1_CFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63225 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.4 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem and providing a fix.
[Bug c++/62127] [5 Regression] ICE with VLA in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine
[Bug c++/60664] bool / out of range int comparison warning failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Binderman from comment #3)
$ fgrep Wtautological-constant-out-of-range-compare mk.out
../../src/trunk/gcc/expr.c:5230:9: warning: comparison of constant -1 with
expression of type 'unsigned int' is always false
[-Wtautological-constant-out-of-range-compare]
$
if (!SUBREG_CHECK_PROMOTED_SIGN (target,
TYPE_UNSIGNED (TREE_TYPE (exp
{
Actually, recent gcc/g++ both warn for your testcase in comment #1:
/home/manuel/test.c:7:12: warning: comparison of constant ‘2’ with boolean
expression is always false [-Wbool-compare]
if (f(a) == 2)
^
David, would you mind testing with a recent revision? In those cases where
Clang warns and GCC doesn't, could you figure out a minimal testcase? Thanks!
[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) X is always false [-Werror=strict-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63496 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Yep, the second offset was meant to be tci-offset. I am testing the fix.
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33695 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33695action=edit Patch that looks into non-canonical VALUEs for AND addresses Patch in testing. This patch solves gfortran failures. The patch looks into non-canonical memory RTXes for possible AND addresses.
[Bug c++/60664] bool / out of range int comparison warning failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664 --- Comment #5 from David Binderman dcb314 at hotmail dot com --- (In reply to Manuel López-Ibáñez from comment #4) David, would you mind testing with a recent revision? In those cases where Clang warns and GCC doesn't, could you figure out a minimal testcase? Thanks! I tested with gcc trunk revision 216125. All seems ok and so no testcase needed. This looks fixed to me, with the possible exception of the remaining warning in gcc trunk source code.
[Bug c++/62127] [5 Regression] ICE with VLA in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
Uff, this is caused by a pasto where I forget to remap TREE_TYPE of array.
Index: tree-inline.c
===
--- tree-inline.c (revision 216141)
+++ tree-inline.c (working copy)
@@ -496,6 +496,8 @@ remap_type_1 (tree type, copy_body_data
if (TYPE_MAIN_VARIANT (new_tree) != new_tree
TREE_TYPE (type) == TREE_TYPE (TYPE_MAIN_VARIANT (type)))
TREE_TYPE (new_tree) = TREE_TYPE (TYPE_MAIN_VARIANT (new_tree));
+ else
+ TREE_TYPE (new_tree) = remap_type (TREE_TYPE (new_tree), id);
if (TYPE_MAIN_VARIANT (new_tree) != new_tree)
{
[Bug c++/60664] bool / out of range int comparison warning failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Binderman from comment #5) This looks fixed to me, with the possible exception of the remaining warning in gcc trunk source code. I think it is a different warning for which clang uses the same switch (-Wbool-compare only warns about boolean expressions). It is also not obvious that there is a bug there. Perhaps it is a false positive by Clang.
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am testing the following
Index: tree.c
===
--- tree.c (revision 216141)
+++ tree.c (working copy)
@@ -863,12 +863,12 @@ build_cplus_array_type (tree elt_type, t
{
t = build_min_array_type (elt_type, index_type);
set_array_type_canon (t, elt_type, index_type);
- if (!dependent)
- layout_type (t);
TYPE_MAIN_VARIANT (t) = m;
TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
TYPE_NEXT_VARIANT (m) = t;
+ if (!dependent)
+ layout_type (t);
}
}
the problem here is that calling layout_type before linking variants makes it
to biuld separate (but equivalent) experessions representing size/size_unit for
the variant. The assert in tree-inline check that type and its variants have
same sizes that should always be true.
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- It seems that C++ FE do not produce any assembler name for b (because it is not instantiated?). (gdb) p debug_tree (node-decl) var_decl 0x76ae4bd0 b type integer_type 0x76adb690 int public type_6 SI size integer_cst 0x76af9048 constant 32 unit size integer_cst 0x76af9060 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76adb690 precision 32 min integer_cst 0x76af9000 -2147483648 max integer_cst 0x76af9018 2147483647 pointer_to_this pointer_type 0x76afd738 public private static tree_0 external tls-local-dynamic decl_3 decl_6 SI file bug.cc line 4 col 23 size integer_cst 0x76af9048 32 unit size integer_cst 0x76af9060 4 align 32 context record_type 0x76c472a0 A template-info 0x76c443a0 chain type_decl 0x76c354c0 A In such case b should never land the symbol table. I am looking into why the node is created.
[Bug libstdc++/61347] std::distance(list.first(),list.end()) in O(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Mon Oct 13 10:00:27 2014 New Revision: 216142 URL: https://gcc.gnu.org/viewcvs?rev=216142root=gccview=rev Log: 2014-10-13 Marc Glisse marc.gli...@inria.fr PR libstdc++/61347 PR libstdc++/63345 * include/bits/list.tcc (_List_base::_M_clear()): Delay cast so it isn't done for the sentinel. * include/bits/stl_list.h (_List_base::_M_size): Move... (_List_base::_List_impl::_M_node): ... here. (_List_base::_M_get_size(), _List_base::_M_set_size(size_t), _List_base::_M_inc_size(size_t), _List_base::_M_dec_size(size_t), _List_base::_M_node_count): Adapt to the move. * 23_containers/list/requirements/dr438/assign_neg.cc: Update line number. * 23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * 23_containers/list/requirements/dr438/constructor_2_neg.cc: Likewise. * 23_containers/list/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Mon Oct 13 10:00:27 2014 New Revision: 216142 URL: https://gcc.gnu.org/viewcvs?rev=216142root=gccview=rev Log: 2014-10-13 Marc Glisse marc.gli...@inria.fr PR libstdc++/61347 PR libstdc++/63345 * include/bits/list.tcc (_List_base::_M_clear()): Delay cast so it isn't done for the sentinel. * include/bits/stl_list.h (_List_base::_M_size): Move... (_List_base::_List_impl::_M_node): ... here. (_List_base::_M_get_size(), _List_base::_M_set_size(size_t), _List_base::_M_inc_size(size_t), _List_base::_M_dec_size(size_t), _List_base::_M_node_count): Adapt to the move. * 23_containers/list/requirements/dr438/assign_neg.cc: Update line number. * 23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * 23_containers/list/requirements/dr438/constructor_2_neg.cc: Likewise. * 23_containers/list/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc
[Bug c++/63506] GCC deduces wrong return type of operator*() inside template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506
--- Comment #5 from Steffen Müthing steffen.muething at iwr dot
uni-heidelberg.de ---
The exact same problem is present on operator[] :
//---
struct proxy {};
struct iterator
{
proxy operator*() { return proxy(); }
proxy operator[](int i) { return proxy(); }
};
//#define DEACTIVATE
#ifndef DEACTIVATE
templatetypename T = int
#endif
void foo(iterator it)
{
auto x = *it;
auto y = it[1];
}
int main()
{
iterator it;
foo(it);
}
//---
[Bug c++/63522] New: [4.8/4.9/5.0] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522
Bug ID: 63522
Summary: [4.8/4.9/5.0] ICE: unexpected expression
'ElementIndices' of kind template_parm_index
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 33696
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33696action=edit
Minimal testcase
Attempting to compile the minimal testcase produces internal compiler error:
unexpected expression 'ElementIndices' of kind template_parm_index. I have
tried the following versions:
$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20141009 (experimental)
$ g++ --version
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
$ g++-4.9
g++-4.9 (GCC) 4.9.0
Program fragment:
template typename... struct tuple;
template typename... void slice();
template int Index, typename... using slice_result = decltype(sliceIndex);
template typename Tuple, typename... Tuples, int... ElementIndices,
typename =
typename tupleslice_resultElementIndices, Tuples...,
slice_resultElementIndices, Tuples..::type
void zip_with(Tuple...);
decltype(zip_with(0))
Here is the full invocation and error using the snapshot of trunk:
$ g++-trunk -std=c++11 main.cpp
main.cpp: In substitution of 'templateint Index, class ... using slice_result
= decltype (sliceIndex) [with int Index = ElementIndices;
template-parameter-1-2 = {}]':
main.cpp:5:11: required by substitution of 'templateclass Tuple, class ...
Tuples, int ...ElementIndices, class void zip_with(Tuple, ...) [with Tuple =
int; Tuples = {}; int ...ElementIndices = {}; template-parameter-1-4 =
missing]'
main.cpp:9:20: required from here
main.cpp:5:11: internal compiler error: unexpected expression 'ElementIndices'
of kind template_parm_index
typename =
^
0x6755a7 cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:10050
0x676de6 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:10070
0x5dd190 convert_nontype_argument
../../gcc/gcc/cp/pt.c:5759
0x5dd190 convert_template_argument
../../gcc/gcc/cp/pt.c:6657
0x5deb5c coerce_template_parms
../../gcc/gcc/cp/pt.c:7081
0x5daa28 coerce_innermost_template_parms
../../gcc/gcc/cp/pt.c:7165
0x5daa28 instantiate_alias_template
../../gcc/gcc/cp/pt.c:15909
0x5daa28 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11723
0x5de392 tsubst_template_args
../../gcc/gcc/cp/pt.c:10123
0x5de58f tsubst_template_args
../../gcc/gcc/cp/pt.c:10105
0x5e09d0 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10320
0x5da0cf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12299
0x5e4125 type_unification_real
../../gcc/gcc/cp/pt.c:16841
0x5e741f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16177
0x5a5ca8 add_template_candidate_real
../../gcc/gcc/cp/call.c:3025
0x5a6371 add_template_candidate
../../gcc/gcc/cp/call.c:3122
0x5a6371 add_candidates
../../gcc/gcc/cp/call.c:5253
0x5a797d perform_overload_resolution
../../gcc/gcc/cp/call.c:3971
0x5a93ea build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4048
0x66ce39 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2368
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.
[Bug c++/11685] typeinfo is not demangled in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11685 Kohei Takahashi flast at flast dot jp changed: What|Removed |Added CC||flast at flast dot jp --- Comment #9 from Kohei Takahashi flast at flast dot jp --- In GCC 4.8.3, we get following error. $ g++ foo.cpp foo.cpp:4:50: error: call to non-constexpr function ‘int get_uuidof(const std::type_info)’ template class T ,int i = get_uuidof( typeid(T) ) ^ foo.cpp:8:19: note: in template argument for type ‘int’ template TBoazint; ^ foo.cpp:8:20: error: expected unqualified-id before ‘;’ token template TBoazint; So, we can simply close this issue, can't we?
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||emsr at gcc dot gnu.org --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Issue 4) started with r215752.
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 Ilya Palachev i.palachev at samsung dot com changed: What|Removed |Added CC||i.palachev at samsung dot com --- Comment #1 from Ilya Palachev i.palachev at samsung dot com --- The error happens for the following sequence of commands g++ test.cpp -c -o test.o -fsanitize=address -flto g++ test.o -o test -Wl,-flto And does not happen for the following sequence of commands: g++ test.cpp -c -o test.o -fsanitize=address -flto g++ test.o -o test -Wl,-flto -fsanitize=address The ICE happens because sanitizer builtins are not initialized (returned tree is null). I've tried to force their initialization as follows: diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c index bc53632..f5ca849 100644 --- a/gcc/lto/lto.c +++ b/gcc/lto/lto.c @@ -55,6 +55,7 @@ along with GCC; see the file COPYING3. If not see #include ipa-inline.h #include params.h #include ipa-utils.h +#include asan.h /* Number of parallel tasks to run, -1 if we want to use GNU Make jobserver. */ @@ -1856,6 +1857,9 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data, data_in = lto_data_in_create (decl_data, (const char *) data + string_offset, header-string_size, resolutions); + /* Initialize sanitizer builtins if necessary. */ + initialize_sanitizer_builtins(); + /* We do not uniquify the pre-loaded cache entries, those are middle-end internal types that should not be merged. */ But after applying this patch the following error happens during the 2nd command: g++ test.o -o test -Wl,-flto /tmp/ccEhycoY.ltrans0.ltrans.o:ccEhycoY.ltrans0.o:function __static_initialization_and_destruction_0(int, int): error: undefined reference to '__asan_before_dynamic_init' /tmp/ccEhycoY.ltrans0.ltrans.o:ccEhycoY.ltrans0.o:function __static_initialization_and_destruction_0(int, int): error: undefined reference to '__asan_after_dynamic_init' collect2: error: ld returned 1 exit status
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||jason at redhat dot com --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Jason, the problem here is that grokdeclaratol call set_decl_tls_model on variable that is uninstantiated template. #0 varpool_node::create_empty () at ../../gcc/varpool.c:140 #1 0x011c78d7 in varpool_node::get_create (decl=0x76ae4bd0) at ../../gcc/varpool.c:154 #2 0x0114d09d in set_decl_tls_model (node=0x76ae4bd0, model=TLS_MODEL_INITIAL_EXEC) at ../../gcc/tree.c:678 #3 0x006abe02 in grokdeclarator (declarator=0x20fe5b0, declspecs=0x7fffe400, decl_context=FIELD, initialized=0, attrlist=0x7fffe370) at ../../gcc/cp/decl.c:10771 #4 0x0077d728 in grokfield (declarator=0x20fe5b0, declspecs=0x7fffe400, init=0x0, init_const_expr_p=true, asmspec_tree=0x0, attrlist=0x0) at ../../gcc/cp/decl2.c:864 #5 0x007c895d in cp_parser_member_declaration (parser=0x76c46000) at ../../gcc/cp/parser.c:20881 #6 0x007c7d2f in cp_parser_member_specification_opt (parser=0x76c46000) at ../../gcc/cp/parser.c:20431 #7 0x007c5b18 in cp_parser_class_specifier_1 (parser=0x76c46000) at ../../gcc/cp/parser.c:19623 #8 0x007c67cb in cp_parser_class_specifier (parser=0x76c46000) at ../../gcc/cp/parser.c:19859 #9 0x007bc5ba in cp_parser_type_specifier (parser=0x76c46000, flags=1, decl_specs=0x7fffe7d0, is_declaration=true, declares_class_or_enum=0x7fffe754, is_cv_qualifier=0x7fffe753) at ../../gcc/cp/parser.c:14532 #10 0x007b83b9 in cp_parser_decl_specifier_seq (parser=0x76c46000, flags=1, decl_specs=0x7fffe7d0, declares_class_or_enum=0x7fffe85c) at ../../gcc/cp/parser.c:11774 #11 0x007cd17a in cp_parser_single_declaration (parser=0x76c46000, checks=0x0, member_p=false, explicit_specialization_p=false, friend_p=0x7fffe89f) at ../../gcc/cp/parser.c:23510 #12 0x007cc91a in cp_parser_template_declaration_after_export (parser=0x76c46000, member_p=false) at ../../gcc/cp/parser.c:23379 #13 0x007ba20a in cp_parser_template_declaration (parser=0x76c46000, member_p=false) at ../../gcc/cp/parser.c:13069 #14 0x007b7643 in cp_parser_declaration (parser=0x76c46000) at ../../gcc/cp/parser.c:11166 #15 0x007b738c in cp_parser_declaration_seq_opt (parser=0x76c46000) at ../../gcc/cp/parser.c:11096 #16 0x007aaf90 in cp_parser_translation_unit (parser=0x76c46000) at ../../gcc/cp/parser.c:4059 this triggers creation of symbol node for it that is not correct, because uninstatiated var decls do not correspond to any variables. I guess similar case may be triggered by section attribute. I wonder if there is resonably easy way to avoid setting these properties on DECLs that are not real variables/functions. Other alternative would be to arrange symtab_node::real_symbol_p to return false on those and make them to bypass assembler name hash. Is there a way to recognize them from a middle-end? Honza
[Bug c++/11685] typeinfo is not demangled in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11685 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Kohei Takahashi from comment #9) So, we can simply close this issue, can't we? I think so. Thanks for noticing!
[Bug target/63521] The AArch64 backend doesn't define REG_ALLOC_ORDER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Ideally, a port should not need to define reg_alloc_order; it's rather a blunt instrument. Better would be for the register allocator to have a better understanding of which registers are being used for parameter passing in the current routine so that it can pick from the remaining call-clobbered list.
[Bug bootstrap/63523] New: [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523
Bug ID: 63523
Summary: [5.0 regression] gcc/cp/pt.c -Werror=format breaks
bootstrap on sparc-linux
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: mikpelinux at gmail dot com
Attempting to bootstrap gcc-5-20141012 on sparc-linux (sparc64 w/ --build and
--target overridden) fails with:
/mnt/scratch/objdir50/./prev-gcc/xg++ -B/mnt/scratch/objdir50/./prev-gcc/
-B/mnt/scratch/install50/sparc-unknown-linux/bin/ -nostdinc++
-B/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/src/.libs
-B/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/libsupc++/.libs
-I/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/include/sparc-unknown-linux
-I/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/include
-I/mnt/scratch/gcc-5-20141012/libstdc++-v3/libsupc++
-L/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/src/.libs
-L/mnt/scratch/objdir50/prev-sparc-unknown-linux/libstdc++-v3/libsupc++/.libs
-c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-DHAVE_CONFIG_H -I. -Icp -I/mnt/scratch/gcc-5-20141012/gcc
-I/mnt/scratch/gcc-5-20141012/gcc/cp
-I/mnt/scratch/gcc-5-20141012/gcc/../include
-I/mnt/scratch/gcc-5-20141012/gcc/../libcpp/include
-I/home/mikpe/pkgs/linux-sparc64/gmp-5.1.3/include
-I/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.2/include
-I/home/mikpe/pkgs/linux-sparc64/mpc-1.0.2/include
-I/mnt/scratch/gcc-5-20141012/gcc/../libdecnumber
-I/mnt/scratch/gcc-5-20141012/gcc/../libdecnumber/dpd -I../libdecnumber
-I/mnt/scratch/gcc-5-20141012/gcc/../libbacktrace-o cp/pt.o -MT cp/pt.o
-MMD -MP -MF cp/.deps/pt.TPo /mnt/scratch/gcc-5-20141012/gcc/cp/pt.c
/mnt/scratch/gcc-5-20141012/gcc/cp/pt.c: In function 'void
print_template_statistics()':
/mnt/scratch/gcc-5-20141012/gcc/cp/pt.c:22329:40: error: format '%ld' expects
argument of type 'long int', but argument 3 has type 'size_t {aka unsigned
int}' [-Werror=format=]
decl_specializations-collisions ());
^
/mnt/scratch/gcc-5-20141012/gcc/cp/pt.c:22329:40: error: format '%ld' expects
argument of type 'long int', but argument 4 has type 'size_t {aka unsigned
int}' [-Werror=format=]
/mnt/scratch/gcc-5-20141012/gcc/cp/pt.c:22333:40: error: format '%ld' expects
argument of type 'long int', but argument 3 has type 'size_t {aka unsigned
int}' [-Werror=format=]
type_specializations-collisions ());
^
/mnt/scratch/gcc-5-20141012/gcc/cp/pt.c:22333:40: error: format '%ld' expects
argument of type 'long int', but argument 4 has type 'size_t {aka unsigned
int}' [-Werror=format=]
cc1plus: all warnings being treated as errors
make[3]: *** [cp/pt.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir50/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir50'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir50'
make: *** [bootstrap] Error 2
The previous weekly snapshot, gcc-5-20141005, bootstrapped fine.
Configuration options:
/mnt/scratch/gcc-5-20141012/configure --prefix=/mnt/scratch/install50
--with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.1.3
--with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.2
--with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.2 --enable-multilib
--disable-plugin --disable-lto --disable-nls --enable-threads=posix
--enable-checking=release --disable-libmudflap
--enable-languages=c,ada,c++,fortran --build=sparc-unknown-linux
--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all
--disable-libsanitizer
[Bug bootstrap/63523] [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- Also on i686
[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) X is always false [-Werror=strict-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63496 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Mon Oct 13 12:44:00 2014 New Revision: 216146 URL: https://gcc.gnu.org/viewcvs?rev=216146root=gccview=rev Log: PR bootstrap/63496 * ipa-polymorphic-call.c (extr_type_from_vtbl_ptr_store): Fix pasto. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-polymorphic-call.c
[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #2) Kaz, could you please add the proposed patch to your test run and let me know of the result? I'd like to sort this out before proceeding with PR 53513. I've just run make -k check-gcc with the patch on my environment and got no new failures.
[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #3) I've just run make -k check-gcc with the patch on my environment and got no new failures. Great. Thanks! I'll try patching GDB sh-sim and check again. If the failures on my side go away after that, I'll commit the patch from comment #2, OK?
[Bug bootstrap/63523] [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/60664] bool / out of range int comparison warning failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from David Binderman dcb314 at hotmail dot com --- (In reply to Manuel López-Ibáñez from comment #6) I think it is a different warning for which clang uses the same switch (-Wbool-compare only warns about boolean expressions). It is also not obvious that there is a bug there. Perhaps it is a false positive by Clang. I looked into this and the definition of SUBREG_CHECK_PROMOTED_SIGN around line 2200 of gcc/rtl.h seems important. #define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN) \ ((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER \ : (SIGN) == SRP_SIGNED ? SUBREG_PROMOTED_SIGNED_P (RTX)\ : SUBREG_PROMOTED_UNSIGNED_P (RTX)) Leaving aside the side issue of ? : being right associative, so some () would help clarify, I notice that const int SRP_POINTER = -1; const int SRP_SIGNED = 0; const int SRP_UNSIGNED = 1; const int SRP_SIGNED_AND_UNSIGNED = 2; so it looks as if this bitfield unsigned unsigned_flag : 1; is being compared to SRP_POINTER. One possible fix might be to change the value of SRP_POINTER to 3 and see if the problem goes away. Clang certainly seems to be finding a problem, AFAIK.
[Bug fortran/63514] functions containing volatile are considered pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-13 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The fortran frontend must do sth wrong here - it seems to mark the function pure itself and either fold or the FE even does the optimization (look at the .original dump).
[Bug tree-optimization/63512] [5 Regression] ICE: error: virtual use of statement not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63512 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/60664] comparison of constant SPR_POINTER with unsigned_flag is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60664 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords|diagnostic | Component|c++ |rtl-optimization Summary|bool / out of range int |comparison of constant |comparison warning failure |SPR_POINTER with ||unsigned_flag is always ||false --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Binderman from comment #7) #define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN) \ ((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER \ : (SIGN) == SRP_SIGNED ? SUBREG_PROMOTED_SIGNED_P (RTX)\ : SUBREG_PROMOTED_UNSIGNED_P (RTX)) Leaving aside the side issue of ? : being right associative, so some () would help clarify, I notice that const int SRP_POINTER = -1; const int SRP_SIGNED = 0; const int SRP_UNSIGNED = 1; const int SRP_SIGNED_AND_UNSIGNED = 2; so it looks as if this bitfield unsigned unsigned_flag : 1; is being compared to SRP_POINTER. One possible fix might be to change the value of SRP_POINTER to 3 and see if the problem goes away. Clang certainly seems to be finding a problem, AFAIK. It seems to me that independently of the value of SRP_POINTER, the result will be always false. Thus, I don't see the bug. In any case, someone else would need to decide whether this is actually a bug or not. RTL is not my expertise.
[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) X is always false [-Werror=strict-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63496 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63260 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #4) If the failures on my side go away after that, I'll commit the patch from comment #2, OK? Please go ahead.
[Bug libstdc++/57350] std::align missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Oct 13 14:08:44 2014 New Revision: 216149 URL: https://gcc.gnu.org/viewcvs?rev=216149root=gccview=rev Log: PR libstdc++/57350 * include/std/memory (align): Do not adjust correctly aligned address. * testsuite/20_util/align/2.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/align/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/memory
[Bug libstdc++/57350] std::align missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk.
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-13 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- We need example code showing the problem you want to check for.
[Bug libstdc++/56109] Add light-weight ABI-compatible debug checks to standard containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed. c.f. https://gcc.gnu.org/ml/libstdc++/2014-06/msg00105.html
[Bug tree-optimization/63379] [4.8 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 clyon at gcc dot gnu.org changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from clyon at gcc dot gnu.org --- After this commit, I've noticed that this new test appears as FAIL on target aarch64_be-none-linux-gnu. My gcc.log shows: PASS: gcc.dg/vect/pr63379.c (test for excess errors) *** EXIT code 4242 emu: host signal 6 FAIL: gcc.dg/vect/pr63379.c execution test I'm using qemu as execution engine.
[Bug libstdc++/63524] New: FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63524 Bug ID: 63524 Summary: FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat .cc (test for excess errors) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src -L/t est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu/gcc/gcc-5.0 /hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/ gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -g -O2 -DLO CALEDIR=. -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib stdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util / test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc -std=gnu++11 ./libtestc++.a -lm -o ./hexfloat.exe In file included from /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/cassert:43:0, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_hooks.h:58, from /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostre am/inserters_arithmetic/char/hexfloat.cc:26:/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmeti c/char/hexfloat.cc: In function 'void test01()': /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:51:17: error: 'stod' is not a member of 'std' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:51:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:60:17: error: 'stod' is not a member of 'std' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:60:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:80:17: error: 'stod' is not a member of 'std' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:80:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:86:17: error: 'stod' is not a member of 'std' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:86:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stod(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc: In function 'void test02()': /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:107:17: error: 'stold' is not a member of 'std' VERIFY( os std::stold(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:107:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stold(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:113:17: error: 'stold' is not a member of 'std' VERIFY( os std::stold(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:113:3: note: in expansion of macro 'VERIFY' VERIFY( os std::stold(os.str()) == d ); ^ /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:130:17: error: 'stold' is not a member of 'std' VERIFY( os std::stold(os.str()) == d ); ^
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug target/53513] [SH] Add support for fschg and fpchg insns and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 --- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #19) No I didn't. That was a patch for PR 63260. Sorry for the noise. Now I have. For both '-m4 -ml' and '-m4 -mb' there are a few new failures: FAIL: gcc.dg/attr-isr.c scan-assembler-times [^f]r[0-9][ \t]*, 8 (SH specific test 'gcc.dg/attr-isr.c' should be moved to 'gcc.target/sh') FAIL: gcc.target/sh/attr-isr-nosave_low_regs.c scan-assembler-not [^f]r1[,0-3] FAIL: gcc.target/sh/attr-isr-nosave_low_regs.c scan-assembler-not [^f]r[0-9][ \t]*, FAIL: gcc.target/sh/attr-isr-trapa.c scan-assembler-not r1[,0-3] FAIL: gcc.target/sh/pr54680.c scan-assembler-times lds\t 6 FAIL: gcc.target/sh/pragma-isr-nosave_low_regs.c scan-assembler-not [^f]r1[,0-3] FAIL: gcc.target/sh/pragma-isr-nosave_low_regs.c scan-assembler-not [^f]r[0-9][ \t]*, FAIL: gcc.target/sh/pragma-isr-trapa.c scan-assembler-not r1[,0-3] FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-not r1[,0-3] FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-times [^_]fpscr 3 FAIL: gcc.target/sh/pragma-isr-trapa2.c scan-assembler-times r[0-7]\n 3 The failures seem to be related to ISR-like function handling or the tests need adjustments because they assume that fpscr is accessed in a particular way, which is now about to change. I'd like to ignore ISR function problems for now, and fix it as part of PR 57339.
[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- The standard containers don't support volatile types.
[Bug c++/62127] [5 Regression] ICE with VLA in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Mon Oct 13 14:43:24 2014 New Revision: 216150 URL: https://gcc.gnu.org/viewcvs?rev=216150root=gccview=rev Log: PR tree-optimization/62127 * g++.dg/torture/pr62127.C: New testcase. * tree.c (remap_type_1): When remapping array, remap also its type. Added: trunk/gcc/testsuite/g++.dg/torture/pr62127.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug c++/62127] [5 Regression] ICE with VLA in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug regression/62102] [5 Regression]: gcc.dg/torture/pr48953.c -O2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62102 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- Since this testcase also involves VLA, can you, please, test if the patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62127 (now in mainline) fixes the problem?
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Since r213922 pthread_create should get linked in, but apparently not pthread_join.
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-13 CC||fdumont at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- I'm pretty sure our implementation conforms to the standard, expression templates don't mix well with auto/decltype, but libc++ does seem to make code like this work somehow so it is a reasonable enhancement request.
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #1 from Jiong Wang jiwang at gcc dot gnu.org --- I noticed this also, my code base is 216144, quite new.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org --- I'd rather work on improving the warnings so we can tell the user how bad his code is, but in case, we had a similar request in GMP, a code that was inspired by libstdc++ valarray: https://gmplib.org/list-archives/gmp-bugs/2014-January/003315.html and the discussion may contain hints relevant to the valarray case.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33697 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33697action=edit gcc5-pr63464.patch WIP patch. What is missing: 1) the optimize_range_tests_to_bit_test call should be guarded by lshift_cheap_p (), Richard, any preference on where to declare that function (tree-switch-conversion.h and include that in tree-ssa-reassoc.c, somewhere else?) 2) much more importantly, it right now doesn't actually fixup the IL, so instead of the desirable jump around the shift we have there just BIT_IOR_EXPR (and the shift actually happens to be done first, before the range test). Richard, any preference how to represent it in the IL from in between the optimization and fixup once all bbs are reassociated? I've been thinking about e.g. some pass-through internal call on the TRUTH_ORIF_EXPR operand. Another option might be, if we'd adjust update_range_test, so that it would not only emit a gimplification of the range test, but also an optional gimple_seq before that, would be to push all the SSA_NAMEs that would be otherwise passed to the internal call, into some vector, and just split bb after the def stmt of those SSA_NAMEs and also before the (single, hopefully) user of that SSA_NAME, adding an edge around the middle of the bb and PHI.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #19 from Jeffrey A. Law law at redhat dot com --- Nobody ever reviewed the changes :(
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #27 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Teresa Johnson from comment #24) Arg, looks very similar so maybe another instance of the duplicate threading is slipping through? My own lto profiled bootstrap succeeded with my patch. I will try updating to r216039 and redo it to see if I can provoke the same failure. I sent you another testcase against r216150.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33698 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33698action=edit bittest.c Testcase I've been playing with.
[Bug fortran/63514] functions containing volatile are considered pure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #2) The fortran frontend must do sth wrong here - it seems to mark the function pure itself and either fold or the FE even does the optimization (look at the .original dump). yes, it certainly is a FE issue.
[Bug bootstrap/63523] [5.0 regression] gcc/cp/pt.c -Werror=format breaks bootstrap on sparc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63523 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Should be fixed by r216151.
[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #1 from lucier at math dot purdue.edu --- This bug has bitten me, too. I built and tested the current mainline with the idea that I'd try to implement the suggested fix, but this is the first time I've looked at any of the autogenerated files and I'm afraid that I have no clue what's going on. Brad
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 --- Comment #2 from Jiong Wang jiwang at gcc dot gnu.org --- Have done a quick investigation, it's caused by the implementation of TARGET_LIBGCC_CMP_RETURN_MODE aarch64_libgcc_cmp_return_mode AArch64 define the return mode to be SImode which seems broken gcc genric code when expand builtin lib call
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #33695|0 |1 is obsolete|| --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33699 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33699action=edit Updated patch
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #3) Created attachment 33699 [details] Updated patch I have started native alpha bootstrap with the above attached patch. The idea implemented the patch is as follows: - always dig into X and MEM addresses using get_addr - use this expanded address when checking for AND codes with MEM_READONLY_P operand - also use expanded address in find_base_term and base_alias_check and canon_rtx. - for canonicalized address, use original address as passed to the functions. (get_addr can still return VALUE, but in this case find_base_term returns ADDRESS RTX, and this prevents invalid detection of non-aliased condition in: /* Differing symbols not accessed via AND never alias. */ if (GET_CODE (x_base) != ADDRESS GET_CODE (y_base) != ADDRESS) return 0; ) Bootstrap and regression test went OK on x86_64.
[Bug rtl-optimization/63525] New: unnecessary reloads generated in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63525
Bug ID: 63525
Summary: unnecessary reloads generated in loop
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: vmakarov at gcc dot gnu.org
Created attachment 33700
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33700action=edit
testcase 1.cxx
For the testcase 1.cxx attached, trunk (r214579) generates an addpd with mem
operand and one extra reload insn in kernel loop. For g++ before r204274, it
generate less insns in the kernel loop.
~/workarea/gcc-r214579/build/install/bin/g++ -O2 -S 1.cxx -o 1.s
kernel loop:
.L3:
pxor%xmm0, %xmm0
cvtsi2sd%eax, %xmm0
addl$1, %eax
cmpl%edx, %eax
unpcklpd%xmm0, %xmm0
addpd -24(%rsp), %xmm0 === mem operand used
movaps %xmm0, -24(%rsp) === reload
jne .L3
~/workarea/gcc-r199418/build/install/bin/g++ -O2 -S 1.cxx -o 2.s
kernel loop:
.L3:
xorpd %xmm1, %xmm1
cvtsi2sd%eax, %xmm1
addl$1, %eax
unpcklpd%xmm1, %xmm1
addpd %xmm1, %xmm0
cmpl%edx, %eax
jne .L3
The reload insns in trunk are generated because of following steps:
With r204274, the IR after expand like this:
Loop:
...
(insn 15 14 16 5 (set (reg/v:V2DF 83 [ v ])
(plus:V2DF (reg/v:V2DF 83 [ v ])
(reg:V2DF 92 [ D.5005 ]))) 1.cxx:14 -1
(nil))
...
end Loop.
(insn 23 22 24 7 (set (reg/v:TI 90 [ tmp ])
(subreg:TI (reg/v:V2DF 83 [ v ]) 0))
/usr/local/google/home/wmi/workarea/gcc-r212442/build/install/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/include/emmintrin.h:157
-1
(nil))
(insn 24 23 25 7 (set (mem/c:DF (symbol_ref:DI (x) [flags 0x2] var_decl
0x75c6d5a0 x) [2 x+0 S8 A64])
(subreg:DF (reg/v:TI 90 [ tmp ]) 0)) 1.cxx:17 -1
(nil))
(insn 25 24 0 7 (set (mem/c:DF (symbol_ref:DI (y) [flags 0x2] var_decl
0x75c6d630 y) [2 y+0 S8 A64])
(subreg:DF (reg/v:TI 90 [ tmp ]) 8)) 1.cxx:18 -1
(nil))
forward propagation will propagate reg 90 from insn 23 to insn 24 and insn 25,
and remove subreg:TI, so we get the IR before IRA like this:
Loop:
...
(insn 15 14 16 4 (set (reg/v:V2DF 83 [ v ])
(plus:V2DF (reg/v:V2DF 83 [ v ])
(reg:V2DF 92 [ D.5005 ]))) 1.cxx:14 1263 {*addv2df3}
(expr_list:REG_DEAD (reg:V2DF 92 [ D.5005 ])
(nil)))
...
end Loop.
(insn 24 22 25 5 (set (mem/c:DF (symbol_ref:DI (x) [flags 0x2] var_decl
0x75c6d5a0 x) [2 x+0 S8 A64])
(subreg:DF (reg/v:V2DF 83 [ v ]) 0)) 1.cxx:17 128 {*movdf_internal}
(nil))
(insn 25 24 0 5 (set (mem/c:DF (symbol_ref:DI (y) [flags 0x2] var_decl
0x75c6d630 y) [2 y+0 S8 A64])
(subreg:DF (reg/v:V2DF 83 [ v ]) 8)) 1.cxx:18 128 {*movdf_internal}
(expr_list:REG_DEAD (reg/v:V2DF 83 [ v ])
(nil)))
ix86_cannot_change_mode_class doesn't allow such subreg: subreg:DF (reg/v:V2DF
83 [ v ]) 8) in insn 25, so reg 83 will be added in invalid_mode_changes by
record_subregs_of_mode and will be allocated NO_REGS regclass.
reg 83 has NO_REGS regclass while plus:V2DF requires the target operand to be
xmm register in insn 15, so reload insns are needed. The kernel loop has low
register pressure and it doesn't form a separate IRA region, so live range
splitting on region boarder doesn't kick in here.
Without r204274, IR after expand is like this:
Loop:
...
(insn 15 14 16 5 (set (reg/v:V2DF 61 [ v ])
(plus:V2DF (reg/v:V2DF 61 [ v ])
(reg:V2DF 68 [ D.4966 ]))) 1.cxx:14 -1
(nil))
...
End Loop.
(insn 25 24 26 7 (set (subreg:V2DF (reg/v:TI 66 [ tmp ]) 0)
(reg/v:V2DF 61 [ v ]))
/usr/local/google/home/wmi/workarea/gcc-r199418/build/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/emmintrin.h:147
-1
(nil))
(insn 26 25 27 7 (set (mem/c:DF (symbol_ref:DI (x) [flags 0x2] var_decl
0x75e80be0 x) [2 x+0 S8 A64])
(subreg:DF (reg/v:TI 66 [ tmp ]) 0)) 1.cxx:17 -1
(nil))
(insn 27 26 0 7 (set (mem/c:DF (symbol_ref:DI (y) [flags 0x2] var_decl
0x75e80c78 y) [2 y+0 S8 A64])
(subreg:DF (reg/v:TI 66 [ tmp ]) 8)) 1.cxx:18 -1
(nil))
Because the subreg is on the left handside of insn 25, it is impossible for
forward propagation to merge insn 25 to insn 26 and insn 27. reg 61 will not
have reference like this: subreg:DF (reg/v:V2DF 61 [ v ]) 8), so it gets SSE
regclass and will not introduce extra reload insns in kernel loop.
r204274 just enables more forward propagations and exposes the problem here.
[Bug c++/63526] New: O1 O2 O3 optimization and inline template constructor - uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526
Bug ID: 63526
Summary: O1 O2 O3 optimization and inline template constructor
- uninitialized member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eles.david.88 at gmail dot com
Created attachment 33701
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33701action=edit
Test case
It seems due to missing zero-initialization in case of inline constructor, I
got a warning for uninitialized value for the following code:
- main.cpp
#include iostream
template class T
struct Foo
{
Foo()
{}
void foo()
{std::cout _foo std::endl;}
T _foo;
};
int main()
{
Foodouble f;
f.foo();
return 0;
}
Compilation with g++ -Wall, the result:
everything is ok.
Compilation with g++ -Wall -O1, the result:
main.cpp: In function ‘int main()’:
main.cpp:10:4: warning: ‘f.Foodouble::_foo’ is used uninitialized in this
function [-Wuninitialized]
main.cpp:16:15: note: ‘f’ was declared here
I got a same result with -O2, -O3.
If the constructor is not inline, everything is ok.
It seems that due to optimization the constructor is inlined, but not in a
prepare way, it is inlined without zero-initialization.
Environment information:
--
$uname -a
Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux
$g++ --version
g++ (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 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.
---
A same behavior can be observed in older releases and distributions:
---
$uname -a
Linux rdv 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:28:30 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux
$g++ --version
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
Copyright (C) 2006 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.
---
But not in the version:
---
$g++ --version
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4)
Copyright (C) 2006 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.
---
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Mon Oct 13 17:02:35 2014 New Revision: 216152 URL: https://gcc.gnu.org/viewcvs?rev=216152root=gccview=rev Log: PR libfortran/63471 * config/pa/pa-hpux11.h (TARGET_OS_CPP_BUILTINS): Define _REENTRANT when _HPUX_SOURCE is defined. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-hpux11.h
[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Why do you think the member should be zero-initialized? Your constructor fails to initialize it.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526 --- Comment #2 from Dávid Éles eles.david.88 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) Why do you think the member should be zero-initialized? Your constructor fails to initialize it. I uses the default mechanism to initialization of members. As far as I know the C++ standard says (8.5/5): To default-initialize an object of type T means: * If T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor). * If T is an array type, each element is default-initialized. * Otherwise, the object is zero-initialized. In case of c++ it should be zero initialized if it is the member of a class/struct. As far as I know I have to force to not doing zero initialization something like that Foo* f = new Foo;
[Bug target/8340] ICE on x86 inline asm w/ -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8340 --- Comment #9 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Mon Oct 13 17:26:49 2014 New Revision: 216154 URL: https://gcc.gnu.org/viewcvs?rev=216154root=gccview=rev Log: gcc/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * config/i386/i386.c (ix86_use_pseudo_pic_reg): New. (ix86_init_pic_reg): New. (ix86_select_alt_pic_regnum): Add check on pseudo register. (ix86_save_reg): Likewise. (ix86_expand_prologue): Remove PIC register initialization now performed in ix86_init_pic_reg. (ix86_output_function_epilogue): Add check on pseudo register. (set_pic_reg_ever_alive): New. (legitimize_pic_address): Replace df_set_regs_ever_live with new set_pic_reg_ever_alive. (legitimize_tls_address): Likewise. (ix86_pic_register_p): New check. (ix86_delegitimize_address): Add check on pseudo register. (ix86_expand_call): Insert move from pseudo PIC register to ABI defined REAL_PIC_OFFSET_TABLE_REGNUM. (TARGET_INIT_PIC_REG): New. (TARGET_USE_PSEUDO_PIC_REG): New. * config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM if pic_offset_table_rtx exists. * doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG): Document. * doc/tm.texi: Regenerate. * function.c (assign_parms): Generate pseudo register for PIC. * init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC register. * ira-color.c (color_pass): Add check on pseudo register. * ira-emit.c (change_loop): Don't create copies for PIC pseudo register. * ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo register. (ira): Add target specific PIC register initialization. (do_reload): Keep PIC pseudo register. * lra-assigns.c (spill_for): Add checks on pseudo register. * lra-constraints.c (contains_symbol_ref_p): New. (lra_constraints): Enable lra risky transformations when PIC is pseudo register. * shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register. * target.def (use_pseudo_pic_reg): New. (init_pic_reg): New. gcc/testsuite/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * gcc.target/i386/pic-1.c: Remove dg-error as test should pass now. * gcc.target/i386/pr55458.c: Likewise. * gcc.target/i386/pr47602.c: New. * gcc.target/i386/pr23098.c: Move to XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/function.c trunk/gcc/init-regs.c trunk/gcc/ira-color.c trunk/gcc/ira-emit.c trunk/gcc/ira.c trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/shrink-wrap.c trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pic-1.c trunk/gcc/testsuite/gcc.target/i386/pr23098.c trunk/gcc/testsuite/gcc.target/i386/pr55458.c
[Bug rtl-optimization/55458] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458 --- Comment #4 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Mon Oct 13 17:26:49 2014 New Revision: 216154 URL: https://gcc.gnu.org/viewcvs?rev=216154root=gccview=rev Log: gcc/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * config/i386/i386.c (ix86_use_pseudo_pic_reg): New. (ix86_init_pic_reg): New. (ix86_select_alt_pic_regnum): Add check on pseudo register. (ix86_save_reg): Likewise. (ix86_expand_prologue): Remove PIC register initialization now performed in ix86_init_pic_reg. (ix86_output_function_epilogue): Add check on pseudo register. (set_pic_reg_ever_alive): New. (legitimize_pic_address): Replace df_set_regs_ever_live with new set_pic_reg_ever_alive. (legitimize_tls_address): Likewise. (ix86_pic_register_p): New check. (ix86_delegitimize_address): Add check on pseudo register. (ix86_expand_call): Insert move from pseudo PIC register to ABI defined REAL_PIC_OFFSET_TABLE_REGNUM. (TARGET_INIT_PIC_REG): New. (TARGET_USE_PSEUDO_PIC_REG): New. * config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM if pic_offset_table_rtx exists. * doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG): Document. * doc/tm.texi: Regenerate. * function.c (assign_parms): Generate pseudo register for PIC. * init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC register. * ira-color.c (color_pass): Add check on pseudo register. * ira-emit.c (change_loop): Don't create copies for PIC pseudo register. * ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo register. (ira): Add target specific PIC register initialization. (do_reload): Keep PIC pseudo register. * lra-assigns.c (spill_for): Add checks on pseudo register. * lra-constraints.c (contains_symbol_ref_p): New. (lra_constraints): Enable lra risky transformations when PIC is pseudo register. * shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register. * target.def (use_pseudo_pic_reg): New. (init_pic_reg): New. gcc/testsuite/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * gcc.target/i386/pic-1.c: Remove dg-error as test should pass now. * gcc.target/i386/pr55458.c: Likewise. * gcc.target/i386/pr47602.c: New. * gcc.target/i386/pr23098.c: Move to XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/function.c trunk/gcc/init-regs.c trunk/gcc/ira-color.c trunk/gcc/ira-emit.c trunk/gcc/ira.c trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/shrink-wrap.c trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pic-1.c trunk/gcc/testsuite/gcc.target/i386/pr23098.c trunk/gcc/testsuite/gcc.target/i386/pr55458.c
[Bug middle-end/47602] Permit inline asm to clobber PIC register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47602 --- Comment #16 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Mon Oct 13 17:26:49 2014 New Revision: 216154 URL: https://gcc.gnu.org/viewcvs?rev=216154root=gccview=rev Log: gcc/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * config/i386/i386.c (ix86_use_pseudo_pic_reg): New. (ix86_init_pic_reg): New. (ix86_select_alt_pic_regnum): Add check on pseudo register. (ix86_save_reg): Likewise. (ix86_expand_prologue): Remove PIC register initialization now performed in ix86_init_pic_reg. (ix86_output_function_epilogue): Add check on pseudo register. (set_pic_reg_ever_alive): New. (legitimize_pic_address): Replace df_set_regs_ever_live with new set_pic_reg_ever_alive. (legitimize_tls_address): Likewise. (ix86_pic_register_p): New check. (ix86_delegitimize_address): Add check on pseudo register. (ix86_expand_call): Insert move from pseudo PIC register to ABI defined REAL_PIC_OFFSET_TABLE_REGNUM. (TARGET_INIT_PIC_REG): New. (TARGET_USE_PSEUDO_PIC_REG): New. * config/i386/i386.h (PIC_OFFSET_TABLE_REGNUM): Return INVALID_REGNUM if pic_offset_table_rtx exists. * doc/tm.texi.in (TARGET_USE_PSEUDO_PIC_REG, TARGET_INIT_PIC_REG): Document. * doc/tm.texi: Regenerate. * function.c (assign_parms): Generate pseudo register for PIC. * init-regs.c (initialize_uninitialized_regs): Ignor pseudo PIC register. * ira-color.c (color_pass): Add check on pseudo register. * ira-emit.c (change_loop): Don't create copies for PIC pseudo register. * ira.c (split_live_ranges_for_shrink_wrap): Add check on pseudo register. (ira): Add target specific PIC register initialization. (do_reload): Keep PIC pseudo register. * lra-assigns.c (spill_for): Add checks on pseudo register. * lra-constraints.c (contains_symbol_ref_p): New. (lra_constraints): Enable lra risky transformations when PIC is pseudo register. * shrink-wrap.c (try_shrink_wrapping): Add check on pseudo register. * target.def (use_pseudo_pic_reg): New. (init_pic_reg): New. gcc/testsuite/ PR target/8340 PR middle-end/47602 PR rtl-optimization/55458 * gcc.target/i386/pic-1.c: Remove dg-error as test should pass now. * gcc.target/i386/pr55458.c: Likewise. * gcc.target/i386/pr47602.c: New. * gcc.target/i386/pr23098.c: Move to XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/function.c trunk/gcc/init-regs.c trunk/gcc/ira-color.c trunk/gcc/ira-emit.c trunk/gcc/ira.c trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/shrink-wrap.c trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pic-1.c trunk/gcc/testsuite/gcc.target/i386/pr23098.c trunk/gcc/testsuite/gcc.target/i386/pr55458.c
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz --- The original testcase also fails with a very different set of flags: $ gcc -Os -fno-if-conversion -fsched2-use-superblocks --param=tracer-min-branch-probability=14 20140326-1.i $ valgrind -q ./a.out ==8525== Invalid read of size 1 ==8525==at 0x40043A: main (in /home/smatz/Downloads/xx/a.out) ==8525== Address 0xfff01f9e6 is not stack'd, malloc'd or (recently) free'd ==8525== ==8525== ==8525== Process terminating with default action of signal 11 (SIGSEGV) ==8525== Access not within mapped region at address 0xFFF01F9E6 ==8525==at 0x40043A: main (in /home/smatz/Downloads/xx/a.out) ==8525== If you believe this happened as a result of a stack ==8525== overflow in your program's main thread (unlikely but ==8525== possible), you can try to increase the size of the ==8525== main thread stack using the --main-stacksize= flag. ==8525== The main thread stack size used in this run was 8388608. Segmentation fault
[Bug target/63527] New: [5 Regression] -fPIC generates more instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63527
Bug ID: 63527
Summary: [5 Regression] -fPIC generates more instructions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: evstupac at gmail dot com
Target: i686-linux
On Linux/x86, r216154 generates more instructions with -O2 -fPIC
for
struct cache_file
{
char magic[sizeof ld.so-1.7.0 - 1];
unsigned int nlibs;
};
typedef unsigned int size_t;
size_t cachesize __attribute__ ((visibility (hidden)));
struct cache_file *cache __attribute__ ((visibility (hidden)));
extern int __munmap (void *__addr, size_t __len);
void
_dl_unload_cache (void)
{
if (cache != ((void *)0) cache != (struct cache_file *) -1)
{
__munmap (cache, cachesize);
cache = ((void *)0) ;
}
}
r216153 generates
---
.text
.LHOTB0:
.p2align 4,,15
.globl_dl_unload_cache
.type_dl_unload_cache, @function
_dl_unload_cache:
pushl%ebx
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$8, %esp
movlcache@GOTOFF(%ebx), %eax
leal-1(%eax), %edx
cmpl$-3, %edx
ja.L1
subl$8, %esp
pushlcachesize@GOTOFF(%ebx)
pushl%eax
call__munmap@PLT
movl$0, cache@GOTOFF(%ebx)
addl$16, %esp
.L1:
addl$8, %esp
popl%ebx
ret
.size_dl_unload_cache, .-_dl_unload_cache
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.hiddencache
.commcache,4,4
.hiddencachesize
.commcachesize,4,4
.section
.text.__x86.get_pc_thunk.bx,axG,@progbits,__x86.get_pc_thunk.bx,comdat
.globl__x86.get_pc_thunk.bx
.hidden__x86.get_pc_thunk.bx
.type__x86.get_pc_thunk.bx, @function
__x86.get_pc_thunk.bx:
movl(%esp), %ebx
ret
---
r216154 generates
--
.text
.LHOTB0:
.p2align 4,,15
.globl_dl_unload_cache
.type_dl_unload_cache, @function
_dl_unload_cache:
pushl%esi
pushl%ebx
call__x86.get_pc_thunk.si
addl$_GLOBAL_OFFSET_TABLE_, %esi
subl$4, %esp
movlcache@GOTOFF(%esi), %eax
leal-1(%eax), %edx
cmpl$-3, %edx
ja.L1
subl$8, %esp
pushlcachesize@GOTOFF(%esi)
movl%esi, %ebx
pushl%eax
call__munmap@PLT
movl$0, cache@GOTOFF(%esi)
addl$16, %esp
.L1:
addl$4, %esp
popl%ebx
popl%esi
ret
.size_dl_unload_cache, .-_dl_unload_cache
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.hiddencache
.commcache,4,4
.hiddencachesize
.commcachesize,4,4
.section
.text.__x86.get_pc_thunk.si,axG,@progbits,__x86.get_pc_thunk.si,comdat
.globl__x86.get_pc_thunk.si
.hidden__x86.get_pc_thunk.si
.type__x86.get_pc_thunk.si, @function
__x86.get_pc_thunk.si:
movl(%esp), %esi
ret
--
Why doesn't r216154 simply use %ebx to access cache, cachesize
and __munmap?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #11 from Rainer Emrich rai...@emrich-ebersheim.de --- Dear friends this issue seems to become a never ending story. In my understanding the person causing the issue is responsible for a fix. There are several hints in this thread how to solve the issue. So please get on to it. Otherwise we have a massive issue here. And last but not least I don't see any reason why this bug has status WAITING. If there is a solid reason please post it here.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #12 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #13 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC|tony.wang at arm dot com |
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #14 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #15 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c++/63528] New: A variadic variable template cannot use the ::value of a variadic trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528 Bug ID: 63528 Summary: A variadic variable template cannot use the ::value of a variadic trait Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com CC: jason at redhat dot com Created attachment 33702 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33702action=edit Preprocessed testcase #include type_traits static_assert(std::is_constructibleint, int::value, ); template class T, class... Args constexpr bool is_constructible_v = std::is_constructibleT, Args...::value; static_assert(is_constructible_vint, int, ); Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++ : (reconfigured) ../configure --prefix=/usr/local --enable-languages=c,c++ Thread model: posix gcc version 5.0.0 20141013 (experimental) (GCC) COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -E -quiet -v -D_GNU_SOURCE variable-template-isconstructible.cpp -mtune=generic -march=x86-64 -std=c++14 -fpch-preprocess -o variable-template-isconstructible.ii ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c++14' '-v' '-save-temps' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -fpreprocessed variable-template-isconstructible.ii -quiet -dumpbase variable-template-isconstructible.cpp -mtune=generic -march=x86-64 -auxbase variable-template-isconstructible -std=c++14 -version -o variable-template-isconstructible.s GNU C++ (GCC) version 5.0.0 20141013 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 5.0.0 20141013 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 5.0.0 20141013 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 5.0.0 20141013 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 50a3aa5021e9015dd41af708b42ad2d3 variable-template-isconstructible.cpp:8:1: error: non-constant condition for static assertion static_assert(is_constructible_vint, int, ); ^ variable-template-isconstructible.cpp:8:1: error: the value of ‘is_constructible_vint, expression error ’ is not usable in a constant expression variable-template-isconstructible.cpp:6:16: note: ‘is_constructible_vint, expression error ’ used in its own initializer constexpr bool is_constructible_v = std::is_constructibleT, Args...::value;
[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622 --- Comment #2 from lucier at math dot purdue.edu --- This was fixed by the patch for PR61106 and backported to 4.8 and 4.9, so it should be closed as FIXED.
[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 57622 has been marked as a duplicate of this bug. ***
[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The patch was reverted in the branches, that is why PR61106 is still open. It was reverted because it exposed a Fortran issue that has since been fixed, thus I could be reapplied. *** This bug has been marked as a duplicate of bug 61106 ***
[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #21 from lucier at math dot purdue.edu --- Regarding: I think this issue may affect other options, not just -Wunused-parameter. I just built mainline gcc and the following bug from 4.8.2 disappeared: gcc -W -Wall -march=native -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -I../include -c -o os_io.o -I. -DHAVE_CONFIG_H -D___GAMBCDIR=\/usr/local/Gambit-C/v4.7.3\ -D___SYS_TYPE_CPU=\x86_64\ -D___SYS_TYPE_VENDOR=\unknown\ -D___SYS_TYPE_OS=\linux-gnu\ -D___CONFIGURE_COMMAND=\./configure 'CC=gcc -W -Wall -march=native' '--enable-single-host' '--enable-multiple-versions'\ -D___OBJ_EXTENSION=\.o\ -D___EXE_EXTENSION=\\ -D___BAT_EXTENSION=\\ -D___PRIMAL os_io.c -D___LIBRARY os_io.c: In function '___device_stream_setup_from_process': os_io.c:7212:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] write (hdp_errno.writing_fd, execvp_errno, sizeof (execvp_errno)); so I think it also affects -Wunused-result. Brad
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #19) Nobody ever reviewed the changes :( If precisely you cannot get someone to review your patches, the lack of manpower in GCC is becoming truly desperate, including the middle-end. In any case, you are a middle-end maintainer. Give a period for last minute comments and commit it? If something breaks, you can always revert it. This is not some major architectural work, it seems quite independent piece.
[Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Dávid Éles from comment #2) I uses the default mechanism to initialization of members. As far as I know the C++ standard says (8.5/5): To default-initialize an object of type T means: * If T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor). [Based on your quotes and your compiler settings you seem to quote the C++98/03 standard. This is where my response is referred to as well] In your example an object of type Foodouble is default-initialized. Class Foodouble is a non-POD class type, and therefore exactly this bullet is entered. The result is what the wording says: the default constructor for T (that is Foodouble in this example is called. The semantics of calling the default-constructor of a class that has no member-initializer provided (such as in this case) is specified in [class.base.init] p5: If a given nonstatic data member or base class is not named by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer), then — If the entity is a nonstatic data member of (possibly cv-qualified) class type (or array thereof) or a base class, and the entity class is a non-POD class [..] — Otherwise, the entity is not initialized. [..] The first bullet here does not apply, because the member is of type double and thus does not match a class type. The second bullet therefore unconditionally applied and says that the member is not initialized at all. * If T is an array type, each element is default-initialized. This bullet does not apply * Otherwise, the object is zero-initialized. This bullet does not apply. In case of c++ it should be zero initialized if it is the member of a class/struct. No, you are incorrectly interpreting the Standard. As far as I know I have to force to not doing zero initialization something like that Foo* f = new Foo; That has essentially the same initialization semantics as your example code.
[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 --- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to lucier from comment #21) so I think it also affects -Wunused-result. You can always retest the patches in the 4.8 and 4.9 branches and resubmit. And ping until someone reviews it.
[Bug c++/63528] A variadic variable template cannot use the ::value of a variadic trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com ---
Reduced example free of library stuff:
//
templateclass...
struct X
{
constexpr static bool value = true;
};
static_assert(Xint::value, );
template class... Args
constexpr bool X_v = XArgs...::value;
static_assert(X_vint, );
//
[Bug fortran/40958] module files too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #18 from russelldub at gmail dot com --- Created attachment 33703 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33703action=edit Proposed patch to fix module equivalence duplicates Here is a proposed fix for the problem related to equivalence statements in nested/recursive use (see also PR 60780). I've run 'make check-fortran' on rev. 216017 with and without this patch had a FAIL on gfortran.dg/typebound_operator_3.f03 (as discussed in PR 63404) both ways.
[Bug target/59401] [SH] GBR addressing mode optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59401
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
Ugh, there's actually another problem with this thing, I think:
void other (void);
int test0 (void)
{
int x = ((int*)__builtin_thread_pointer ())[2];
other ();
return ((int*)__builtin_thread_pointer ())[5] + x;
}
compiles to:
stcgbr,r8
mov.l.L3,r1
jsr@r1
mov.l@(8,r8),r9
mov.l@(20,r8),r0 use GBR value before the call
addr9,r0
lds.l@r15+,pr
mov.l@r15+,r9
rts
mov.l@r15+,r8
By default, GBR is marked as call-clobbered. Currently, if the GBR mem
optimization thing sees any calls in a function it will not form the GBR
address. It's not optimal, but was supposed to produce at least correct code.
Obviously the code above is wrong. The __builtin_thread_pointer insn is
hoisted by something else before combine/split1. The patch from r216128 is
incomplete. I'm checking it out.
