[Bug rtl-optimization/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Andrew M. changed: What|Removed |Added Component|target |rtl-optimization --- Comment #4 from Andrew M. --- SSE2/AVX/AVX2 are all generated similarly poorly. Non-SIMD versions do not appear to be affected. I don't know enough (anything) about gcc to investigate any further at this point
[Bug c++/77347] [6/7 Regression] Incorrect auto deduction failure in template class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77347 --- Comment #4 from Jakub Jelinek --- Note your testcase is invalid due to [dcl.spec.auto]/7: "If the init-declarator-list contains more than one init-declarator, they shall all form declarations of variables."
[Bug c++/77347] [6/7 Regression] Incorrect auto deduction failure in template class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77347 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- This is the same bug as PR78693. *** This bug has been marked as a duplicate of bug 78693 ***
[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693 Jakub Jelinek changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #4 from Jakub Jelinek --- *** Bug 77347 has been marked as a duplicate of this bug. ***
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #3 from Andrew M. --- Created attachment 40443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40443&action=edit generated code for gcc-6.3 example.c -O1
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #2 from Andrew M. --- Created attachment 40442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40442&action=edit generated code for gcc-4.9.4 example.c -O1
[Bug target/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #1 from Andrew M. --- gcc versions >= 5 started dropping all of the additions down to the bottom of the function instead of keeping a running total. Optimization appears to follow 4.x.x up to tree-reassoc1 where >= 5 uses slightly different addition scheduling. This stays the same until rtl-expand, where _all_ of the additions get deferred to the bottom of the function, requiring a massive stack frame and a large performance hit. No version of 4.x.x I tried had this problem, so it looks like it was introduced in 5.
[Bug c++/71166] [7 Regression] ICE with nested constexpr/initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71166 --- Comment #10 from Jakub Jelinek --- At this point it is getting too late to reconsider VEC_INIT_EXPR for GCC 7, so shall we apply the fix from GCC 7 to trunk too?
[Bug rtl-optimization/78972] New: [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Bug ID: 78972 Summary: [5/6/7 Regression] poor x86 simd instruction scheduling Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: liquidsun at gmail dot com Target Milestone: --- Created attachment 40441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40441&action=edit example.c
[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/78965] [7 Regression] Invalid -fprintf-return-value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78965 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/78965] [7 Regression] Invalid -fprintf-return-value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78965 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Jan 3 07:23:11 2017 New Revision: 244014 URL: https://gcc.gnu.org/viewcvs?rev=244014&root=gcc&view=rev Log: PR tree-optimization/78965 * gimple-ssa-sprintf.c (pass_sprintf_length::compute_format_length): Change first argument from const call_info & to call_info &. For %n set info.nowrite to false. * gcc.dg/pr78965.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78965.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/78901] [7 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Tue Jan 3 07:20:04 2017 New Revision: 244013 URL: https://gcc.gnu.org/viewcvs?rev=244013&root=gcc&view=rev Log: PR middle-end/78901 * gimple-ssa-sprintf.c (try_substitute_return_value): Don't change possibly throwing calls. * g++.dg/opt/pr78901.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr78901.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969 --- Comment #2 from Andrew Pinski --- I think there might be a dup of this bug already. basically VRP does a copy prop of where the assert was. get_range_info is not position sensitive so the range is gone after VRP.
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 --- Comment #1 from Andrew Pinski --- There is to check if there is a constructor which converts X. There might be a C++ Defect report about this case too.
[Bug other/78971] ggc-min-expand default value is probably obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971 --- Comment #2 from Aurelien Jarno --- (In reply to Andrew Pinski from comment #1) > Actually it would be better if we reduce the need to allocate as much memory. > > >In 2017 it's quite common to have a machine with 1GB of RAM. > > Actually is is quite common to have a machine with more than 32G of memory > especially servers. Yes, exactly my point. It means the heuristic now almost always uses the same value, that is 100%. > But really ggc-min-expand is not the problem rather the amount of GC memory > being allocated. Ok. I'll do that.
[Bug other/78971] ggc-min-expand default value is probably obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971 --- Comment #1 from Andrew Pinski --- Actually it would be better if we reduce the need to allocate as much memory. >In 2017 it's quite common to have a machine with 1GB of RAM. Actually is is quite common to have a machine with more than 32G of memory especially servers. But really ggc-min-expand is not the problem rather the amount of GC memory being allocated. Please file a bug for each case instead.
[Bug other/78971] New: ggc-min-expand default value is probably obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971 Bug ID: 78971 Summary: ggc-min-expand default value is probably obsolete Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: aurelien at aurel32 dot net Target Milestone: --- According to the manpage (and to the code) the default ggc-min-expand value defaults to: "30% + 70% * (RAM/1GB) with an upper bound of 100% when RAM >= 1GB." In 2017 it's quite common to have a machine with 1GB of RAM, especially on a machine used to compile code. For example both the Raspberry Pi 2 and 3 have 1GB of RAM. I therefore think this default should be updated. On 32-bit machines, it's getting more and more common to get a "virtual memory exhausted: Cannot allocate memory" error and not be able to compile some code. This is especially true on MIPS32 as the virtual memory space is limited to 2GB. A workaround is to use --ggc-min-expand=20, which shows the default value is not optimal.
[Bug target/78967] inserts are not effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78967 Uroš Bizjak changed: What|Removed |Added Target||x86 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Uroš Bizjak --- Fixed.
[Bug target/78967] inserts are not effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78967 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jan 2 22:08:18 2017 New Revision: 244006 URL: https://gcc.gnu.org/viewcvs?rev=244006&root=gcc&view=rev Log: target/78967 * config/i386/i386.md (UNSPEC_NOREX_MEM): New unspec. (*insvqi_1): New insn pattern. (*insvqi_1_mem_rex64): Ditto. (*insvqi_2): Ditto. (*insvqi_3): Rename from *insvqi. (*extzvqi_mem_rex64): Add UNSPEC_NOREX_MEM tag. testsuite/ChangeLog: PR target/78967 * gcc.target/i386/pr78967-1.c: New test. * gcc.target/i386/pr78967-2.c: Ditto. * gcc.target/i386/pr78967-3.c: Ditto. * gcc.target/i386/pr78904-2.c: Tighten scan-asm patterns. * gcc.target/i386/pr78904-4.c: Ditto. * gcc.target/i386/pr78904-6.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr78967-1.c trunk/gcc/testsuite/gcc.target/i386/pr78967-2.c trunk/gcc/testsuite/gcc.target/i386/pr78967-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr78904-2.c trunk/gcc/testsuite/gcc.target/i386/pr78904-4.c trunk/gcc/testsuite/gcc.target/i386/pr78904-6.c
[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826 --- Comment #4 from Yuri Gribov --- As this is not a GCC bug I suggest you * close this issue (as not-a-bug?) * report to Glibc folks (perhaps they could do more checking of return address or at least document their calling convention assumptions in manpages)
[Bug tree-optimization/66826] Unused result from dlsym in constructor results in a segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #3 from Yuri Gribov ---
This is a very funny bug but not related to GCC per se. Firstly, let's consider
a miminal repro:
__attribute__((constructor)) static void some_init() {
dlsym(RTLD_DEFAULT, "anything");
}
(segfaults just as well). Under -O0 this produces a normal call:
calldlsym@PLT
...
ret
but with -O2 GCC is clever enough to tail-call-optimize it to a plain jump:
jmp dlsym@PLT
Now dlsym (and other dl-functions) secretly take shadow parameter - return
address on stack:
void *
__dlsym (void *handle, const char *name DL_CALLER_DECL)
{
...
struct dlsym_args args;
args.who = DL_CALLER;
args.handle = handle;
args.name = name;
(from dlsym.c). As in our case return address is missing, args.who argument is
missing which causes segfault during symbol resolution (dynamic linker is lame
on checks).
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880
--- Comment #7 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #6)
> Additional data points:
>
> - The ICE in comment #4 can be reproduced with
>
> character(:), dimension(:), pointer :: p => NULL()
> write(*,*) size(p)! ICE
> write(*,*) len(p) ! ICE
> end
The ICE is generated by the assert at trans-decl.c:1738
/* Associate names can use the hidden string length variable
of their associated target. */
if (sym->ts.type == BT_CHARACTER
&& TREE_CODE (length) != INTEGER_CST)
{
gfc_finish_var_decl (length, sym);
gcc_assert (!sym->value);
}
It does not show up when the initialization is removed,
or when the "pointer" is replaced by "allocatable".
[Bug c/78970] New: GCC crashes if input file is dash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970 Bug ID: 78970 Summary: GCC crashes if input file is dash Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: guriev-ns at ya dot ru Target Milestone: --- GCC with an input file as hyphen crashes when it tries to process a C/C++ header. But it perfectly works if the argument is a normal file name (even link `/dev/stdin`). mymedia@comp2:/tmp/tmp.kRcQNR9Tky$ ls -A test.h mymedia@comp2:/tmp/tmp.kRcQNR9Tky$ cat test.h #include mymedia@comp2:/tmp/tmp.kRcQNR9Tky$ /usr/lib/gcc-snapshot/bin/gcc -x c-header -o /dev/null test.h mymedia@comp2:/tmp/tmp.kRcQNR9Tky$ /usr/lib/gcc-snapshot/bin/gcc -x c-header -o /dev/null /dev/stdin :1:0: internal compiler error: Segmentation fault 0xb7364f crash_signal ../../src/gcc/toplev.c:333 0x13f275b md5_stream ../../src/libiberty/md5.c:158 0x13bcc9d _cpp_save_file_entries ../../src/libcpp/files.c:1889 0x13cb44f cpp_write_pch_state(cpp_reader*, _IO_FILE*) ../../src/libcpp/pch.c:383 0x6c0cce c_common_write_pch() ../../src/gcc/c-family/c-pch.c:186 0x6c0857 c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1103 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. mymedia@comp2:/tmp/tmp.kRcQNR9Tky$ /usr/lib/gcc-snapshot/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/7.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 20161231-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.0.0 20161231 (experimental) [trunk revision 243987] (Ubuntu 20161231-1ubuntu1) mymedia@comp2:/tmp/tmp.kRcQNR9Tky$
[Bug tree-optimization/69908] recognizing idioms that check for a buffer of all-zeros could make *much* better code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov --- It would be nice if there was a standard API for expressing the pattern. This could be both tuned for particular target in std. library and recognized/optimized by compiler. FreeBSD seems to have memcchr (https://www.freebsd.org/cgi/man.cgi?query=memcchr) so I've risked filing request at Glibc folks (https://sourceware.org/bugzilla/show_bug.cgi?id=21018).
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #6 from Harald Anlauf --- Additional data points: - The ICE in comment #4 can be reproduced with character(:), dimension(:), pointer :: p => NULL() write(*,*) size(p)! ICE write(*,*) len(p) ! ICE end - The bug in the other comments also shows up when one replaces character(:), dimension(:), allocatable, target :: c by character(1), dimension(:), allocatable, target :: c
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #6 from Rich Felker --- Created attachment 40440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40440&action=edit updated patch for gcc 6.3.0 Issue confirmed. The patch from April 2015 does not apply to current gcc, but here's an updated version that works for me.
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #16 from Jan Hubicka --- >run-old.resultrun-new.result > f416.gamess 6.55s6.70s ( 2.29%, -2.24% ) > i400.perlbench 7.17s7.37s ( 2.79%, -2.71% ) > i445.gobmk 3.64s3.55s ( -2.47%, 2.54% ) > i458.sjeng 3.83s3.75s ( -2.09%, 2.13% ) > i473.astar 7.33s7.62s ( 3.96%, -3.81% ) I can imagine perlbench to have indirect call in the internal loop, but the other benchmarks may be just a noise for reducing the hitrate down. > i483.xalancbmk 7.47s8.06s ( 7.90%, -7.32% ) This however is probably a bug. Does it help to change the direction of predictor for polymorphic calls back to likely not taken? Index: predict.c === --- predict.c (revision 244002) +++ predict.c (working copy) @@ -2789,7 +2789,7 @@ tree_estimate_probability_bb (basic_bloc if (gimple_call_fndecl (stmt)) predict_edge_def (e, PRED_CALL, NOT_TAKEN); else if (virtual_method_call_p (gimple_call_fn (stmt))) - predict_edge_def (e, PRED_POLYMORPHIC_CALL, TAKEN); + predict_edge_def (e, PRED_POLYMORPHIC_CALL, NOT_TAKEN); else predict_edge_def (e, PRED_INDIR_CALL, TAKEN); break; Honza
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #14 from Janne Blomqvist --- Author: jb Date: Mon Jan 2 20:00:18 2017 New Revision: 244003 URL: https://gcc.gnu.org/viewcvs?rev=244003&root=gcc&view=rev Log: PR 78534 Modify string copy to avoid -Wstringop-overflow warning When the character length is changed from int to size_t the existing algorithm causes a -Wstringop-overflow warning with -O1 on the gfortran.dg/allocate_deferred_char_scalar_1.f03 testcase. This change is committed separately from the character length size change in order to make bisecting potential performance issues easier. 2017-01-02 Janne Blomqvist PR fortran/78534 * trans-expr.c (gfc_trans_string_copy): Rework string copy algorithm to avoid -Wstringop-overflow warning. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug tree-optimization/78969] bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic,
||missed-optimization
--- Comment #1 from Martin Sebor ---
The same underlying problem (lack of range info) can be seen in the VRP dump
for the following test case. The -Walloca-larger-than option is interesting
because the alloca pass that implements it tries to compensate for the missing
range info by deriving it from conditions the alloca() argument is subjected to
(see the alloca_call_type_by_arg function). Although the logic it uses is
quite simple in this case it manages to successfully determine the range on its
own and avoids the warning.
$ cat t.c && gcc -O2 -S -Wall -Walloca-larger-than=255
-fdump-tree-vrp=/dev/stdout t.c
void foo (void*);
void f (unsigned long j)
{
if (j / 256)
return;
foo (__builtin_alloca (j));
}
;; Function f (f, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_7 -> { j_3(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)
Value ranges after VRP:
_1: ~[0B, 0B]
.MEM_2: VARYING
j_3(D): VARYING
j_7: [0, 255] EQUIVALENCES: { j_3(D) } (1 elements)
f (long unsigned int j)
{
void * _1;
[100.00%]:
if (j_3(D) > 255)
goto ; [51.01%]
else
goto ; [48.99%]
[48.99%]:
_1 = __builtin_alloca (j_3(D));
foo (_1);
[100.00%]:
return;
}
;; Function f (f, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_7 -> { j_3(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)
Value ranges after VRP:
_1: ~[0B, 0B]
.MEM_2: VARYING
j_3(D): VARYING
j_7: [0, 255] EQUIVALENCES: { j_3(D) } (1 elements)
f (long unsigned int j)
{
void * _1;
[100.00%]:
if (j_3(D) > 255)
goto ; [51.01%]
else
goto ; [48.99%]
[48.99%]:
_1 = __builtin_alloca (j_3(D));
foo (_1);
[100.00%]:
return;
}
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #9 from John Paul Adrian Glaubitz --- (In reply to Mikael Pettersson from comment #8) > Created attachment 40362 [details] > patch adding -mlong-jump-table-offsets option for m68k > > This is the crude patch I mentioned in an older comment, forward-ported to > trunk. It's only a compile-time option for using long offsets, plus needed > adjustments here and there. Sounds good. I can give it a try in the following days or weeks and see if I can get a C code with such large switch statements compiled.
[Bug tree-optimization/78969] New: bogus snprintf truncation warning due to missing range info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78969
Bug ID: 78969
Summary: bogus snprintf truncation warning due to missing range
info
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In both functions in the following test case the %3u argument to snprintf is in
the range [0, 999] and so the directive writes exactly 3 bytes into the
destination buffer of size 4. As the VRP dump shows, GCC exposes that range to
the -Wformat-length checker via the get_range_info() function in the call in
function f() allowing it to avoid a warning. But in the call in function g(),
even though the same range is also known, it's not made available for the
argument to the directive, resulting in a false positive.
$ cat t.c && gcc -O2 -S -Wall -Wformat-length=2 -fdump-tree-vrp=/dev/stdout t.c
void f (unsigned j, char *p)
{
if (j > 999)
j = 0;
__builtin_snprintf (p, 4, "%3u", j);
}
void g (unsigned j, char *p)
{
if (j > 999)
return;
__builtin_snprintf (p, 4, "%3u", j);
}
;; Function f (f, funcdef_no=0, decl_uid=1796, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_6 -> { j_2(D) }
j_7 -> { j_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 4 ( 67%)
Value ranges after VRP:
j_1: [0, 999] EQUIVALENCES: { } (0 elements)
j_2(D): VARYING
j_6: [1000, +INF] EQUIVALENCES: { j_2(D) } (1 elements)
j_7: [0, 999] EQUIVALENCES: { j_2(D) } (1 elements)
Removing basic block 3
f (unsigned int j, char * p)
{
[100.00%]:
if (j_2(D) > 999)
goto ; [54.00%]
else
goto ; [46.00%]
[46.00%]:
[100.00%]:
# j_1 = PHI
__builtin_snprintf (p_4(D), 4, "%3u", j_1);
return;
}
;; Function f (f, funcdef_no=0, decl_uid=1796, cgraph_uid=0, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_6 -> { j_2(D) }
j_7 -> { j_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 4 ( 67%)
Value ranges after VRP:
j_1: [0, 999] EQUIVALENCES: { } (0 elements)
j_2(D): VARYING
j_6: [1000, +INF] EQUIVALENCES: { j_2(D) } (1 elements)
j_7: [0, 999] EQUIVALENCES: { j_2(D) } (1 elements)
Removing basic block 3
f (unsigned int j, char * p)
{
[100.00%]:
if (j_2(D) > 999)
goto ; [54.00%]
else
goto ; [46.00%]
[46.00%]:
[100.00%]:
# j_1 = PHI
__builtin_snprintf (p_4(D), 4, "%3u", j_1);
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1800, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_6 -> { j_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)
Value ranges after VRP:
.MEM_1: VARYING
j_2(D): VARYING
j_6: [0, 999] EQUIVALENCES: { j_2(D) } (1 elements)
g (unsigned int j, char * p)
{
[100.00%]:
if (j_2(D) > 999)
goto ; [51.01%]
else
goto ; [48.99%]
[48.99%]:
__builtin_snprintf (p_4(D), 4, "%3u", j_2(D));
[100.00%]:
return;
}
t.c: In function ‘g’:
t.c:14:30: warning: ‘%3u’ directive output may be truncated writing between 3
and 10 bytes into a region of size 4 [-Wformat-length=]
__builtin_snprintf (p, 4, "%3u", j);
^~~
t.c:14:29: note: using the range [1, 4294967295] for directive argument
__builtin_snprintf (p, 4, "%3u", j);
^
t.c:14:3: note: format output between 4 and 11 bytes into a destination of size
4
__builtin_snprintf (p, 4, "%3u", j);
^~~
;; Function g (g, funcdef_no=1, decl_uid=1800, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
j_6 -> { j_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)
Value ranges after VRP:
.MEM_1: VARYING
j_2(D): VARYING
j_6: [0, 999] EQUIVALENCES: { j_2(D) } (1 elements)
g (unsigned int j, char * p)
{
[100.00%]:
if (j_2(D) > 999)
goto ; [51.01%]
[Bug c/60256] No -Wuninitialized warning for strcpy copying to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256 --- Comment #9 from Martin Sebor --- Thanks for the reference. The strcmp(s, s) (and likewise memcmp(p, p, n)) case in bug 65452 is different because unlike this one, strcmp doesn't change the arrays pointed to by its arguments (which are also not declared restrict) and so calling the function with the same array is valid.
[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913 Martin Sebor changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Martin Sebor --- Sounds good. I am interested in reports of excessive false positives so please let me know if you run into some. FYI: I'm testing a patch that splits out the snprintf truncation warning from -Wformat-length and adds a new option (-Wformat-truncation=n) to control the former independently of the latter. Under this patch, the "may be truncated" warnings are issued at n=1 when the snprintf return value is unused, and only at n=2 when it is used. I'll post it for review sometime this week.
[Bug c++/77284] [5/6/7 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I wonder if we should simply --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -5675,6 +5675,9 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, return false; } +case CLEANUP_STMT: + return RECUR (CLEANUP_BODY (t), want_rval); + default: if (objc_is_property_ref (t)) return false; which would also fix Bug 77545.
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016
--- Comment #9 from Jakub Jelinek ---
Actually, on x86_64-linux without -mbmi{,2} -mlzcnt the CLZ and CTZ is actually
undefined at zero, so there is nothing to do with that I'm afraid. With those
additional options foo is optimized:
- xorl%edx, %edx
- movl$17, %eax
- lzcntq %rdi, %rdx
+ xorl%eax, %eax
+ movl$17, %edx
+ lzcntq %rdi, %rax
testq %rdi, %rdi
- cmovne %edx, %eax
- cltq
+ cmove %rdx, %rax
with the patch and similarly baz:
- xorl%edx, %edx
- movl$17, %eax
- tzcntq %rdi, %rdx
- addq$1, %rdx
+ xorl%eax, %eax
+ movl$17, %edx
+ tzcntq %rdi, %rax
+ addq$1, %rax
testq %rdi, %rdi
- cmovne %edx, %eax
- cltq
+ cmove %rdx, %rax
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016
--- Comment #8 from Jakub Jelinek ---
So, trying:
long int
foo (long int i)
{
return i == 0 ? 17 : __builtin_clzl (i);
}
long int
bar (long int i)
{
return i == 0 ? 17 : __builtin_popcountl (i);
}
long int
baz (long int i)
{
return i == 0 ? 17 : __builtin_ffsl (i);
}
at -O2 to see effect on various builtins. On x86_64-linux I see:
- bsrq%rdi, %rdx
- movl$17, %eax
- xorq$63, %rdx
+ bsrq%rdi, %rax
+ movl$17, %edx
+ xorq$63, %rax
testq %rdi, %rdi
- cmovne %edx, %eax
cltq
+ cmove %rdx, %rax
in foo (so not better not worse; nonzero_bits isn't able to see through the (63
- CLZ (x)) ^ 63 stuff; but the patched compiler has potential to do better, if
we during expansion on the SUBREG set promoted flag to SRP_SIGNED_AND_UNSIGNED,
perhaps we could get rid of the unneeded cltq), in bar:
movl$17, %eax
- cltq
ret
(better; something in the pro_and_epilogue pass creates set to constant
followed by sign extension and there is no combiner afterwards to fix stuff
up),
and in baz:
- xorl%edx, %edx
- movl$17, %eax
- rep; bsfq %rdi, %rdx
- addq$1, %rdx
+ xorl%eax, %eax
+ movl$17, %edx
+ rep; bsfq %rdi, %rax
+ addq$1, %rax
testq %rdi, %rdi
- cmovne %edx, %eax
cltq
+ cmove %rdx, %rax
(different, but not better or worse).
On aarch64-linux, I see:
clz x2, x0
cmp x0, 0
- mov w1, 17
- cselw0, w1, w2, eq
- sxtwx0, w0
+ mov x1, 17
+ cselx0, x2, x1, ne
in foo (better),
- mov w0, 17
- sxtwx0, w0
+ mov x0, 17
in bar (better) and
- rbitx1, x0
- cmp x0, 0
- clz x1, x1
- mov w2, 17
- csinc w0, w2, w1, eq
+ cbz x0, .L14
+ rbitx0, x0
+ clz x0, x0
+ add x0, x0, 1
sxtwx0, w0
ret
+ .align 3
+.L14:
+ mov x0, 17
+ ret
in baz (worse). Of course, only foo (with some more sensical constant instead
of 17) is real-world stuff.
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016 --- Comment #7 from Jakub Jelinek --- Created attachment 40439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40439&action=edit gcc7-pr71016.patch Actually, it is (sometimes) beneficial even for library calls. Untested patch.
[Bug libstdc++/78968] New: conflict gnu's __cxa_thread_atexit and LLVM's/FreeBSD's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 Bug ID: 78968 Summary: conflict gnu's __cxa_thread_atexit and LLVM's/FreeBSD's Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: h2+bugs at fsfe dot org Target Milestone: --- I originally reported this here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215709 libc++ / FreeBSD has recently acquired it's own implementation of __cxa_thread_atexit so that thread_local storage now works. This is great, except that it breaks static linkage with GCC which now complains about double definition: cd /home/mi/h4nn3s/devel/lambda-build/pkg/src && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/lambda.dir/link.txt --verbose=1 /usr/local/libexec/ccache/g++6 -fopenmp -Wno-vla -O3 -DNDEBUG -flto=8 -s -static CMakeFiles/lambda.dir/lambda.cpp.o -o ../bin/lambda -lpthread -lexecinfo -lelf -lz -lbz2 //usr/lib/libc.a(cxa_thread_atexit.o): In function `__cxa_thread_atexit': /usr/src/lib/libc/stdlib/cxa_thread_atexit.c:(.text+0x0): multiple definition of `__cxa_thread_atexit' /usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd11.0/6.3.0/../../../libstdc++.a(atexit_thread.o):/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.3.0/libstdc++-v3/libsupc++/atexit_thread.cc:117: first defined here collect2: error: ld returned 1 exit status The FreeBSD maintainer responded with: This is a bug in gcc. The libsupc++ configuration assumes that there are exactly two possibilities: either libc is glibc and implements __cxa_thread_atexit() using __cxa_thread_atexit_impl(), or libsupc++ must provide an implementation on its own. Right solution is to add detection of __cxa_thread_atexit() in libc, to libstdc++ configure.ac and libsupc++/atexit_thread.cc. What is your opinion on the matter? Thanks!
[Bug target/78967] inserts are not effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78967 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-02 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Created attachment 40438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40438&action=edit Patch that implements missing insert patterns Prototype patch.
[Bug target/78967] New: inserts are not effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78967
Bug ID: 78967
Summary: inserts are not effective
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Similar to PR78904, following testcase:
--cut here--
struct S1
{
unsigned char pad1;
unsigned char val;
unsigned short pad2;
};
extern unsigned char t;
struct S1 foo (struct S1 a)
{
a.val = t;
return a;
}
--cut here--
compiles to (-O2):
movzbl t(%rip), %edx
movl%edi, %eax
movb%dl, %ah
Optimal code would be:
movl%edi, %eax
movbt(%rip), %ah
[Bug c++/78966] New: Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Bug ID: 78966
Summary: Unjustified variadic template instantiation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
template
struct vari
{
static_assert(sizeof...(TT) != 0, "bleh");
};
template struct X {};
void f(void(*)(X));
template void f(vari);
// if this line is commented out, code compiles fine
template void g(X);
void h() { f(g); }
When compiled with gcc 7.0.0 20161219, the static assert triggers:
prog.cc: In instantiation of 'struct vari<>':
prog.cc:16:15: required from here
prog.cc:4:3: error: static assertion failed: bleh
static_assert(sizeof...(TT) != 0, "bleh");
But there's no reason for vari to be instantiated without arguments here, is
there?
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Comment #15 from Dominik Vogt ---
The commit in comment 14 has instroduced size and runtime regressions in the
Spec2006 testsuite on s390x:
Runtime (only changes > 2%):
run-old.resultrun-new.result
f416.gamess 6.55s6.70s ( 2.29%, -2.24% )
i400.perlbench 7.17s7.37s ( 2.79%, -2.71% )
i445.gobmk 3.64s3.55s ( -2.47%, 2.54% )
i458.sjeng 3.83s3.75s ( -2.09%, 2.13% )
i473.astar 7.33s7.62s ( 3.96%, -3.81% )
i483.xalancbmk 7.47s8.06s ( 7.90%, -7.32% )
Executable size ("+/- lines" menas number of instructions);
f470.lbm: 2718 old.s 27 changed (+0 lines)
i429.mcf: 2801 old.s 2091 BIGGER! (+346 lines) (2 funcs bigger)
i462.libquantum: 8200 old.s 2723 smaller (-15 lines)
i473.astar: 9458 old.s 4936 smaller (-294 lines) (11 funcs bigger)
f410.bwaves: 9035 old.s 0 identical (+/- 0 lines)
i401.bzip2: 18190 old.s 8032 smaller (-11 lines) (6 funcs bigger)
f437.leslie3d: 19536 old.s 1939 smaller (-14 lines)
i458.sjeng: 34678 old.s 23820 smaller (-197 lines) (7 funcs bigger)
f433.milc: 29745 old.s 14898 smaller (-276 lines) (5 funcs bigger)
f482.sphinx3: 37726 old.s 23881 BIGGER! (+115 lines) (15 funcs bigger)
i456.hmmer: 64427 old.s 33803 smaller (-698 lines) (28 funcs bigger)
f444.namd: 55512 old.s 1785 smaller (-2 lines) (1 funcs bigger)
f434.zeusmp: 63606 old.s 2764 BIGGER! (+4 lines) (1 funcs bigger)
f459.GemsFDTD: 76971 old.s 32948 BIGGER! (+30 lines) (3 funcs bigger)
f436.cactusADM: 148768 old.s 60861 smaller (-547 lines) (68 funcs bigger)
f435.gromacs: 198339 old.s 86425 smaller (-1483 lines) (62 funcs bigger)
i471.omnetpp: 118737 old.s 37232 BIGGER! (+1879 lines) (59 funcs bigger)
i445.gobmk: 216664 old.s 152439 smaller (-1352 lines) (178 funcs bigger)
f450.soplex: 94178 old.s 55926 smaller (-2624 lines) (39 funcs bigger)
f453.povray: 221353 old.s 144618 smaller (-1680 lines) (118 funcs bigger)
i400.perlbench: 248535 old.s 232015 smaller (-1201 lines) (209 funcs bigger)
f454.calculix: 372030 old.s 222377 smaller (-788 lines) (96 funcs bigger)
i464.h264ref: 302278 old.s 152578 BIGGER! (+51 lines) (45 funcs bigger)
i403.gcc: 715454 old.s 614572 smaller (-2639 lines) (504 funcs bigger)
f465.tonto: 760124 old.s 174792 smaller (-987 lines) (140 funcs bigger)
f447.dealII: 553779 old.s 247834 smaller (-1134 lines) (246 funcs bigger)
f481.wrf: 811803 old.s 238154 smaller (-76 lines) (120 funcs bigger)
i483.xalancbmk: 743937 old.s 441474 BIGGER! (+2434 lines) (733 funcs bigger)
f416.gamess: 1913604 old.s 1175120 BIGGER! (+7805 lines) (327 funcs bigger)
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- So shall factor_out_conditional_conversion just check for cases like these and not try to "optimize" those? In particular, casts of int returning unary builtin to an integer with the precision of the unary builtin's argument. Affected builtins CASE_CFN_CLZ: CASE_CFN_CTZ: CASE_CFN_CLRSB: CASE_CFN_FFS: CASE_CFN_PARITY: CASE_CFN_POPCOUNT: are of this kind, perhaps only if there is corresponding optab and thus it is likely that it might help.
[Bug c/77767] [5 Regression] Side-effect from VLA array parameters lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767 Jakub Jelinek changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org Summary|[5/6/7 Regression] |[5 Regression] Side-effect |Side-effect from VLA array |from VLA array parameters |parameters lost |lost --- Comment #10 from Jakub Jelinek --- Fixed for 6.4+ so far.
[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Any progress with this?
[Bug tree-optimization/72739] [7 Regression] FAIL: gcc.dg/vect/vect-mask-store-move-1.c after r238301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72739 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The test has been xfailed in r238583. Do we want to mark this as a dup of PR65206? Or, if the runtime test that actually would be performed is not a compile time constant, doesn't that just mean there is a bug in the computation whether there is a must alias or may alias?
[Bug c/60256] No -Wuninitialized warning for strcpy copying to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256 --- Comment #8 from Marek Polacek --- For strcpy(s, s) see Bug 65452, which also contains a patch for -Wsame-arguments.
[Bug tree-optimization/65206] Vectorized version of loop is removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206 --- Comment #8 from Jakub Jelinek --- Adding some flag on the MASK_STORE or MASK_LOAD is not hard, it can be in another argument, or some GF_*, whatever. But I don't understand here what is the difference between originally pointer based and array based access. Doesn't for non-masked stores or loads forwprop propagate array accesses into pointer stores/loads anyway?
[Bug c/78927] implicit-fallthrough is very picky about FALLTHROUGH comment location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78927 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from Marek Polacek --- Or "__attribute__((fallthrough));" for C. Or, as you noticed, move the comment after }.
[Bug c++/71966] [7 Regression] ICE on invalid C++11 code (undefined constructor used in a constant expression): in cp_build_addr_expr_1, at cp/typeck.c:5671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71966
--- Comment #3 from Jakub Jelinek ---
Apparently this is because
else if (non_constant_p && TREE_CONSTANT (r))
{
/* This isn't actually constant, so unset TREE_CONSTANT. */
if (EXPR_P (r))
r = copy_node (r);
else if (TREE_CODE (r) == CONSTRUCTOR)
r = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (r), r);
else
r = build_nop (TREE_TYPE (r), r);
TREE_CONSTANT (r) = false;
}
creates a NOP_EXPR around the VAR_DECL so that it can have !TREE_CONSTANT.
Then we try to implicitly convert that NOP_EXPR to int, find the user
conversion and build_user_type_conversion_1 -> add_candidates attempts to emit
a method call with &NOP_EXPR, which is not allowed. I think we need to
strip such NOP_EXPR away somewhere, but not sure where.
[Bug c++/71966] [7 Regression] ICE on invalid C++11 code (undefined constructor used in a constant expression): in cp_build_addr_expr_1, at cp/typeck.c:5671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71966
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Doesn't ICE starting with r239267 anymore.
struct A
{
constexpr A (int);
constexpr operator int () const { return 0; }
int c;
};
template
struct B {};
constexpr A a = 0;
B b;
still ICEs though.
[Bug fortran/78865] [5/6/7 Regression] ICE in create_tmp_var, at gimple-expr.c:473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4
[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Created attachment 40437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40437&action=edit
gcc7-pr78693.patch
Untested fix, if auto deduction can't be performed during the parsing, because
the initializers have dependent types, it is premature to diagnose inconsistent
deduction, the deduction might be inconsistent, but might be consistent as
well.
But this also reveals that without extra infrastructure, we don't and can't
diagnose invalid cases, e.g.
template
void
foo (T t)
{
auto i = t, j = 1;
}
template
void
bar (T t)
{
auto i = 1, j = t, k = 2;
}
template
void
foo (T t, U u)
{
auto i = t, j = u;
}
void
foo ()
{
foo (0L);
bar (0L);
foo (1, 2L);
}
After parsing we loose the information which variables have been declared
together and what auto deduction has been performed. So perhaps we'd need some
extra tree that would hold a vector of variables (for those not deduced during
parsing) and auto_result (for those deduced during parsing) and during
instantiation check for the inconsistencies again. Jason?
Another probably invalid testcase I found while googling around for this is:
struct A
{
auto foo(), bar();
};
auto A::foo() { return 1; }
auto A::bar() { return 2; }
[dcl.spec.auto]/7 in N4618 says:
"If the init-declarator-list contains more than one init-declarator, they shall
all form declarations of variables." so the last testcase I think violates
that.
and
"The type of each declared variable is determined by placeholder type deduction
(7.1.7.4.1), and if the type that replaces the placeholder type is not the same
in each deduction, the program is ill-formed."
later in the same paragraph is why the first testcase above should be
diagnosed.
[Bug tree-optimization/78965] [7 Regression] Invalid -fprintf-return-value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78965 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 40436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40436&action=edit gcc7-pr78965.patch Untested fix.
[Bug tree-optimization/78965] [7 Regression] Invalid -fprintf-return-value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78965 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-02 Target Milestone|--- |7.0 Ever confirmed|0 |1
[Bug tree-optimization/78965] New: [7 Regression] Invalid -fprintf-return-value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78965
Bug ID: 78965
Summary: [7 Regression] Invalid -fprintf-return-value
optimization
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
int
main ()
{
int a = 5, b = 6;
int c = __builtin_snprintf (0, 0, "a%nb%nc", &a, &b);
if (a + b + c != 6)
__builtin_abort ();
return 0;
}
is miscompiled since r242674 at -O2.
[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78938 Jakub Jelinek changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- vectorizable_comparison has complicated code to deal with comparisons of VECTOR_BOOLEAN_P operands, but vectorizable_condition does not have any of this. So, IMHO either we duplicate that (or partially move into helper functions), e.g. the /* Boolean values may have another representation in vectors and therefore we prefer bit operations over comparison for them (which also works for scalar masks). We store opcodes to use in bitop1 and bitop2. Statement is vectorized as BITOP2 (rhs1 BITOP1 rhs2) or rhs1 BITOP2 (BITOP1 rhs2) depending on bitop1 and bitop2 arity. */ if (VECTOR_BOOLEAN_TYPE_P (vectype)) stuff and the bitop1/bitop2 handling later on, or refuse to vectorize COND_EXPR if the comparison operands are VECTOR_BOOLEAN_TYPE_P (with the exception of easy cases where rhs1 is the boolean itself or something easily transformable into that (boolv != 0, boolv != 1, boolv == 0, boolv == 1) perhaps with swapping rhs2 and rhs3. Or refuse to vectorize such COND_EXPRs and add pattern recognizer that replaces x = boolv1 op boolv2 ? rhs2 : rhs3; with tmp = boolv1 op boolv2; x = tmp ? rhs2 : rhs3; and then vectorizable_comparison should be able to deal with the first stmt and vectorizable_condition with the latter. Richard, any preferences?
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 --- Comment #7 from TC --- (In reply to Jakub Jelinek from comment #6) > Sure, I just wanted to understand why the r211318 change has been done and > my comment lists why I think that happened. Ah, my fault for not actually reading the patch. (FWIW, the sentence I quoted was introduced by the same paper that relaxed the static data member restrictions (N2544), so I'm not sure how that description makes sense, but certainly it appears that r211318's author somehow thought so - possibly due to paragraph numbering changes between C++03 and C++11?)
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 --- Comment #6 from Jakub Jelinek --- Sure, I just wanted to understand why the r211318 change has been done and my comment lists why I think that happened.
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 --- Comment #5 from TC --- (In reply to Jakub Jelinek from comment #4) > Apparently what changed in C++11 is that it allows static > data members in unions and those clearly can have reference type, so that is > the reason why the restriction has been removed and nothing added the > restriction that non-static data members still may not have reference type. ...I quoted the part of the standard that says this is ill-formed in comment #3?
[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78890 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40435&action=edit gcc7-pr78890.patch Untested fix. Apparently what changed in C++11 is that it allows static data members in unions and those clearly can have reference type, so that is the reason why the restriction has been removed and nothing added the restriction that non-static data members still may not have reference type.
[Bug rtl-optimization/78883] [avr] ICE triggered by change to combine.c (r243578)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78883 --- Comment #4 from Dominik Vogt --- A discussion of the problem starts here: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01776.html (Looks like a reload problem)
[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913 --- Comment #6 from Martin Liška --- (In reply to Martin Sebor from comment #5) > (In reply to Martin Sebor from comment #4) > > 1) use the %.508s directive instead of %s, or > > 2) verify the snprintf return value is less than 512. > > Whoops. An off-by-one error. I meant to follow that by: > > > Of the two alternatives, (1) is the expected/recommended way to avoid both > > the truncation and the warning. (2) is a possible enhancement that could > > also be used to suppress the warning (along with changing the code). Thanks Martin for very verbose explanation. To be honest, I'm not much interested in this particular test-case as it comes from a random package in openSUSE that started to fail with new GCC version. I would incline to let this PR opened as a reminder that cooperation of string manipulation functions is needed to provide more precise warnings. I will probably choose to fix my concrete package with %.xs format.
