[Bug tree-optimization/67199] ICE with compile bug related to vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67199 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- This seems to be fixed in all active branches.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #4 from Sujoy --- Yes, I agree to your comment. With -fno-signaling-nans (which is the default), we need to fix the ccp so that the sNaN is converted to qNaN when the value is propagated. With -fsignaling-nans, we need to ensure that we disable the folding since it reduces the number of exceptions visible with sNaNs. I notice that even if I disable ccp, other optimizations like dead code elimination with cddce also needs to be disabled. Let me know if you agree.
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #25 from John Paul Adrian Glaubitz --- Ok, this seems to have been fixed: Comparing stages 2 and 3 warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs Comparison successful. gcc-5 is still building though and we might run into another issue, but cross your fingers :).
[Bug tree-optimization/66070] [GRAPHITE] cc1 gets killed by OOM killer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66070 Andrey Turkin changed: What|Removed |Added CC||andrey.turkin at gmail dot com --- Comment #1 from Andrey Turkin --- Created attachment 36177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36177&action=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 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 --- Author: amodra Date: Thu Aug 13 05:25:02 2015 New Revision: 226848 URL: https://gcc.gnu.org/viewcvs?rev=226848&root=gcc&view=rev Log: More split-stack fixes Backport rev 226443 2015-07-31 Alan Modra 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 * 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 * 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 * 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 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.
gcc-bugs@gcc.gnu.org
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=226847&root=gcc&view=rev Log: 2015-08-13 Naveen H.S 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 #61 from Bill Schmidt --- (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/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 for instructions
[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 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 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 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 changed: What|Removed |Added CC||boger at us dot ibm.com --- Comment #1 from Ian Lance Taylor --- I can't win. I deeply do not care about this type. Please sort it out with Lynn Boger. Thanks.
[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 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 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 changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #12 from Anton Blanchard ---
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 {
^
public unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x3fff76e01110
pointer_to_this >
decl_3 VOID file testcase.i line 4 col 15
align 1 offset_align 1 context
chain
nonlocal decl_4 VOID file testcase.i line 3 col 20
align 1 context result
chain >> context
full-name "struct bn_gencb_st"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
full-name "BN_GENCB"
n_parents=0 use_template=0 interface-unknown
pointer_to_this chain >
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 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0, 5.0 Resolution|--- |WORKSFORME --- Comment #5 from Paolo Carlini --- I'm adding a testcase and closing the bug.
[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 --- Author: paolo Date: Wed Aug 12 22:38:04 2015 New Revision: 226840 URL: https://gcc.gnu.org/viewcvs?rev=226840&root=gcc&view=rev Log: 2015-08-12 Paolo Carlini PR c++/53330 * g++.dg/init/new42.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new42.C Modified: trunk/gcc/testsuite/ChangeLog
[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 --- Author: meissner Date: Wed Aug 12 21:54:23 2015 New Revision: 226836 URL: https://gcc.gnu.org/viewcvs?rev=226836&root=gcc&view=rev Log: [gcc] 2015-08-12 Michael Meissner 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 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/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 --- 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 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 --- 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/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 --- 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 --- > 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 tree-optimization/67196] Another false positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196
Manuel López-Ibáñez 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 ---
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 inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 --- Comment #18 from Stas Sergeev --- (In reply to Andy Lutomirski from comment #17) > I'll chime in, possibly uselessly. > > Before Linux 4.1, only CS was saved. (Unless you go *way* back.) In 4.1 > or newer, SS is saved, too. > > In 64-bit code, DS and ES have no effect*, so I don't think it should affect > code gen. OK, so the problem is TLS-specific, and is therefore have less relevance to gcc. Indeed it then will be very good if the kernel can take care of TLS. My point was just that for gcc it may not be a big problem to implement a segreg clobbering, if the kernel devs don't want to restore TLS. > Anyway, I tend to agree with Andrew here, I think: if you want to fiddle > with FS and GS, write a little asm wrapper around the C code. Yes but what kind of wrapper? Should it do also the syscall to set the needed fs base? At one point I may start pestering glibc guys to provide such a wrapper, if everyone else is unhelpful. :)
[Bug bootstrap/67197] GCC_FINAL causes bootstrap failure on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67197 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-12 CC||tbsaunde at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug bootstrap/67197] New: GCC_FINAL causes bootstrap failure on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67197 Bug ID: 67197 Summary: GCC_FINAL causes bootstrap failure on AIX Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- In file included from /nasfarm/edelsohn/src/src/gcc/omp-low.c:31:0: /nasfarm/edelsohn/src/src/gcc/gimple.h: In function 'void gimple_call_set_fndecl(gimple, tree)': /nasfarm/edelsohn/src/src/gcc/gimple.h:2902:1: error: void gimple_call_set_fndecl(gimple, tree) causes a section type conflict with unsigned int gimple_omp_subcode(const_gimple) gimple_call_set_fndecl (gimple gs, tree decl) ^ /nasfarm/edelsohn/src/src/gcc/gimple.h:2131:1: note: 'unsigned int gimple_omp_subcode(const_gimple)' was declared here gimple_omp_subcode (const_gimple s)
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 Andy Lutomirski changed: What|Removed |Added CC||luto at mit dot edu --- Comment #17 from Andy Lutomirski --- I'll chime in, possibly uselessly. Before Linux 4.1, only CS was saved. (Unless you go *way* back.) In 4.1 or newer, SS is saved, too. In 64-bit code, DS and ES have no effect*, so I don't think it should affect code gen. FS and GS are weird, and they may get weirder when WRGSBASE and friends are enabled, which will happen at some point. Anyway, I tend to agree with Andrew here, I think: if you want to fiddle with FS and GS, write a little asm wrapper around the C code. * Except in an odd case on AMD processors that is mostly invisible to userspace. On new enough kernels, it's completely invisible to userspace, and I don't think it was ever visible without long jumps or such.
[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=36176&action=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 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 --- (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 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 --- 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 c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 --- Comment #7 from Marek Polacek --- I meant "agree with closing".
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #6 from Jason Merrill --- Fixed.
[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 --- Author: jason Date: Wed Aug 12 18:08:45 2015 New Revision: 226833 URL: https://gcc.gnu.org/viewcvs?rev=226833&root=gcc&view=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++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 --- Comment #6 from Marek Polacek --- -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 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 --- Author: jason Date: Wed Aug 12 18:05:49 2015 New Revision: 226831 URL: https://gcc.gnu.org/viewcvs?rev=226831&root=gcc&view=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++/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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jason Merrill --- Fixed.
[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 #7 from Jason Merrill --- Author: jason Date: Wed Aug 12 18:02:43 2015 New Revision: 226830 URL: https://gcc.gnu.org/viewcvs?rev=226830&root=gcc&view=rev Log: PR c++/67104 * constexpr.c (cxx_eval_array_reference): Handle sparse CONSTRUCTORs. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-array1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[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 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed Aug 12 18:02:35 2015 New Revision: 226829 URL: https://gcc.gnu.org/viewcvs?rev=226829&root=gcc&view=rev Log: PR c++/67108 * decl2.c (c_parse_final_cleanups): Set at_eof to 2 at end. * error.c (dump_template_bindings): Don't tsubst in that case. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-targ3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c 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++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Paolo Carlini changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #5 from Paolo Carlini --- 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 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 --- Author: jason Date: Wed Aug 12 17:33:39 2015 New Revision: 226827 URL: https://gcc.gnu.org/viewcvs?rev=226827&root=gcc&view=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++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 Marek Polacek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Marek Polacek --- Hopefully fixed for good.
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #19 from Marek Polacek --- Author: mpolacek Date: Wed Aug 12 17:25:23 2015 New Revision: 226826 URL: https://gcc.gnu.org/viewcvs?rev=226826&root=gcc&view=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 middle-end/67194] New: Missed jump thread and false positive from -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67194
Bug ID: 67194
Summary: Missed jump thread and false positive from
-Wuninitialized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Extracted from bz55035:
Reconfirmed.
Nowadays (trunk@221914) also breaks all-gcc for nios2-linux-gnu.
Reminds me of bug #36550
Smallish testcase:
$ cat reload1.i ; echo EOF
/* PR target/55035 */
/* { dg-do compile } */
/* { dg-options "-O2 -W -Wall -Werror" } */
struct rtx_def;
typedef struct rtx_def *rtx;
enum rtx_code {
UNKNOWN,
INSN,
ASM_INPUT,
CLOBBER
};
struct rtx_def {
enum rtx_code code: 4;
};
class rtx_def;
class rtx_insn : public rtx_def {};
struct recog_data_d
{
rtx operand[30];
rtx *operand_loc[30];
rtx *dup_loc[1];
char dup_num[1];
char n_operands;
char n_dups;
};
extern struct recog_data_d recog_data;
extern int get_int(void);
void
elimination_costs_in_insn (rtx_insn *insn)
{
int icode = get_int ();
int i;
rtx orig_operand[30];
rtx orig_dup[30];
if (icode < 0)
{
if (((enum rtx_code) insn->code) == INSN)
__builtin_abort();
return;
}
for (i = 0; i < recog_data.n_dups; i++)
orig_dup[i] = *recog_data.dup_loc[i];
for (i = 0; i < recog_data.n_operands; i++)
{
orig_operand[i] = recog_data.operand[i];
if (orig_operand[i]->code == CLOBBER)
*recog_data.operand_loc[i] = 0;
}
for (i = 0; i < recog_data.n_dups; i++)
*recog_data.dup_loc[i]
= *recog_data.operand_loc[(int) recog_data.dup_num[i]];
for (i = 0; i < recog_data.n_dups; i++)
*recog_data.dup_loc[i] = orig_dup[i];
}
EOF
$ g++ -O2 -W -Wall -Werror -c reload1.i -o reload1.o
reload1.i: In function ‘void elimination_costs_in_insn(rtx_insn*)’:
reload1.i:53:41: error: ‘orig_dup[0]’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
*recog_data.dup_loc[i] = orig_dup[i];
^
cc1plus: all warnings being treated as errors
And a second, related testcase:
typedef struct rtx_def *rtx;
struct recog_data_d
{
rtx operand;
char n_dups;
};
rtx *operand_loc;
rtx dup_loc;
struct recog_data_d recog_data;
void elimination_costs_in_insn ()
{
rtx orig_dup;
if (recog_data.n_dups)
orig_dup = dup_loc;
*operand_loc = 0;
if (recog_data.n_dups)
dup_loc = orig_dup;
}
A warning is issued even at -O1. If I remove "rtx operand" field from struct
recog_data_d (or if I change the type of n_dups to int), then it disappears at
-O2 (but still present at -O1).
In both cases the -Wuninitialized warning is bogus and points to a miss jump
threading opportunity.
[Bug c++/52742] Initializing an array using brace initializer and template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52742 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC|M at ttDiesel dot co.uk| Resolution|--- |FIXED Target Milestone|--- |4.8.1 --- Comment #5 from Paolo Carlini --- Closing.
[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 --- Author: paolo Date: Wed Aug 12 17:18:14 2015 New Revision: 226824 URL: https://gcc.gnu.org/viewcvs?rev=226824&root=gcc&view=rev Log: 2015-08-12 Paolo Carlini 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++/66941] Missing diagnostic "extraneous template parameter list in template specialization"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66941 Mikhail Maltsev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mikhail Maltsev --- 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 changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #3 from Mikhail Maltsev --- *** 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 --- (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++/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
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 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=226820&root=gcc&view=rev Log: Fix warnings when bootstrapping on darwin with vtable verification enabled. libstdc++-v3/ChangeLog: 2015-08-11 Caroline Tice 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 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 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/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=226819&root=gcc&view=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries 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=226819&root=gcc&view=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries 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/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=226819&root=gcc&view=rev Log: Remove --with-host-libstdcxx 2015-08-12 Tom de Vries 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 c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Paolo Carlini changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #3 from Paolo Carlini --- Maybe Marek is interested (beyond -Wtautological-compare)
[Bug c++/49409] some possible new warnings for strange code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49409 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- 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 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;
:
[foo.c:10:11] D.1415 = bar ();
[foo.c:10:10] if (D.1415 != 0) goto ; else goto ;
:
[foo.c:11:2] goto ;
:
[foo.c:12:7] baz ();
[foo.c:14:3] goto ; /* <== WRONG! Should be [foo.c:13:5]. */
:
[foo.c:14:3] baz ();
}
[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 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++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Paolo Carlini --- Done.
[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 --- Author: paolo Date: Wed Aug 12 14:47:58 2015 New Revision: 226816 URL: https://gcc.gnu.org/viewcvs?rev=226816&root=gcc&view=rev Log: 2015-08-12 Paolo Carlini 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 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 changed:
What|Removed |Added
CC||antoine.balestrat at gmail dot
com
--- Comment #5 from Antoine Balestrat ---
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 for instructions.
[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 --- (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 --- Comment #3 from Richard Biener --- 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 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 --- Hmm, doesn't reproduce on x86_64 for me. Anyway mine, hopefully we'll get a x86_64 testcase as well.
[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 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 fortran/35234] Undetected "use before definition".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35234 Manuel López-Ibáñez 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 --- (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
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-12
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
trippels@gcc2-power8 tools % cat fwd_set_test.ii
template class A;
template using __allocator_base = _Tp;
template >
class B;
template
bool operator==(B const &, B const &);
template
bool operator!=(B const &, B const &);
typedef B int_multiset;
int a;
template struct C {
C(int) {}
};
template struct D;
template struct K;
struct L : C>>, C>> {
template
L(First, Second)
: C>>(0), C>>(0) {}
};
template struct F {
typedef typename Node::node_pointer node_pointer;
node_pointer node_;
F();
F(typename Node::link_pointer p1) : node_(static_cast(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 struct table : functions {
typedef typename Types::policy policy;
typedef Types node_allocator;
typedef F 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 struct K : G { typedef K *node_pointer; };
struct I {
typedef G *link_pointer;
};
struct J {
typedef I::link_pointer link_pointer;
};
template struct D {
typedef int hasher;
typedef int key_equal;
typedef K node;
typedef J::link_pointer link_pointer;
typedef H policy;
};
struct M : table> {
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 B {
M table_;
public:
B(unsigned long = 0);
friend bool operator==<>(B const &, B const &);
friend bool operator!=<>(B const &, B const &);
};
template
B::B(unsigned long)
: table_(0, 0) {}
template
bool operator==(B const &p1, B const &p2) {
p1.table_.equals(p2.table_);
}
template
bool operator!=(B const &p1, B 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++/47461] warn_unused_result attribute ignored for templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47461 --- Comment #3 from Paolo Carlini --- Let's add a testcase and close the bug.
[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 ---
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 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 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 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 c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 --- Comment #18 from Marek Polacek --- Testing a fix for the sign bit problem.
[Bug c++/55095] Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095 Marek Polacek changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #17 from Marek Polacek --- Reopening.
[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 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 --- Author: yroux Date: Wed Aug 12 13:27:41 2015 New Revision: 226811 URL: https://gcc.gnu.org/viewcvs?rev=226811&root=gcc&view=rev Log: 2015-08-12 Yvan Roux 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++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 Marc Glisse changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #1 from Marc Glisse --- *** Bug 67190 has been marked as a duplicate of this bug. ***
[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 --- (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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marc Glisse --- Dup *** This bug has been marked as a duplicate of bug 63809 ***
[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 --- -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 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
struct vector
{};
template
struct z
{};
template <>
template <> // extra
struct z >
{};
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.
1>main.cpp(44): error C2910: 'z>' : cannot be explicitly specialized
Clang accepts this code, but it gives a warning: "extraneous template parameter
list in template specialization".
[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 changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- I fixed this for 4.9. Closing as fixed thus.
[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/27120] Should warn about uninitialized use of variable array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- We now warn even for the first testcase in Description (both C and C++).
[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/25702] feature request: generate a warning for sizeof on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- I think -Wsizeof-pointer-memaccess should be enough for this PR be closed now.
[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 --- We now warn for the testcase in Comment 2.
[Bug c/55892] Bogus compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55892 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- With current trunk I get two warnings, on line 33 and on line 34. I guess fixed then.
[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 changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #6 from Markus Trippelsdorf ---
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++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Markus Trippelsdorf --- (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++/65143] [C++11] missing devirtualization for virtual base in "final" classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143 Markus Trippelsdorf changed: What|Removed |Added CC||gpderetta at gmail dot com --- Comment #5 from Markus Trippelsdorf --- *** 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 Paolo Carlini changed: What|Removed |Added CC|gpderetta at gmail dot com | --- Comment #2 from Paolo Carlini --- Related to c++/65143.
[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 --- 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 bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66801 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Markus Trippelsdorf --- 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf --- Cannot reproduce the issue anymore. Closing.
[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 --- 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 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 changed: What|Removed |Added Component|c |preprocessor --- Comment #3 from Marek Polacek --- Sorry, I meant to say that the warning about the redefinition seems in place to me.
