[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #13 from Tom de Vries ---
Author: vries
Date: Tue Nov 7 08:11:43 2017
New Revision: 254489
URL: https://gcc.gnu.org/viewcvs?rev=254489&root=gcc&view=rev
Log:
[libgcc] Remove semicolon after do {} while (0) in FP_HANDLE_EXCEPTIONS
2017-11-07 Tom de Vries
PR other/82784
* config/aarch64/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Remove
semicolon after "do {} while (0)".
* config/i386/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Same.
* config/ia64/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Same.
* config/mips/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Same.
* config/rs6000/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Same.
Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/aarch64/sfp-machine.h
trunk/libgcc/config/i386/sfp-machine.h
trunk/libgcc/config/ia64/sfp-machine.h
trunk/libgcc/config/mips/sfp-machine.h
trunk/libgcc/config/rs6000/sfp-machine.h
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #14 from Tom de Vries ---
Author: vries
Date: Tue Nov 7 08:11:54 2017
New Revision: 254490
URL: https://gcc.gnu.org/viewcvs?rev=254490&root=gcc&view=rev
Log:
[arm] Remove semicolon after while {} do (0) in HANDLE_NARROW_SHIFT_ARITH
2017-11-07 Tom de Vries
PR other/82784
* config/arm/arm.c (HANDLE_NARROW_SHIFT_ARITH): Remove semicolon after
"while {} do (0)".
(arm_rtx_costs_internal): Add missing semicolon after
HANDLE_NARROW_SHIFT_ARITH call.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
[Bug ipa/82879] New: [8 regression] ICE in max, at profile-count.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82879
Bug ID: 82879
Summary: [8 regression] ICE in max, at profile-count.h:889
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz, marxin at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 ffmpeg % cat motionpixels.i
int a, b;
static __attribute__((cold)) void fn1() {
for (;;)
for (; a;)
;
}
void fn2() {
if (b)
fn1();
}
trippels@gcc2-power8 ffmpeg % gcc -c -O2 motionpixels.i
during IPA pass: inline
motionpixels.i: In function ‘fn2’:
motionpixels.i:7:6: internal compiler error: in max, at profile-count.h:889
void fn2() {
^~~
0x1086b0af profile_count::max(profile_count) const
../../gcc/gcc/profile-count.h:889
0x1086b0af counts_to_freqs()
../../gcc/gcc/predict.c:3327
0x10a3947b optimize_inline_calls(tree_node*)
../../gcc/gcc/tree-inline.c:5115
0x112da10f inline_transform(cgraph_node*)
../../gcc/gcc/ipa-inline-transform.c:709
0x1084bd6f execute_one_ipa_transform_pass
../../gcc/gcc/passes.c:2239
0x1084bd6f execute_all_ipa_transforms()
../../gcc/gcc/passes.c:2281
0x103ea68b cgraph_node::expand()
../../gcc/gcc/cgraphunit.c:2132
0x103ec2f3 expand_all_functions
../../gcc/gcc/cgraphunit.c:2275
0x103ec2f3 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2623
0x103ef9c7 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2682
0x103ef9c7 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2716
[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 Summary|[8 Regression] |--enable-maintainter-mode |--enable-maintainter-mode |broken by incompatiblity of |broken by automake failure |gcc's required automake and ||modern Perl Ever confirmed|0 |1 --- Comment #5 from Thomas Koenig --- It seems that automake 1.15.1 fixed the issue. This is not really a regression, it is just relying on an old version finally started to break things. So, it seems it is finally time to update all the auto* tools for gcc. I don't think using a hand-patched version like in comment #3 is really an option.
[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 --- Comment #6 from rguenther at suse dot de --- On Tue, 7 Nov 2017, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 > > Thomas Koenig changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2017-11-07 > Summary|[8 Regression] |--enable-maintainter-mode >|--enable-maintainter-mode |broken by incompatiblity of >|broken by automake failure |gcc's required automake and >||modern Perl > Ever confirmed|0 |1 > > --- Comment #5 from Thomas Koenig --- > It seems that automake 1.15.1 fixed the issue. > > This is not really a regression, it is just relying on an old version > finally started to break things. > > So, it seems it is finally time to update all the auto* tools > for gcc. I don't think using a hand-patched version like in > comment #3 is really an option. Updating autotools is somewhat tedius but I guess if there's a volunteer stage3 would be still appropriate.
[Bug c++/82861] 'long double sqrtf128(long double)' conflicts with built-in declaration 'long double sqrtf128(long double)' [-Wbuiltin-declaration-mismatch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82861 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug target/82863] [8 Regression] ICE in verify_flow_info building SH libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82863 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/82875] ICE at -Os on valid code on x86_64-linux-gnu: in find_widening_optab_handler_and_mode, at optabs-query.c:414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82875
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-07
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Liška ---
Confirmed, I see same back-trace starting from r254302:
$ cat ice.i
const int a = 100;
void b () { int c[a]; }
$ gcc -ftree-ter ice.i -c
during RTL pass: expand
ice.i: In function ‘b’:
ice.i:2:17: internal compiler error: in find_widening_optab_handler_and_mode,
at optabs-query.c:414
void b () { int c[a]; }
^
0xab7891 find_widening_optab_handler_and_mode(optab_tag, machine_mode,
machine_mode, machine_mode*)
../../gcc/optabs-query.c:414
0xaaaf7c expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../gcc/optabs.c:1152
0xaae410 expand_doubleword_mult
../../gcc/optabs.c:865
0xaac2a7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../gcc/optabs.c:1705
0x85141d expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int)
../../gcc/expmed.c:3427
0x876594 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8802
0x746dc9 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3712
0x746dc9 expand_gimple_stmt
../../gcc/cfgexpand.c:3773
0x74861f expand_gimple_basic_block
../../gcc/cfgexpand.c:5774
0x74e76e execute
../../gcc/cfgexpand.c:6375
[Bug tree-optimization/82870] [6 Regression] Assignment by Designated Initializer Overwrites a Flexible Array Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82870
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||7.2.1
Keywords||needs-bisection, wrong-code
Last reconfirmed||2017-11-07
Component|c |tree-optimization
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Assignment by Designated|[6 Regression] Assignment
|Initializer Overwrites a|by Designated Initializer
|Flexible Array Member |Overwrites a Flexible Array
||Member
Target Milestone|--- |6.5
Known to fail||6.4.0, 7.2.0
--- Comment #1 from Richard Biener ---
*obj = (struct Example){
.bitmap = {0, 0, 0, 0, 0, 0}
};
this _probably_ adds a single 0 for the flex array. The bug seems to be fixed
on the GCC 7 branch, confirmed on the tip of the GCC 6 branch.
GCC 6 DSEs the table[0] assignment in the following:
Example_assignment ()
{
struct Example * obj;
struct Example * D.1788;
struct Example * obj;
:
obj_6 = __builtin_malloc (64);
obj_6->table[0] = 1000;
*obj_6 = {};
return obj_6;
Wonder what fixed it / which bug is the dup.
[Bug middle-end/82875] [8 Regression] ICE at -Os on valid code on x86_64-linux-gnu: in find_widening_optab_handler_and_mode, at optabs-query.c:414
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82875 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Component|tree-optimization |middle-end Target Milestone|--- |8.0
[Bug c++/82873] Generated copy constructor calls constructors for 0-sized array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82873 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 Ever confirmed|0 |1 Known to fail||5.4.0, 6.4.0, 7.2.0 --- Comment #2 from Richard Biener --- Confirmed.
[Bug ipa/82879] [8 regression] ICE in max, at profile-count.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82879 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/82872] [6/7/8 Regression] ICE in ignore_overflows on __PTRDIFF_MAX__ index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82872 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug middle-end/82878] [7/8 Regression] ICE in assign_temp, at function.c:968 when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.3
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > This seems previously latent bug in bb-reorder. It produces order of blocks > which has hot blocks, then some cold blocks and then hot blocks again. Probably because some hot block is turned into a cold block, see: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02006.html for a previous example.
[Bug libgomp/82864] Stop using GOMP_OFFLOAD_openacc_async_set_async
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82864 --- Comment #1 from Tom de Vries --- Hmm, I found this on openacc-gcc-7-branch: ... commit cd69c58db3f41ac72c20bc9b780772ab7e0c113e Author: Chung-Lin Tang Date: Tue Jul 25 15:02:26 2017 + OpenACC async re-work ... libgomp/ (GOMP_OFFLOAD_openacc_async_set_async): Remove. ... ... ...
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Confirmed, I see Fortran discrepancy since r243830: $ gfortran pr82869-2.f90 -O0 && ./a.out (Expect F F) F F $ gfortran pr82869-2.f90 -O2 && ./a.out (Expect F F) T T Comparison of sanitized and not sanitized tree dump looks the same (modulo memory checks).
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- (In reply to Martin Liška from comment #4) > Confirmed, I see Fortran discrepancy since r243830: > > $ gfortran pr82869-2.f90 -O0 && ./a.out > (Expect F F) F F > $ gfortran pr82869-2.f90 -O2 && ./a.out > (Expect F F) T T > > Comparison of sanitized and not sanitized tree dump looks the same (modulo > memory checks). Hmm. Actually, I have prepared a patch to fix some other minor fallout due to r243830, I'll have to check whether it fixes this issue as well. Assigning to myself.
[Bug c++/82833] [concepts] Out-of-line definition of nested class template errors with constraint (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82833 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 Blocks||67491 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug target/82871] Unneeded lsls lsrs instructions generated on half word access for arm cortex-m4 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82871 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Earnshaw --- Dup *** This bug has been marked as a duplicate of bug 71942 ***
[Bug middle-end/71942] [ARM] Zero-extending whats allready zero-extended even when -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71942 Richard Earnshaw changed: What|Removed |Added CC||mikael.rosbacke at gmail dot com --- Comment #7 from Richard Earnshaw --- *** Bug 82871 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/82614] GCOV crashes while parsing gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614 --- Comment #10 from Marco Castelluccio --- (In reply to Martin Liška from comment #9) > (In reply to Marco Castelluccio from comment #8) > > Created attachment 42462 [details] > > Archive with GCNO and GCDA file generated with GCC 6 > > > > This is an archive containing the GCNO and GCDA files generated with GCC 6. > > > > We are going to test 7 next. > > Thanks for that. Still can't reproduce and it will be highly probably that > it's related to fact that I do not have source files which are annotated. > Can you please attach them? > > Moreover, can you please run it in gdb and paste full backtrace? I don't have the source files either, they are built on a remote machine and I'm only downloading the gcno/gcda file. Here's the backtrace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x77a2df5d in __GI_abort () at abort.c:90 #2 0x77a7628d in __libc_message (action=action@entry=(do_abort | do_backtrace), fmt=fmt@entry=0x77b9b9e6 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x77b1c7ef in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x77b9b96d "buffer overflow detected") at fortify_fail.c:33 #4 0x77b1c811 in __GI___fortify_fail (msg=msg@entry=0x77b9b96d "buffer overflow detected") at fortify_fail.c:44 #5 0x77b1a500 in __GI___chk_fail () at chk_fail.c:28 #6 0x77b199e9 in _IO_str_chk_overflow (fp=, c=) at vsprintf_chk.c:31 #7 0x77a7ad59 in __GI__IO_default_xsputn (f=0x7fffd0f0, data=, n=19) at genops.c:455 #8 0x77a4932d in _IO_vfprintf_internal (s=s@entry=0x7fffd0f0, format=, format@entry=0x46f771 "%ld", ap=ap@entry=0x7fffd230) at vfprintf.c:1642 #9 0x77b19a8b in ___vsprintf_chk (s=0x697670 "-674122451547433726", flags=1, slen=20, format=0x46f771 "%ld", args=args@entry=0x7fffd230) at vsprintf_chk.c:82 #10 0x77b199ba in ___sprintf_chk (s=s@entry=0x697670 "-674122451547433726", flags=flags@entry=1, slen=slen@entry=20, format=format@entry=0x46f771 "%ld") at sprintf_chk.c:31 #11 0x00405934 in sprintf (__fmt=0x46f771 "%ld", __s=0x697670 "-674122451547433726") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:34 #12 format_gcov (top=, bottom=, dp=-1) at ../../src/gcc/gcov.c:1998 #13 0x00404b41 in output_lines (src=0x1108e00, gcov_file=0x71a650) at ../../src/gcc/gcov.c:2563 #14 output_gcov_file (src=0x1108e00, file_name=0xa8f490 "Unified_cpp_js_src31.gcda") at ../../src/gcc/gcov.c:962 #15 generate_results (file_name=) at ../../src/gcc/gcov.c:1035 #16 main (argc=, argv=) at ../../src/gcc/gcov.c:640
[Bug gcov-profile/82614] GCOV crashes while parsing gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #11 from Martin Liška --- (In reply to Marco Castelluccio from comment #10) > (In reply to Martin Liška from comment #9) > > (In reply to Marco Castelluccio from comment #8) > > > Created attachment 42462 [details] > > > Archive with GCNO and GCDA file generated with GCC 6 > > > > > > This is an archive containing the GCNO and GCDA files generated with GCC > > > 6. > > > > > > We are going to test 7 next. > > > > Thanks for that. Still can't reproduce and it will be highly probably that > > it's related to fact that I do not have source files which are annotated. > > Can you please attach them? > > > > Moreover, can you please run it in gdb and paste full backtrace? > > I don't have the source files either, they are built on a remote machine and > I'm only downloading the gcno/gcda file. > > Here's the backtrace: > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x77a2df5d in __GI_abort () at abort.c:90 > #2 0x77a7628d in __libc_message (action=action@entry=(do_abort | > do_backtrace), fmt=fmt@entry=0x77b9b9e6 "*** %s ***: %s terminated\n") > at ../sysdeps/posix/libc_fatal.c:181 > #3 0x77b1c7ef in __GI___fortify_fail_abort > (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x77b9b96d > "buffer overflow detected") > at fortify_fail.c:33 > #4 0x77b1c811 in __GI___fortify_fail (msg=msg@entry=0x77b9b96d > "buffer overflow detected") at fortify_fail.c:44 > #5 0x77b1a500 in __GI___chk_fail () at chk_fail.c:28 > #6 0x77b199e9 in _IO_str_chk_overflow (fp=, > c=) at vsprintf_chk.c:31 > #7 0x77a7ad59 in __GI__IO_default_xsputn (f=0x7fffd0f0, > data=, n=19) at genops.c:455 > #8 0x77a4932d in _IO_vfprintf_internal (s=s@entry=0x7fffd0f0, > format=, format@entry=0x46f771 "%ld", > ap=ap@entry=0x7fffd230) at vfprintf.c:1642 > #9 0x77b19a8b in ___vsprintf_chk (s=0x697670 long, int)::buffer> "-674122451547433726", flags=1, slen=20, > format=0x46f771 "%ld", args=args@entry=0x7fffd230) at > vsprintf_chk.c:82 > #10 0x77b199ba in ___sprintf_chk (s=s@entry=0x697670 > "-674122451547433726", > flags=flags@entry=1, > slen=slen@entry=20, format=format@entry=0x46f771 "%ld") at > sprintf_chk.c:31 > #11 0x00405934 in sprintf (__fmt=0x46f771 "%ld", __s=0x697670 > "-674122451547433726") > at /usr/include/x86_64-linux-gnu/bits/stdio2.h:34 > #12 format_gcov (top=, bottom=, dp=-1) at > ../../src/gcc/gcov.c:1998 > #13 0x00404b41 in output_lines (src=0x1108e00, gcov_file=0x71a650) > at ../../src/gcc/gcov.c:2563 > #14 output_gcov_file (src=0x1108e00, file_name=0xa8f490 > "Unified_cpp_js_src31.gcda") at ../../src/gcc/gcov.c:962 > #15 generate_results (file_name=) at ../../src/gcc/gcov.c:1035 > #16 main (argc=, argv=) at > ../../src/gcc/gcov.c:640 Thanks! Now I know where's the problem. Let me fix it.
[Bug gcov-profile/82614] GCOV crashes while parsing gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614 --- Comment #12 from Martin Liška --- So problem is quite simple, there's a branch counter that has negative value: $ ./gcov-dump -l Unified_cpp_js_src31.gcda ... Unified_cpp_js_src31.gcda: 0100: 3:FUNCTION ident=642196265, lineno_checksum=0xca05d7bd, cfg_checksum=0xa9867a71 Unified_cpp_js_src31.gcda:01a1: 46:COUNTERS arcs 23 counts Unified_cpp_js_src31.gcda: 0: 37 37 37 0 0 0 0 0 Unified_cpp_js_src31.gcda: 8: 0 0 0 0 0 0 0 0 Unified_cpp_js_src31.gcda: 16: 7650095318414917635 -5852759779117600487 128876347392 0 0 0 0 Which is very suspicious. I points to following function: https://github.com/servo/mozjs/blob/master/mozjs/js/src/jsweakmap.h#L153 Note that first arcs counter has value 37, which should be number of execution of entry basic block. Thus counters at offset 16, 17, 18 look somehow skewed. Note that these counters at very end of *.gcda file and thus maybe somehow corrupted. We can obviously add some validation of such numbers, but it would be more interesting to find where these numbers come from.
[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #13 from Martin Liška --- I've got patch for that, will send to mailing list soon.
[Bug middle-end/80131] powerpc: 1U << (31 - x) doesn't generate optimised code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80131 --- Comment #7 from Wilco --- Author: wilco Date: Tue Nov 7 12:23:38 2017 New Revision: 254496 URL: https://gcc.gnu.org/viewcvs?rev=254496&root=gcc&view=rev Log: PR80131: Simplification of 1U << (31 - x) Currently the code A << (B - C) is not simplified. However at least a more specific case of 1U << (C -x) where C = precision(type) - 1 can be simplified to (1 << C) >> x. This is done by adding a new simplification rule in match.pd. 2017-11-07 Sudakshina Das gcc/ PR middle-end/80131 * match.pd: Simplify 1 << (C - x) where C = precision (x) - 1. testsuite/ PR middle-end/80131 * testsuite/gcc.dg/pr80131-1.c: New Test. Added: trunk/gcc/testsuite/gcc.dg/pr80131-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug middle-end/80131] powerpc: 1U << (31 - x) doesn't generate optimised code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80131 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #8 from Wilco --- Fixed in r254496.
[Bug tree-optimization/82870] [6 Regression] Assignment by Designated Initializer Overwrites a Flexible Array Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82870 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r222305. Went away with r251217.
[Bug tree-optimization/82870] [6 Regression] Assignment by Designated Initializer Overwrites a Flexible Array Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82870 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- Dup then. *** This bug has been marked as a duplicate of bug 81884 ***
[Bug tree-optimization/81884] [6 Regression] Invalid code generation with zero size arrays or flexible array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81884 Richard Biener changed: What|Removed |Added CC||webstrand at gmail dot com --- Comment #11 from Richard Biener --- *** Bug 82870 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/71026] Missing division optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026 --- Comment #8 from Wilco --- Author: wilco Date: Tue Nov 7 12:38:55 2017 New Revision: 254497 URL: https://gcc.gnu.org/viewcvs?rev=254497&root=gcc&view=rev Log: PR71026: Canonicalize negates in division Canonicalize x / (- y) into (-x) / y. This moves negates out of the RHS of a division in order to allow further simplifications and potentially more reciprocal CSEs. 2017-11-07 Wilco Dijkstra Jackson Woodruff gcc/ PR tree-optimization/71026 * match.pd: Canonicalize negate in division. testsuite/ PR 71026/tree-optimization/71026 * gcc.dg/div_neg: New test. Added: trunk/gcc/testsuite/gcc.dg/div_neg.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712 Jan Smets changed: What|Removed |Added CC||jan.smets at nokia dot com --- Comment #7 from Jan Smets --- Any chance of the fix being backported to the 6 branch, for the 6.5 release?
[Bug other/82880] New: [6/7/8 Regression] gcc --help=target --help=optimizers hangs on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82880 Bug ID: 82880 Summary: [6/7/8 Regression] gcc --help=target --help=optimizers hangs on mips Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jcowgill+gcc at jcowgill dot uk Target Milestone: --- Created attachment 42555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42555&action=edit mips workaround From Debian: https://bugs.debian.org/880962 As the title says, running "gcc --help=target --help=optimizers" on mips (including cross compilers targeting mips) hangs. The bug only occurs on gcc-7-branch and not in any released version of gcc 7. Bisected (on gcc-7-branch) to: > 4972d77dcbe0c4186dabc67a0edb7f3f2df4e646 is the first bad commit > commit 4972d77dcbe0c4186dabc67a0edb7f3f2df4e646 > Author: marxin > Date: Fri Sep 15 08:18:34 2017 + > > Subject: Backport r251400 > > 2017-09-15 Martin Liska > > Backport from mainline > 2017-08-29 Martin Liska > > PR other/39851 [...] > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@252787 > 138bc75d-0d04-0410-961f-82ee72b054a4 > > :04 04 435ac2ed3f121183790fa89d3120400725e3c6a0 > 424643290a7f6c41e0abe05fb6c596113ed6e611 Mgcc After this commit, mips_option_override is called twice (once for each --help option). This results in a pass being registered twice (mips_register_frame_header_opt) which causes register_pass to hang in an infinite loop inside position_pass. The reason the same pass is registered twice is becaise the register_pass_info struct in mips_register_frame_header_opt is declared static and is therefore only initialized once. Having said that, the documentation of TARGET_OPTION_OVERRIDE seems to imply this hook should only ever be executed once, so I think the actual bug is in the generic code which calls the hook more than once. Hanging backtrace for reference: > (gdb) bt > #0 position_pass (new_pass_info=0x1cd3780 > , pass_list=0x1e4d048) at > ../../gcc/gcc/passes.c:1325 > #1 0x00c1385e in gcc::pass_manager::register_pass (this=0x1e4d030, > pass_info=0x1cd3780 ) at > ../../gcc/gcc/passes.c:1463 > #2 0x00c136ea in register_pass (pass_info=0x1cd3780 > ) at ../../gcc/gcc/passes.c:1418 > #3 0x010b38f9 in mips_register_frame_header_opt () at > ../../gcc/gcc/config/mips/frame-header-opt.c:103 > #4 0x010aa8b1 in mips_option_override () at > ../../gcc/gcc/config/mips/mips.c:20171 > #5 0x01486ee3 in common_handle_option (opts=0x1e131e0 > , opts_set=0x1e14000 , decoded=0x1e632e0, > lang_mask=16, kind=0, loc=0, handlers=0x7fffdd70, > dc=0x1e14ee0 , > target_option_override_hook=0x10a91ef ) at > ../../gcc/gcc/opts.c:1857 > #6 0x0148b23c in handle_option (opts=0x1e131e0 , > opts_set=0x1e14000 , decoded=0x1e632e0, lang_mask=16, > kind=0, loc=0, handlers=0x7fffdd70, generated_p=false, > dc=0x1e14ee0 ) at > ../../gcc/gcc/opts-common.c:989 > #7 0x0148b990 in read_cmdline_option (opts=0x1e131e0 > , opts_set=0x1e14000 , decoded=0x1e632e0, > loc=0, lang_mask=16, handlers=0x7fffdd70, > dc=0x1e14ee0 ) at > ../../gcc/gcc/opts-common.c:1218 > #8 0x00c10a91 in read_cmdline_options (opts=0x1e131e0 > , opts_set=0x1e14000 , > decoded_options=0x1e63240, decoded_options_count=3, loc=0, lang_mask=16, > handlers=0x7fffdd70, dc=0x1e14ee0 ) at > ../../gcc/gcc/opts-global.c:228 > #9 0x00c10c3e in decode_options (opts=0x1e131e0 , > opts_set=0x1e14000 , decoded_options=0x1e63240, > decoded_options_count=3, loc=0, > dc=0x1e14ee0 , > target_option_override_hook=0x10a91ef ) at > ../../gcc/gcc/opts-global.c:309 > #10 0x00d35574 in toplev::main (this=0x7fffde7e, argc=3, > argv=0x7fffdf78) at ../../gcc/gcc/toplev.c:2116 > #11 0x014828f3 in main (argc=3, argv=0x7fffdf78) at > ../../gcc/gcc/main.c:39 Note the current and next passes are identical: > (gdb) p pass > $28 = (opt_pass *) 0x1e2a360 > (gdb) p pass->next > $29 = (opt_pass *) 0x1e2a360 The attached patch works around this in the mips code, although as I said above, I don't think this is the correct fix.
[Bug ipa/82879] [8 regression] ICE in max, at profile-count.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82879 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 Ever confirmed|0 |1 Known to fail||8.0 --- Comment #1 from Martin Liška --- Confirmed.
[Bug middle-end/82878] [7/8 Regression] ICE in assign_temp, at function.c:968 when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r244728.
[Bug tree-optimization/58774] tree-switch-conversion doesn't optimize with content in default scase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58774 Shawn Landden changed: What|Removed |Added CC||slandden at gmail dot com --- Comment #4 from Shawn Landden --- Created attachment 42556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42556&action=edit appers-fixed
[Bug tree-optimization/58774] tree-switch-conversion doesn't optimize with content in default scase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58774 --- Comment #5 from Shawn Landden --- Appears fixed
[Bug middle-end/82878] [7/8 Regression] ICE in assign_temp, at function.c:968 when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #4 from Jakub Jelinek ---
Started with r244728.
Slightly adjusted testcase:
struct S { ~S (); };
struct A { operator int (); S a; };
void
bar ()
{
void (*foo)(A) = [](A) { bar (); };
A b;
if (auto c = b)
foo (c);
}
[Bug middle-end/82878] [7/8 Regression] ICE in assign_temp, at function.c:968 when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/82835] [8 Regression] ICE on valid code with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82835 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 42557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42557&action=edit gcc8-pr82835.patch Untested fix.
[Bug debug/82837] [8 Regression] ICE in output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82837 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2017-11/msg00415.ht ||ml Last reconfirmed||2017-11-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So, either we need on-demand VRP for this, or tree niters = number_of_latch_executions (loop); niters = fold_convert_loc (loc, sizetype, niters); if (dominated_by_p (CDI_DOMINATORS, single_exit (loop)->src, bb)) niters = size_binop_loc (loc, PLUS_EXPR, niters, size_one_node); needs to be smarter, dunno if it should look if the loop has a guard that makes sure the var in niters is non-zero, or something similar. Such guards are common though, so perhaps the niters infrastructure should be able to do that. Have number_of_latch_executions alternative that would add one to that if needed and take into account the possible preheaders.
[Bug rtl-optimization/82881] New: [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82881 Bug ID: 82881 Summary: [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 42558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42558&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -freorder-blocks-algorithm=simple testcase.c during RTL pass: bbro testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in df_compact_blocks, at df-core.c:1729 } ^ 0x8a6b3f df_compact_blocks() /repo/gcc-trunk/gcc/df-core.c:1729 0x1543a45 compact_blocks() /repo/gcc-trunk/gcc/cfg.c:160 0x153c150 reorder_basic_blocks /repo/gcc-trunk/gcc/bb-reorder.c:2502 0x153c150 execute /repo/gcc-trunk/gcc/bb-reorder.c:2592 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-254487-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-254487-checking-yes-rtl-df-extra-nographite-amd64 Thread model: posix gcc version 8.0.0 20171107 (experimental) (GCC)
[Bug target/82703] [7/8 Regression] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82703 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law --- Where do you think we'd want that on-demand VRP? I've got a tree here which splits up tree-vrp.c dramatically. The net result is I've got an embeddable range analysis engine that's easy to wire into a dominator walker. Alternately we'll have to wait for Andrew's work to land.
[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 --- Comment #6 from Jakub Jelinek --- For this exact testcase anywhere in between ldist and strlen pass, so e.g. in dom or strlen passes. Though it would need to be something that handles what vrp handles with ASSERT_EXPRs. Yet another option is consider moving strlen pass right after vrp2 instead of being before thread4 and vrp2. Dunno what kind of harm would that cause, if we rely on vrp2 to clean stuff after strlen, or compute value ranges for whatever that pass creates, etc. Though https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01784.html mentions that having strlen before vrp2 is on purpose.
[Bug tree-optimization/82732] malloc+zeroing other than memset not optimized to calloc, so asm output is malloc+memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732 --- Comment #7 from Jeffrey A. Law --- Given that both DOM and strlen are already dom walker based, getting better range information in them is going to be easy. The former is actually part of the motivation behind the refactoring work. We actually don't need to muck around with ASSERT_EXPRs in the IL. THe analysis is the EVRP bits refactored. So you get a embeddable context sensitive range analysis that doesn't change the IL. It's just analyzes it as you walk the dominator tree allowing you to make queries during the walk. I've done a proof of concept with embedding it into Martin's sprintf work and it was truly trivial. Martin and I have lightly discussed adding the analysis to the strlen pass as probably being a high value target once the refactoring work his the trunk.
[Bug c++/82882] New: [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882
Bug ID: 82882
Summary: [8 regression] ICE Segmentation fault
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
% cat Application.ii
template void foo() {
[] { enum {}; };
}
void bar() { foo; }
% g++ -c Application.ii
Application.ii: In instantiation of ‘void foo() [with
= int]’:
Application.ii:4:22: required from here
Application.ii:2:13: internal compiler error: Segmentation fault
[] { enum {}; };
^
0xd95aff crash_signal
../../gcc/gcc/toplev.c:324
0x6bd2b1 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3087
0x6bd2b1 determine_visibility(tree_node*)
../../gcc/gcc/cp/decl2.c:2387
0x7b88d3 lookup_template_class_1
../../gcc/gcc/cp/pt.c:9098
0x7b88d3 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9114
0x7badd9 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12008
0x7b1944 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13641
0x7bbfd6 tsubst_decl
../../gcc/gcc/cp/pt.c:12940
0x7b1a97 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13558
0x7a7318 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16023
0x7a4dc8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15950
0x7a7253 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16193
0x7a7253 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16193
0x7941e6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15935
0x7941e6 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:16936
0x794e7b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18225
0x7a72a3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16980
0x7a72a3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16718
0x7a5a08 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15964
0x7a4dc8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15950
[Bug middle-end/82404] Unnecessary instructions in switch table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82404 --- Comment #10 from Antony Polukhin --- Do we need a autotest on that to make sure that cmp won't appear again?
[Bug target/82883] New: eax register unnecessary consumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82883
Bug ID: 82883
Summary: eax register unnecessary consumed
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following example:
void foo(char* ch) {
__builtin_memcpy(ch, "Hello word", 6);
}
Produces the assembly
foo(char*):
mov eax, 8303 <=== This is not required
mov DWORD PTR [rdi], 1819043144
mov WORD PTR [rdi+4], ax
ret
The code could be further optimized to not use the eax register. For example
clang does the following:
foo(char*): # @foo(char*)
mov word ptr [rdi + 4], 8303
mov dword ptr [rdi], 1819043144
ret
[Bug c++/82882] [8 regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82882 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r251433.
[Bug rtl-optimization/82881] [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82881 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r249019.
[Bug fortran/65428] ICE on nest array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65428 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from G. Steinmetz --- Updating backtrace, see below. The following example is comparable to that from comment 0, the value of "shape(1)" is a rank-one array of size zero. $ cat z1.f90 program p print *, [shape(1)] end $ gfortran-8-20171105 -c z1.f90 z1.f90:2:0: print *, [shape(1)] internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1102 0x7a7123 gfc_typenode_for_spec(gfc_typespec*, int) ../../gcc/fortran/trans-types.c:1102 0x74473e trans_array_constructor ../../gcc/fortran/trans-array.c:2471 0x74473e gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:2814 0x7455c5 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:5093 0x7891cb gfc_trans_transfer(gfc_code*) ../../gcc/fortran/trans-io.c:2620 0x72fec7 trans_code ../../gcc/fortran/trans.c:2028 0x786b47 build_dt ../../gcc/fortran/trans-io.c:2028 0x72fee7 trans_code ../../gcc/fortran/trans.c:2000 0x756bfc gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6421 0x6e8b90 translate_all_program_units ../../gcc/fortran/parse.c:6091 0x6e8b90 gfc_parse_file() ../../gcc/fortran/parse.c:6294 0x72d3bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82884] New: ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82884 Bug ID: 82884 Summary: ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Derived from a modified legacy code : $ cat z1.f90 program p character :: c(4) = [1h(, 1hi, 1h4, 1h)] end $ gfortran-8-20171105 -c z1.f90 z1.f90:2:22: character :: c(4) = [1h(, 1hi, 1h4, 1h)] 1 Warning: Extension: Conversion from HOLLERITH to CHARACTER(1) at (1) z1.f90:2:41: character :: c(4) = [1h(, 1hi, 1h4, 1h)] 1 Warning: Legacy Extension: Hollerith constant at (1) f951: internal compiler error: Segmentation fault 0xb60fdf crash_signal ../../gcc/toplev.c:324 0x6642e1 gfc_resolve_character_array_constructor(gfc_expr*) ../../gcc/fortran/array.c:2069 0x6f5fd6 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6751 0x7064b9 resolve_values ../../gcc/fortran/resolve.c:11488 0x71ae0b do_traverse_symtree ../../gcc/fortran/symbol.c:4157 0x703889 resolve_types ../../gcc/fortran/resolve.c:16344 0x6ff04c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16440 0x6e89ba resolve_all_program_units ../../gcc/fortran/parse.c:6030 0x6e89ba gfc_parse_file() ../../gcc/fortran/parse.c:6280 0x72d3bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug middle-end/82885] New: memcpy does not propagate aliasing knowledge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82885
Bug ID: 82885
Summary: memcpy does not propagate aliasing knowledge
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code:
void foo3(char* ch1, const char* ch2) {
__builtin_memcpy(ch1, ch2, 1024*1024);
ch1[0] = ch2[2];
ch1[1] = ch2[2];
}
Produces assembly
foo3(char*, char*):
pushrbx
mov edx, 1048576
mov rbx, rsi
callmemcpy
mov rcx, rax
movzx eax, BYTE PTR [rbx+2]
mov BYTE PTR [rcx], al
movzx eax, BYTE PTR [rbx+2] <== This could be removed
mov BYTE PTR [rcx+1], al
pop rbx
ret
memcpy works for non aliased data, otherwise it is UB. Knowledge that pointers
do not alias could be propagated further to remove reads from ch2.
[Bug fortran/82886] New: ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Bug ID: 82886 Summary: ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With file ./gcc/testsuite/gfortran.dg/c_ptr_tests_9.f03 : $ gfortran-8-20171105 -c c_ptr_tests_9.f03 -finit-derived c_ptr_tests_9.f03:22:0: end subroutine sub0 internal compiler error: Segmentation fault 0xb60fdf crash_signal ../../gcc/toplev.c:324 0x763411 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:7807 0x767c0e gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool) ../../gcc/fortran/trans-expr.c:7535 0x768a2e gfc_trans_subcomponent_assign ../../gcc/fortran/trans-expr.c:7459 0x767a70 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool) ../../gcc/fortran/trans-expr.c:7624 0x76996f gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7691 0x76b089 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10002 0x74d8e0 gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool) ../../gcc/fortran/trans-decl.c:4010 0x754caa gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4688 0x756d53 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6526 0x733ac1 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2206 0x6e8abd translate_all_program_units ../../gcc/fortran/parse.c:6078 0x6e8abd gfc_parse_file() ../../gcc/fortran/parse.c:6294 0x72d3bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 --- Comment #1 from G. Steinmetz --- A possible reduction : $ cat z1.f90 program p use, intrinsic :: iso_c_binding, only: c_ptr, c_null_ptr type t type(c_ptr) :: my_c_ptr end type contains subroutine sub0() bind(c) type(t), target :: my_f90_type my_f90_type%my_c_ptr = c_null_ptr end subroutine end
[Bug fortran/82884] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82884 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed, present from 4.8 up to trunk (8.0).
[Bug c/53037] warn_if_not_aligned(X)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037 --- Comment #42 from Eric Botcazou --- Author: ebotcazou Date: Tue Nov 7 17:37:29 2017 New Revision: 254503 URL: https://gcc.gnu.org/viewcvs?rev=254503&root=gcc&view=rev Log: PR c/53037 * stor-layout.c: Include attribs.h. (handle_warn_if_not_align): Replace test on TYPE_USER_ALIGN with explicit lookup of "aligned" attribute. Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||foreese at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed. My instrumented gfortran reports ../../work/gcc/fortran/trans-expr.c:7807:16: runtime error: member access within null pointer of type 'struct gfc_expr'
[Bug target/82887] New: ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with _mm512_extracti64x4_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887
Bug ID: 82887
Summary: ICE: in extract_insn, at recog.c:2287 (unrecognizable
insn) with _mm512_extracti64x4_epi64
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marcin.slusarz at intel dot com
Target Milestone: ---
$ cat avx512-ice.c
#include
void something(__m512i zmm)
{
__m256i ymm = _mm512_extracti64x4_epi64(zmm, 0);
}
$ gcc -c avx512-ice.c -mavx512f
avx512-ice.c: In function ‘something’:
avx512-ice.c:6:1: error: unrecognizable insn:
}
^
(insn 12 11 16 2 (set (mem/c:V4DI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -32 [0xffe0])) [3 ymm+0 S32 A256])
(vec_merge:V4DI (vec_select:V4DI (reg:V8DI 88)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(reg:V4DI 89)
(reg:QI 90))) avx512-ice.c:5 -1
(nil))
avx512-ice.c:6:1: internal compiler error: in extract_insn, at recog.c:2287
(...)
[Bug bootstrap/81149] [8 Regression] profiledbootstrap failed with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81149 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #2 from H.J. Lu --- Reopen
[Bug bootstrap/81149] [8 Regression] profiledbootstrap failed with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81149 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed as of r254454.
[Bug middle-end/82885] memcpy does not propagate aliasing knowledge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82885 --- Comment #1 from Marc Glisse --- gcc (illegally) generates some calls to memcpy(p,q,n) where p and q may be the same pointer, although they mustn't overlap in any more complicated way. That makes such an optimization problematic (although this memcpy generation seems to happen at expansion time, so doing the optimization earlier might be ok).
[Bug middle-end/71942] [ARM] Zero-extending whats allready zero-extended even when -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71942
--- Comment #8 from Mikael Rosbacke ---
Previous bug i filed was marked as a duplicate of this. Collecting my
information from that report here. Same basic problem, slightly different
symptom.
--- old text ---
I used the following code on arm-gcc 6.3 compiler (using Matt godbolts compiler
explorer)
#include
volatile uint32_t reg32;
volatile uint16_t reg16;
void test16()
{
volatile uint16_t* reg_p = ®16;
uint16_t mask = 0x800u;
*reg_p &= (uint16_t)~mask;
}
void test32()
{
volatile uint32_t* reg_p = ®32;
uint32_t mask = 0x800u;
*reg_p &= (uint32_t)~mask;
}
And I got the following assembler: (arguments: -std=c99 -mthumb -Os
-mcpu=cortex-m4)
test16():
ldr r2, .L2
ldrh r3, [r2]
bic r3, r3, #2048
lsls r3, r3, #16
lsrs r3, r3, #16
strh r3, [r2] @ movhi
bx lr
.L2:
.word .LANCHOR0
test32():
ldr r2, .L5
ldr r3, [r2, #4]
bic r3, r3, #2048
str r3, [r2, #4]
bx lr
.L5:
.word .LANCHOR0
reg16:
reg32:
The case for 32 bit seems fine. load value, clear bits and then write it back.
The second case have 2 extra instructions, lsls/lsrs. I assume these are for
clearing bit 16-31. However the value is written using a half word instruction
so bit 16-31 should not matter.
This particular case is very common on microcontrollers when accessing hardware
registers. Using '-Os' to save flash memory and then operating bit field in
registers makes this come up often, sometimes in interrupt handlers where
timing is important.
Would like the lsls/lsrs instructions removed unless there is a good reason to
have them there.
Thanks in advance,
--- Mikael R
[Bug c++/82888] New: terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888
Bug ID: 82888
Summary: terrible code generation for initialization of POD
array members vs. clang
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: froydnj at gcc dot gnu.org
CC: jseward at acm dot org, mh+gcc at glandium dot org
Target Milestone: ---
Consider the testcase:
class A
{
public:
A();
private:
unsigned char mStorage[4096];
};
A::A()
: mStorage()
{}
gcc -O2 generates a loop that looks like:
.L2:
movb$0, (%rdi)
addq$1, %rdi
cmpq%rdi, %rax
jne .L2
which is terribly slow. (The original motivation for this bug report came from
an -Og compilation, where you get:
movl$4095, %eax
.L3:
testq %rax, %rax
js .L1
movb$0, (%rdi)
addq$1, %rdi
subq$1, %rax
jmp .L3
which is even worse.)
clang -O2 (or -O1), on the other hand, generates:
xorl%esi, %esi
movl$4096, %edx # imm = 0x1000
jmp memset # TAILCALL
which is ideal, and opens up opportunities for the backend to lower the memset
to something intelligent (e.g. rep stos)
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2017-11/msg00521.ht ||ml --- Comment #6 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00521.html
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #1 from Andrew Pinski --- -O3 produces the memset: _ZN1AC2Ev: .LFB1: .cfi_startproc mov x2, 4096 mov w1, 0 b memset .cfi_endproc
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #2 from jseward at acm dot org --- (In reply to Andrew Pinski from comment #1) > -O3 produces the memset: Having to go to -O3 to get reasonable code isn't a great solution, though. Couldn't gcc at least produce a word-at-a-time loop, or "rep stosw" on x86s?
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #3 from Nathan Froyd --- Thanks, I didn't think to test -O3. Do we get the memset at -O3 because loop idiom recognition is enabled? Producing the memset upfront probably generates better code for all cases, even if the frontend code is a little more complicated.
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #4 from Marc Glisse --- The front-end internally uses VEC_INIT_EXPR, and gimplifies it to a loop. I believe we should end up with an empty CONSTRUCTOR instead.
[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80425 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Tue Nov 7 18:51:22 2017 New Revision: 254505 URL: https://gcc.gnu.org/viewcvs?rev=254505&root=gcc&view=rev Log: PR target/80425 * config/i386.i386.md (*zero_extendsidi2): Change (?r,*Yj), (?*Yi,r) and (*x,m) to ($r,Yj), ($Yi,r) and ($x,m). (zero-extendsidi peephole2): Remove peephole. testsuite/ChangeLog: PR target/80425 * gcc.target/i386/pr80425-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr80425-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Eric Botcazou --- > Producing the memset upfront probably generates better code for all cases, > even if the frontend code is a little more complicated. FWIW that's what the Ada front-end does in similar cases.
[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81096 seurer at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from seurer at gcc dot gnu.org --- Yes, it works on ppc64 now too.
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #28 from seurer at gcc dot gnu.org --- FWIW I am still seeing these fail: FAIL: g++.dg/vect/slp-pr56812.cc -std=c++11 scan-tree-dump-times slp1 "basic block vectorized" 1 (found 0 times) FAIL: g++.dg/vect/slp-pr56812.cc -std=c++14 scan-tree-dump-times slp1 "basic block vectorized" 1 (found 0 times) FAIL: g++.dg/vect/slp-pr56812.cc -std=c++98 scan-tree-dump-times slp1 "basic block vectorized" 1 (found 0 times)
[Bug target/80425] Extra inter-unit register move with zero-extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80425 Uroš Bizjak changed: What|Removed |Added Keywords|ra | Status|NEW |RESOLVED Component|rtl-optimization|target Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #8 from Uroš Bizjak --- The final patch fixes all testcases.
[Bug target/82812] ICE in emit_move_insn, at expr.c:3706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82812 --- Comment #3 from Kirill Yukhin --- Author: kyukhin Date: Tue Nov 7 19:11:08 2017 New Revision: 254507 URL: https://gcc.gnu.org/viewcvs?rev=254507&root=gcc&view=rev Log: Fix SSE bits dependencies. gcc/ PR target/82812 * common/config/i386/i386-common.c (OPTION_MASK_ISA_GENERAL_REGS_ONLY_UNSET): Remove MPX from flag. (ix86_handle_option): Move MPX to isa_flags2 and GFNI to isa_flags. * config/i386/i386-c.c (ix86_target_macros_internal): Ditto. * config/i386/i386.opt: Ditto. * config/i386/i386.c (ix86_target_string): Ditto. (ix86_option_override_internal): Ditto. (ix86_init_mpx_builtins): Move MPX to args2. (ix86_expand_builtin): Special handling for OPTION_MASK_ISA_GFNI. * config/i386/i386-builtin.def (__builtin_ia32_vgf2p8affineinvqb_v64qi, __builtin_ia32_vgf2p8affineinvqb_v64qi_mask, __builtin_ia32_vgf2p8affineinvqb_v32qi, __builtin_ia32_vgf2p8affineinvqb_v32qi_mask, __builtin_ia32_vgf2p8affineinvqb_v16qi, __builtin_ia32_vgf2p8affineinvqb_v16qi_mask): Move to ARGS array. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/i386/i386-common.c trunk/gcc/config/i386/i386-builtin.def trunk/gcc/config/i386/i386-c.c trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.opt
[Bug c/82272] RFE: request a warning for ( == ) etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Let me confirm this request, in part because I agree that such a warning has the potential to prevent bugs, and in part because C's lack of a first class Boolean type has implications for C++: https://wg21.link/lwg3011 (prompted by https://sourceware.org/bugzilla/show_bug.cgi?id=21972). In light of the latter issue I also agree that it would be appropriate to bring it up with WG14 (the C committee).
[Bug c++/82768] ICE in synthesize_implicit_template_parm, at cp/parser.c:39338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82768 Casey Carter changed: What|Removed |Added CC||Casey at Carter dot net --- Comment #2 from Casey Carter --- (In reply to Martin Liška from comment #1) > Confirmed on all release that support -fconcepts. Is it a valid code? No. Using a placeholder type for the parameter of a requires expression is not supported. (Specifically, the Addressable parameter in the definition of InternalCompilerError.)
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #3 from Martin Liška ---
The problematic block (for which we trigger the assert is):
(gdb) p debug_bb(bb)
(code_label 8952 8954 310 18 1247 (nil) [2 uses])
(note 310 8952 311 18 [bb 18] NOTE_INSN_BASIC_BLOCK)
(insn:TI 311 310 313 18 (set (reg/f:SI 0 ax [orig:873 MEM[(struct phi_arg_d
*)gsi_240].args[0].def ] [873])
(mem/f:SI (plus:SI (reg/f:SI 3 bx [orig:127 gsi ] [127])
(const_int 56 [0x38])) [193 MEM[(struct phi_arg_d
*)gsi_240].args[0].def+0 S4 A32])) "../../gcc/tree-ssa-strlen.c":2729 75
{*movsi_internal}
(nil))
(call_insn:TI 313 311 315 18 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("_ZL10get_stridxP9tree_node") [flags 0x3]
) [0 get_stridx S1 A8])
(const_int 0 [0]))) "../../gcc/tree-ssa-strlen.c":2729 553
{*call_value}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("_ZL10get_stridxP9tree_node")
[flags 0x3] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:SI (use (reg:SI 0 ax))
(nil)))
(insn:TI 315 313 314 18 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [orig:110 idx ] [110])
(const_int 0 [0]))) "../../gcc/tree-ssa-strlen.c":2730 3
{*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 0 ax [orig:110 idx ] [110])
(nil)))
(insn 314 315 316 18 (set (reg/v:SI 5 di [orig:110 idx ] [110])
(reg:SI 0 ax)) "../../gcc/tree-ssa-strlen.c":2729 75 {*movsi_internal}
(nil))
(jump_insn:TI 316 314 317 18 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:SI 343)
(pc))) "../../gcc/tree-ssa-strlen.c":2730 536 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 1064185877 (nil)))
-> 343)
Has following count:
(gdb) p bb->count
$10 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 9888, m_quality =
profile_precise}
And previous block is:
(gdb) p bb->prev_bb
$11 = (basic_block) 0xf3afc3c0
(gdb) p debug_bb(bb->prev_bb)
(note 8951 309 8953 17 [bb 17] NOTE_INSN_BASIC_BLOCK)
(jump_insn/j:TI 8953 8951 8954 17 (set (pc)
(label_ref 8952)) 537 {jump}
(nil)
-> 8952)
Has count:
(gdb) p bb->prev_bb.count
$13 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 0, m_quality =
profile_precise}
And the count is set here:
#0 0x084bce69 in force_nonfallthru_and_redirect (e=0xf4247400,
target=0xf3fd4438, jump_label=0x0) at ../../gcc/cfgrtl.c:1631
#1 0x084bd902 in rtl_force_nonfallthru (e=0xf4247400) at
../../gcc/cfgrtl.c:1709
#2 0x084ac2a4 in force_nonfallthru(edge_def*) ()
#3 0x084c1257 in fixup_new_cold_bb (bb=0xf4233c6c) at ../../gcc/cfgrtl.c:1394
#4 fixup_partitions () at ../../gcc/cfgrtl.c:2384
#5 0x08d688e5 in cleanup_cfg(int) ()
#6 0x08d54afb in (anonymous namespace)::pass_reorder_blocks::execute
(this=0x9938470, fun=0xf47733a8) at ../../gcc/bb-reorder.c:2593
#7 0x0873d5aa in execute_one_pass(opt_pass*) ()
#8 0x0873ddbf in execute_pass_list_1(opt_pass*) ()
#9 0x0873ddd2 in execute_pass_list_1(opt_pass*) ()
#10 0x0873ddd2 in execute_pass_list_1(opt_pass*) ()
#11 0x0873de19 in execute_pass_list(function*, opt_pass*) ()
#12 0x084d547c in cgraph_node::expand() ()
#13 0x084d65ba in symbol_table::compile() [clone .part.55] ()
#14 0x084d8389 in symbol_table::finalize_compilation_unit() ()
#15 0x087f613e in compile_file() ()
#16 0x082c03b9 in toplev::main(int, char**) ()
#17 0x082c2781 in main ()
[Bug rtl-optimization/82889] New: Unnecessary sign extension of int32 to int64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889
Bug ID: 82889
Summary: Unnecessary sign extension of int32 to int64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat t.cpp
#include
int lol(int32_t* table, int32_t* ht, uint32_t hash, uint32_t mask) {
for (uint64_t probe = (uint32_t)hash & mask, i = 1;; ++i) {
int32_t pos = ht[probe];
if (pos >= 0) {
if (table[pos] == 42) {
return true;
}
} else if (pos & 1) {
return false;
}
probe += i;
probe &= mask;
}
// notreached
}
compile with:
gcc -std=c++11 -O3 -s -o -
lol(int*, int*, unsigned int, unsigned int):
andl%ecx, %edx
movl$1, %r8d
movl%ecx, %ecx
jmp .L5
.L10:
cmpl$42, (%rdi,%rax,4)
je .L9
.L4:
addq%r8, %rdx
addq$1, %r8
andq%rcx, %rdx
.L5:
movslq (%rsi,%rdx,4), %rax #
[Bug demangler/82890] New: Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890 Bug ID: 82890 Summary: Demangler segfaults Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: ahoward at foxguardsolutions dot com Target Milestone: --- Demangler causes a segmentation fault when demangling name: "_ZN5boost2di6v1_0_19providers15stack_over_heap3getIN3FGS9ICSUpdate7Parsing11PatchParserEJNS1_4core10successful8any_typeIS8_NS9_8injectorINS1_6configENS9_4poolINS1_3aux9type_listIJEJZNKS1_6detailUlT_E_clINSC_ISD_SI_JZNKSM_INSC_ISD_SI_JZNKSM_INSC_ISD_SI_JNS9_10dependencyINS1_6scopes6uniqueENS7_17IPatchLinksParserENS7_16PatchLinksParserENS1_7no_nameEvEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_INSO_6deduceENS7_15IPatchCveParserENS7_14PatchCveParserESS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS7_20IPatchChecksumParserENS7_19PatchChecksumParserESS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS7_12IPatchParserES8_SS_vEEEDaSK_E1iEDaSK_E1iZNKSM_INSC_ISD_SI_JZNKSM_INSC_ISD_SI_JNSN_ISW_NS7_17PatchAvailability18ISuccessItemParserENS1D_17SuccessItemParserESS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS1D_18IFailureItemParserENS1D_17FailureItemParserESS_vEEEDaSK_E1iEDaSK_E1iZNKSM_INSC_ISD_SI_JZNKSM_INSC_ISD_SI_JNSN_ISW_NS6_14FileOperations11IFileReaderENS1Q_10FileReaderESS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS1D_13IReportParserENS1D_12ReportParserESS_vEEEDaSK_E1iEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_INSO_8instanceESt8functionIFSt10unique_ptrINS7_10JsonModels13IJsonDocumentESt14default_deleteIS27_EERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEZNKS6_2DI13ParsingModule23registerDocumentFactoryEvEUlS2I_E_SS_vEEEDaSK_E1iEDaSK_E1iZNKSM_INSC_ISD_SI_JZNKSM_INSC_ISD_SI_JNSN_ISW_NS6_18ChartDataFactories18ItemValueFactories28ItemValueAccumulationFactoryES2V_SS_vEENSN_ISW_NS2T_31ValueAccumulationFactoryWrapperIS2V_EES2Y_SS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS2T_26SingleAxisChartDataFactoryIS2Y_EES33_SS_vEENSN_ISW_NS2T_28MultipleAxisChartDataFactoryES35_SS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS9_5arrayINS2T_37IPropertyNameChartDataSelectionMapperINS6_6Models11JsonReports17PatchAvailability11SuccessItemES2G_St6vectorIPNS3C_5PatchESaIS3H_EES3G_EEJEEENS39_IS3K_JNS2T_23PatchChartDataFactories25PatchNameChartDataFactoryENS3M_27PatchVendorChartDataFactoryENS3M_24SeverityChartDataFactoryENS3M_26UpdateTypeChartDataFactorySS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS39_INS3A_IS3E_S2G_S3F_IPS3E_SaIS3V_EES3E_EEJEEENS39_IS3Y_JNS2T_32FGSIdentifiersChartDataFactories26VendorNameDataPointFactoryENS40_33VendorProductNameDataPointFactoryENS40_40VendorProductVersionNameDataPointFactorySS_vEEEDaSK_E1iZNKSM_INSC_ISD_SI_JNSN_ISW_NS39_INS2T_21ReportActionExecutors21IReportActionExecutorEJEEENS39_IS49_JNS48_25PatchReportActionExecutorIS35_S33_EENS48_31SuccessItemReportActionExecutorIS35_S33_ESS_vEENSN_ISW_S49_NS48_29ReportActionExecutorCompositeESS_vEEEDaSK_E1iEDaSK_E1iES4O_S4O_EEEDaRKNS1_11type_traits6directERKNS4P_4heapEDpOT0_" A small test program with a call to `cxa::__cxa_demangle` with the offending string as an argument yeilds the following backtrace from gdb: ` $ gdb ./a.out GNU gdb (GDB) 8.0.1 Reading symbols from ./a.out...done. (gdb) r Starting program: /mnt/f/repos/c++/demangling/a.out Program received signal SIGSEGV, Segmentation fault. d_print_callback (options=17, opaque=0x7fffe7a0, callback=0x77ae0770 , dc=0x7ffe29b0) at cp-demangle.c:4282 4282cp-demangle.c: No such file or directory. (gdb) bt #0 d_print_callback (options=17, opaque=0x7fffe7a0, callback=0x77ae0770 , dc=0x7ffe29b0) at cp-demangle.c:4282 #1 d_demangle_callback (mangled=, callback=callback@entry=0x77ae0770 , opaque=opaque@entry=0x7fffe7a0, options=17) at cp-demangle.c:6256 #2 0x77ae9a69 in d_demangle (options=17, palc=, mangled=) at cp-demangle.c:6277 #3 __cxa_demangle (mangled_name=, output_buffer=0x0, length=0x0, status=0x7fffe814) at cp-demangle.c:6341 #4 0x4a74 in main (argc=1, argv=0x7fffe908) at bug.cc:10 (gdb) l 4277in cp-demangle.c (gdb) ` I'm using gcc 7.2.0 on arch with gdb 8.0.1. As a note, while I did compile the program above myself (for debugging symbols), the same symbol will also crash c++filt. Please let me know if you need further information. Thanks!
[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Nov 7 20:48:35 2017 New Revision: 254509 URL: https://gcc.gnu.org/viewcvs?rev=254509&root=gcc&view=rev Log: PR target/82855 * config/i386/i386.c (ix86_swap_binary_operands_p): Treat RTX_COMM_COMPARE as commutative as well. (ix86_binary_operator_ok): Formatting fix. * config/i386/sse.md (*mul3, *3, *3, *tf3, *mul3, *mul3_highpart, *vec_widen_umult_even_v16si, *vec_widen_umult_even_v8si, *vec_widen_umult_even_v4si, *vec_widen_smult_even_v16si, *vec_widen_smult_even_v8si, *sse4_1_mulv2siv2di3, *avx2_pmaddwd, *sse2_pmaddwd, *_mul3, *avx2_3, *avx512f_3, *sse4_1_3, *v8hi3, *sse4_1_3, *v16qi3, *avx2_eq3, _eq3_1, *sse4_1_eqv2di3, *sse2_eq3, 3, *3, *_uavg3, *_pmulhrsw3, *ssse3_pmulhrswv4hi3): Use !(MEM_P (operands[1]) && MEM_P (operands[2])) condition instead of ix86_binary_operator_ok. Formatting fixes. (*3, *3, *3_m): Formatting fixes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sse.md
[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Nov 7 20:49:30 2017 New Revision: 254510 URL: https://gcc.gnu.org/viewcvs?rev=254510&root=gcc&view=rev Log: PR target/82855 * config/i386/i386.md (SWI1248_AVX512BWDQ2_64): New mode iterator. (*cmp_ccz_1): New insn with $k alternative. * gcc.target/i386/avx512dq-pr82855.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr82855.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/82835] [8 Regression] ICE on valid code with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82835 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Nov 7 20:51:05 2017 New Revision: 254511 URL: https://gcc.gnu.org/viewcvs?rev=254511&root=gcc&view=rev Log: PR c++/82835 * cp-gimplify.c (cxx_omp_clause_apply_fn): For methods pass i - 1 to convert_default_arg instead of i. * testsuite/libgomp.c++/pr82835.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr82835.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/libgomp/ChangeLog
[Bug c++/82835] [8 Regression] ICE on valid code with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82835 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug libstdc++/82891] New: stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
Bug ID: 82891
Summary: stable_sort() won't compile with function object that
takes parameters by non-const reference
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This fails to compile:
~~~
#include
#include
int main() {
std::vector a = { 5, 7, 1, 4, 1, 4, 2 };
std::stable_sort(
std::begin( a ),
std::end ( a ),
[] (int &x, int &y) { return x < y; }
);
}
~~~
...but works with std::sort(). The problem is that libstdc++ is trying to call
the function object with a const int (&), which the compiler can't bind a
non-const reference to.
Yet I suspect this code is valid. In point 9 (P896-897) of $25.1 of the C++14
draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf, it
says:
> The BinaryPredicate parameter is used whenever an algorithm expects a
> function object that when applied
> to the result of dereferencing two corresponding iterators or to
> dereferencing an iterator and type
> T when T is part of the signature returns a value testable as true. In other
> words, if an algorithm takes
> BinaryPredicate binary_pred as its argument and first1 and first2 as its
> iterator arguments, it should
> work correctly in the construct binary_pred(*first1, *first2) contextually
> converted to bool (Clause 4).
> BinaryPredicate always takes the first iterator’s value_type as its first
> argument, that is, in those cases
> when T value is part of the signature, it should work correctly in the
> construct binary_pred(*first1,
> value) contextually converted to bool (Clause 4). binary_pred shall not apply
> any non-constant function
> through the dereferenced iterators.
I'm not versed in standardese but I understand the middle part of this as
saying that an implementation of the standard library should work with any
predicate that can take dereferenced iterators as arguments and can be called
in a bool context (so long as it meets other specific requirements).
The errors on GodBolt are:
> In file included from
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algobase.h:71:0,
> from
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/algorithm:61,
> from :1:
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/predefined_ops.h:
> In instantiation of 'bool
> __gnu_cxx::__ops::_Iter_comp_val<_Compare>::operator()(_Iterator, _Value&)
> [with _Iterator = __gnu_cxx::__normal_iterator >;
> _Value = const int; _Compare = main()::]':
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algobase.h:959:14:
>required from '_ForwardIterator std::__lower_bound(_ForwardIterator,
> _ForwardIterator, const _Tp&, _Compare) [with _ForwardIterator =
> __gnu_cxx::__normal_iterator >; _Tp = int; _Compare =
> __gnu_cxx::__ops::_Iter_comp_val >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:2501:26:
>required from 'void std::__merge_without_buffer(_BidirectionalIterator,
> _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance,
> _Compare) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator std::vector >; _Distance = long int; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:2772:34:
>required from 'void std::__inplace_stable_sort(_RandomAccessIterator,
> _RandomAccessIterator, _Compare) [with _RandomAccessIterator =
> __gnu_cxx::__normal_iterator >; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:5004:28:
>required from 'void std::__stable_sort(_RandomAccessIterator,
> _RandomAccessIterator, _Compare) [with _RandomAccessIterator =
> __gnu_cxx::__normal_iterator >; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:5075:36:
>required from 'void std::stable_sort(_RAIter, _RAIter, _Compare) [with
> _RAIter = __gnu_cxx::__normal_iterator >; _Compare =
> main()::]'
> 10 : :10:2: required from here
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/predefined_ops.h:177:11:
> error: no match for call to '(main()::) (int&, const
> int&)'
> { return bool(_M_comp(*__it, __val)); }
>^~~
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/predefined_ops.h:177:11:
> note: candidate: 'bool (*)(int&, int&)'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/predefined_ops.h:177:11:
> note: conversion of ar
[Bug c/82892] New: Spelling hints do not take into account missing compiler options (e.g. -fopenmp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82892
Bug ID: 82892
Summary: Spelling hints do not take into account missing
compiler options (e.g. -fopenmp)
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
The nice diagnostics feature of spelling hints made me scratch my head
until I noticed that I forgot to provide the flag -fopenmp:
% cat print_openmp_version.c
#include
int
main ()
{
printf ("_OPENMP = %d\n", _OPENMP);
return 0;
}
% gcc-7 print_openmp_version.c
print_openmp_version.c: In function 'main':
print_openmp_version.c:6:29: error: '_OPENMP' undeclared (first use in this
function); did you mean '_G_OPEN64'?
printf ("_OPENMP = %d\n", _OPENMP);
^~~
_G_OPEN64
print_openmp_version.c:6:29: note: each undeclared identifier is reported only
once for each function it appears in
% gcc-7 print_openmp_version.c -fopenmp
Would it make sense to extend this feature to appropriate compilation flags?
[Bug c++/82893] New: Bad diagnostic on negative sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82893
Bug ID: 82893
Summary: Bad diagnostic on negative sized array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider this example:
struct Foo {
int n;
};
struct Bar {
double n;
bool b;
};
template
struct Baz : public T {
char pad[8 - sizeof(T)];
};
int main() {
static_assert(sizeof(Baz) == 8, "");
static_assert(sizeof(Baz) == 8, "");
}
The diagnostic that every gcc yields (on basically every version) is:
prog.cc:15:5: error: non-constant condition for static assertion
static_assert(sizeof(Baz) == 8, "");
^
This is very misleading and unhelpful. It'd be nice if it were possible to get
a better diagnostic that points to the cause of the problem. clang, for
instance, yields:
prog.cc:10:14: error: array is too large (18446744073709551608 elements)
char pad[8 - sizeof(T)];
^
prog.cc:15:19: note: in instantiation of template class 'Baz' requested
here
static_assert(sizeof(Baz) == 8, "");
^
[Bug fortran/82886] ICE with -finit-derived in gfc_conv_expr, at fortran/trans-expr.c:7807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82886 Fritz Reese changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot gnu.org --- Comment #3 from Fritz Reese --- On it.
[Bug c/82272] RFE: request a warning for ( == ) etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272 --- Comment #4 from joseph at codesourcery dot com --- I should point out that expanding to the tokens 0 and 1 for C does not in any way prevent warning (it's a perfectly reasonable optional style warning); you could for example have the preprocessor specially mark the macros true and false when defined in stdbool.h in a system include directory, and then specially mark tokens resulting from their expansions so that the compiler can warn for dubious comparisons. So, whether or not the standard should require those exact token expansions, the standard does not prevent such warnings, though it may make them more complicated to implement.
[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 82839, which changed state. Bug 82839 Summary: missing -Wmaybe-uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430 Manuel López-Ibáñez changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #33 from Manuel López-Ibáñez --- *** Bug 82839 has been marked as a duplicate of this bug. ***
[Bug middle-end/82839] missing -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez --- Most Wuninitialized bugs are known. *** This bug has been marked as a duplicate of bug 19430 ***
[Bug tree-optimization/18501] [6/7/8 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #81 from Manuel López-Ibáñez --- *** Bug 82810 has been marked as a duplicate of this bug. ***
[Bug middle-end/82810] missed uninitialized variable warning in for/while loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82810 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- I guess this prints 0. If so, then it is Infamous 18501. Those are easy to recognize because there is an assignment to the uninitialized variable after the uninitialized use. *** This bug has been marked as a duplicate of bug 18501 ***
[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 82810, which changed state. Bug 82810 Summary: missed uninitialized variable warning in for/while loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82810 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 Manuel López-Ibáñez changed: What|Removed |Added CC||s-beyer at gmx dot net --- Comment #35 from Manuel López-Ibáñez --- *** Bug 82552 has been marked as a duplicate of this bug. ***
[Bug c++/82552] No warning when using uninitialized values in initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82552 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Manuel López-Ibáñez --- (In reply to Eric Gallager from comment #3) > (In reply to Jonathan Wakely from comment #1) > > This is a duplicate of an existing bug report. > > bug 19808 perhaps? Yes. *** This bug has been marked as a duplicate of bug 19808 ***
[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 82552, which changed state. Bug 82552 Summary: No warning when using uninitialized values in initializer list https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82552 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
