[Bug tree-optimization/78608] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78608 --- Comment #4 from Markus Trippelsdorf --- The patch fixes all issue that I came across. Please apply your patch. Thanks.
[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822 --- Comment #32 from Andreas Krebbel --- Author: krebbel Date: Fri Dec 2 08:26:19 2016 New Revision: 243159 URL: https://gcc.gnu.org/viewcvs?rev=243159&root=gcc&view=rev Log: PR target/77822: Add helper macro EXTRACT_ARGS_IN_RANGE to system.h. The macro can be used to validate the arguments of zero_extract and sign_extract to fix this problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822 gcc/ChangeLog: 2016-12-02 Dominik Vogt PR target/77822 * rtl.h (EXTRACT_ARGS_IN_RANGE): New. Modified: trunk/gcc/ChangeLog trunk/gcc/rtl.h
[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822
--- Comment #33 from Andreas Krebbel ---
Author: krebbel
Date: Fri Dec 2 08:30:16 2016
New Revision: 243160
URL: https://gcc.gnu.org/viewcvs?rev=243160&root=gcc&view=rev
Log:
PR target/77822: S390: Validate argument range of {zero,sign}_extract.
With some undefined code, combine generates patterns where the arguments to
*_extract are out of range, e.b. a negative bit position. If the s390 backend
accepts these, they lead to not just undefined behaviour but invalid assembly
instructions (argument out of the allowed range). So this patch makes sure
that the rtl expressions with out of range arguments are rejected.
gcc/ChangeLog:
2016-12-02 Dominik Vogt
PR target/77822
* config/s390/s390.md ("extzv")
("*extzv")
("*extzvdi_lshiftrt")
("*_ior_and_sr_ze")
("*extract1bitdi")
("*insv", "*insv_rnsbg_noshift")
("*insv_rnsbg_srl", "*insv_mem_reg")
("*insvdi_mem_reghigh", "*insvdi_reg_imm"): Use EXTRACT_ARGS_IN_RANGE
to validate the arguments of zero_extract and sign_extract.
gcc/testsuite/ChangeLog:
2016-12-02 Dominik Vogt
PR target/77822
* gcc.target/s390/s390.exp: Support .C tests.
* gcc.target/s390/pr77822-2.c: New test.
* gcc.target/s390/pr77822-1.C: New test.
Added:
trunk/gcc/testsuite/gcc.target/s390/pr77822-1.C
trunk/gcc/testsuite/gcc.target/s390/pr77822-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/s390/s390.exp
[Bug middle-end/78629] vec.h: null pointer passed as argument 1, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78629 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822 Andreas Krebbel changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Andreas Krebbel --- Fixed in the S/390 backend as well.
[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #35 from Andreas Krebbel --- Closing
[Bug ipa/78555] gcc/sreal.c:232:20: runtime error: left shift of negative value -2018967552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78555 --- Comment #8 from Martin Liška --- Author: marxin Date: Fri Dec 2 08:36:01 2016 New Revision: 243163 URL: https://gcc.gnu.org/viewcvs?rev=243163&root=gcc&view=rev Log: Fix runtime error: left shift of negative value (PR PR ipa/78555 * sreal.c (sreal::to_int): Make absolute value before shifting. (sreal::operator/): Likewise. (sreal_verify_negative_division): New test. (void sreal_c_tests): Call the new test. * sreal.h (sreal::normalize_up): Use new SREAL_ABS and SREAL_SIGN macros. (sreal::normalize_down): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/sreal.c trunk/gcc/sreal.h
[Bug target/78639] [7 Regression] Power9 bad code generation for cactusADM benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78639 Richard Biener changed: What|Removed |Added Target||powerpc64le-*-* Target Milestone|--- |7.0 Summary|Power9 bad code generation |[7 Regression] Power9 bad |for cactusADM benchmark |code generation for ||cactusADM benchmark
[Bug c++/78637] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78637 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78635 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.3
[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||i?86-*-* CC||bernds at gcc dot gnu.org Target Milestone|--- |7.0
[Bug ipa/78555] gcc/sreal.c:232:20: runtime error: left shift of negative value -2018967552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78555 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- Fixed.
[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.0 --- Comment #3 from Richard Biener --- Likely latent on release branches.
[Bug rtl-optimization/78575] [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78575 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Dec 2 08:42:12 2016 New Revision: 243164 URL: https://gcc.gnu.org/viewcvs?rev=243164&root=gcc&view=rev Log: PR rtl-optimization/78575 * config/i386/i386.c (timode_scalar_chain::fix_debug_reg_uses): Use DF infrastructure to wrap all V1TImode reg uses into TImode subreg if not already wrapped in a subreg. Make sure df_insn_rescan does not affect further iterations. * gcc.dg/pr78575.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78575.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.4 Keywords||ice-on-valid-code Last reconfirmed||2016-12-02 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 Summary|[OOP] ICE on polymorphic|[5/6/7 Regression] [OOP] |allocatable function in |ICE on polymorphic |array constructor |allocatable function in ||array constructor Known to fail||5.4.1, 6.2.0, 7.0 --- Comment #1 from janus at gcc dot gnu.org --- Version 4.9.4 swallows it without complaining, later versions give the ICE. The backtrace on trunk is: f951: internal compiler error: Segmentation fault 0xfd6d26 crash_signal /home/jweil/gcc/gcc7/trunk/gcc/toplev.c:333 0x7b2d75 gfc_add_component_ref(gfc_expr*, char const*) /home/jweil/gcc/gcc7/trunk/gcc/fortran/class.c:211 0x87d5dd resolve_ordinary_assign /home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10090 0x87f56d gfc_resolve_code(gfc_code*, gfc_namespace*) /home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10919 0x88c605 resolve_codes /home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16028 0x88c752 gfc_resolve(gfc_namespace*) /home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16063 0x85d10f resolve_all_program_units /home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:5977 0x85d92b gfc_parse_file() /home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6224 0x8b6bc3 gfc_be_parse_file /home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202
[Bug rtl-optimization/78547] [7 Regression] ICE: in loc_cmp, at var-tracking.c:3417 with -Os -g -mstringop-strategy=libcall -freorder-blocks-algorithm=simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78547 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Dec 2 08:44:42 2016 New Revision: 243165 URL: https://gcc.gnu.org/viewcvs?rev=243165&root=gcc&view=rev Log: PR rtl-optimization/78547 * emit-rtl.c (unshare_all_rtl): Make sure DECL_RTL and DECL_INCOMING_RTL is not shared. * config/i386/i386.c (convert_scalars_to_vectors): If any insns have been converted, adjust all parameter's DEC_RTL and DECL_INCOMING_RTL back from V1TImode to TImode if the parameters have TImode. * gcc.dg/pr78547.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78547.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/emit-rtl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 --- Comment #2 from janus at gcc dot gnu.org --- Possibly related to PR 58557.
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 --- Comment #3 from janus at gcc dot gnu.org --- Here is a slightly simpler version, replacing the function call with a variable reference, which fails with the same ICE with version 5, 6 and trunk: implicit none type foo end type type(foo) :: bar(1) class(foo), allocatable :: x allocate(x, source=foo()) bar = [x] end Version 4.9 again compiles fine, but I suspect that it generates wrong code.
[Bug rtl-optimization/78575] [7 Regression] ICE: in trunc_int_for_mode, at explow.c:55 with -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78575 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/78547] [7 Regression] ICE: in loc_cmp, at var-tracking.c:3417 with -Os -g -mstringop-strategy=libcall -freorder-blocks-algorithm=simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78547 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #6 from Georg-Johann Lay --- Fixed in v6.
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Georg-Johann Lay --- .
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641
--- Comment #4 from janus at gcc dot gnu.org ---
This patch seems to fix comment 3:
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 243035)
+++ gcc/fortran/class.c (working copy)
@@ -208,6 +208,19 @@ gfc_add_component_ref (gfc_expr *e, const char *na
gfc_component *c;
gfc_ref **tail = &(e->ref);
gfc_ref *ref, *next = NULL;
+
+ if (e->expr_type == EXPR_ARRAY)
+{
+ /* Handle array constructors. */
+ for (gfc_constructor *cons = gfc_constructor_first
(e->value.constructor);
+ cons; cons = gfc_constructor_next (cons))
+ {
+ if (cons->expr->ts.type == BT_CLASS)
+ gfc_add_component_ref (cons->expr, name);
+ }
+ return;
+}
+
gfc_symbol *derived = e->symtree->n.sym->ts.u.derived;
while (*tail != NULL)
{
but comment 0 still fails with a different ICE:
internal compiler error: in fold_convert_loc, at fold-const.c:2361
0xb57cb1 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/jweil/gcc/gcc7/trunk/gcc/fold-const.c:2361
0x887d13 gfc_trans_array_ctor_element
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:1447
0x88853e gfc_trans_array_constructor_value
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:1631
0x88a538 trans_array_constructor
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:2365
0x88af3a gfc_add_loop_ss_code
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:2639
0x892042 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-array.c:4890
0x8e63f2 gfc_trans_assignment_1
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-expr.c:9781
0x8e7448 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-expr.c:10124
0x8e74c0 gfc_trans_assign(gfc_code*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-expr.c:10136
0x882b1d trans_code
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:1790
0x8830fe gfc_trans_code(gfc_code*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:2097
0x8c127a gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6271
0x883142 gfc_generate_code(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:2114
0x811d07 translate_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6038
0x81237c gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6238
0x86b55d gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202
[Bug other/67373] Can't compile gcc snapshot for avr target with mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Georg-Johann Lay --- Closed, presumably an invalid combination of GCC / Binutils / AVR-LibC.
[Bug target/78642] New: [7 regression] ICE: invalid rtl sharing found in the insn on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78642 Bug ID: 78642 Summary: [7 regression] ICE: invalid rtl sharing found in the insn on sparc Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.12 Target: sparc-sun-solaris2.12 Build: sparc-sun-solaris2.12 Between 20161125 and 20161201, many testsuite regressions occured on SPARC, e.g. +FAIL: gcc.c-torture/compile/20030917-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) +FAIL: gcc.c-torture/compile/20030917-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) and many more. Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1: error: invalid rtl sharing found in the insn (insn 417 94 418 (clobber (reg/i:SI 8 %o0 [24])) "/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c":17 -1 (nil)) /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1: error: shared rtx (clobber (reg/i:SI 8 %o0 [24])) /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1: internal compiler error: internal consistency failure 0x64c72f verify_rtx_sharing /vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2743 0x64cedf verify_insn_sharing /vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2829 0x651f7b verify_rtl_sharing() /vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2852 0x8fabf7 execute_function_todo /vol/gcc/src/hg/trunk/local/gcc/passes.c:1982 0x8fbb37 do_per_function /vol/gcc/src/hg/trunk/local/gcc/passes.c:1649 0x8fbd5b execute_todo /vol/gcc/src/hg/trunk/local/gcc/passes.c:2015 Rainer
[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78642 Rainer Orth changed: What|Removed |Added Target Milestone|--- |7.0
[Bug fortran/78640] [F2015] gfortran accepts invalid allocatable polymorphic result in pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The constraint is C1287 in my draft. Confirmed from 4.9 up to trunk (7.0). Gfortran 4.8 gives the following error pr78640.f90:4.8: bar = f() 1 Error: Can't convert CLASS(foo) to TYPE(foo) at (1)
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 --- Comment #5 from Dominique d'Humieres --- The ICE appeared between revisions r216305 (2014-10-16, compiles) and r216470 (2014-10-20, ICE), likely r216427 (pr63553).
[Bug fortran/78641] [5/6/7 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > The ICE appeared between revisions r216305 (2014-10-16, compiles) and > r216470 (2014-10-20, ICE), likely r216427 (pr63553). Yes, that revision is certainly the culprit.
[Bug target/78643] New: ICE in convert_move, at expr.c:230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643
Bug ID: 78643
Summary: ICE in convert_move, at expr.c:230
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
Created attachment 40223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40223&action=edit
test case
seen on trunk, 6 and 5 branches on x86_64-linux-gnu, works with -O1 and up:
$ g++ -c -O0 main.cpp
main.cpp: In function 'void p(AV)':
main.cpp:80:6: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
void p(union AV a) {
^
main.cpp: In function 'void test(AV, int)':
main.cpp:101:29: internal compiler error: in convert_move, at expr.c:230
r.av = _mm256_shift_left(a.av,n);
~^~~~
0x898da0 convert_move(rtx_def*, rtx_def*, int)
../../src/gcc/expr.c:230
0x89f5cb store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../src/gcc/expr.c:5628
0x89fa3e expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5320
0x7b3dcd expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3641
0x7b3dcd expand_gimple_stmt
../../src/gcc/cfgexpand.c:3737
0x7b538f expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5744
0x7ba596 execute
../../src/gcc/cfgexpand.c:6358
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/78637] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in pop_namespace, at cp/name-lookup.c:3826)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78637 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| --- Comment #2 from Paolo Carlini --- Looking into it.
[Bug ipa/78644] New: [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Bug ID: 78644 Summary: [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-checking, ice-on-valid-code Severity: normal Priority: P3 Component: ipa 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 Build: x86_64-pc-linux-gnu Created attachment 40224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40224&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Og -fipa-cp testcase.c -Wno-psabi -wrapper valgrind,-q ==13237== Invalid read of size 2 ==13237==at 0x99A789: is_gimple_reg_type (gimple-expr.h:75) ==13237==by 0x99A789: is_gimple_val(tree_node*) (gimple-expr.c:781) ==13237==by 0xCE310B: verify_gimple_assign_binary (tree-cfg.c:3797) ==13237==by 0xCE310B: verify_gimple_assign (tree-cfg.c:4477) ==13237==by 0xCE310B: verify_gimple_stmt(gimple*) (tree-cfg.c:4731) ==13237==by 0xCF56E4: verify_gimple_in_cfg(function*, bool) (tree-cfg.c:5192) ==13237==by 0xB95092: execute_function_todo(function*, void*) (passes.c:1965) ==13237==by 0xB95A49: execute_todo(unsigned int) (passes.c:2015) ==13237==by 0xB9853D: execute_one_pass(opt_pass*) (passes.c:2410) ==13237==by 0xB98917: execute_pass_list_1(opt_pass*) (passes.c:2459) ==13237==by 0xB98929: execute_pass_list_1(opt_pass*) (passes.c:2460) ==13237==by 0xB98974: execute_pass_list(function*, opt_pass*) (passes.c:2470) ==13237==by 0x81AE63: cgraph_node::expand() (cgraphunit.c:2001) ==13237==by 0x81C747: expand_all_functions (cgraphunit.c:2137) ==13237==by 0x81C747: symbol_table::compile() (cgraphunit.c:2494) ==13237==by 0x81E995: symbol_table::finalize_compilation_unit() (cgraphunit.c:2584) ==13237== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==13237== testcase.c: In function 'bar.constprop': testcase.c:7:1: internal compiler error: Segmentation fault bar (u128 x2, u128 x3) ^~~ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> 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-243165-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.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 --disable-bootstrap --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-243165-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64 Thread model: posix gcc version 7.0.0 20161202 (experimental) (GCC) Some checking is probably needed in order to have verify_gimple_in_cfg() called.
[Bug c++/78645] New: ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, cxx_eval_call_expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78645
Bug ID: 78645
Summary: ICE on invalid C++ code on x86_64-linux-gnu
(Segmentation fault, cxx_eval_call_expression)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161202 (experimental) [trunk revision 243153] (GCC)
$
$ gcc-trunk small.C
small.C:4:29: error: invalid conversion from ‘bool (*)(int, Function) {aka bool
(*)(int, bool (*)(int))}’ to ‘Function {aka bool (*)(int)}’ [-fpermissive]
static_assert(check(2, check));
^
small.C:2:16: note: initializing argument 2 of ‘constexpr bool check(int,
Function)’
constexpr bool check(int x, Function p) { p(x); }
^
small.C:4:20: in constexpr expansion of ‘check(2, ((Function)check))’
small.C:2:44: in constexpr expansion of ‘p(x)’
small.C:4:31: internal compiler error: Segmentation fault
static_assert(check(2, check));
^
0xdf7cff crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x8d83eb hash_table, tree_node*>
>::hash_entry, xcallocator>::remove_elt_with_hash(tree_node* const&, unsigned
int)
../../gcc-source-trunk/gcc/hash-table.h:920
0x8cacf9 hash_map, tree_node*>
>::remove(tree_node* const&)
../../gcc-source-trunk/gcc/hash-map.h:174
0x8cacf9 cxx_eval_call_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1655
0x8cc073 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3847
0x8cbf4c cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:4218
0x8cc0b6 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3966
0x8cc0b6 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3966
0x8caba6 cxx_eval_call_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1619
0x8cc073 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3847
0x8d3469 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4481
0x8d6968 maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4685
0x8d6968 maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4709
0x83b925 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc-source-trunk/gcc/cp/semantics.c:8774
0x7b58a0 cp_parser_static_assert
../../gcc-source-trunk/gcc/cp/parser.c:13597
0x7c8dc9 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12587
0x7cf850 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12488
0x7cfc54 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12364
0x7cff98 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4368
0x7cff98 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:38262
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
typedef bool (*Function)(int);
constexpr bool check(int x, Function p) { p(x); }
static_assert(check(2, check));
$
[Bug tree-optimization/78646] New: incorrect result type for pointer addition in slsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
Bug ID: 78646
Summary: incorrect result type for pointer addition in slsr
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan at reservoir dot com
Target Milestone: ---
Created attachment 40225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40225&action=edit
output of -fdump-tree-slsr
In the program below, struct A is 64-bit aligned and struct B is 128-bit
aligned. An array of struct A in part of struct B.
When the array in B is accessed with a variable index, slsr computes the
pointer to the array element with the incorrect type 'struct B *' rather than
'struct A *'.
On my out-of-tree target, this results in incorrect code being generated; on
x86 I can only show the issue when looking at the debug output.
In the attached dump, the type of _8 and _14 is 'struct B *' but I would expect
them to have type 'struct A *'.
Here is the preprocessed program:
# 1 "bug.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "bug.cpp"
typedef int v4si __attribute__((vector_size(16)));
typedef int v2si __attribute__((vector_size(8)));
int __builtin_foo(int, int, int);
template struct A;
template <> struct alignas(v2si) A {
int _a;
int _b;
};
template T foo(T a, A &b, int) {
return __builtin_foo(a, b._a, b._b);
}
template T foo(A &a, T b, int c) {
return foo(b, a, c);
}
struct alignas(v4si) B {
struct {
A ara[16];
};
int bar(int, int);
};
int B::bar(int i, int a) {
return foo(ara[i], a, 1);
}
Compiled using:
g++ -v -save-temps -Wall -Wextra -std=gnu++14 -fdump-tree-slsr
-fdump-tree-optimized -O -S bug.ii
Using built-in specs.
COLLECT_GCC=g++
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=gnu++14'
'-fdump-tree-slsr' '-fdump-tree-optimized' '-O' '-S' '-shared-libgcc'
'-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-linux-gnu/5/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.ii -mtune=generic -march=i686 -auxbase bug -O -Wall -Wextra -std=gnu++14
-version -fdump-tree-slsr -fdump-tree-optimized -o bug.s
-fstack-protector-strong -Wformat-security
GNU C++14 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(i686-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(i686-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 427d6507e583781294a191f5962a1495
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/5/:/usr/lib/gcc/i686-linux-gnu/5/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/5/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/5/:/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/5/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=gnu++14'
'-fdump-tree-slsr' '-fdump-tree-optimized' '-O' '-S' '-shared-libgcc'
'-mtune=generic' '-march=i686'
Here is a possible solution for this problem (the assert is presumably
gratuitous):
diff --git a/gcc/gimple-ssa-strength-reduction.c
b/gcc/gimple-ssa-strength-reduction.c
---
[Bug c++/78647] New: ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:664)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78647
Bug ID: 78647
Summary: ICE on invalid C++ code on x86_64-linux-gnu (internal
compiler error: tree check: expected tree_list, have
error_mark in get_attribute_name, at attribs.c:664)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161202 (experimental) [trunk revision 243153] (GCC)
$
$ gcc-trunk small.C
small.C: In function ‘void f()’:
small.C:3:35: error: expected primary-expression before ‘)’ token
void f() { alignas(do_not_remove(A)); }
^
small.C:3:37: internal compiler error: tree check: expected tree_list, have
error_mark in get_attribute_name, at attribs.c:664
void f() { alignas(do_not_remove(A)); }
^
0x10a150c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9814
0x8e5445 tree_check
../../gcc-source-trunk/gcc/tree.h:3302
0x8e5445 get_attribute_name(tree_node const*)
../../gcc-source-trunk/gcc/attribs.c:664
0x10a3645 private_lookup_attribute(char const*, unsigned long, tree_node*)
../../gcc-source-trunk/gcc/tree.c:6100
0x914ab3 lookup_attribute
../../gcc-source-trunk/gcc/tree.h:4163
0x914ab3 attribute_fallthrough_p(tree_node*)
../../gcc-source-trunk/gcc/c-family/c-common.c:5561
0x7ca009 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10696
0x7cb22c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11019
0x7cb31f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10973
0x7c5e1f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21357
0x7c5e1f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21393
0x7c6701 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26151
0x7c7939 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26063
0x7c7939 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19109
0x7c7db9 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12764
0x7c8a21 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12591
0x7cf850 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12488
0x7cfc54 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12364
0x7cff98 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4368
0x7cff98 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:38262
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
struct A;
void do_not_remove();
void f() { alignas(do_not_remove(A)); }
$
[Bug c++/78645] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, cxx_eval_call_expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78645 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r224903: Implement N3928 - Extending static_assert.
[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646 Richard Biener changed: What|Removed |Added CC||wschmidt at linux dot vnet.ibm.com --- Comment #1 from Richard Biener --- - add_expr = fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (c->base_expr), + gcc_assert (POINTER_TYPE_P (c->cand_type)); + add_expr = fold_build2 (POINTER_PLUS_EXPR, + build_pointer_type (TREE_TYPE (c->cand_type)), c->base_expr, c->stride); if it is already a pointer type there's no need to build another one. Can't reproduce the ICE on the GCC 5 branch (on x86_64-linux, with -m32 or -m64).
[Bug c++/78645] [6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, cxx_eval_call_expression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78645 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.3
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 Known to work||5.4.1, 6.2.1 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/78328] wrong wording for unbounded alloc case in -Walloca-larger-than note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78328 --- Comment #2 from Aldy Hernandez --- Author: aldyh Date: Fri Dec 2 12:20:42 2016 New Revision: 243174 URL: https://gcc.gnu.org/viewcvs?rev=243174&root=gcc&view=rev Log: PR middle-end/78328 * gimple-ssa-warn-alloca.c (alloca_call_type): Handle VR_ANTI_RANGE. Added: trunk/gcc/testsuite/gcc.dg/Walloca-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-alloca.c
[Bug middle-end/78328] wrong wording for unbounded alloc case in -Walloca-larger-than note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78328 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Aldy Hernandez --- Fixed.
[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78642 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-12-02 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I cannot reproduce at r243172: eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/xgcc -Bgcc -S 20030917-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 20030917-1.c:9:1: warning: return type defaults to 'int' [-Wimplicit-int] blah(size,strp) ^~~~ eric@polaris:~/build/gcc/sparc-sun-solaris2.10>
[Bug rtl-optimization/78038] [5 Regression] internal compiler error: in get_sub_rtx, at ree.c:655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038 --- Comment #12 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Dec 2 12:22:54 2016 New Revision: 243175 URL: https://gcc.gnu.org/viewcvs?rev=243175&root=gcc&view=rev Log: [ree] PR rtl-optimization/78038: Handle global register dataflow definitions in ree 2016-12-02 Kyrylo Tkachov Backport from mainline 2016-10-21 Kyrylo Tkachov PR rtl-optimization/78038 * ree.c (get_defs): Return NULL if a defining insn for REG cannot be deduced to set REG through the RTL structure. (make_defs_and_copies_lists): Return false on a failing get_defs call. * gcc.target/aarch64/pr78038.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr78038.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ree.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/78648] New: ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78648
Bug ID: 78648
Summary: ICE on invalid C++ code on x86_64-linux-gnu
(Segmentation fault, contains_struct_check)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161202 (experimental) [trunk revision 243153] (GCC)
$
$ gcc-trunk small.C
small.C: In function ‘void bar()’:
small.C:4:14: error: invalid use of cv-qualified type ‘const void’ in parameter
declaration
e([](const void) {});
^~~~
small.C: In instantiation of ‘void e(F) [with F = bar() [with int =
1]::]’:
small.C:1:28: internal compiler error: Segmentation fault
template void e(F) {}
^
0xdf7cff crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0x8787d3 contains_struct_check
../../gcc-source-trunk/gcc/tree.h:3159
0x8787d3 write_closure_type_name
../../gcc-source-trunk/gcc/cp/mangle.c:1641
0x8787d3 write_unqualified_name
../../gcc-source-trunk/gcc/cp/mangle.c:1385
0x87e667 write_name
../../gcc-source-trunk/gcc/cp/mangle.c:939
0x87e528 write_local_name
../../gcc-source-trunk/gcc/cp/mangle.c:2027
0x87e528 write_name
../../gcc-source-trunk/gcc/cp/mangle.c:966
0x87f091 write_class_enum_type
../../gcc-source-trunk/gcc/cp/mangle.c:2769
0x87f091 write_type
../../gcc-source-trunk/gcc/cp/mangle.c:2187
0x87e0fc write_template_args
../../gcc-source-trunk/gcc/cp/mangle.c:2798
0x87e433 write_name
../../gcc-source-trunk/gcc/cp/mangle.c:935
0x883658 write_encoding
../../gcc-source-trunk/gcc/cp/mangle.c:823
0x88568c mangle_decl_string
../../gcc-source-trunk/gcc/cp/mangle.c:3743
0x8857d8 get_mangled_id
../../gcc-source-trunk/gcc/cp/mangle.c:3765
0x885a80 mangle_decl(tree_node*)
../../gcc-source-trunk/gcc/cp/mangle.c:3835
0x10a2490 decl_assembler_name(tree_node*)
../../gcc-source-trunk/gcc/tree.c:671
0x9f1231 symtab_node::get_comdat_group_id()
../../gcc-source-trunk/gcc/cgraph.h:210
0x9f1231 analyze_functions
../../gcc-source-trunk/gcc/cgraphunit.c:1037
0x9f29f8 symbol_table::finalize_compilation_unit()
../../gcc-source-trunk/gcc/cgraphunit.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
template void e(F) {}
template void bar() {
e([](const void) {});
}
void baz() { bar<1>; }
$
[Bug rtl-optimization/78038] [5 Regression] internal compiler error: in get_sub_rtx, at ree.c:655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from ktkachov at gcc dot gnu.org --- Fixed on all active branches
[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631
--- Comment #2 from Dmitrii Kuvaiskii ---
(In reply to Ilya Enkovich from comment #1)
> PLT section is generated by linker. To have MPX friendly PLT you have to
> have MPX enabled linker supporting '-z bndplt' flag and GCC should be
> configured using MPX enabled toolchain to pass this linker option it by
> default.
> Situation you describe might happen when you use old bfd or any version of
> gold.
I'm not sure I understand the answer.
If I understand right, you mean that I need to build my shared libraries using
a friendly linker which supports '-z bndplt'. This I understand, but I do not
build a shared library. My problem is that I am using the 'libmpxwrappers'
library (already built together with gcc) which I believe contains a bug
because it was built incorrectly.
Here is the test case which reproduces the problem:
#include
#include
char s[10];
char d[10];
__attribute__((noinline))
char* foo(char* dst, char* src, size_t size) {
return memcpy(dst, src, size);
}
int main() {
char* r = foo(d, s, 11); // out-of-bounds!
printf("r = %p\n", r);
return 0;
}
Here is how I run it:
> gcc -fcheck-pointer-bounds -mmpx test.c
> CHKP_RT_BNDPRESERVE=0 ./a.out
r = 0x600bd8
> CHKP_RT_BNDPRESERVE=1 ./a.out
Saw a #BR! status 1 at 0x7f17bdb84189
Saw a #BR! status 1 at 0x7f17bdb84192
r = 0x600bd8
So the obvious buffer overflow in memcpy() is detected only when I set
BNDPRESERVE=1. Debugging this with gdb, I see:
Program received signal SIGSEGV, Segmentation fault.
=> 0x779cf189 <__mpx_wrapper_memmove+89>: bndcu bnd0,[r15]
So the upper-bound check detected the overflow as expected.
Can you reproduce the same behavior on your machine?
(My GCC is 6.1.0, ld is bfd version 2.26.1, I see that GCC passes '-z bndplt'
to the linker and linker eats it without problems.)
[Bug c++/78649] New: ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor, at cp/init.c:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78649
Bug ID: 78649
Summary: ICE on invalid C++ code on x86_64-linux-gnu (internal
compiler error: tree check: expected class ‘type’,
have ‘exceptional’ (error_mark) in
build_value_init_noctor, at cp/init.c:380)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161202 (experimental) [trunk revision 243153] (GCC)
$
$ gcc-trunk small.C
small.C: In instantiation of ‘void test() [with T = void; Args = {}]’:
small.C:4:24: required from here
small.C:2:51: error: variable or field ‘t’ declared void
template void test() { T t(create...); }
^
small.C:2:51: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in build_value_init_noctor, at cp/init.c:380
0x10a1c87 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9865
0x80db2b tree_class_check
../../gcc-source-trunk/gcc/tree.h:3169
0x80db2b build_value_init_noctor(tree_node*, int)
../../gcc-source-trunk/gcc/cp/init.c:380
0x80dbbd build_value_init(tree_node*, int)
../../gcc-source-trunk/gcc/cp/init.c:369
0x5e31a2 tsubst_init
../../gcc-source-trunk/gcc/cp/pt.c:14095
0x6fb2aa tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15500
0x6f79f3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15618
0x6f50ce instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22536
0x7373f2 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22655
0x77e8b1 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4512
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
template void create();
template void test() { T t(create...); }
int main() { test; }
$
[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78642 --- Comment #2 from Jakub Jelinek --- Can't reproduce in a cross-compiler, I also see (clobber (reg/i:SI 8 %o0 [24])) just once in the IL. That said, rtl sharing verification has been mistakenly not performed even with --enable-checking=rtl during the last 3 years and got reenabled only in r243019.
[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78649 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 CC||jakub at gcc dot gnu.org Summary|ICE on invalid C++ code on |[5/6/7 Regression] ICE on |x86_64-linux-gnu (internal |invalid C++ code on |compiler error: tree check: |x86_64-linux-gnu (internal |expected class ‘type’, have |compiler error: tree check: |‘exceptional’ (error_mark) |expected class ‘type’, have |in build_value_init_noctor, |‘exceptional’ (error_mark) |at cp/init.c:380) |in build_value_init_noctor, ||at cp/init.c:380) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE with either r175765 or r175764, r175761 accepts it.
[Bug target/78650] New: ira-costs.c:1716:53: runtime error: member access within null pointer of type 'struct cost_classes'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78650
Bug ID: 78650
Summary: ira-costs.c:1716:53: runtime error: member access
within null pointer of type 'struct cost_classes'
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
On ppc64le I get:
% cat test.i
void foo() {}
% /home/trippels/gcc_ubsan_clang/usr/local/bin/gcc -c -O3 test.i
../../gcc/gcc/ira-costs.c:1716:53: runtime error: member access within null
pointer of type 'struct cost_classes'
(gdb) b __ubsan::Diag::~Diag
Breakpoint 1 at 0x101f7f38: file
/home/trippels/llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc, line 335.
(gdb) run
...
(gdb) up
#1 0x101fbb34 in handleTypeMismatchImpl (Data=,
Pointer=0, Opts=...) at
/home/trippels/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:71
71 Diag(Loc, DL_Error, "%0 null pointer of type %1")
(gdb) up
#2 0x1133727c in find_costs_and_classes (dump_file=) at
../../gcc/gcc/ira-costs.c:1716
1716 enum reg_class *cost_classes = cost_classes_ptr->classes;
(gdb) l
1711 int rclass, a_num, parent_a_num, add_cost;
1712 ira_loop_tree_node_t parent;
1713 int best_cost, allocno_cost;
1714 enum reg_class best, alt_class;
1715 cost_classes_t cost_classes_ptr = regno_cost_classes[i];
1716 enum reg_class *cost_classes = cost_classes_ptr->classes;
1717 int *i_costs = temp_costs->cost;
1718 int i_mem_cost;
1719 int equiv_savings = regno_equiv_gains[i];
1720
(gdb) p i
$1 = 154
(gdb) p max_reg_num () - 1
$2 = 154
(gdb) p regno_cost_classes[154]
$3 = (cost_classes *) 0x0
[Bug c++/78651] New: Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651
Bug ID: 78651
Summary: Incorrect exception handling when catch clause uses
local class and PIC and sanitizer are active
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dyp-cpp at gmx dot net
Target Milestone: ---
Consider the following program:
#include
#ifndef EXCEPTION_TYPE
# define EXCEPTION_TYPE LocalException
#endif
#define STRINGIFY(X) STRINGIFY2(X)
#define STRINGIFY2(X) #X
struct Exception {};
int main()
{
struct LocalException {};
try
{
std::cout << "throwing int\n";
throw 42;
}catch(EXCEPTION_TYPE const& d)
{
std::cout << "caught " STRINGIFY(EXCEPTION_TYPE) "\n";
}catch(...)
{
std::cout << "caught ...\n";
}
}
Compile with -fPIC -fsanitize=address on x86-64, then the first catch clause
(EXCEPTION_TYPE const&) is executed. If you drop either option (fPIC or
fsanitize), then the second catch clause is executed. I ran into this issue on
g++4.8.5, but the behaviour is still the same with the current master branch.
By setting -DEXCEPTION_TYPE=Exception, the first catch clause uses a non-local
class and is never executed, even with -fPIC and -fsanitize.
Problem does not occur on clang++.
[Bug target/78650] ira-costs.c:1716:53: runtime error: member access within null pointer of type 'struct cost_classes'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78650 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- Sorry, looks like a bug in the LLVM instrumentation. I cannot reproduce this with bootstrapped gcc.
[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #1 from dyp-cpp at gmx dot net --- Same issue if the LocalException is a non-local class with internal linkage.
[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78649 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |5.5
[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78649 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Priority|P3 |P4
[Bug rtl-optimization/78652] New: LRA generates wrong code by inheriting changed register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78652
Bug ID: 78652
Summary: LRA generates wrong code by inheriting changed
register
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Hi, given below sample code:
extern int printf(const char *, ...);
short a, b = 1, p, t;
struct {
signed f1 : 9;
} m = {3};
int c, g = 0, h = 8, i, k, l, q, r, s, w, x = 9;
long long d = 1;
long long e = 1;
char f[9][6][4] = {{{1}}};
short j[6] = {1};
unsigned n;
static long long *o = &e;
char u;
short *v;
char *y = &f[6][4][3];
short fn1(short p1) { return a == 0 ? p1 : p1 % a; }
static int *fn2(signed char p1, int p2, signed char p3) {
lbl_2057:
if (n >= (q >= fn1(3)))
return &r;
if (p2)
t = u;
*v = (t | *o) * p2;
for (;;) {
for (; u <= 1;)
goto lbl_2057;
if (p1)
s = g = 0;
}
}
void fn3(int *p1) {
if (*p1)
;
else {
x = w;
for (;;)
;
}
}
int *fn4(long p1) {
for (; p1; p1--)
e = 1;
y = 0;
return &h;
}
__attribute__((section(".text")))
int main() {
int *z;
long t1;
long long *t2 = &d;
*t2 = b;
z = fn4(*t2);
fn3(z);
short *t3 = &j[0];
*t3 = f[6][4][3] >= (b = i);
t1 = p < n;
fn2(c < t1 >= m.f1, l, k);
j[5]++;
printf("result = %X\n", m.f1);
}
Compiled/run with below command line on arm-none-eabi:
$ arm-none-eabi-gcc -march=armv7-a -fno-strict-aliasing test.c -o test.exe
-specs=aprofile-validation.specs -O2
$ ./test.exe
result = 1
Which should be:
result = 3
This doesn't happen with O1.
[Bug rtl-optimization/78652] LRA generates wrong code by inheriting changed register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78652
--- Comment #1 from amker at gcc dot gnu.org ---
GCC is configured as below:
--target=arm-none-eabi --prefix=... --with-gmp=... --with-mpfr=...
--with-mpc=... --with-isl=... --disable-shared --disable-nls --disable-threads
--disable-tls --enable-checking=yes --enable-languages=c,c++,fortran
--with-newlib
Piece of generated assmebly is as:
ldr r5, .L44<--init r5
ldrsh r0, [r0]
movtr3, #:upper16:l
movcs r1, #0
movcc r1, #1
cmp lr, r1
ldrhip, [r5, #12]! <--modify r5
ldr r3, [r3]
movwfp, #:lower16:v
movge r1, #0
movlt r1, #1
str r1, [sp, #8]
movtfp, #:upper16:v
ldrbr1, [r4, #203]
movwr2, #:lower16:a
movwr9, #:lower16:u
movwr8, #:lower16:t
cmp r1, r0
movwr7, #:lower16:.LANCHOR1
movwr6, #:lower16:s
movtr2, #:upper16:a
movlt r1, #0
movge r1, #1
movtr9, #:upper16:u
strhr1, [r5]<--inherit use of changed r5.
It's clear LRA inherits register with changed value for r5. Looking at below
dump of IRA:
51: r262:SI=const(`*.LANCHOR0'+0x100) <--init r262
REG_EQUIV const(`*.LANCHOR0'+0x100)
277: r186:SI=high(`p')
REG_EQUAL high(`p')
279: r258:SI=high(`n')
REG_EQUAL high(`n')
278: r186:SI=r186:SI+low(`p')
REG_EQUAL `p'
280: r258:SI=r258:SI+low(`n')
REG_EQUAL `n'
275: r185:SI=high(`c')
REG_EQUAL high(`c')
276: r185:SI=r185:SI+low(`c')
REG_EQUAL `c'
58: r187:SI=sign_extend([r186:SI])
REG_DEAD r186:SI
REG_EQUAL sign_extend([`p'])
60: r190:SI=[r258:SI]
REG_EQUIV [r258:SI]
REG_EQUAL [`n']
273: r176:SI=high(`i')
REG_EQUAL high(`i')
254: r263:SI=r262:SI <--init r263 with r262
274: r176:SI=r176:SI+low(`i')
REG_EQUAL `i'
281: r203:SI=high(`l')
REG_EQUAL high(`l')
282: r203:SI=r203:SI+low(`l')
REG_EQUAL `l'
63: r193:SI=[r185:SI]
REG_DEAD r185:SI
REG_EQUAL [`c']
62: {r191:SI=ltu(r187:SI,r190:SI);clobber cc:CC;}
REG_DEAD r190:SI
REG_DEAD r187:SI
REG_UNUSED cc:CC
71: r201:SI=zero_extend([pre r263:SI+=0xc]) <--r263 is modified
REG_INC r263:SI
REG_EQUAL zero_extend([const(`*.LANCHOR0'+0x10c)])
283: r266:SI=high(`a')
REG_EQUAL high(`a')
45: r116:SI=sign_extend([r176:SI])
REG_DEAD r176:SI
65: {r126:SI=r193:SI=r116:SI;clobber cc:CC;}
REG_DEAD r116:SI
REG_DEAD r114:SI
REG_UNUSED cc:CC
55: [r262:SI]=r184:SI#0 <---use of r262
It results in assigning the same hard register (r5) to both r263 and r262.
[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646 --- Comment #2 from Stefan M Freudenberger --- It's not an ICE on x86, but the dump shows the incorrect pointer type. Can I assert that the cand_type is a pointer and not a reference?
[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug c++/78649] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_value_init_noctor,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78649 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40226&action=edit gcc7-pr78649.patch Untested fix.
[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78635 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/78648] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78648 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |5.5 Summary|ICE on invalid C++ code on |[5/6/7 Regression] ICE on |x86_64-linux-gnu|invalid C++ code on |(Segmentation fault,|x86_64-linux-gnu |contains_struct_check) |(Segmentation fault, ||contains_struct_check) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Also started to ICE with either r175765 or r175764, r175761 doesn't ICE.
[Bug c++/78648] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (Segmentation fault, contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78648 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4
[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646 --- Comment #3 from Andrew Pinski --- A reference type is treated as a pointer type all the way through the middle end of gcc. Why is there an issue with that for your target?
[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561 --- Comment #2 from James Greenhalgh --- Author: jgreenhalgh Date: Fri Dec 2 14:29:35 2016 New Revision: 243182 URL: https://gcc.gnu.org/viewcvs?rev=243182&root=gcc&view=rev Log: [Patch 1/2 PR78561] Rename get_pool_size to get_pool_size_upper_bound gcc/ PR rtl-optimization/78561 * config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p) Rename get_pool_size to get_pool_size_upper_bound. (rs6000_stack_info): Likewise. (rs6000_emit_prologue): Likewise. (rs6000_elf_declare_function_name): Likewise. (rs6000_set_up_by_prologue): Likewise. (rs6000_can_eliminate): Likewise, reformat spaces to tabs. * output.h (get_pool_size): Rename to... (get_pool_size_upper_bound): ...This. * varasm.c (get_pool_size): Rename to... (get_pool_size_upper_bound): ...This. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/output.h trunk/gcc/varasm.c
[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561 --- Comment #3 from James Greenhalgh --- Author: jgreenhalgh Date: Fri Dec 2 14:31:10 2016 New Revision: 243183 URL: https://gcc.gnu.org/viewcvs?rev=243183&root=gcc&view=rev Log: [Patch 2/2 PR78561] Recalculate constant pool size before emitting it gcc/ PR rtl-optimization/78561 * varasm.c (recompute_pool_offsets): New. (output_constant_pool): Call it. gcc/testsuite/ PR rtl-optimization/78561 * gcc.target/aarch64/pr78561.c: New. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug c++/67054] Constructor inheritance with non-default constructible members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67054 --- Comment #2 from Martin Hierholzer --- I stumbled across this bug, too (and asked about it on stackoverflow, since I wasn't sure if it's valid C++11, see http://stackoverflow.com/questions/40932844/constructor-inheritance-and-direct-member-initialisation). This problem is still there in gcc 6.2.0. The code compiles, if one adds a default constructor to NonDefault, despite that default constructor never gets called in the end. (This can be used as a work-around).
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 Ville Voutilainen changed: What|Removed |Added Version|7.0 |unknown --- Comment #5 from Ville Voutilainen --- Jonathan and I looked at this, and a proper fix requires teaching the functions in bits/stl_tree.h new tricks. That's not stage3 material, so let's punt this to 8.
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > This prints "conv" twice, because we create a temporary to get the key here: > > pair<_Base_ptr, _Base_ptr> __res > = _M_get_insert_unique_pos(_KeyOfValue()(__v)); This is extra-broken, because the temporary that gets implicitly created could fail for at least these reasons: - the relevant constructor of value_type is explicit - there is no relevant constructor, because it expects an allocator (we would need to use the _Temporary_value helper type from there) Even if the implicit conversion works, the key of that temporary might not be the same as the key that would result from constructing the value_type with an allocator. Here be dragons. With guns. And they're angry.
[Bug other/78653] New: badly optimized kernel code with -fsanitize=object-size -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78653
Bug ID: 78653
Summary: badly optimized kernel code with
-fsanitize=object-size -fsanitize=null
Product: gcc
Version: 7.0
URL: https://bugs.linaro.org/show_bug.cgi?id=2354
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
As described in the original bug report
(https://bugs.linaro.org/show_bug.cgi?id=2354)
parts of the Linux kernel fail to build after enabling UBSAN.
With the sample attached testcase, a simple function gets expanded to a very
complex expression. The original source for the function is
static void zl10353_calc_nominal_rate(struct dvb_frontend *fe,
u32 bandwidth,
u16 *nominal_rate)
{
struct zl10353_state *state = fe->demodulator_priv;
u32 adc_clock = 450560; /* 45.056 MHz */
u64 value;
u8 bw = bandwidth / 100;
if (state->config.adc_clock)
adc_clock = state->config.adc_clock;
value = (u64)10 * (1 << 23) / 7 * 125;
value = (bw * value) + adc_clock / 2;
do_div(value, adc_clock);
*nominal_rate = value;
dprintk("%s: bw %d, adc_clock %d => 0x%x\n",
__func__, bw, adc_clock, *nominal_rate);
}
The key here appears to be the setting of adc_clock, which the compiler knows
is not zero, but it doesn't know the actual value of.
The do_div() macro in turn is a complex way of turning a constant 64-bit
division into a multiplication, for reference the non-preprocessed version is
at
http://lxr.free-electrons.com/source/include/asm-generic/div64.h?v=4.6
The __builtin_constant_p() here should guard code that only makes sense for a
constant input:
208 if (__builtin_constant_p(__base) && \
209 is_power_of_2(__base)) {\
210 __rem = (n) & (__base - 1); \
211 (n) >>= ilog2(__base); \
however, the ilog2_NaN symbol is referenced here:
#define ilog2(n)\
( \
__builtin_constant_p(n) ? ( \
(n) < 1 ? ilog2_NaN() : \
(n) & (1ULL << 63) ? 63 : \
(n) & (1ULL << 62) ? 62 : \
(n) & (1ULL << 61) ? 61 : \
(n) & (1ULL << 60) ? 60 : \
...
(n) & (1ULL << 1) ? 1 : \
(n) & (1ULL << 0) ? 0 : \
ilog2_NaN() \
) : \
(sizeof(n) <= 4) ? \
__ilog2_u32(n) :\
__ilog2_u64(n) \
)
after 'n' has been determined to be constant yet not known whether
it is less than '1', which mathematically makes no sense.
[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78653 --- Comment #1 from Christophe Lyon --- Created attachment 40227 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40227&action=edit preprocessed source from linux/drivers/media/dvb-frontends/zl10353.i
[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78653 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-02 Ever confirmed|0 |1 --- Comment #2 from Christophe Lyon --- To reproduce, use: arm-linux-gnueabi-gcc -Wno-pointer-sign -O2 -fsanitize=object-size -fsanitize=null -c -o zl10353.o zl10353.i nm zl10353.o | grep ilog2_NaN Compiling without -fsanitize=object-size -fsanitize=null removes the reference to ilog2_NaN Reproduced with today's trunk, but originally reported against 5.3.1
[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78653 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- See: PR72785
[Bug other/78654] New: ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 Bug ID: 78654 Summary: ubsan can lead to excessive stack usage Product: gcc Version: 7.0 URL: https://bugs.linaro.org/show_bug.cgi?id=2350 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- [Forwarding Arnd's bug report from https://bugs.linaro.org/show_bug.cgi?id=2350] When building the kernel with all sanitizers enabled, some functions have a much larger stack frame than expected. In some cases we just barely cross the 1024 byte stack size limit for functions that were already using a lot, but one file sticks out from using almost twice as much as before. Using today's trunk $ arm-none-linux-gnueabi-gcc -O2 -Wno-pointer-sign -Wframe-larger-than=100 - c serpent_generic.i frame size 528 $ arm-none-linux-gnueabi-gcc -O2 -Wno-pointer-sign -Wframe-larger-than=1024 -c serpent_generic.i -fsanitize=shift -fsanitize=integer-divide-by-zero -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null -fsanitize=signed-integer-overflow -fsanitize=bounds -fsanitize=object-size -fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum -fsanitize=alignment frame size 1072 $ arm-none-linux-gnueabi-gcc -Wall -Wframe-larger-than=100 -Wno-pointer-sign -Os -c mb86a16.i frame size 416 $ arm-none-linux-gnueabi-gcc -Wall -Wframe-larger-than=100 -Wno-pointer-sign -Os -c mb86a16.i -fsanitize=signed-integer-overflow frame size 448
[Bug other/78654] ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 --- Comment #1 from Christophe Lyon --- Created attachment 40228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40228&action=edit preprocessed source from linux/crypto/serpent_generic.c
[Bug other/78654] ubsan can lead to excessive stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654 --- Comment #2 from Christophe Lyon --- Created attachment 40229 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40229&action=edit preprocessed source from linux/drivers/media/dvb-frontends/mb86a16.c
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595
--- Comment #7 from Jonathan Wakely ---
Pure evil:
#include
#include
struct Key { int key; };
struct X {
operator std::pair() const { return { { x }, 0 }; }
int x;
};
template
struct Alloc
{
Alloc() = default;
template
Alloc(const Alloc&) { }
using value_type = T;
T* allocate(std::size_t n) { return std::allocator().allocate(n); }
void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n);
}
template
void construct(U* p, const X&) { ::new (p) U{ { 99 }, 0}; }
template
bool operator==(const Alloc&) { return true; }
template
bool operator!=(const Alloc&) { return false; }
};
bool operator<(const Key& l, const Key& r) { return l.key < r.key; }
int main()
{
using namespace std;
map, Alloc>> m;
m.insert(X{});
m.insert(X{}); // RB tree is corrupted
if (m.size() != 1)
__builtin_puts("RB tree corrupt");
map, Alloc>> m2;
m.insert(X{});
m.insert(X{99});
if (m.size() != 2)
__builtin_puts("RB tree failed to insert distinct value");
}
[Bug c++/78655] New: gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
Bug ID: 78655
Summary: gcc doesn't exploit the fact that the result of
pointer addition can not be nullptr
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider the following piece of code:
#include
struct blob
{
void* data;
size_t size;
};
void uninitialized_copy(blob* first, blob* last, blob* current)
{
for (; first != last; ++first, (void) ++current) {
::new (static_cast(current)) blob(*first);
}
}
The nested loop generated for it by GCC 7 is the following:
.L4:
testq %rdx, %rdx
je .L3
movdqu (%rdi), %xmm0
movups %xmm0, (%rdx)
.L3:
addq$16, %rdi
addq$16, %rdx
cmpq%rdi, %rsi
jne .L4
As you can see after each iteration generated code checks if current is nullptr
and omit calling the copy constructor if it is so.
Clang 3.9 doesn't exhibit such behavior. It translates the loop into:
.LBB0_1:# =>This Inner Loop Header: Depth=1
movups (%rdi), %xmm0
movups %xmm0, (%rdx)
addq$16, %rdi
addq$16, %rdx
cmpq%rdi, %rsi
jne .LBB0_1
This optimization is valid, because if addition of pointer and integer results
in nullptr, the integer was clearly out of bound of allocated memory block thus
the addition causes undefined behavior.
Absence of this optimization affects std::uninitialized_copy and any functions
that use it (for example std::vector::push_back).
The issue can be reproduced with a simpler piece of code:
bool g(int* a)
{
return (a + 10) != nullptr;
}
GCC 7:
g(int*):
cmpq$-40, %rdi
setne %al
ret
Clang 3.9:
g(int*): # @g(int*)
movb$1, %al
retq
P.S. Another issue is that GCC used mismatched instructions to read from/to
memory. movdqu -- is for integer data, movups -- is for single precision
floating point. I don't know if it causes any stalls on modern CPUs, I heard
that on older CPU writing register with an instruction of one type and reading
with an instruction of another might causes stalls. Should I report a separate
bug report issue for this?
[Bug libstdc++/78595] Unnecessary copies in _Rb_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78595
--- Comment #8 from Jonathan Wakely ---
Oops, the second condition *should* fail in that last example, but here it
shouldn't:
#include
#include
#include
struct Key { int key; };
struct X {
operator std::pair() const { return { { x }, 0 }; }
int x;
};
template
struct Alloc
{
Alloc() = default;
template
Alloc(const Alloc&) { }
using value_type = T;
T* allocate(std::size_t n) { return std::allocator().allocate(n); }
void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p, n);
}
template
void construct(U* p, const X& x) { ::new (p) U{ { x.x+1 }, 0}; }
template
bool operator==(const Alloc&) { return true; }
template
bool operator!=(const Alloc&) { return false; }
};
bool operator<(const Key& l, const Key& r) { return l.key < r.key; }
int main()
{
using namespace std;
map, Alloc>> m;
m.insert(X{});
m.insert(X{}); // RB tree is corrupted
if (m.size() != 1)
puts("RB tree corrupt");
map, Alloc>> m2;
m.insert(X{});
m.insert(X{1});
if (m.size() != 2)
puts("RB tree failed to insert distinct value");
}
[Bug libstdc++/78058] Complex initialization of nested std::optional does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78058 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- This is fixed by r242401
[Bug libstdc++/78058] Complex initialization of nested std::optional does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78058 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ville Voutilainen --- Fixed by r242401
[Bug target/78614] [7 Regression] ICE error: invalid rtl sharing found in the insn (verify_rtx_sharing) gcc/emit-rtl.c:2743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78614 --- Comment #24 from Jakub Jelinek --- Author: jakub Date: Fri Dec 2 15:42:04 2016 New Revision: 243194 URL: https://gcc.gnu.org/viewcvs?rev=243194&root=gcc&view=rev Log: PR target/78614 * rtl.c (copy_rtx): Don't clear used flag here. (shallow_copy_rtx_stat): Clear used flag here unless code the rtx is shareable. * simplify-rtx.c (simplify_replace_fn_rtx): When copying rtx with 'E' in format, copy all vectors. * emit-rtl.c (copy_insn_1): Don't clear used flag here. * valtrack.c (cleanup_auto_inc_dec): Likewise. * config/rs6000/rs6000.c (rs6000_frame_related): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/emit-rtl.c trunk/gcc/rtl.c trunk/gcc/valtrack.c
[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from vehre at gcc dot gnu.org --- Waiting for review. Patch available at: https://gcc.gnu.org/ml/fortran/2016-12/msg00012.html
[Bug c++/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #22 from Mark Wielaard --- Created attachment 40230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40230&action=edit d_printing mark/walk/unmark protection (In reply to Nathan Sidwell from comment #21) > Why doesn't a mark/walk/unmark idiom when walking a potentially circular > data structure work here? I.e. add a mutable counter to demangle_component. > Inc/dec at start/end of d_print_comp? IIUC if it gets to >1 there's a > problem. That is a good idea. However it seems things aren't as simple as that. The attached patch implements it, but that produces various testsuite failures: ./test-demangle: 960 tests, 7 failures It might of course be that I messed up the check or that any of these failures really are bad.
[Bug c++/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #23 from Mark Wielaard --- Created attachment 40231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40231&action=edit Check output with d_printing.patch
[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78599 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #7 from Martin Jambor --- I cannot reproduce this using the testcase from comment #1 even whe I add -fsanitize=undefined to the command line. Is this on x86_64?
[Bug c++/78656] New: Fix-it suggestion for std::alocator doesn't include std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78656
Bug ID: 78656
Summary: Fix-it suggestion for std::alocator doesn't include
std::allocator
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
This typo for std::allocator gets a poor suggestion:
#include
void* allocate(std::size_t n) { return std::allocate().allocate(n); }
bad-fixit.cc: In function ‘void* allocate(std::size_t)’:
bad-fixit.cc:3:40: error: ‘allocate’ is not a member of ‘std’
void* allocate(std::size_t n) { return std::allocate().allocate(n); }
^~~
bad-fixit.cc:3:40: note: suggested alternative:
bad-fixit.cc:3:7: note: ‘allocate’
void* allocate(std::size_t n) { return std::allocate().allocate(n); }
^~~~
bad-fixit.cc:3:54: error: expected primary-expression before ‘char’
void* allocate(std::size_t n) { return std::allocate().allocate(n); }
^~~~
bad-fixit.cc:3:54: error: expected ‘;’ before ‘char’
bad-fixit.cc:3:58: error: expected unqualified-id before ‘>’ token
void* allocate(std::size_t n) { return std::allocate().allocate(n); }
^
Even std::allocato or std::allocator or std::alocator doesn't get a good
suggestion, it still suggests changing "std" to "allocate" (which would give
"allocate::allocate")
It seems that qualification with namespaces isn't really supported properly.
[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255 --- Comment #10 from wilco at gcc dot gnu.org --- (In reply to Richard Earnshaw from comment #8) > Hmm, why is this even being considered on ARM? > > arm.h:#define NO_FUNCTION_CSE 1 > > doc/tm.texi > @defmac NO_FUNCTION_CSE > Define this macro to be true if it is as good or better to call a constant > function address than to call an address kept in a register. > @end defmac (In reply to Jeffrey A. Law from comment #9) > Also note that on some targets indirect calls have a different ABI than > calls to named function. SO changing between direct and indirect calls is > strictly forbidden on some targets. > > I suspect there's some magic we need to replicate in postreload-gcse from > cse/gcse/combine to prevent this from occurring unnecessarily. Well it's easy to add NO_FUCNTION_CSE to postreload. However a quick experiment shows combine still changes indirect calls to direct calls, so if the ABI is not identical this would be incorrect. So there are multiple places where this would need to be fixed.
[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78599 --- Comment #8 from Markus Trippelsdorf --- (In reply to Martin Jambor from comment #7) > I cannot reproduce this using the testcase from comment #1 even whe I add > -fsanitize=undefined to the command line. Is this on x86_64? You need to use an instrumented compiler, either --with-build-config="bootstrap-ubsan" or CXX="g++ -fsanitize=undefined" ../gcc/configure.
[Bug other/78653] badly optimized kernel code with -fsanitize=object-size -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78653 Christophe Lyon changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Christophe Lyon --- Thanks for the pointer, Markus. *** This bug has been marked as a duplicate of bug 72785 ***
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #18 from Christophe Lyon --- *** Bug 78653 has been marked as a duplicate of this bug. ***
[Bug target/70322] STV doesn't optimize andn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70322 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Dec 2 16:28:41 2016 New Revision: 243195 URL: https://gcc.gnu.org/viewcvs?rev=243195&root=gcc&view=rev Log: PR target/70322 * config/i386/i386.c (dimode_scalar_to_vector_candidate_p): Handle NOT. (dimode_scalar_chain::compute_convert_gain): Likewise. (dimode_scalar_chain::convert_insn): Likewise. * config/i386/i386.md (*one_cmpldi2_doubleword): New define_insn_and_split. (one_cmpl2): Use SWIM1248x iterator instead of SWIM. * gcc.target/i386/pr70322-1.c: New test. * gcc.target/i386/pr70322-2.c: New test. * gcc.target/i386/pr70322-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70322-1.c trunk/gcc/testsuite/gcc.target/i386/pr70322-2.c trunk/gcc/testsuite/gcc.target/i386/pr70322-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/70799] STV pass does not convert DImode shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70799 --- Comment #6 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #5) > (In reply to Uroš Bizjak from comment #0) > > These should all be converted to DImode vector shifts for SSE2/AVX2 32bit > > target (and similar for rotates): > > There are no corresponding SSE insns for rotates. There are only variable logical shifts missing from the set of possible STV transformations on x86. There is slight complication present: in contrast to integer instructions, SSE shifts don't use masked count operand, so masking of count operand is necessary. Loading of 0x63 constant and executing AND on SSE register can be costly, so masking should be performed with a SImode integer instruction. After that, SImode value can be moved to SSE register and used in a shift. OTOH, following code for a simple DImode shift: movl4(%esp), %ecx movla+4, %edx movla, %eax shrdl %edx, %eax shrl%cl, %edx testb $32, %cl je .L2 movl%edx, %eax xorl%edx, %edx .L2: movl%eax, c movl%edx, c+4 ret would be converted to: movl4(%esp), %eax andl$63, %eax movd%eax, %xmm1 movqa, %xmm0 psrlq %xmm1, %xmm0 movq%xmm0, c ret if we don't care about undefined values, then movzbl 4(%esp), %eax movd%eax, %xmm1 movqa, %xmm0 psrlq %xmm1, %xmm0 movq%xmm0, c ret would do the trick, too.
[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646 --- Comment #4 from Stefan M Freudenberger --- I guess there wouldn't be an issue if it were a reference type. However, there is an issue with the incorrect alignment for the object type.
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm seeing it starting with r242923, but that doesn't make any sense, the ICE is in ccp4 and the dump before ccp4 looks identical between compiler that ICEs and doesn't ICE. So r242920 looks much more likely culprit from a close range to that.
[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638 --- Comment #2 from Bill Seurer --- I see it on both BE and LE, power7 and power8. Also a whole bunch more of your new tests started complaining: New failures: FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlz FAIL: gcc.target/powerpc/rldic-0.c scan-assembler-times (?n)^s+[a-z] 1799 FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+[a-z] 1799 FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+rldic 415 FAIL: gcc.target/powerpc/rldic-1.c scan-assembler-times (?n)^s+sldi 29 FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+[a-z] 4471 FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+mr 873 FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+rldimi 1744 FAIL: gcc.target/powerpc/rldimi-0.c scan-assembler-times (?n)^s+rotldi 54 FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+[a-z] 4045 FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+mr 447 FAIL: gcc.target/powerpc/rldimi-1.c scan-assembler-times (?n)^s+rldimi 892 FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+[a-z] 9730 FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+rldicl 3095 FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+rlwinm 3094 FAIL: gcc.target/powerpc/rlwinm-0.c scan-assembler-times (?n)^s+srdi 12 FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+[a-z] 9606 FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+rldic 2946 FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+rlwinm 622 FAIL: gcc.target/powerpc/rlwinm-1.c scan-assembler-times (?n)^s+slwi 1 FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+[a-z] 9466 FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+rldic 2840 FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+rlwinm 721 FAIL: gcc.target/powerpc/rlwinm-2.c scan-assembler-times (?n)^s+srdi 12
[Bug rtl-optimization/78638] [7 regression] test cases gcc.target/powerpc/rlwimi-0.c and rlwimi-2.c fail starting with r243000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638 --- Comment #3 from Bill Seurer --- Also on power6...
[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644
--- Comment #3 from Jakub Jelinek ---
So, before ccp4 we have:
_7 = x3_1 + x2_3;
_8 = {_7, _7, _7, _7};
x4.1_9 = x4;
_15 = {_7, _7, _7, _7};
_16 = BIT_FIELD_REF <_15, 128, 0>;
_17 = BIT_FIELD_REF ;
_18 = _16 + _17;
_19 = {_7, _7, _7, _7};
_20 = BIT_FIELD_REF <_19, 128, 128>;
_21 = BIT_FIELD_REF ;
_22 = _20 + _21;
_23 = {_7, _7, _7, _7};
_24 = BIT_FIELD_REF <_23, 128, 256>;
_25 = BIT_FIELD_REF ;
_26 = _24 + _25;
_27 = {_7, _7, _7, _7};
_28 = BIT_FIELD_REF <_27, 128, 384>;
_29 = BIT_FIELD_REF ;
_30 = _28 + _29;
_10 = {_18, _22, _26, _30};
= _10;
ccp4 sees those uses:
_7 : -->20 uses.
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_27 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_23 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_19 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_15 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
_8 = {_7, _7, _7, _7};
...
Visiting statement:
_7 = x3_1 + x2_3;
which is likely CONSTANT
Match-and-simplified x3_1 + x2_3 to 0
Lattice value changed to CONSTANT 0. Adding SSA edges to worklist.
and replaces all those ctors with {x2_3, x2_3, x2_3, x2_3}.
But folding also happens while this is ongoing:
Folding statement: _17 = BIT_FIELD_REF ;
Not folded
Folding statement: _18 = _16 + _17;
Folded into: _18 = _7 + _17;
and thus a new _7 reference appears, and we don't fold that into _18 = x2_3 +
_17, but remove the _7 setter, because we assume all uses are replaced:
Removing dead stmt _7 = x3_1 + x2_3;
Richi, I think this is your area of expertise.
[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255 --- Comment #11 from Jeffrey A. Law --- IIRC the (proprietary) linker didn't generate argument shuffling stubs for indirect calls. So we ran into problems if any pass changed a direct into an indirect call. The only pass that did this back in the early 90s was CSE :-) If an indirect call were changed to a direct call, we could have an argument location mis-match, but the linker would step in and generate a little stub to shuffle them into the expected locations. Thus we never bothered trying to fix combine.
