[Bug c++/80332] Warning is issued for deprecated "using" type alias of deprecated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80332 --- Comment #2 from Freddie Chopin --- Same behaviour with gcc 7.0.1 20170409.
[Bug c++/80458] [-Wreturn-type] false negative on missing return statement in a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80458
--- Comment #4 from Ulya ---
That sounds reasonable, however if I comment out 'if (!p) exit(1);', I get
warning no matter inline or not:
$ cat 1.cc
#include // exit
extern void *f();
inline void *g() {
void *p = f();
//if (!p) exit(1);
}
skvadrik@skvadr_home ~ $ g++ -c -Wall -Wextra -O2 1.cc
1.cc: In function ‘void* g()’:
1.cc:4:11: warning: unused variable ‘p’ [-Wunused-variable]
void *p = f();
^
1.cc:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
}
^
[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725 --- Comment #15 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #13) > (In reply to Richard Biener from comment #12) > > Confirmed. I suspect it's coverage mismatch errors causing the issue. > > No. The file in question changes between stages as shown in comment 10. > PGO of course can not work in this case. That mentioned, isn't that reason to close the PR as invalid?
[Bug debug/80461] New: [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 Bug ID: 80461 Summary: [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ian at airs dot com Target Milestone: --- Created attachment 41224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41224&action=edit tset-case After r245039, we ICE on attached test-case: $ g++ ice.ii -c -g ice.ii:47:1: internal compiler error: in modified_type_die, at dwarf2out.c:12566 } ^ 0xa7eaea modified_type_die ../../gcc/dwarf2out.c:12566 0xa7ec84 add_type_attribute ../../gcc/dwarf2out.c:20595 0xa6b7ce generic_parameter_die ../../gcc/dwarf2out.c:12880 0xa6be61 gen_generic_params_dies ../../gcc/dwarf2out.c:12805 0xa6ceae gen_subprogram_die ../../gcc/dwarf2out.c:22315 0xa70986 force_decl_die ../../gcc/dwarf2out.c:25031 0xa6e24b gen_subprogram_die ../../gcc/dwarf2out.c:21880 0xa6f43c gen_decl_die ../../gcc/dwarf2out.c:25320 0xa7040e dwarf2out_decl ../../gcc/dwarf2out.c:25829 0xa8dc17 dwarf2out_early_global_decl ../../gcc/dwarf2out.c:25486 0x9f6d88 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2617
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |7.0
--- Comment #3 from Jakub Jelinek ---
This seems to go wrong during loop splitting, there is highly undesirable
change in the *.lsplit dump:
e_95 -> { e_14 }
+b.0_96 -> { b.0_16 }
Incremental SSA update started at block: 42
Number of blocks in CFG: 46
-Number of blocks to update: 5 ( 11%)
+Number of blocks to update: 10 ( 22%)
...
int _94;
+ int b.0_96;
[0.29%]:
...
# f_43 = PHI
# a_lsm.15_24 = PHI
+ # b.0_96 = PHI
[50.00%]:
# .MEM_52 = PHI <.MEM_9(7), .MEM_52(9)>
# f_51 = PHI
# a_lsm.15_50 = PHI
# a_lsm.16_49 = PHI <0(7), 1(9)>
+ # DEBUG f => f_51
+ # DEBUG D#3 => (unsigned int) b.0_96
+ # DEBUG f => D#3
That extra b.0_96 PHI has been added because there is a debug use of b.0_16 and
we want to rewrite it into loop closed SSA form.
[Bug c++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290 --- Comment #16 from rguenther at suse dot de --- On April 19, 2017 8:10:58 AM GMT+02:00, "jason at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290 > >--- Comment #15 from Jason Merrill --- >Adding a timevar to cxx_eval_outermost_constant_expr shows minimal time >spent >in constexpr evaluation; it also doesn't show up in -fmem-report. So >constexpr >isn't the problem. The number of calls suggest otherwise. Are you sure the timevar isn't pushed away here (overload resolution seemed to be triggered by constexpr evaluation, so better constrxpr caching should help) >It seems to me that the problem is that we added a bunch of constructor >template overloads, and made all of them rely on doing further overload >resolution in order to evaluate the SFINAE condition, and that's a lot >more >work for the compiler. And then there are a few places, notably >push_tinst_level, that allocate memory that isn't freed until the next >GC, so >in this case it keeps building up. I suppose adding GC points isn't easily possible either? >We ought to be able to be smarter about caching previous overload >resolution >results, but that would be new machinery that doesn't seem suitable for >stage >4. > >I'll keep poking.
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172 --- Comment #13 from Sergio Martins --- Any point in using warn_unused_result instead of nodiscard on compilers that support both ? Probably a good time to close this bug. While it would be nice to have it fixed there's no point on wasting resources on it anymore.
[Bug gcov-profile/80435] Expose __gcov_flush to allow developers to dump coverage numbers on demand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80435 --- Comment #4 from Martin Liška --- Author: marxin Date: Wed Apr 19 08:08:44 2017 New Revision: 246990 URL: https://gcc.gnu.org/viewcvs?rev=246990&root=gcc&view=rev Log: Introduce gcov.h header file (PR gcov-profile/80435). 2017-04-19 Martin Liska PR gcov-profile/80435 * Makefile.in: Install gcov.h. * gcov.h: New file. * libgcov.h: Use the header and make __gcov_flush publicly visible. Added: trunk/libgcc/gcov.h Modified: trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/libgcov.h
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436 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 41225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41225&action=edit gcc7-pr80436.patch Untested fix. Seems debug stmts are generally an exception from loop closed SSA form, we already have: if (is_gimple_debug (stmt)) return; in find_uses_to_rename_stmt and check_loop_closed_ssa_stmt, just not at this spot.
[Bug gcov-profile/80435] Expose __gcov_flush to allow developers to dump coverage numbers on demand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80435 Martin Liška changed: What|Removed |Added Known to work||7.0.1 Known to fail||5.4.0, 6.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk, queued for active branches.
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #10 from Martin Liška --- I'm testing the suggested patch.
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815 --- Comment #3 from Martin Liška --- I see, can you please paste configure options for GCC, that would help me so that I can try to reproduce. Apart from that, the problematic GCC invocation command line would be also appreciated.
[Bug c++/80458] [-Wreturn-type] false negative on missing return statement in a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80458 --- Comment #5 from Jonathan Wakely --- In that case no control flow analysis is needed, it's clear that the missing return is always reached. With the conditional exit it depends on whether p can be null, which requires more analysis.
[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- /* Avoid trouble with non-power-of-two sizes. */ #if !defined(__i386__) && !defined(__x86_64__) && !defined(__m68k__) && !defined(__ia64__) && !defined(__hppa__) T_TEST(long double) #endif Guess we should ifdef away also targets where (__SIZEOF_LONG_DOUBLE__ & (__SIZEOF_LONG_DOUBLE__ - 1)) != 0 or where #ifdef __SIZEOF_INT128__ #define SIZEOF_MAXINT __SIZEOF_INT128__ #else #define SIZEOF_MAXINT __SIZEOF_LONG_LONG__ __SIZEOF_LONG_DOUBLE__ > SIZEOF_MAXINT .
[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-19 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- I also can't reproduce that, even before the mentioned commit r242965, all look fine.
[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-19 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 41226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41226&action=edit gcc7-pr80459.patch Untested fix.
[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Jakub Jelinek --- > Created attachment 41226 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41226&action=edit > gcc7-pr80459.patch > > Untested fix. Works for me on sparc-sun-solaris2.12. Thanks. Rainer
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #52 from Jürgen Reuter --- I tried again to make a more reduced test case, but I couldn't really separate it from library structure of our code. Do you think you can work with the given test case?
[Bug target/80462] New: [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80462 Bug ID: 80462 Summary: [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- const __flash char string1[] = "same string"; const __flash char string2[] = "same string"; throws the following incorrect warning when compiled with -Os -Wall -fmerge-all-constants: file.c:2:20: warning: uninitialized variable 'string2' put into program memory area [-Wuninitialized] const __flash char string2[] = "same string"; ^~~
[Bug target/80462] [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80462 Georg-Johann Lay changed: What|Removed |Added Keywords||diagnostic Target||avr Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-19 Version|unknown |6.3.1 Ever confirmed|0 |1
[Bug rtl-optimization/80429] -fcompare-debug failure on ppc64le with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80429 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Wed Apr 19 10:03:35 2017 New Revision: 246991 URL: https://gcc.gnu.org/viewcvs?rev=246991&root=gcc&view=rev Log: IRA: Don't create new regs for debug insns (PR80429) In split_live_ranges_for_shrink_wrap IRA also splits regs that are only used in debug insns, leading to -fcompare-debug failures. PR rtl-optimization/80429 * ira.c (split_live_ranges_for_shrink_wrap): Don't split regs that are only used in debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The warning is done before optimizations (except GENERIC opts), and can hardly be done much later. In *.original we have: case 0:; <; case 1:; <; and what the warning code sees in *.gimple when it is performed is: switch (i) , case 0: , case 1: > : if (1 != 0) goto ; else goto ; : qt_assert (); : qt_noop (); : qt_noop (); : So, to get rid of the warning, we'd need to do some optimization already during the gimplification, perhaps if we have COND_EXPR with constant condition scan the non-active branch and if there are no labels in there, don't try to gimplify it at all? Walking it for all COND_EXPRs with constant condition would have undesirable compile time complexity though if there are any labels. And trying to prove if some code is reachable or not reachable at gimplification time is not really doable, we don't have CFG. Moving the warning later is also undesirable, because the IL would be mangled and wouldn't match the original source the way we need.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #53 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #51) > (In reply to Thomas Koenig from comment #50) > > (In reply to Jürgen Reuter from comment #48) > > > (In reply to Thomas Koenig from comment #47) > > > > I'll try some bisection. > > > > > > Did you get the full tarball running on an x86_64? > > > > Yes, at least up to the point where I could "make check". > > > > I would have gone faster if "make -j4" worked to compile > > the package in parallel :-) > > Strange. We always do `make -j4`. What went wrong? Well, "make -j4" worked, but the speedup due to parallel processing was not big, around 29 min of CPU time for 22 min of wall clock time: real22m21.054s user28m7.053s sys 0m52.747s
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #54 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #53) > (In reply to Jürgen Reuter from comment #51) > > (In reply to Thomas Koenig from comment #50) > > > (In reply to Jürgen Reuter from comment #48) > > > > (In reply to Thomas Koenig from comment #47) > > > > > I'll try some bisection. > > > > > > > > Did you get the full tarball running on an x86_64? > > > > > > Yes, at least up to the point where I could "make check". > > > > > > I would have gone faster if "make -j4" worked to compile > > > the package in parallel :-) > > > > Strange. We always do `make -j4`. What went wrong? > > Well, "make -j4" worked, but the speedup due to parallel > processing was not big, around 29 min of CPU time for > 22 min of wall clock time: > > real22m21.054s > user28m7.053s > sys 0m52.747s I see. This is indeed true, but is IMHO the price to pay for OO code with many interdependencies. Up to now we refrained from using submodules.
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460 --- Comment #2 from Marek Polacek --- I thought we could (in collect_fallthrough_labels) look at the GIMPLE_COND, see if its OP0 and OP1 are INTEGER_CSTs, and if they are, determine which branch cannot be taken, and then maybe don't do labels->safe_push (l); which should suppress the warning.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #55 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #52) > I tried again to make a more reduced test case, but I couldn't really > separate it from library structure of our code. Do you think you can work > with the given test case? What I can (personally) do is to try and find the offending revision by bisection. It should then be doable (hopefully by somebody else) to find any differences due to that particular revision by examining differences in tree and RTL dumps. This will take some time, though.
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
--- Comment #3 from Jakub Jelinek ---
Would that disable warning for:
if (0)
switch (x)
{
case 5:
x++;
case 6:
x += 17;
break;
}
?
Perhaps that is ok. Wouldn't that also disable warning for:
if (x > 24)
goto lab;
if (0)
{
lab:
switch (x)
{
case 37:
x++;
case 38:
x += 18;
break;
}
}
? On the latter we should warn...
[Bug libstdc++/80446] UNRESOLVED: 18_support/launder/1.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80446 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Wed Apr 19 10:49:12 2017 New Revision: 246992 URL: https://gcc.gnu.org/viewcvs?rev=246992&root=gcc&view=rev Log: PR libstdc++/80446 cope with libc defining __has_builtin PR libstdc++/80446 * include/std/type_traits (is_aggregate): Change __has_builtin checks. * libsupc++/new (launder): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/libsupc++/new
[Bug libstdc++/80446] UNRESOLVED: 18_support/launder/1.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80446 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Jonathan Wakely --- Fixed.
[Bug libstdc++/80448] #include fails with Clang 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80448 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Apr 19 11:03:43 2017 New Revision: 246993 URL: https://gcc.gnu.org/viewcvs?rev=246993&root=gcc&view=rev Log: PR libstdc++/80448 remove noexcept from defaulted functions PR libstdc++/80448 * include/experimental/bits/fs_dir.h (directory_iterator) (recursive_directory_iterator): Remove noexcept from defaulted constructors. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/bits/fs_dir.h
[Bug bootstrap/53757] [llto bootstrap] fails due to various -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53757 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Liška --- Since 4.8.0 times, I successfully finished LTO bootstrap.
[Bug libstdc++/80448] #include fails with Clang 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80448 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Jonathan Wakely --- Should be fixed.
[Bug lto/54118] ICE in lto_output_varpool_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54118 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- I can confirm that I failed in 4.7.x times, however starting from GCC 4.8.0 it works fine.
[Bug rtl-optimization/80463] New: [6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
Bug ID: 80463
Summary: [6/7 Regression] ICE with -fselective-scheduling2 and
-fvar-tracking-assignments
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from r227844, we ICE on:
$ cat ice.ii
int *a;
int b, c;
void
d ()
{
for (int e; c; e++)
switch (e)
{
case 0:
a[e] = 1;
case 1:
b = 2;
break;
default:
a[e] = 3;
}
}
$ g++ ice.ii -fselective-scheduling2 -O2 -c -fvar-tracking-assignments
cc1plus: warning: var-tracking-assignments changes selective scheduling
ice.ii: In function ‘void d()’:
ice.ii:17:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6393
}
^
0xdba2f2 code_motion_process_successors
../../gcc/sel-sched.c:6390
0xdba2f2 code_motion_path_driver
../../gcc/sel-sched.c:6613
0xdb9ec7 code_motion_process_successors
../../gcc/sel-sched.c:6347
0xdb9ec7 code_motion_path_driver
../../gcc/sel-sched.c:6613
0xdba7e6 move_op
../../gcc/sel-sched.c:6704
0xdba7e6 move_exprs_to_boundary
../../gcc/sel-sched.c:5227
0xdba7e6 schedule_expr_on_boundary
../../gcc/sel-sched.c:5440
0xdbe2bb fill_insns
../../gcc/sel-sched.c:5582
0xdbfdc4 schedule_on_fences
../../gcc/sel-sched.c:7356
0xdbfdc4 sel_sched_region_2
../../gcc/sel-sched.c:7494
0xdc1544 sel_sched_region_1
../../gcc/sel-sched.c:7536
0xdc1544 sel_sched_region(int)
../../gcc/sel-sched.c:7637
0xdc2981 run_selective_scheduling()
../../gcc/sel-sched.c:7713
0xd9b4c5 rest_of_handle_sched2
../../gcc/sched-rgn.c:3722
0xd9b4c5 execute
../../gcc/sched-rgn.c:3866
The commit is probably not responsible for the ICE.
[Bug debug/80461] [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0
[Bug other/53925] dbgcnt.c:dbg_cnt_set_limit_by_index emits diagnostic via fprintf (stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53925 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Martin Liška --- Hello. Thanks for the PR, however the option is mainly intended for people how reduce a problem and this justifies why it's printed to stderr. It makes it visible to user which can fast change the value to find a problematic transformation.
[Bug other/51732] typo in man gcc: "runt-time check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51732 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed in 4.7.
[Bug sanitizer/55661] options summary lists -fsanitize in wrong section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55661 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Currently the options live in section called 'Program Instrumentation Options'.
[Bug sanitizer/55519] [asan] False positive -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55519 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Liška --- Can't reproduce, please attach a pre-processed file if it's still valid. Thanks.
[Bug sanitizer/55509] gcc.dg/torture/matrix-6.c failures with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55509 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-19 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Is the issue still present?
[Bug sanitizer/55506] gcc.dg/cleanup-{10,11,8,9}.c execution test failures with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55506 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-19 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Likewise, is the issue still present?
[Bug debug/80461] [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 --- Comment #1 from Jakub Jelinek --- Created attachment 41227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41227&action=edit gcc7-pr80461.patch Untested fix.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #56 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #55) > (In reply to Jürgen Reuter from comment #52) > > I tried again to make a more reduced test case, but I couldn't really > > separate it from library structure of our code. Do you think you can work > > with the given test case? > > What I can (personally) do is to try and find the offending > revision by bisection. It should then be doable (hopefully by somebody > else) to find any differences due to that particular revision > by examining differences in tree and RTL dumps. > > This will take some time, though. Sure, take your time. As we have a workaround there is no panic on our side. In any case, the problem only appeared for using fp-80 as kind parameters for floats which is not the default application.
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815 --- Comment #4 from vicencb at gmail dot com --- I can confirm that with the provided list of steps it is still reproducible. To obtain the buildroot version use this: cd /tmp git clone git://git.buildroot.net/buildroot cd buildroot git checkout eb1a30a3d92c8ddbcc295cb48226604d6d881e25 And then following the steps, this is the error message reported (including the command line invocation): Making all in mpxrt /bin/sh ../libtool --tag=CC --mode=compile /tmp/buildroot/output/build/host-gcc-final-6.1.0/build/./gcc/xgcc -B/tmp/buildroot/output/build/host-gcc-final-6.1.0/build/./gcc/ -B/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/bin/ -B/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/lib/ -isystem /tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/include -isystem /tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/sys-include -DHAVE_CONFIG_H -I. -I../../../../libmpx/mpxrt -I.. -I../../../../libmpx/.. -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c -o libmpx_la-mpxrt.lo `test -f 'mpxrt.c' || echo '../../../../libmpx/mpxrt/'`mpxrt.c libtool: compile: /tmp/buildroot/output/build/host-gcc-final-6.1.0/build/./gcc/xgcc -B/tmp/buildroot/output/build/host-gcc-final-6.1.0/build/./gcc/ -B/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/bin/ -B/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/lib/ -isystem /tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/include -isystem /tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/sys-include -DHAVE_CONFIG_H -I. -I../../../../libmpx/mpxrt -I.. -I../../../../libmpx/.. -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -c ../../../../libmpx/mpxrt/mpxrt.c -fPIC -DPIC -o .libs/libmpx_la-mpxrt.o In file included from ../../../../libmpx/mpxrt/mpxrt.c:54:0: ../../../../libmpx/mpxrt/mpxrt.c: In function 'read_mpx_status_sig': ../../../../libmpx/mpxrt/mpxrt.h:52:42: error: invalid application of 'sizeof' to incomplete type 'struct _libc_fpstate' #define XSAVE_OFFSET_IN_FPMEMsizeof (struct _libc_fpstate) ^ ../../../../libmpx/mpxrt/mpxrt.c:132:58: note: in expansion of macro 'XSAVE_OFFSET_IN_FPMEM' uint8_t *regs = (uint8_t *)uctxt->uc_mcontext.fpregs + XSAVE_OFFSET_IN_FPMEM; ^ And the gcc configuration from /tmp/buildroot/output/build/host-gcc-final-6.1.0/build/gcc/config.log: $ /tmp/buildroot/output/build/host-gcc-final-6.1.0/gcc/configure --srcdir=../../gcc --cache-file=./config.cache --prefix=/tmp/i686-buildroot-linux-musl/usr/usr --sysconfdir=/tmp/i686-buildroot-linux-musl/usr/etc --enable-static --with-sysroot=/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/sysroot --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --with-gmp=/tmp/i686-buildroot-linux-musl/usr/usr --with-mpfr=/tmp/i686-buildroot-linux-musl/usr/usr --with-pkgversion=Buildroot 2016.08-git-01592-geb1a30a3d --with-bugurl=http://bugs.buildroot.net/ --enable-libquadmath --disable-libsanitizer --disable-tls --enable-plugins --enable-lto --disable-libmudflap --enable-threads --with-mpc=/tmp/i686-buildroot-linux-musl/usr/usr --with-isl=/tmp/i686-buildroot-linux-musl/usr/usr --disable-decimal-float --with-arch=i686 --with-build-time-tools=/tmp/i686-buildroot-linux-musl/usr/usr/i686-buildroot-linux-musl/bin --enable-shared --disable-libgomp --enable-languages=c,c++,lto --program-transform-name=s&^&i686-buildroot-linux-musl-& --disable-option-checking --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=i686-buildroot-linux-musl Please, note that this is a crosscompiler. I hope this helps fixing the bug. Regards.
[Bug sanitizer/55799] AddressSanitizer with `-pg' option results in spurious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55799 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-19 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Is the issues still present on GCC 5+ ?
[Bug lto/50345] Incomplete GCC Internals sentence on LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345 --- Comment #3 from Martin Liška --- Author: marxin Date: Wed Apr 19 12:00:47 2017 New Revision: 246995 URL: https://gcc.gnu.org/viewcvs?rev=246995&root=gcc&view=rev Log: Fix typo in LTO documentation (PR lto/50345). 2017-04-19 Paulo J. Matos PR lto/50345 * doc/lto.texi: Remove an extra 'that'. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/lto.texi
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-04-19
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Marek Polacek ---
I think it shouldn't affect those at all.
Another idea is to return fake FALLTHROUGH () if the else branch is dead. Let
me see.
extern void die (void) __attribute__((noreturn));
extern void nop (void);
void
f (int i)
{
switch (i)
{
case 0:
if (1)
die ();
else
nop ();
case 1:;
i++;
}
switch (i)
{
case 0:
if (0)
die ();
else
nop ();
case 1:;
i++;
}
switch (i)
{
case 0:
if (1)
nop ();
else
die ();
case 1:;
i++;
}
switch (i)
{
case 0:
if (0)
nop ();
else
die ();
case 1:;
i++;
}
}
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #57 from Thomas Koenig --- And here comes the first problem... Running with rev 243584 (as a bisection) results in very many failed tests like
[Bug lto/50345] Incomplete GCC Internals sentence on LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed on trunk.
[Bug rtl-optimization/80463] [6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
--- Comment #1 from amker at gcc dot gnu.org ---
Not sure which pass should be responsible for this.
The test uses un-initialized variable e, which could cause undefined behavior?
Also if I change the test into:
int *a;
int b, c;
void
d ()
{
for (int e = 0; c; e++)
switch (e)
{
case 0:
a[e] = 1;
case 1:
b = 2;
break;
default:
a[e] = 3;
}
}
Then r227842 has segmentation fault too, though at different place.
$ ./g++ pr80463.c -fselective-scheduling2 -O2 -c -fvar-tracking-assignments -S
pr80463.c:1:0: warning: var-tracking-assignments changes selective scheduling
int *a;
^
pr80463.c: In function ‘void d()’:
pr80463.c:17:1: internal compiler error: Segmentation fault
}
^
0xfaf6e2 crash_signal
../../gcc/gcc/toplev.c:352
0xb043e4 bb_note(basic_block_def*)
../../gcc/gcc/cfgrtl.c:679
0xf5d4dd sel_bb_head(basic_block_def*)
../../gcc/gcc/sel-sched-ir.c:4520
0xf6c739 moveup_expr_cached
../../gcc/gcc/sel-sched.c:2528
0xf74945 move_op_ascend
../../gcc/gcc/sel-sched.c:6151
0xf75548 code_motion_path_driver
../../gcc/gcc/sel-sched.c:6653
0xf756b9 move_op
../../gcc/gcc/sel-sched.c:6709
0xf729ef move_exprs_to_boundary
../../gcc/gcc/sel-sched.c:5226
0xf73541 schedule_expr_on_boundary
../../gcc/gcc/sel-sched.c:5438
0xf739b7 fill_insns
../../gcc/gcc/sel-sched.c:5580
0xf76e23 schedule_on_fences
../../gcc/gcc/sel-sched.c:7363
0xf77308 sel_sched_region_2
../../gcc/gcc/sel-sched.c:7501
0xf77491 sel_sched_region_1
../../gcc/gcc/sel-sched.c:7543
0xf778e4 sel_sched_region(int)
../../gcc/gcc/sel-sched.c:7644
0xf779fe run_selective_scheduling()
../../gcc/gcc/sel-sched.c:7720
0xf50167 rest_of_handle_sched2
../../gcc/gcc/sched-rgn.c:3628
0xf50340 execute
../../gcc/gcc/sched-rgn.c:3772
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 --- Comment #11 from Martin Liška --- Author: marxin Date: Wed Apr 19 12:06:35 2017 New Revision: 246996 URL: https://gcc.gnu.org/viewcvs?rev=246996&root=gcc&view=rev Log: Update SSA after AutoPGO early inlining (PR ipa/65972). 2017-04-19 Richard Biener PR ipa/65972 * auto-profile.c (afdo_vpt_for_early_inline): Update SSA when needed by AutoPGO. Modified: trunk/gcc/ChangeLog trunk/gcc/auto-profile.c
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972 Martin Liška changed: What|Removed |Added Known to work||7.0.1 Known to fail||5.4.0, 6.3.0 --- Comment #12 from Martin Liška --- Fixed on trunk, queued for active branches.
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #58 from Thomas Koenig --- (In reply to Thomas Koenig from comment #57) > And here comes the first problem... > > Running with rev 243584 (as a bisection) results in > very many failed tests like *** Error in `/home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard': double free or corruption (!prev): 0x01e97360 *** === Backtrace: = /lib64/libc.so.6(+0x7383b)[0x7f05eded383b] /lib64/libc.so.6(+0x79dee)[0x7f05eded9dee] /lib64/libc.so.6(+0x7a5fe)[0x7f05ededa5fe] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__models_MOD___final_models_Model_t+0x23a)[0x7f05f00121ca] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_config_MOD_process_config_data_final+0x69)[0x7f05f005fb89] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_MOD_process_final+0x4e)[0x7f05f007d44e] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_stacks_MOD_process_stack_clear+0xbd)[0x7f05f00bee2d] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__process_stacks_MOD_process_stack_final+0xb)[0x7f05f00b6dab] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__rt_data_MOD_rt_data_global_final+0x2a)[0x7f05efca80fa] /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so.1(__whizard_MOD_whizard_final+0x2a)[0x7f05efd41c1a] /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so.0(+0x412f)[0x7f05f215d12f] /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so.0(main+0x1f)[0x7f05f215b9bf] /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f05ede80541] /home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard[0x4005da] Hmm... seems like I need to apply revision 245191 on top. We'll see what that does.
[Bug middle-end/80270] ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270
--- Comment #2 from Alexander Ivchenko ---
Another test that fails similarly, but already at "-O0":
typedef int v8 __attribute__ ((vector_size (8)));
struct S2
{
v8 s2f2;
int* f3;
};
int foo (int i)
{
register struct S2 b asm ("xmm0");
int k = 5;
b.f3 = &k;
b.f3 = b.f3 + i;
return *b.f3;
}
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #59 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #58) > (In reply to Thomas Koenig from comment #57) > > And here comes the first problem... > > > > Running with rev 243584 (as a bisection) results in > > very many failed tests like > > *** Error in `/home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard': double > free or corruption (!prev): 0x01e97360 *** > === Backtrace: = > /lib64/libc.so.6(+0x7383b)[0x7f05eded383b] > /lib64/libc.so.6(+0x79dee)[0x7f05eded9dee] > /lib64/libc.so.6(+0x7a5fe)[0x7f05ededa5fe] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__models_MOD___final_models_Model_t+0x23a)[0x7f05f00121ca] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_config_MOD_process_config_data_final+0x69)[0x7f05f005fb89] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_MOD_process_final+0x4e)[0x7f05f007d44e] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_stacks_MOD_process_stack_clear+0xbd)[0x7f05f00bee2d] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__process_stacks_MOD_process_stack_final+0xb)[0x7f05f00b6dab] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__rt_data_MOD_rt_data_global_final+0x2a)[0x7f05efca80fa] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/libwhizard.so. > 1(__whizard_MOD_whizard_final+0x2a)[0x7f05efd41c1a] > /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so. > 0(+0x412f)[0x7f05f215d12f] > /home/ig25/Downloads/whizard-2.4.1/src/whizard-core/.libs/libwhizard_main.so. > 0(main+0x1f)[0x7f05f215b9bf] > /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f05ede80541] > /home/ig25/Downloads/whizard-2.4.1/src/.libs/whizard[0x4005da] > > Hmm... seems like I need to apply revision 245191 on top. > We'll see what that does. Yep, that was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79230 introduced in r243480.
[Bug target/80462] [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80462 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Wed Apr 19 12:20:57 2017 New Revision: 246997 URL: https://gcc.gnu.org/viewcvs?rev=246997&root=gcc&view=rev Log: PR target/80462 * config/avr/avr.c (tree.h): Include it. (cgraph.h): Include it. (avr_encode_section_info): Don't warn for uninitialized progmem variable if it's just an alias. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/80462] [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80462 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Wed Apr 19 12:22:59 2017 New Revision: 246998 URL: https://gcc.gnu.org/viewcvs?rev=246998&root=gcc&view=rev Log: Backport from 2017-04-19 trunk r246997. PR target/80462 * config/avr/avr.c (tree.h): Include it. (cgraph.h): Include it. (avr_encode_section_info): Don't warn for uninitialized progmem variable if it's just an alias. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.c
[Bug target/80462] [avr] Incorrect "warning: uninitialized variable 'xxx' put into program memory area" for identical strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80462 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Target Milestone|--- |6.4 --- Comment #3 from Georg-Johann Lay --- Fixed in 6.4+.
[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 --- Comment #5 from David Malcolm --- Likewise, I tried but failed to reproduce it. A hunch: given the "-march=native", is there a chance that this bug is dependent on the precise CPU flags on the host?
[Bug other/51732] typo in man gcc: "runt-time check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51732 --- Comment #2 from Martin Guy --- :D :D Reminds me of the first edition of a Gutenberg text for Shakespeare which, due to an unfortunate OCR mismatch which also passed the spelling check, had "He held the babe in his anus" for several years. (That should be "arms")
[Bug rtl-optimization/80463] [5/6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-19 Summary|[6/7 Regression] ICE with |[5/6/7 Regression] ICE with |-fselective-scheduling2 and |-fselective-scheduling2 and |-fvar-tracking-assignments |-fvar-tracking-assignments Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.4, 5.4.0, 6.3.0, ||7.0.1 --- Comment #2 from Martin Liška --- It would be related to selective scheduling pass. Testing your fixed test-case, I see ICE starting from GCC 4.8.0. GCC 4.5.0 works, and in between I see probably an infinite recursion.
[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70773 wilco at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||wilco at gcc dot gnu.org --- Comment #10 from wilco at gcc dot gnu.org --- I can't reproduce any of this. GCC6 and GCC7 always use smull for the divisions on ARM, even with profile-use. I could only make GCC emit a library call by using -Os on a CPU that doesn't have divide, but that is expected and correct. On AArch64 I get > 20% speedup with -fprofile-use vs plain -O3, so it works as expected. With -mcpu=cortex-a53 there are more uses of sdiv, but the profiled version is still faster. So without more details I don't see any issue here.
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #2 from Jakub Jelinek --- While I could reproduce this yesterday on x86_64-linux (but only with bootstrapped gcc), I can't reproduce this anymore today. My tree includes the PR80436 fix, but it doesn't seem that changed spot is ever encountered while compiling the testcase.
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
--- Comment #5 from Marek Polacek ---
Actually, nothing I imagined wouldn't work for the case when the else branch is
dead :(.
A patch that helps with bogus warning for dead then branches:
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1912,6 +1912,7 @@ collect_fallthrough_labels (gimple_stmt_iterator *gsi_p,
if (gimple_code (gsi_stmt (*gsi_p)) == GIMPLE_COND)
{
gcond *cond_stmt = as_a (gsi_stmt (*gsi_p));
+ bool false_p = gimple_cond_false_p (cond_stmt);
tree false_lab = gimple_cond_false_label (cond_stmt);
location_t if_loc = gimple_location (cond_stmt);
@@ -1956,7 +1957,9 @@ collect_fallthrough_labels (gimple_stmt_iterator *gsi_p,
= gimple_call_internal_p (gsi_stmt (*gsi_p), IFN_FALLTHROUGH);
gsi_next (gsi_p);
tree goto_dest = gimple_goto_dest (gsi_stmt (*gsi_p));
- if (!fallthru_before_dest)
+ /* If FALSE_P, the then branch is dead, do not collect
+the label. */
+ if (!fallthru_before_dest && !false_p)
{
struct label_entry l = { goto_dest, if_loc };
labels->safe_push (l);
[Bug other/51732] typo in man gcc: "runt-time check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51732 --- Comment #3 from Martin Liška --- (In reply to Martin Guy from comment #2) > :D :D > > Reminds me of the first edition of a Gutenberg text for Shakespeare which, > due to an unfortunate OCR mismatch which also passed the spelling check, had > "He held the babe in his anus" for several years. (That should be "arms") :D funny things can happen!
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460
--- Comment #6 from Marek Polacek ---
But even that is not enough for
switch (i)
{
case 0:
goto X;
if (0) // nowarn
X:
nop ();
else
die ();
case 1:;
i++;
}
because we need to remember whether the then branch contained any labels.
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #3 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #2) > While I could reproduce this yesterday on x86_64-linux (but only with > bootstrapped gcc), I can't reproduce this anymore today. My tree includes > the PR80436 fix, but it doesn't seem that changed spot is ever encountered > while compiling the testcase. It was "fixed" by r246965, which doesn't make much sense.
[Bug debug/80461] [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 --- Comment #2 from Ian Lance Taylor --- It's hard to believe that GCC doesn't crash on that test case before 245039, too.
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Martin Liška --- Good, looks there's missing definition of the problematic struct. I've got it defined in "/usr/include/sys/ucontext.h" Maybe following patch can help you? diff --git a/libmpx/mpxrt/mpxrt.c b/libmpx/mpxrt/mpxrt.c index 76d11f71fd1..c9dad67f9df 100644 --- a/libmpx/mpxrt/mpxrt.c +++ b/libmpx/mpxrt/mpxrt.c @@ -49,6 +49,7 @@ #include #include #include +#include #include #include "mpxrt-utils.h" #include "mpxrt.h" Do you use glibc in your environment?
[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80401 --- Comment #7 from Bill Schmidt --- There was some dispute about whether it was fixed. Mike, can you still reproduce the problem?
[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80401 --- Comment #8 from seurer at gcc dot gnu.org --- I tried to reproduce natively on power using the same revision where Mike was seeing failures but I didn't see any problems. He was doing an x86->power cross compiler though.
[Bug c++/80456] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #2 from Marek Polacek --- With the volatile, cxx_eval_constant_expression sees *(volatile struct A *) this;, A::test(); and it's not able to evaluate 'this' in it. Without the volatile it only sees A::test() which it can evaluate. The COMPOUND_EXPR comes from build_new_method_call_1: 8827 /* In an expression of the form `a->f()' where `f' turns 8828 out to be a static member function, `a' is 8829 none-the-less evaluated. */ 8830 if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE 8831 && !is_dummy_object (instance) 8832 && TREE_SIDE_EFFECTS (instance)) 8833 call = build2 (COMPOUND_EXPR, TREE_TYPE (call), 8834instance, call);
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815 --- Comment #6 from vicencb at gmail dot com --- Yes, the host (and build) system uses glibc, target system uses musl. Thanks for the fix! Should I test it or you already did?
[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725 --- Comment #16 from Martin Sebor --- If there's no way to make profiledbootstrap work with in-tree GMP (or other prerequisites) then it would be most helpful to change the configure script to detect it and error out early with a descriptive message.
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #7 from Alexander Monakov ---
Adding the include directive wouldn't help: musl defines the corresponding
struct with a different tag, i.e. while glibc does
typedef struct _libc_fpstate *fpregset_t;
musl does:
typedef struct _fpstate {
/* matching fields */
} *fpregset_t;
On the one hand, it's possible to fix libmpx code to deduce the size of the
struct from the public typedef, but on the other hand, it's possible that that
is not the only platform-specific assumption in libmpx that will break on musl.
I think it's advisable to simply configure gcc with --without-libmpx when
targeting musl (unless you're specifically intending to test MPX on musl).
[Bug gcov-profile/78792] gfortran + gcov confused by #line directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78792 --- Comment #2 from Martin Liška --- I'm unable to feed Fortran FE with a pre-processed file: https://gcc.gnu.org/ml/fortran/2017-04/msg00072.html
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453
--- Comment #4 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #3)
>
> It was "fixed" by r246965, which doesn't make much sense.
On the other hand r246965 "causes" a new heisenbug on ppc64le:
% /home/trippels/gcc_test/usr/local/bin/g++ --save-temps -fcompare-debug -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -Wno-implicit-fallthrough -O3 -pipe
-UNDEBUG -fno-exceptions -fno-rtti -c BasicBlockUtils.ii -w
g++: warning: -pipe ignored because -save-temps specified
g++: error: BasicBlockUtils.ii: -fcompare-debug failure (length)
--- BasicBlockUtils.gkd 2017-04-19 14:19:18.678115265 +
+++ BasicBlockUtils.gk.gkd 2017-04-19 14:19:29.648375254 +
@@ -35537,7 +35537,7 @@
(insn:TI # 0 0 (set (reg:DI 5 5)
(const_int 1 [0x1])) "BasicBlockUtils.ii":61700# {*movdi_internal64}
(nil))
-(insn # 0 0 (set (reg/f:DI 31 31 [orig:174 _36 ] [174])
+(insn # 0 0 (set (reg/f:DI 31 31 [orig:177 _36 ] [177])
(reg:DI 3 3)) "BasicBlockUtils.ii":46281# {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 3 3)
(nil)))
@@ -35547,7 +35547,7 @@
(const_int 32 [0x20]))
(nil)))
(insn # 0 0 (set (reg:DI 4 4)
-(reg/f:DI 31 31 [orig:174 _36 ] [174])) "BasicBlockUtils.ii":61700#
{*movdi_internal64}
+(reg/f:DI 31 31 [orig:177 _36 ] [177])) "BasicBlockUtils.ii":61700#
{*movdi_internal64}
(nil))
(call_insn # 0 0 (parallel [
(call (mem:SI (symbol_ref/i:DI
("_ZN4llvm14TerminatorInst12SuccIteratorIPS0_NS_10BasicBlockEEC1ES2_b") [flags
0x3] ) [ __comp_ctor S4
A8])
@@ -35566,21 +35566,21 @@
(expr_list:DI (use (reg:DI 4 4))
(expr_list:QI (use (reg:DI 5 5))
(nil))
-(insn # 0 0 (set (reg/f:DI 9 9 [orig:602 SR.2614 ] [602])
+(insn # 0 0 (set (reg/f:DI 9 9 [orig:175 SR.2614 ] [175])
(mem/f/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20])) [ MEM[(struct SuccIterator *)&D.]+0
S8 A128])) "BasicBlockUtils.ii":61700# {*movdi_internal64}
(expr_list:REG_EQUIV (mem/f/c:DI (plus:DI (reg/f:DI 113 sfp)
(const_int 32 [0x20])) [ MEM[(struct SuccIterator *)&D.]+0
S8 A128])
(nil)))
-(insn:TI # 0 0 (set (reg/v:DI 26 26 [orig:387 SR.2615 ] [387])
+(insn:TI # 0 0 (set (reg/v:DI 26 26 [orig:173 SR.2615 ] [173])
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 1 1)
(const_int 40 [0x28])) [ MEM[(struct SuccIterator
*)&D. + 8B]+0 S4 A64]))) "BasicBlockUtils.ii":61700# {zero_extendsidi2}
(nil))
(insn # 0 0 (set (reg:CCUNS 75 7 [642])
-(compare:CCUNS (reg/f:DI 31 31 [orig:174 _36 ] [174])
-(reg/f:DI 9 9 [orig:602 SR.2614 ] [602])))
"BasicBlockUtils.ii":60645# {*cmpdi_unsigned}
- (expr_list:REG_DEAD (reg/f:DI 31 31 [orig:174 _36 ] [174])
-(expr_list:REG_DEAD (reg/f:DI 9 9 [orig:602 SR.2614 ] [602])
+(compare:CCUNS (reg/f:DI 9 9 [orig:175 SR.2614 ] [175])
+(reg/f:DI 31 31 [orig:177 _36 ] [177])))
"BasicBlockUtils.ii":60645# {*cmpdi_unsigned}
+ (expr_list:REG_DEAD (reg/f:DI 31 31 [orig:177 _36 ] [177])
+(expr_list:REG_DEAD (reg/f:DI 9 9 [orig:175 SR.2614 ] [175])
(nil
(jump_insn # 0 0 (set (pc)
(if_then_else (ne (reg:CCUNS 75 7 [642])
[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725 --- Comment #17 from Martin Liška --- (In reply to Martin Sebor from comment #16) > If there's no way to make profiledbootstrap work with in-tree GMP (or other > prerequisites) then it would be most helpful to change the configure script > to detect it and error out early with a descriptive message. Would be interesting to investigate why is the source file changed in between stages. Is it a generated source file?
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #5 from Markus Trippelsdorf --- Created attachment 41228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41228&action=edit another unreduced testcase
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815
--- Comment #8 from Alexander Monakov ---
Perhaps it's a good idea to adjust libmpx/configure.tgt to build libmpx only
for Glibc by default? I'm not sure if there's a particular reason that current
code accepts any suffix in the triple.
diff --git a/libmpx/configure.tgt b/libmpx/configure.tgt
index 5060b7e..f24373f 100644
--- a/libmpx/configure.tgt
+++ b/libmpx/configure.tgt
@@ -21,7 +21,7 @@
# Filter out unsupported systems.
LIBMPX_SUPPORTED=no
case "${target}" in
- x86_64-*-linux* | i?86-*-linux*)
+ x86_64-*-linux-gnu | i?86-*-linux-gnu)
LIBMPX_SUPPORTED=yes
;;
*)
[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66278 Martin Liška changed: What|Removed |Added CC||amker.cheng at gmail dot com Known to work||7.0.1 --- Comment #4 from Martin Liška --- Greating, starting from r238586 the test-case is vectorized. Bin should I create a test-case from this, or do you have a similar one. I'll then close the PR.
[Bug other/72815] libmpx on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815 Martin Liška changed: What|Removed |Added CC||aivchenk at gcc dot gnu.org, ||ienkovich at gcc dot gnu.org --- Comment #9 from Martin Liška --- (In reply to Alexander Monakov from comment #8) > Perhaps it's a good idea to adjust libmpx/configure.tgt to build libmpx only > for Glibc by default? I'm not sure if there's a particular reason that > current code accepts any suffix in the triple. > Me neither, adding MPX people to the PR.
[Bug target/80464] New: [7 regression] S/390: ICE failed to split vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80464
Bug ID: 80464
Summary: [7 regression] S/390: ICE failed to split vector move
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 41229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41229&action=edit
Reduced testcase
Compiling the attached testcase with:
gfortran -c -O3 t.f90 -march=z13
triggers:
t.f90:39:0:
end subroutine bla
Error: could not split insn
(insn 184 187 425 12 (set (reg:V2DF 2 %r2 [orig:331 MEM[(real(kind=8)
*)vectp.19_644] ] [331])
(mem:V2DF (plus:DI (plus:DI (reg:DI 3 %r3 [449])
(reg:DI 2 %r2 [327]))
(const_int -24 [0xffe8])) [1 MEM[(real(kind=8)
*)vectp.19_644]+0 S16 A64])) "t.f90":28 342 {movv2df}
(nil))
t.f90:39:0: internal compiler error: in final_scan_insn, at final.c:3025
0x1b11785 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/andreas/build/../gcc/gcc/rtl-error.c:108
0x16baa61 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/andreas/build/../gcc/gcc/final.c:3025
0x16b878f final(rtx_insn*, _IO_FILE*, int)
/home/andreas/build/../gcc/gcc/final.c:2051
0x16bdfab rest_of_handle_final
/home/andreas/build/../gcc/gcc/final.c:4489
0x16be351 execute
/home/andreas/build/../gcc/gcc/final.c:4562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/77770] [5/6/7 Regression] Internal compiler error on source which compiles with earlier versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #7 from Vladimir Makarov --- I can not reproduce it anymore on the test in comment #3. There were a few changes in LRA code (insn alternative) selection heuristics last 3 months. I guess they solved the problem.
[Bug target/80464] [7 regression] S/390: ICE failed to split vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80464 Andreas Krebbel changed: What|Removed |Added Target||s390x-ibm-linux Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-19 Host||s390x-ibm-linux Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org Ever confirmed|0 |1 Build||s390x-ibm-linux
[Bug target/80464] [7 regression] S/390: ICE failed to split vector move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80464 --- Comment #1 from Andreas Krebbel --- Created attachment 41230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41230&action=edit Experimental patch The problem was introduced with the arch12 patchset.
[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66278 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #5 from amker at gcc dot gnu.org --- (In reply to Martin Liška from comment #4) > Greating, starting from r238586 the test-case is vectorized. Bin should I > create a test-case from this, or do you have a similar one. I'll then close > the PR. Yes, please add a test for it. Thanks.
[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 Component|middle-end |fortran --- Comment #16 from Jeffrey A. Law --- So WRT c#4, that is not an equivalent testcase in C AFAICT. The reduced fortran testcase fails at -O2, the C testcase does not. The fact that the C testcase fails at -O1 is simply uninteresting. If we go back to the Fortran testcases I don't see anything that would allow us to determine statically that the problematical block can not be reached. Working with the reduced Fortran testcase we have this in the dumps: sizetype _1; integer(kind=4) _2; unsigned long _3; _1 = (sizetype) _yerrmsg_9(D); [ ... ] _2 = _yerrmsg_9(D) + 5; _3 = (unsigned long) _2; [ ... ] if (_1 > _3) goto ; [36.64%] else goto ; [63.36%] We're dealing with unsigned types here, so overflow has well defined semantics. Thus we can not statically determine the result of that conditional. This really is a Fortran problem AFAICT.
[Bug debug/80453] [7 Regression] another compare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80453 --- Comment #6 from Jakub Jelinek --- So, for the #c0 testcase with r246965 reverted on x86_64-linux, the ugly thing is that -fdump-tree-all makes the -fcompare-debug failure go away, but trying individual -fdump-tree-* usually works. The retslot dump is still pretty much the same except for added DEBUG stmts and some minor changes in decl uids (that is fine), but fre3 already in one function has different number of basic blocks and major changes like that. The first change in -fdump-tree-fre3-all when I ignore decl numbers, # DEBUG stmts and differences is: Value numbering iftmp.63_180 stmt = iftmp.63_180 = PHI -Setting value number of iftmp.63_180 to iftmp.63_169 (changed) +Setting value number of iftmp.63_180 to iftmp.63_73 (changed) Starting iteration 2 Value numbering iftmp.63_180 stmt = iftmp.63_180 = PHI -Setting value number of iftmp.63_180 to iftmp.63_169 +Setting value number of iftmp.63_180 to iftmp.63_73 Processing SCC needed 2 iterations Visiting control stmt ending BB 77: if (iftmp.63_73 == iftmp.63_180) -Visiting BB 78 -Recording temporarily iftmp.63_73 eq_expr iftmp.63_180 == false -Recording temporarily iftmp.63_73 ne_expr iftmp.63_180 == true +Applying pattern match.pd:2342, gimple-match.c:6143 +Marking all edges out of BB 77 but (77 -> 79) as not executable +Marking all outgoing edges of unreachable BB 78 as not executable Visiting BB 79
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Apr 19 16:29:45 2017 New Revision: 247000 URL: https://gcc.gnu.org/viewcvs?rev=247000&root=gcc&view=rev Log: PR debug/80436 * tree-ssa-loop-manip.c (find_uses_to_rename_def): Ignore debug uses. * g++.dg/opt/pr80436.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr80436.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-manip.c
[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Apr 19 16:31:11 2017 New Revision: 247001 URL: https://gcc.gnu.org/viewcvs?rev=247001&root=gcc&view=rev Log: PR c++/80459 * c-c++-common/opaque-vector.c (SIZEOF_MAXINT): Define. (f): Don't test long double vectors if __SIZEOF_LONG_DOUBLE__ is not power of 2, or is more than 16 or more than SIZEOF_MAXINT. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/opaque-vector.c
[Bug debug/80461] [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Apr 19 16:32:02 2017 New Revision: 247002 URL: https://gcc.gnu.org/viewcvs?rev=247002&root=gcc&view=rev Log: PR debug/80461 * dwarf2out.c (modified_type_die, gen_type_die_with_usage): Check for t with zero TYPE_QUALS_NO_ADDR_SPACE. * g++.dg/debug/pr80461.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/pr80461.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80459 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug debug/80461] [7 Regression] ICE in modified_type_die, at dwarf2out.c:12566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80461 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug middle-end/80423] [7 Regression] GC related -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80423 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #60 from Thomas Koenig --- r242780 works. With both r243586 and r244391, plus the patch for r245191 applied, I got numerous failures in the test suite. Apparently, something else was wrong for some time, which blocks the attempt at bisection for that particular error in that range.
[Bug c++/80460] Incorrect fallthrough warning after [[noreturn]] function inside always-true conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80460 --- Comment #7 from Thiago Macieira --- (In reply to Jakub Jelinek from comment #1) > The warning is done before optimizations (except GENERIC opts), and can > hardly be done much later. I imagined it would be the case. Treat this as low priority. I've added the [[fallthrough]] to the source code where this appeared to silence the warning. Arguably, the author should have used Q_UNREACHABLE() there too, not Q_ASSERT(!"message").
[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 --- Comment #6 from Jeffrey Walton --- (In reply to David Malcolm from comment #5) > Likewise, I tried but failed to reproduce it. > > A hunch: given the "-march=native", is there a chance that this bug is > dependent on the precise CPU flags on the host? Thanks David. Well, that's a good question. I was testing on a Skylake, which is 6th gen. It has AVX and AVX2, but it does not have AVX-512. Is there a way I can test it? Another possibility is Fedora 25 has an older version of the autocomplete library that's producing it.
