[Bug c++/67161] [5/6 Regression] ICE with a static_assert using our internal __not/__or/__and traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67161 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/67192] New: Backward-goto in loop can get wrong line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192
Bug ID: 67192
Summary: Backward-goto in loop can get wrong line number
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: arnez at linux dot vnet.ibm.com
Target Milestone: ---
This bug causes a number of failures in the GDB test suite, e.g. with
checkpoint.exp. I can reproduce it with the command line:
gcc -fdump-tree-gimple-lineno -o foo.o -c -g foo.c
foo.c
extern int bar(void);
extern int baz(void);
extern int foo(int x);
int foo(int x)
{
for (;;)
{
if (bar ())
break;
baz ();
}
baz (); /* Line 14. */
}
foo.c.004t.gimple
foo (int x)
[foo.c:7:1] {
int D.1415;
D.1413:
[foo.c:10:11] D.1415 = bar ();
[foo.c:10:10] if (D.1415 != 0) goto D.1416; else goto D.1417;
D.1416:
[foo.c:11:2] goto D.1412;
D.1417:
[foo.c:12:7] baz ();
[foo.c:14:3] goto D.1413; /* == WRONG! Should be [foo.c:13:5]. */
D.1412:
[foo.c:14:3] baz ();
}
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 --- Comment #15 from vries at gcc dot gnu.org --- Author: vries Date: Wed Aug 12 15:13:35 2015 New Revision: 226819 URL: https://gcc.gnu.org/viewcvs?rev=226819root=gccview=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries t...@codesourcery.com PR other/67092 PR other/67098 * configure.ac: Remove --with_host_libstdcxx support. * configure: Regenerate. * doc/install.texi: Remove --with_host_libstdcxx item. Update --with-stage1-libs, --with-boot-ldflags and --with-boot-libs items accordingly. Mention default for --with-stage1-ldflags. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug other/67098] Documentation --with-stage1-ldflags does not mention default -static-libstdc++ -static-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67098 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Wed Aug 12 15:13:35 2015 New Revision: 226819 URL: https://gcc.gnu.org/viewcvs?rev=226819root=gccview=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries t...@codesourcery.com PR other/67092 PR other/67098 * configure.ac: Remove --with_host_libstdcxx support. * configure: Regenerate. * doc/install.texi: Remove --with_host_libstdcxx item. Update --with-stage1-libs, --with-boot-ldflags and --with-boot-libs items accordingly. Mention default for --with-stage1-ldflags. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug other/67099] Documentation --with-host-libstdcxx is outdated, mentions ppl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67099 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2015-08/msg00361.html : Author: vries Date: Wed Aug 12 15:13:35 2015 New Revision: 226819 URL: https://gcc.gnu.org/viewcvs?rev=226819root=gccview=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries t...@codesourcery.com PR other/67092 PR other/67098 * configure.ac: Remove --with_host_libstdcxx support. * configure: Regenerate. * doc/install.texi: Remove --with_host_libstdcxx item. Update --with-stage1-libs, --with-boot-ldflags and --with-boot-libs items accordingly. Mention default for --with-stage1-ldflags. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug other/67098] Documentation --with-stage1-ldflags does not mention default -static-libstdc++ -static-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67098 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from vries at gcc dot gnu.org --- Patch in docs committed, marking resolved-fixed.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 vries at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from vries at gcc dot gnu.org --- Committed patch that removes configure option --with-host-libstdcxx. Marking resolved-fixed.
[Bug c++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Marek is interested (beyond -Wtautological-compare)
[Bug fortran/35234] Undetected use before definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35234 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2015-08-12 CC||manu at gcc dot gnu.org Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #2) It's indeed a duplicate of 27120. It seems it wasn't.
[Bug tree-optimization/67191] [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Oh, maybe just the reduced testcase no longer fails after r226814.
[Bug tree-optimization/67191] [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, doesn't reproduce on x86_64 for me. Anyway mine, hopefully we'll get a x86_64 testcase as well.
[Bug tree-optimization/67191] [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) Oh, maybe just the reduced testcase no longer fails after r226814. Still fails on ppc64le after r226814. So a cross should reproduce this.
[Bug tree-optimization/67191] [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191
Antoine Balestrat antoine.balestrat at gmail dot com changed:
What|Removed |Added
CC||antoine.balestrat at gmail dot
com
--- Comment #5 from Antoine Balestrat antoine.balestrat at gmail dot com ---
Hello ! This simpler C testcase seemingly triggers the exact same ICE at -O1 on
my x86_64 machine :
$ cat tested.c
int a;
void f(void)
{
int b;
for(a=1; a;);
for(; b; b++)
lbl:
b || a;
if(a)
goto lbl;
}
$ xgcc -w -O1 tested.c
tested.c: In function ‘f’:
tested.c:11:1: internal compiler error: in before_dom_children, at
tree-ssa-sccvn.c:4372
}
^
0xc66ffc sccvn_dom_walker::before_dom_children(basic_block_def*)
../../srcdir/gcc/tree-ssa-sccvn.c:4371
0x10c46a1 dom_walker::walk(basic_block_def*)
../../srcdir/gcc/domwalk.c:177
0xc681d6 run_scc_vn(vn_lookup_kind)
../../srcdir/gcc/tree-ssa-sccvn.c:4459
0xc3a3b2 execute
../../srcdir/gcc/tree-ssa-pre.c:4959
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++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 12 14:47:58 2015 New Revision: 226816 URL: https://gcc.gnu.org/viewcvs?rev=226816root=gccview=rev Log: 2015-08-12 Paolo Carlini paolo.carl...@oracle.com PR c++/47461 * g++.dg/warn/Wunused-result-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-result-1.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/67108] [6 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1345 when dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67108 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- With -Wall -Wlogical-op we warn for all the cases except if ((i - i) 10) and I'm not sure if we really want a warning for this case.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #14 from ctice at gcc dot gnu.org --- Author: ctice Date: Wed Aug 12 15:40:11 2015 New Revision: 226820 URL: https://gcc.gnu.org/viewcvs?rev=226820root=gccview=rev Log: Fix warnings when bootstrapping on darwin with vtable verification enabled. libstdc++-v3/ChangeLog: 2015-08-11 Caroline Tice cmt...@google.com PR 66521, Contributed by Eric Gallager * acinclude.m4 (VTV_CXXLINKFLAGS): Make this variable OS-specific, and fix the rpath flag to work properly for darwin. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 --- Comment #5 from Matt Breedlove breedlove.matt at gmail dot com --- On previous builds, you could have DWARF2_UNWIND_INFO be defined and have EH_FRAME_SECTION_NAME undefined within libgcc2.c (the section name was still defined within cygming-crtbegin.c - crtbegin.o). When compiling, EH_FRAME_SECTION_NAME ends up defined while building libgcc's crtbegin.o while it was undefined during libgcc2.c preventing that extern from being emitted. Now, it is instead tied to __LIBGCC_EH_FRAME_SECTION_NAME__ which is primarily tied to DWARF2_UNWIND_INFO and part of a large amount of definitions common to both cygwin and mingw most of which I don't know the significance of. Using the new builtin causes the definition to be synchronized between crtbegin and libgcc2.c which not emits an undefined extern which fails to link. It's not a question of whether it should be reverted or not (the patch merely returned to prior behavior until a proper fix), but rather where and how it has to be changed. You can't simply undefine it within a target-section because defaults.h gets pulled into c-cppbuiltin.c right beforehand which then redefines it. There are also blocks which use DWARF2_UNWIND_INFO as a check before attempting to use it which would break those as well. I'm still waiting for input from Kai or someone more familiar with how the target should be configured. You're right though; some sort of change needs to happen there, but I don't know enough about the target's dwarf2 implementation to say what especially when other parts of the code rely on the set of definitions that make-up the following block of code in defaults.h that both decides to define it first or ultimately redefines it if we were to undefine it along the way. /* If we have named sections, and we're using crtstuff to run ctors, use them for registering eh frame information. */ #if defined (TARGET_ASM_NAMED_SECTION) DWARF2_UNWIND_INFO \ !defined (EH_FRAME_IN_DATA_SECTION) #ifndef EH_FRAME_SECTION_NAME #define EH_FRAME_SECTION_NAME .eh_frame #endif #endif
[Bug go/67198] [5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||boger at us dot ibm.com --- Comment #1 from Ian Lance Taylor ian at airs dot com --- I can't win. I deeply do not care about this type. Please sort it out with Lynn Boger. Thanks.
[Bug tree-optimization/67196] Another false positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-12
CC||manu at gcc dot gnu.org
Blocks||24639
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
For some reason, the uninit pass does not even analyze the predicates and
thinks all uses are unguarded (or it doesn't dump it).
A shorter testcase:
int some_test(int);
int test (int n)
{
int num_captions_in_row = 0;
int first_caption = 0; /* set to zero here */
int first_caption_idx;
int i;
for (i = 0; i n; i++)
{
if (some_test (i))
{
num_captions_in_row++;
first_caption = 1; /* only ever set here */
first_caption_idx = i; /* set here */
}
}
/* The guard on first_caption here requires we entered the block
above that sets first_caption_idx. */
if (first_caption num_captions_in_row == 1)
return first_caption_idx; /* get bogus warning here at -O1 and above */
return 0;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug go/67198] New: gccgo: change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67198 Bug ID: 67198 Summary: gccgo: change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: michael.hudson at canonical dot com CC: cmang at google dot com Target Milestone: --- https://github.com/golang/go/issues/11469 / https://go.googlesource.com/gofrontend/+/a850225433a66a58613c22185c3b09626f5545eb%5E!/ fixed gccgo tip to match what Go 1.5 does for the type of syscall.RawSockaddr.Data on ppc64le, which sounds good, but it means that the type is different from previous releases of gccgo on ppc64le, which means that programs that used to compile now don't, including docker: https://launchpadlibrarian.net/214319094/buildlog_ubuntu-wily-ppc64el.docker.io_1.6.2~dfsg1-1ubuntu4_BUILDING.txt.gz I don't know that docker can be changed in a way that will build with both new and old gccgo, which seems pretty unfortunate. At least changing the Go 1.5 type would allow that, but it's way too late for that.
[Bug target/67172] [5/6 regression] i686-w64-mingw32 dwarf2 bootstrap fails with undefined reference to __EH_FRAME_BEGIN__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 11 Aug 2015, breedlove.matt at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172 --- Comment #3 from Matt Breedlove breedlove.matt at gmail dot com --- In gcc/defaults.h, it gets defined via: So why does not exactly the same sequence of conditional macro definitions apply when libgcc is being built and so cause your patch to be ineffective, given that libgcc does still include the host-side tm.h until the transition away from host-side target macros in target-side code is complete? (In any case, my point still applies: stop __LIBGCC_EH_FRAME_SECTION_NAME__ being defined if it's incorrect, which means some sort of host-side change.)
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
Anton Blanchard anton at samba dot org changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #12 from Anton Blanchard anton at samba dot org ---
I hit this when building MariaDB. Reduced testcase:
typedef struct bn_gencb_st BN_GENCB;
struct bn_gencb_st {
void *arg;
union {
int (*cb_2)(int, int, BN_GENCB *);
};
};
g++ -O0 -g -c testcase.i
testcase.i:5:15: error: TYPE_CANONICAL is not compatible
union {
^
record_type 0x3fff76fbc630 bn_gencb_st type_5 VOID
align 8 symtab 1995243680 alias set -1 canonical type 0x3fff76fbc630
fields field_decl 0x3fff76eb49a0 arg
type pointer_type 0x3fff76e01110 type void_type 0x3fff76e00fc0 void
public unsigned DI
size integer_cst 0x3fff76db1470 constant 64
unit size integer_cst 0x3fff76db1488 constant 8
align 64 symtab 0 alias set -1 canonical type 0x3fff76e01110
pointer_to_this pointer_type 0x3fff76e04cc8
decl_3 VOID file testcase.i line 4 col 15
align 1 offset_align 1 context record_type 0x3fff76fbc630 bn_gencb_st
chain type_decl 0x3fff76eb4908 bn_gencb_st type record_type
0x3fff76fbc8d0 bn_gencb_st
nonlocal decl_4 VOID file testcase.i line 3 col 20
align 1 context record_type 0x3fff76fbc630 bn_gencb_st result
record_type 0x3fff76fbc630 bn_gencb_st
chain type_decl 0x3fff76eb4ad0 ._0 context
translation_unit_decl 0x3fff79680078 D.1
full-name struct bn_gencb_st
n_parents=0 use_template=0 interface-unknown
pointer_to_this pointer_type 0x3fff76fbcb70 chain type_decl
0x3fff76eb47d8 bn_gencb_st
record_type 0x3fff76fbc6d8 BN_GENCB type_5 VOID
align 8 symtab 1995243600 alias set -1 canonical type 0x3fff76fbc630
context translation_unit_decl 0x3fff79680078 D.1
full-name BN_GENCB
n_parents=0 use_template=0 interface-unknown
pointer_to_this pointer_type 0x3fff76fbcac8 chain type_decl
0x3fff76eb47d8 bn_gencb_st
testcase.i:5:15: internal compiler error: verify_type failed
0x10dd6617 verify_type(tree_node const*)
../../gcc/gcc/tree.c:13570
0x1067fc67 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20685
0x10680887 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20783
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x1067f3d3 gen_formal_types_die
../../gcc/gcc/dwarf2out.c:18225
0x1067f91b gen_subroutine_type_die
../../gcc/gcc/dwarf2out.c:20505
0x1068046f gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20812
0x10680887 gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20783
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x1067538f gen_decl_die
../../gcc/gcc/dwarf2out.c:21519
0x106786bb gen_member_die
../../gcc/gcc/dwarf2out.c:20356
0x106786bb gen_struct_or_union_type_die
../../gcc/gcc/dwarf2out.c:20461
0x106786bb gen_tagged_type_die
../../gcc/gcc/dwarf2out.c:20662
0x1068079f gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20824
0x10681d97 gen_type_die
../../gcc/gcc/dwarf2out.c:20879
0x10675b9b gen_decl_die
../../gcc/gcc/dwarf2out.c:21465
0x1067681f dwarf2out_decl
../../gcc/gcc/dwarf2out.c:21915
0x10676c77 dwarf2out_type_decl
../../gcc/gcc/dwarf2out.c:21625
0x1098065f rest_of_type_compilation(tree_node*, int)
../../gcc/gcc/passes.c:336
0x102c2223 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6747
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 12 22:38:04 2015 New Revision: 226840 URL: https://gcc.gnu.org/viewcvs?rev=226840root=gccview=rev Log: 2015-08-12 Paolo Carlini paolo.carl...@oracle.com PR c++/53330 * g++.dg/init/new42.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new42.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0, 5.0 Resolution|--- |WORKSFORME --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding a testcase and closing the bug.
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #9 from ncm at cantrip dot org --- I did experiment with -m[no-]bmi[2] a fair bit. It all made a significant difference in the instructions emitted, but exactly zero difference in runtime. That's actually not surprising at all; those instructions get decomposed into micro-ops that exactly match those from the equivalent instructions, and are cached, and the loops that dominate runtime execute out of the micro-op cache. The only real effect is maybe slightly shorter object code, which could matter in a program dominated by bus traffic with loops too big to cache well. I say maybe slightly shorter because instruction-set extension instructions are actually huge, mostly prefixes. I.e. most of the BMI stuff is marketing fluff, added mainly to make the competition waste money matching them instead of improving the product.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- Bugs in -fsignaling-nans (in this case, that a conversion of a signaling NaN from float to double is incorrectly folded) should be fixed just like any other bug. That sentence is simply warning that there are many known bugs in this area.
[Bug target/67071] GCC misses an optimization to load vector constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67071 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Aug 12 21:54:23 2015 New Revision: 226836 URL: https://gcc.gnu.org/viewcvs?rev=226836root=gccview=rev Log: [gcc] 2015-08-12 Michael Meissner meiss...@linux.vnet.ibm.com PR target/67071 * config/rs6000/predicates.md (easy_vector_constant_vsldoi): New predicate to allow construction of vector constants using the VSLDOI vector shift instruction. * config/rs6000/rs6000-protos.h (vspltis_shifted): Add declaration. * config/rs6000/rs6000.c (vspltis_shifted): New function to return the number of bytes to be shifted left and filled in with either all zero or all one bits. (gen_easy_altivec_constant): Call vsplitis_shifted if no other methods exist. (output_vec_const_move): On power8, generate XXLORC to generate a vector constant with all 1's. Do a split if we need to use a VSLDOI instruction. * config/rs6000/rs6000.h (EASY_VECTOR_MSB): Use mode mask to properly test for the MSB. * config/rs6000/altivec.md (VSLDOI splitter): Add splitter for vector constants that can be created with VSLDOI. [gcc/testsuite] 2015-08-12 Michael Meissner meiss...@linux.vnet.ibm.com PR target/67071 * gcc.target/powerpc/pr67071-1.c: New file to test PR 67071 new vector constants. * gcc.target/powerpc/pr67071-2.c: Likewise. * gcc.target/powerpc/pr67071-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr67071-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr67071-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr67071-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/testsuite/ChangeLog
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #61 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to amker from comment #60) (In reply to Bill Schmidt from comment #59) We don't have a lot of data yet, but we have seen several examples in SPEC and other benchmarks where turning on -funroll-loops is helpful, but should be much more helpful -- in many cases performance improves with a much higher unroll factor. However, the effectiveness of unrolling is very much tied up with these issues in IVOPTS, where we currently end up with too many separate base registers for IVs. As we increase the unroll factor, we By this, do you mean too many candidates are chosen? Or the issue just like this PR describes? Thanks. On the surface, it's the issue from this PR where we have lots of separate induction variables with their own index registers each requiring an add during each iteration. The presence of this issue masks whether we have too many candidates, but in the sense that we often see register spill associated with this kind of code, we do have too many. I.e., the register pressure model may not be in tune with the kind of addressing mode that's being selected, but that's just a theory. Or perhaps pressure is just being generically under-predicted for POWER. Up till now we haven't done a lot of detailed analysis. Hopefully we can free somebody up to start looking at some of our unrolling issues soon.
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #11 from ncm at cantrip dot org --- Aha, Uroš, I see your name in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 Please forgive me for teaching you about micro-ops. The code being generated for all versions does use (e.g.) popcntq %rax, %rax almost everywhere. Not quite everywhere -- I see one popcntq %rax, %rdx -- but certainly in all the performance-sensitive bits.
[Bug tree-optimization/67199] New: ICE with compile bug related to vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67199
Bug ID: 67199
Summary: ICE with compile bug related to vector_size
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
testcase:
__attribute__ ((vector_size (16))) g_73 = {0x15FE687EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) g_1124;
int func_1(void)
{
__attribute__ ((vector_size (16))) l_1117 = {0x15FE688EL, 0x5827DF98L,
0xF8411272L, 0x235E695EL};
__attribute__ ((vector_size (16))) zhong = ( g_73 = g_73);
g_1124 = (((g_73 l_1117) == (zhong)) 9);
return 0;
}
the following issue can be reproduced with -O2 when the gcc built on 64 bits
system.
internal compiler error: in fold_convert_loc, at fold-const.c:1974
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions
[Bug c++/67200] New: Copy elision and implicit move in return performed in cases not allowed by standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67200
Bug ID: 67200
Summary: Copy elision and implicit move in return performed in
cases not allowed by standard
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Consider:
struct A {
A() = default;
A(const A) = delete;
A(A) = default;
};
A f() {
A a;
return true ? a : a;
}
This code is ill-formed; `true ? a : a` is an lvalue of type `A`; it neither
qualifies for copy elision under [class.copy]/p31 (it is not the name of a
nonvolatile
automatic object) nor for implicit moving under [class.copy]/p32 (it's not an
id-expression, either). Therefore, overload resolution should select the copy
constructor, which in the above example is deleted.
GCC compiles this code and in fact elides a move.
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #22 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Thu Aug 13 05:25:02 2015 New Revision: 226848 URL: https://gcc.gnu.org/viewcvs?rev=226848root=gccview=rev Log: More split-stack fixes Backport rev 226443 2015-07-31 Alan Modra amo...@gmail.com PR target/66870 * config/rs6000/rs6000.c (machine_function): Add split_stack_argp_used. (rs6000_emit_prologue): Set it. (rs6000_set_up_by_prologue): Specify r12 when split_stack_argp_used. Backport rev 223878 2015-05-30 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (split_stack_arg_pointer_used_p): Scan correct block for use of r12. (rs6000_expand_split_stack_prologue): Error on r29 asm global reg. Backport rev 223427 2015-05-20 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Return stack adjusting insn. Formatting. (rs6000_emit_prologue): Track stack adjusting insn, and use of r12. If possible, emit first -fsplit-stack arg pointer insn before stack adjust. Don't use r12 to save cr if split-stack. Backport rev 223425 2015-05-20 Alan Modra amo...@gmail.com * config/rs6000/rs6000.c (struct rs6000_stack): Correct comments. (direct_return): Test vrsave_size rather than vrsave_mask. (rs6000_emit_prologue): Likewise. Remove redundant altivec tests. (rs6000_emit_epilogue): Likewise. Revert bogus rs6000_function_ok_for_sibcall change that caused failure of glibc build. Revert rs6000_can_eliminate cosmetic change Modified: branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c
[Bug tree-optimization/66070] [GRAPHITE] cc1 gets killed by OOM killer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66070 Andrey Turkin andrey.turkin at gmail dot com changed: What|Removed |Added CC||andrey.turkin at gmail dot com --- Comment #1 from Andrey Turkin andrey.turkin at gmail dot com --- Created attachment 36177 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36177action=edit Minified sample Same here. I don't think it is just a memory hog; compiler probably enters some kind of infinite loop. Tested on 4.9.2, 4.9.3 and 5.2.0. Command line to reproduce is x86_64-pc-linux-gnu-gcc -m32 -O2 -floop-interchange -c fram_gen.c. It only happens when using this specific combination of flags (32-bit mode, O2 and loop interchange enabled).
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #10 from ncm at cantrip dot org --- I found this, which at first blush seems like it might be relevant. The hardware complained about here is the same Haswell i7-4770. http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #60 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #59) (In reply to rguent...@suse.de from comment #57) It's been a long time since I've done SPEC measuring with/without -funroll-loops (or/and -fpeel-loops). Note that these flags have secondary effects as well: toplev.c:flag_web = flag_unroll_loops || flag_peel_loops; toplev.c:flag_rename_registers = flag_unroll_loops || flag_peel_loops; We don't have a lot of data yet, but we have seen several examples in SPEC and other benchmarks where turning on -funroll-loops is helpful, but should be much more helpful -- in many cases performance improves with a much higher unroll factor. However, the effectiveness of unrolling is very much tied up with these issues in IVOPTS, where we currently end up with too many separate base registers for IVs. As we increase the unroll factor, we By this, do you mean too many candidates are chosen? Or the issue just like this PR describes? Thanks. eventually hit this as a limiting factor, so fixing this IVOPTS issue would be very helpful for POWER. As a side note, with -fprofile-use a GIMPLE unroller could peel and unroll hot loop traces in loops that would otherwise be too complex to unroll. I.e., if there is a single hot trace through a loop, you can do tail duplication on the trace to force it into superblock form, and then peel and unroll that superblock while falling into the original loop if the trace is left. Complete unrolling and unrolling by a factor are both possible. I don't know of specific benchmarks that would be helped by this, though. (An RTL unroller could do this as well, but it seems much more natural and implementable in GIMPLE.)
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #62 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #61) (In reply to amker from comment #60) (In reply to Bill Schmidt from comment #59) We don't have a lot of data yet, but we have seen several examples in SPEC and other benchmarks where turning on -funroll-loops is helpful, but should be much more helpful -- in many cases performance improves with a much higher unroll factor. However, the effectiveness of unrolling is very much tied up with these issues in IVOPTS, where we currently end up with too many separate base registers for IVs. As we increase the unroll factor, we By this, do you mean too many candidates are chosen? Or the issue just like this PR describes? Thanks. On the surface, it's the issue from this PR where we have lots of separate induction variables with their own index registers each requiring an add during each iteration. The presence of this issue masks whether we have too IMHO, this issue should be fixed by a gimple unroller before IVO, or in RTL unroller. It's not that practical to fix it in IVO. many candidates, but in the sense that we often see register spill associated with this kind of code, we do have too many. I.e., the register pressure model may not be in tune with the kind of addressing mode that's being selected, but that's just a theory. Or perhaps pressure is just being generically under-predicted for POWER. IVO's reg-pressure model fails to preserve a small iv set sometime on aarch64 too. I have this issue on list. On the other hand, the loops I saw are generally very big, it's might be inappropriate that rtl unroller decides to unroll them at the first place. Up till now we haven't done a lot of detailed analysis. Hopefully we can free somebody up to start looking at some of our unrolling issues soon.
[Bug middle-end/25529] (unsigned * 2)/2 is not changed into unsigned 0x7FFFFFFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25529 --- Comment #3 from naveenh at gcc dot gnu.org --- Author: naveenh Date: Thu Aug 13 04:37:22 2015 New Revision: 226847 URL: https://gcc.gnu.org/viewcvs?rev=226847root=gccview=rev Log: 2015-08-13 Naveen H.S naveen.hurugalaw...@caviumnetworks.com PR middle-end/25529 * match.pd (div (mult @0 @1) @1) : New simplifier. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #58 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #56) (In reply to Bill Schmidt from comment #53) I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me. I would be willing to soften this statement. I think that an early unroller might well be a profitable approach for most systems with large caches and so forth, where if the unrolling heuristics are not completely accurate we are still likely to make a reasonably good decision. However, I would expect to see ports with limited caches/memory to want more accurate control over unrolling decisions. So I could see allowing ports to select between a GIMPLE unroller and an RTL unroller (I doubt anybody would want both). Thanks for the comments. As David suggested, we can try to implement a relatively conservative unroller and make sure it's a win in most unrolled cases, even with some opportunities missed. Then we can enable it at O3/Ofast level, that would be wanted I think since now we don't have a general unroller by default. In general it seems like PowerPC could benefit from more aggressive unrolling much of the time, provided we can also solve the related IVOPTS problems that cause too much register spill. I may have an interest in working on a GIMPLE unroller, depending on how quickly I can complete or shed some other projects... (In reply to rguent...@suse.de from comment #57) On Tue, 11 Aug 2015, wschmidt at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #56 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #53) I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me. I would be willing to soften this statement. I think that an early unroller might well be a profitable approach for most systems with large caches and so forth, where if the unrolling heuristics are not completely accurate we are still likely to make a reasonably good decision. However, I would expect to see ports with limited caches/memory to want more accurate control over unrolling decisions. So I could see allowing ports to select between a GIMPLE unroller and an RTL unroller (I doubt anybody would want both). In general it seems like PowerPC could benefit from more aggressive unrolling much of the time, provided we can also solve the related IVOPTS problems that cause too much register spill. I may have an interest in working on a GIMPLE unroller, depending on how quickly I can complete or shed some other projects... I think that a separate unrolling on GIMPLE would be a hard sell due to the lack of a good cost mode. _But_ doing unrolling as part of another transform like we are doing now makes sense. So does eventually moving parts of an RTL pass involving unrolling to GIMPLE, like modulo scheduling or SMS (leaving the scheduling part to RTL). (In reply to Bill Schmidt from comment #56) (In reply to Bill Schmidt from comment #53) I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me. I would be willing to soften this statement. I think that an early unroller might well be a profitable approach for most systems with large caches and so forth, where if the unrolling heuristics are not completely accurate we are still likely to make a reasonably good decision. However, I would expect to see ports with limited caches/memory to want more accurate control over unrolling decisions. So I could see allowing ports to select between a GIMPLE unroller and an RTL unroller (I doubt anybody would want both). As David suggested, we can try to implement a relatively conservative unroller and make sure it's a win in most unrolled cases, even with some opportunities missed. Then we can enable it at O3/Ofast level, it would be nice since we don't have a general unroller by default. About cost-model. Is it possible to introduce cache information model in GCC? I don't see it's a difficult problem, and can be a start for possible cache sensitive optimizations in the future? Another general question is: what kind of cost do we need in a fine unroller, besides cache/branch ones? In general it seems like PowerPC could benefit from more aggressive unrolling much of the time, provided we can also solve the related IVOPTS problems that cause too much register spill. I may have an interest in working on a GIMPLE unroller, depending on how quickly I can complete or shed some other projects... Note that the RTL unroller is not enabled by default by any
[Bug libgomp/67141] wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 --- Comment #2 from xantares09 at hotmail dot com --- Note that you'll need mingw-w64 4.0.4, not 4.0.2 to reproduce, I used gcc 5.2.0.
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jai from comment #2) I am talking about this [snip wall of text with some warnings but no error as far as I can see] How to remove this issue? Again, what issue?
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #4 from Jai jai.sharma3521 at gmail dot com --- Created attachment 36175 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36175action=edit Config file While building GMP6.0.0 Attached is the config while when I try to build GMP.There is Clang Error.
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #57 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 11 Aug 2015, wschmidt at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #56 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #53) I'm not a fan of a tree-level unroller. It's impossible to make good decisions about unroll factors that early. But your second approach sounds quite promising to me. I would be willing to soften this statement. I think that an early unroller might well be a profitable approach for most systems with large caches and so forth, where if the unrolling heuristics are not completely accurate we are still likely to make a reasonably good decision. However, I would expect to see ports with limited caches/memory to want more accurate control over unrolling decisions. So I could see allowing ports to select between a GIMPLE unroller and an RTL unroller (I doubt anybody would want both). In general it seems like PowerPC could benefit from more aggressive unrolling much of the time, provided we can also solve the related IVOPTS problems that cause too much register spill. I may have an interest in working on a GIMPLE unroller, depending on how quickly I can complete or shed some other projects... I think that a separate unrolling on GIMPLE would be a hard sell due to the lack of a good cost mode. _But_ doing unrolling as part of another transform like we are doing now makes sense. So does eventually moving parts of an RTL pass involving unrolling to GIMPLE, like modulo scheduling or SMS (leaving the scheduling part to RTL). Note that the RTL unroller is not enabled by default by any optimization level and note that unfortunately the RTL unroller shares flags with the GIMPLE level complete peeling (where it mainly controls cost modeling). Oh, but it's enabled with -fprofile-use. It's been a long time since I've done SPEC measuring with/without -funroll-loops (or/and -fpeel-loops). Note that these flags have secondary effects as well: toplev.c:flag_web = flag_unroll_loops || flag_peel_loops; toplev.c:flag_rename_registers = flag_unroll_loops || flag_peel_loops;
[Bug preprocessor/67132] gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Component|c |preprocessor --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Sorry, I meant to say that the warning about the redefinition seems in place to me.
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- This is not a GCC bug as GCC does not control either clang or GMP.
[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #2 from Jay jay.krell at cornell dot edu --- er, three traversals. Also, ideally, nothing is ever output in hash order. At least not to assembly source and objects. It might be unavoidable for final executables. i.e. adding one randomly named function should not cause the output to be ordered, but that one function merely inserted in its predictable place.
[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #3 from Jay jay.krell at cornell dot edu --- https://github.com/modula3/cm3/commit/14d5e667e19abaab679b52bc8fd35a4e38073330 is a simple patch against 4.7 that establishes a partial ordering, separating the indirect functions from the indirect data, and appears to workaround the llvm-as bug. It still outputs in hash order mostly. Something similar/trivial against trunk should do.
[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66801 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Cannot reproduce the issue anymore. Closing.
[Bug bootstrap/66994] [6 Regression] ICE: Segmentation fault during bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66994 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Cannot reproduce the issue anymore. Closing.
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187 --- Comment #5 from Jai jai.sharma3521 at gmail dot com --- (In reply to Marc Glisse from comment #3) (In reply to Jai from comment #2) I am talking about this [snip wall of text with some warnings but no error as far as I can see] How to remove this issue? Again, what issue? See the Config.log you can see the Clang error. ndefined symbols for architecture x86_64: _main, referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
[Bug driver/67187] Not able to build GMP for Mac OS Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67187
Jai jai.sharma3521 at gmail dot com changed:
What|Removed |Added
Version|unknown |5.1.0
--- Comment #2 from Jai jai.sharma3521 at gmail dot com ---
(In reply to Marc Glisse from comment #1)
Where do you see an error? I can only find warnings in that config.log file.
Hi
Thanks for replying
I am talking about this
Applications/Xcode.app/Contents/Developer/usr/bin/make install-recursive
Making install in tests
Making install in .
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in devel
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpn
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpz
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpq
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpf
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in rand
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in misc
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in cxx
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in mpn
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpz
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpq
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in mpf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in printf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in scanf
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in rand
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in cxx
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in demos
Making install in calc
/Applications/Xcode.app/Contents/Developer/usr/bin/make install-am
make[5]: Nothing to be done for `install-exec-am'.
make[5]: Nothing to be done for `install-data-am'.
Making install in expr
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
Making install in tune
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in doc
make[3]: Nothing to be done for `install-exec-am'.
../../install-sh -c -d '/usr/gcc-5.1.0/share/info'
/usr/bin/install -c -m 644 ../../doc/gmp.info ../../doc/gmp.info-1
../../doc/gmp.info-2 '/usr/gcc-5.1.0/share/info'
install-info --info-dir='/usr/gcc-5.1.0/share/info'
'/usr/gcc-5.1.0/share/info/gmp.info'
../install-sh -c -d '/usr/gcc-5.1.0/lib'
/bin/sh ./libtool --mode=install /usr/bin/install -c libgmp.la libgmpxx.la
'/usr/gcc-5.1.0/lib'
libtool: install: /usr/bin/install -c .libs/libgmp.10.dylib
/usr/gcc-5.1.0/lib/libgmp.10.dylib
libtool: install: (cd /usr/gcc-5.1.0/lib { ln -s -f libgmp.10.dylib
libgmp.dylib || { rm -f libgmp.dylib ln -s libgmp.10.dylib libgmp.dylib; };
})
libtool: install: /usr/bin/install -c .libs/libgmp.lai
/usr/gcc-5.1.0/lib/libgmp.la
libtool: install: /usr/bin/install -c .libs/libgmpxx.4.dylib
/usr/gcc-5.1.0/lib/libgmpxx.4.dylib
libtool: install: (cd /usr/gcc-5.1.0/lib { ln -s -f libgmpxx.4.dylib
libgmpxx.dylib || { rm -f libgmpxx.dylib ln -s libgmpxx.4.dylib
libgmpxx.dylib; }; })
libtool: install: /usr/bin/install -c .libs/libgmpxx.lai
/usr/gcc-5.1.0/lib/libgmpxx.la
libtool: install: /usr/bin/install -c .libs/libgmp.a
/usr/gcc-5.1.0/lib/libgmp.a
libtool: install: chmod 644 /usr/gcc-5.1.0/lib/libgmp.a
libtool: install: ranlib /usr/gcc-5.1.0/lib/libgmp.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: /usr/gcc-5.1.0/lib/libgmp.a(mp_clz_tab.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: /usr/gcc-5.1.0/lib/libgmp.a(obprintf.o) has no symbols
[Bug testsuite/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from vries at gcc dot gnu.org --- Patch committed, marking resolved-fixed
[Bug testsuite/67175] gcc.dg/vect/trapv-vect-reduc-4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67175 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) I just wonder if it wouldn't be better to skip part of the test based on some target property rather than target triplet. Submitted '[RFC] Add check_effective_target_vect_min_max' at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00567.html .
[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #1 from Jay jay.krell at cornell dot edu --- It turns out, this looks easy to fix on the gcc side. See machopic_finish. Have it run two traversla instead of one. The first editing stubs, the second non-lazy pointers.
[Bug c++/65143] [C++11] missing devirtualization for virtual base in final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||gpderetta at gmail dot com --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 67184 has been marked as a duplicate of this bug. ***
[Bug c++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) Related to c++/65143. Yes, lets close this one. *** This bug has been marked as a duplicate of bug 65143 ***
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- We now warn for the testcase in Comment 2.
[Bug c++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gpderetta at gmail dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Related to c++/65143.
[Bug c/55892] Bogus compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55892 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- With current trunk I get two warnings, on line 33 and on line 34. I guess fixed then.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 27120, which changed state. Bug 27120 Summary: Should warn about uninitialized use of variable array element https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/27120] Should warn about uninitialized use of variable array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- We now warn even for the first testcase in Description (both C and C++).
[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138 Bug 10138 depends on bug 27120, which changed state. Bug 27120 Summary: Should warn about uninitialized use of variable array element https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- I think -Wsizeof-pointer-memaccess should be enough for this PR be closed now.
[Bug c/35694] Error about bad function argument isn't issued on the line of the argument but on the line where function ends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35694 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I fixed this for 4.9. Closing as fixed thus.
[Bug preprocessor/67132] gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 --- Comment #4 from Giacomo Tesio giacomo at tesio dot it --- Indeed, this is a request for an enhancement, not a bug report. I mean, being able to decide how gcc defines wchar_t is an enhancement, given the poor definition of such type in the standard. With -Wno-pointer-sign one will miss useful warnings for pointer signedness unrelated to wide characters. Note however that I don't want to be able to redefine *any* built-in definition without warnings, just those three. To me, an even better alternative is: add a -funsigned-wchar to gcc to enable unsigned 32bit wchar_t. Something along the line of -fshort-wchar, but that change only the sign of wchar_t, not the size. Given that according to the unicode standard the width of wchar_t is compiler-specific, such a flag can improve the ability to use gcc for code developed with more exotic compilers and platforms.
[Bug c++/65143] [C++11] missing devirtualization for virtual base in final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Testcase from PR67184:
markus@x4 tmp % cat test.ii
struct V {
virtual void foo();
};
struct wV final : V {};
struct oV final : V {
void foo();
};
void call(V x) { x.foo(); }
void call(wV x) { x.foo(); }
void call(oV x) { x.foo(); }
markus@x4 tmp % clang++ -std=c++14 -c -O3 -S test.ii -o -
...
_Z4callR2wV:# @_Z4callR2wV
.cfi_startproc
# BB#0: # %entry
jmp _ZN1V3fooEv # TAILCALL
...
markus@x4 tmp % g++ -std=c++14 -O3 -c -S test.ii -o -
...
_Z4callR2wV:
.LFB1:
.cfi_startproc
movq(%rdi), %rax
jmp *(%rax)
[Bug c++/67193] New: Overzealous -Wstack-usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67193
Bug ID: 67193
Summary: Overzealous -Wstack-usage warning
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobi at gcc dot gnu.org
Target Milestone: ---
-Wstack-usage throws a warning if it cannot prove that the stack is bounded.
Therefore it is more noisy with optimization turned off. That is fine, but
sometimes it's really too noisy, such as in this example (this is with current
trunk):
$ cat t.cc
#include alloca.h
void f(char *p) {
char *q = (char*)alloca(1);
*q = *p;
return;
}
$ bin/g++ -c -Wstack-usage=898989 t.cc
t.cc: In function ‘void f(char*)’:
t.cc:3:6: warning: stack usage might be unbounded [-Wstack-usage=]
void f(char *p) {
^
$ bin/g++ -O -c -Wstack-usage=898989 t.cc
$ bin/g++ --version
g++ (GCC) 6.0.0 20150812 (experimental)
Copyright (C) 2015 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.
$
Constant folding should suffice to get rid of this warning but apparently
alloca is converted to some more complicated operation before the warning is
issued. (I know that alloca with a fixed argument is fairly pointless, but
this can happen with templates.)
[Bug c++/66941] Missing diagnostic extraneous template parameter list in template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66941 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 63809 ***
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #3 from Mikhail Maltsev miyuki at gcc dot gnu.org --- *** Bug 66941 has been marked as a duplicate of this bug. ***
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 --- Comment #2 from Ivan Sorokin vanyacpp at gmail dot com --- (In reply to Marc Glisse from comment #0) g++ fails to warn about the extra parameter list. clang does warn, see PR63750. Why is it a warning? Isn't this code incorrect? I can not find anything in [temp.expl.spec] that forbid a code like this, but I can not find anything that assign a specific meaning to this code either. At least one compiler (MSVC) rejects this code with an error.
[Bug c++/67190] New: gcc allows extra template on explicit template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67190
Bug ID: 67190
Summary: gcc allows extra template on explicit template
specializations
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
GCC accepts this code:
template typename T
struct vector
{};
template typename T
struct z
{};
template
template // extra
struct zvectorint
{};
After reading [temp.expl.spec] I can not find anything that forbids or allows
extra 'template'. MSVC rejects this code and I find this reasonable.
1main.cpp(44): error C2910: 'zvectorT' : cannot be explicitly specialized
Clang accepts this code, but it gives a warning: extraneous template parameter
list in template specialization.
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 --- Comment #11 from Mark Eklund meklund at cisco dot com --- -Wsizeof-pointer-memaccess is definitely a good targeted fix and probably hits a majority of what I've seen. I'm good with this being resolved.
[Bug other/67098] Documentation --with-stage1-ldflags does not mention default -static-libstdc++ -static-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67098 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #1 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00603.html
[Bug fortran/67170] PRE can't hoist out a readonly argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, the argument may go like foo (D.3438) may not modify *arg_29(D)
because then the fnspec on foo would be incorrect - *arg_29(D) would be
modified.
Untested patch (works for the testcase):
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 226807)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -2153,6 +2153,33 @@ call_may_clobber_ref_p_1 (gcall *call, a
return false;
}
+ /* If the base of an indirect access is a parameter which by means
+ of the fnspec of ourselves not clobbered by us then it is surely
+ not modified by calls we do. */
+ tree base_ptr;
+ tree fnspec;
+ if (TREE_CODE (base) == MEM_REF
+ (base_ptr = TREE_OPERAND (base, 0))
+ TREE_CODE (base_ptr) == SSA_NAME
+ SSA_NAME_IS_DEFAULT_DEF (base_ptr)
+ SSA_NAME_VAR (base_ptr)
+ TREE_CODE (SSA_NAME_VAR (base_ptr)) == PARM_DECL
+ (fnspec = lookup_attribute (fn spec,
+TYPE_ATTRIBUTES (TREE_TYPE
(cfun-decl)
+{
+ unsigned i = 0;
+ tree arg;
+ for (arg = DECL_ARGUMENTS (cfun-decl);
+ arg arg != SSA_NAME_VAR (base_ptr); arg = DECL_CHAIN (arg), ++i)
+ ;
+ gcc_assert (arg == SSA_NAME_VAR (base_ptr));
+ fnspec = TREE_VALUE (TREE_VALUE (fnspec));
+ if ((unsigned) TREE_STRING_LENGTH (fnspec) i + 1
+ (TREE_STRING_POINTER (fnspec)[i + 1] == 'R'
+ || TREE_STRING_POINTER (fnspec)[i + 1] == 'r'))
+ return false;
+}
+
/* Check if the base variable is call-clobbered. */
if (DECL_P (base))
return pt_solution_includes (gimple_call_clobber_set (call), base);
of course this asks for the argument being marked somehow to avoid the
linear search for its index. It also requires some thinking on if and
when derived pointers (from the argument) allow similar handling.
A way simpler approach would be to change code generation by the Frontend
for scalar pass-by-reference intent-in arguments to load such parameters
at the beginning of the function and further use that load result for
all references to that parameter.
Martin, can you check if the above solves the RA issue it was blocking?
[Bug c++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Let's add a testcase and close the bug.
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #18 from Marek Polacek mpolacek at gcc dot gnu.org --- Testing a fix for the sign bit problem.
[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #14 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00603.html
[Bug target/29256] [4.9/5/6 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #59 from Bill Schmidt wschmidt at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #57) It's been a long time since I've done SPEC measuring with/without -funroll-loops (or/and -fpeel-loops). Note that these flags have secondary effects as well: toplev.c:flag_web = flag_unroll_loops || flag_peel_loops; toplev.c:flag_rename_registers = flag_unroll_loops || flag_peel_loops; We don't have a lot of data yet, but we have seen several examples in SPEC and other benchmarks where turning on -funroll-loops is helpful, but should be much more helpful -- in many cases performance improves with a much higher unroll factor. However, the effectiveness of unrolling is very much tied up with these issues in IVOPTS, where we currently end up with too many separate base registers for IVs. As we increase the unroll factor, we eventually hit this as a limiting factor, so fixing this IVOPTS issue would be very helpful for POWER. As a side note, with -fprofile-use a GIMPLE unroller could peel and unroll hot loop traces in loops that would otherwise be too complex to unroll. I.e., if there is a single hot trace through a loop, you can do tail duplication on the trace to force it into superblock form, and then peel and unroll that superblock while falling into the original loop if the trace is left. Complete unrolling and unrolling by a factor are both possible. I don't know of specific benchmarks that would be helped by this, though. (An RTL unroller could do this as well, but it seems much more natural and implementable in GIMPLE.)
[Bug c++/67190] gcc allows extra template on explicit template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67190 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Dup *** This bug has been marked as a duplicate of bug 63809 ***
[Bug target/67127] [ARM] Avoiding odd-number ldrd/strd in movdi introduced a regression on armeb-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67127 --- Comment #1 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Wed Aug 12 13:27:41 2015 New Revision: 226811 URL: https://gcc.gnu.org/viewcvs?rev=226811root=gccview=rev Log: 2015-08-12 Yvan Roux yvan.r...@linaro.org PR target/67127 * config/arm/arm.md (movdi): Restrict illegitimate ldrd/strd checking to ARM core registers. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #17 from Marek Polacek mpolacek at gcc dot gnu.org --- Reopening.
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- *** Bug 67190 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/67191] New: [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191
Bug ID: 67191
Summary: [6 Regression] ICE: in before_dom_children, at
tree-ssa-sccvn.c:4372
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
r226801 causes:
trippels@gcc2-power8 tools % ~/gcc_test/usr/local/bin/g++ -ftemplate-depth-128
-O3 -finline-functions -Wno-inline -Wall -pedantic -fPIC -m64 -pedantic
-Wstrict-aliasing -fstrict-aliasing -Wextra -Wsign-promo -Wunused-parameter
-Wconversion -Wfloat-equal -Wshadow -Wno-long-long -DBOOST_ALL_NO_LIB=1
-DNDEBUG -I.. -c -o
/home/trippels/boost_testing/results/boost/bin.v2/libs/unordered/test/unordered/fwd_set_test.test/gcc-6.0.0/release/fwd_set_test.o
../libs/unordered/test/unordered/fwd_set_test.cpp
In file included from
../libs/unordered/test/unordered/../helpers/test.hpp:10:0,
from ../libs/unordered/test/unordered/fwd_set_test.cpp:61:
../libs/unordered/test/unordered/fwd_set_test.cpp: In member function ‘virtual
void use_multiset_fwd_declared_function_type::run()’:
../libs/unordered/test/unordered/fwd_set_test.cpp:96:21: internal compiler
error: in before_dom_children, at tree-ssa-sccvn.c:4372
UNORDERED_AUTO_TEST(use_multiset_fwd_declared_function) {
^
../boost/preprocessor/cat.hpp:29:34: note: in definition of macro
‘BOOST_PP_CAT_I’
#define BOOST_PP_CAT_I(a, b) a ## b
^
../libs/unordered/test/unordered/../helpers/test.hpp:24:10: note: in expansion
of macro ‘BOOST_PP_CAT’
void BOOST_PP_CAT(x, _type)::run() \
^
../libs/unordered/test/unordered/fwd_set_test.cpp:96:1: note: in expansion of
macro ‘UNORDERED_AUTO_TEST’
UNORDERED_AUTO_TEST(use_multiset_fwd_declared_function) {
^
0x10c518c7 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-sccvn.c:4371
0x110b0e2b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:177
0x10c53033 run_scc_vn(vn_lookup_kind)
../../gcc/gcc/tree-ssa-sccvn.c:4459
0x10c23503 execute
../../gcc/gcc/tree-ssa-pre.c:4847
Please submit a full bug report,
with preprocessed source if appropriate
reducing...
[Bug other/67099] Documentation --with-host-libstdcxx is outdated, mentions ppl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67099 --- Comment #2 from vries at gcc dot gnu.org --- If this ( https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00603.html ) gets approved, --with-host-libstdcxx will be removed, and we can mark this as resolved-wont-fix.
[Bug tree-optimization/67191] [6 Regression] ICE: in before_dom_children, at tree-ssa-sccvn.c:4372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67191
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-12
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
trippels@gcc2-power8 tools % cat fwd_set_test.ii
template typename class A;
template typename _Tp using __allocator_base = _Tp;
template class T, class = T, class = int, class = __allocator_baseint
class B;
template class T, class H, class P, class A
bool operator==(BT, H, P, A const , BT, H, P, A const );
template class T, class H, class P, class A
bool operator!=(BT, H, P, A const , BT, H, P, A const );
typedef Bint int_multiset;
int a;
template typename struct C {
C(int) {}
};
template typename struct D;
template typename struct K;
struct L : CADint, CAKint {
template typename First, typename Second
L(First, Second)
: CADint(0), CAKint(0) {}
};
template typename Node struct F {
typedef typename Node::node_pointer node_pointer;
node_pointer node_;
F();
F(typename Node::link_pointer p1) : node_(static_castnode_pointer(p1)) {}
void operator++() { node_ = 0; }
int operator!=(F p1) { return node_ != p1.node_; }
};
struct G {
typedef G *link_pointer;
};
struct H {
static int new_bucket_count(int) {
int b;
int *c = 0;
if (a)
b = *c;
return b;
}
};
class functions {
public:
functions(int, int) {}
~functions();
};
template typename Types struct table : functions {
typedef typename Types::policy policy;
typedef Types node_allocator;
typedef Ftypename Types::node iterator;
L allocators_;
int bucket_count_;
int size_;
typename Types::link_pointer get_previous_start() const;
iterator begin() const { return size_ ? get_previous_start() : 0; }
table(int, typename Types::hasher, typename Types::key_equal, node_allocator)
: functions(0, 0), allocators_(0, 0),
bucket_count_(policy::new_bucket_count(0)), size_() {}
};
template typename struct K : G { typedef K *node_pointer; };
struct I {
typedef G *link_pointer;
};
struct J {
typedef I::link_pointer link_pointer;
};
template typename struct D {
typedef int hasher;
typedef int key_equal;
typedef Kint node;
typedef J::link_pointer link_pointer;
typedef H policy;
};
struct M : tableDint {
node_allocator grouped_table_impl_a;
M(int, int) : table(0, 0, 0, grouped_table_impl_a) {}
void equals(M const ) const {
for (iterator d = begin(); d.node_;) {
iterator e;
group_equals(e);
}
}
static int group_equals(iterator p1) {
int f;
iterator g;
for (; g != p1; ++g)
if (find())
if (f)
return 0;
}
static int find();
};
template class, class, class, class class B {
M table_;
public:
B(unsigned long = 0);
friend bool operator==(B const , B const );
friend bool operator!=(B const , B const );
};
template class T, class H, class P, class A
BT, H, P, A::B(unsigned long)
: table_(0, 0) {}
template class T, class H, class P, class A
bool operator==(BT, H, P, A const p1, BT, H, P, A const p2) {
p1.table_.equals(p2.table_);
}
template class T, class H, class P, class A
bool operator!=(BT, H, P, A const p1, BT, H, P, A const p2) {
p1.table_.equals(p2.table_);
}
void use_multiset_fwd_declared_function_typerun() {
int_multiset x, y;
x == y;
x != y;
}
trippels@gcc2-power8 tools % g++ -O2 -c fwd_set_test.ii
fwd_set_test.ii: In function ‘void
use_multiset_fwd_declared_function_typerun()’:
fwd_set_test.ii:111:6: internal compiler error: in before_dom_children, at
tree-ssa-sccvn.c:4372
void use_multiset_fwd_declared_function_typerun() {
^
[Bug c++/52742] Initializing an array using brace initializer and template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52742 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 12 17:18:14 2015 New Revision: 226824 URL: https://gcc.gnu.org/viewcvs?rev=226824root=gccview=rev Log: 2015-08-12 Paolo Carlini paolo.carl...@oracle.com PR c++/52742 * g++.dg/cpp0x/pr52742.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr52742.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/67161] [5/6 Regression] ICE with a static_assert using our internal __not/__or/__and traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67161 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 12 17:33:39 2015 New Revision: 226827 URL: https://gcc.gnu.org/viewcvs?rev=226827root=gccview=rev Log: PR c++/67161 * error.c (dump_decl) [TEMPLATE_ID_EXPR]: Pass TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug c++/67195] New: cpp and g++ does not define __GLIBCXX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67195 Bug ID: 67195 Summary: cpp and g++ does not define __GLIBCXX__ Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: noloader at gmail dot com Target Milestone: --- I'm trying to detect a debug build, and enjoy the benefit of additional instrumentation: # Debug testing ifneq ($(filter -DDEBUG -DDEBUG=1 -O0 -O1 -Og,$(CXXFLAGS)),) CXXFLAGS += -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_CONCEPT_CHECKS=1 endif # Debug build According to Chapter 3. Using Macros (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html): __GLIBCXX__ The current version of libstdc++ in compressed ISO date format, as an unsigned long. However, on Fedora22 x86_64: $ cpp -x c++ -dM /dev/null | grep -i lib $ cpp -x c++ -dM /dev/null | grep -i c++ #define __GLIBCXX_BITSIZE_INT_N_0 128 #define __GLIBCXX_TYPE_INT_N_0 __int128 $ cpp -x c++ -dM /dev/null | grep -i cxx #define __GLIBCXX_BITSIZE_INT_N_0 128 #define __GLIBCXX_TYPE_INT_N_0 __int128 $ g++ -E -dM - /dev/null | grep -i lib $ g++ -E -dM - /dev/null | grep -i c++ $ g++ -E -dM - /dev/null | grep -i cxx $ - $ uname -a Linux localhost.localdomain 4.1.3-201.fc22.x86_64 #1 SMP Wed Jul 29 19:50:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ g++ --version g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4) Copyright (C) 2015 Free Software Foundation, Inc
[Bug c++/67108] [6 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1345 when dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67108 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- -Wtautological-compare has been added to GCC 6. -Wlogical-op is older, but the part of it that warns about i i is new and has only been added to GCC 6. I agree about closing the bug now, BTW.
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #18 from Yann Collet yann.collet.73 at gmail dot com --- This issue makes me wonder : how to efficiently access unaligned memory ? The case in point is ARM cpu. They don't support SSE/AVX, so they seem unaffected by this specific issue, but this issue force writing the source code in a certain way, to remain compatible with vectorizer assumtion. Therefore, for portable code, it becomes an issue : how to write a code which is both portable and efficient on both targets ? Since apparently, writing : u32 = *(U32*)ptr; is forbidden if ptr is not guaranteed to be aligned on 4-bytes boundaries as the compiler will then be authorized to assume ptr is properly aligned, how to efficiently load 4-bytes from memory at unaligned position ? I know 3 ways : 1) byte by byte : secure, but slow == not efficient 2) using memcpy : memcpy(u32, ptr, sizeof(u32)); It works. It's safe, and on x86/x64 it's correctly translated into a single mov instruction, so it's also fast. Alas, on ARM target, this get translated into much more complex /cautious sequence, depending on optimization settings. This is not a small difference : at -O3 settings, we get a x2 performance difference. at -O2 settings, it becomes x5 (unaligned code is slower). 3) using __packed instruction : Basically, feature the same benefits and problems than memcpy() method above The problem is therefore for newer ARM CPU, which efficiently support unaligned memory. Accessing this performance is not possible using memcpy() nor __packed. And it seems the only way to get it is to do : u32 = *(U32*)ptr; The difference in performance is really huge, in fact it totally changes the application, so it can't be ignored. The question is : Is there a way to access this performance without violating the principle which has been stated into this thread, that is : it's not authorized to write : u32 = *(U32*)ptr; if ptr is not guaranteed to be properly aligned on 4-bytes boundaries.
[Bug tree-optimization/67196] New: Another false positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196 Bug ID: 67196 Summary: Another false positive from -Wmaybe-uninitialized Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 36176 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36176action=edit Reproducer The attached generates a false -Wmaybe-uninitialized warning: $ gcc -O1 -Wall -c diagnostic.cc diagnostic.cc: In function ‘void test(int)’: diagnostic.cc:28:28: warning: ‘first_caption_idx’ may be used uninitialized in this function [-Wmaybe-uninitialized] foo (first_caption_idx); /* get bogus warning here at -O1 and above */ ^ Seen with gcc 4.8.3 and with trunk (specifically, r226697).
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Marek Polacek mpolacek at gcc dot gnu.org --- Hopefully fixed for good.
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #19 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Aug 12 17:25:23 2015 New Revision: 226826 URL: https://gcc.gnu.org/viewcvs?rev=226826root=gccview=rev Log: PR c++/55095 * c-common.c (maybe_warn_shift_overflow): Properly handle left-shifting 1 into the sign bit. * c-c++-common/Wshift-overflow-6.c: New test. * c-c++-common/Wshift-overflow-7.c: New test. * g++.dg/cpp1y/left-shift-2.C: New test. Added: trunk/gcc/testsuite/c-c++-common/Wshift-overflow-6.c trunk/gcc/testsuite/c-c++-common/Wshift-overflow-7.c trunk/gcc/testsuite/g++.dg/cpp1y/left-shift-2.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Marek, could you please add to the audit trail which warnings work in which version of GCC? Thanks in advance! About the remaining case, I would be tempted to close the bug or maybe we could first ask other maintainers...
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #19 from Jeffrey Walton noloader at gmail dot com --- (In reply to Yann Collet from comment #18) This issue makes me wonder : how to efficiently access unaligned memory ? The case in point is ARM cpu. They don't support SSE/AVX, so they seem unaffected by this specific issue, but this issue force writing the source code in a certain way, to remain compatible with vectorizer assumtion. Just one comment here (sorry for speaking out of turn) Modern ARM has __ARM_FEATURE_UNALIGNED, which means the processor tolerates unaligned access. However, I believe it runs afoul of the C/C++ standard and GCC aliasing rules. Therefore, for portable code, it becomes an issue : how to write a code which is both portable and efficient on both targets ? I've been relying on intrinsics to side step C/C++ requirements. In the absence of intrinsics, I use inline assembler to avoid the C/C++ language rules. Now, I could be totally wrong, but I don't feel I'm violating the C/C++ language rules until a write a C/C++ statement that performs the violation. Hence the reason I use intrinsics or drop into assembler.
[Bug c++/67161] [5/6 Regression] ICE with a static_assert using our internal __not/__or/__and traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67161 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 12 18:05:49 2015 New Revision: 226831 URL: https://gcc.gnu.org/viewcvs?rev=226831root=gccview=rev Log: PR c++/67161 * error.c (dump_decl) [TEMPLATE_ID_EXPR]: Pass TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ44.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/error.c
[Bug c++/67104] [5/6 regression] Constant expression factory function initializes std::array with static storage duration strangely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67104 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 12 18:08:45 2015 New Revision: 226833 URL: https://gcc.gnu.org/viewcvs?rev=226833root=gccview=rev Log: PR c++/67104 * constexpr.c (cxx_eval_array_reference): Fix typo. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/67161] [5/6 Regression] ICE with a static_assert using our internal __not/__or/__and traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67161 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
