[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 qinzhao at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-09-13 Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #7 from Richard Biener --- Btw, you can do make check RUNTESTFLAGS="--target_board=unix/-ftrivial-auto-var-init=zero" to have dejagnu automagically add the flag to all tests (doesn't work for Ada ACATS)
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #6 from David Binderman --- (In reply to qinzhao from comment #5) > with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c > -g -O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure: > /home/opc/Install/latest/bin/gcc -c -g -ftrivial-auto-var-init=zero -O2 > -Wall ./gcc.dg/graphite/pr82421.c > delete -ftrivial-auto-var-init=zero, the failure is gone. > > I will study this one to fix it. Good news. I'll test with -O3 -march=native, and if it passes then the C side of things looks good enough for prime time. I will then test C++ and Fortran in a similar way, and if they pass too, then the new flag looks IMHO ready for other compiler users.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #5 from qinzhao at gcc dot gnu.org --- with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c -g -O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure: /home/opc/Install/latest/bin/gcc -c -g -ftrivial-auto-var-init=zero -O2 -Wall ./gcc.dg/graphite/pr82421.c during RTL pass: expand ./gcc.dg/graphite/pr82421.c: In function ‘qy’: ./gcc.dg/graphite/pr82421.c:10:7: internal compiler error: in expand_expr_addr_expr_1, at expr.c:8432 10 | int fb[tw]; | ^~ 0x6b3494 expand_expr_addr_expr_1 ../../latest-gcc/gcc/expr.c:8432 0xaecd9d expand_expr_addr_expr ../../latest-gcc/gcc/expr.c:8545 0xaecd9d expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../latest-gcc/gcc/expr.c:11761 0xaeac65 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../latest-gcc/gcc/expr.c:8733 0xaeac65 expand_expr ../../latest-gcc/gcc/expr.h:301 0xaeac65 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../latest-gcc/gcc/expr.c:9053 0xaeb732 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../latest-gcc/gcc/expr.c:11818 0x991030 expand_expr ../../latest-gcc/gcc/expr.h:301 0x991030 get_memory_rtx ../../latest-gcc/gcc/builtins.c:1369 0x9989f5 expand_builtin_memset_args ../../latest-gcc/gcc/builtins.c:4101 0x9c4a67 expand_call_stmt ../../latest-gcc/gcc/cfgexpand.c:2749 0x9c4a67 expand_gimple_stmt_1 ../../latest-gcc/gcc/cfgexpand.c:3876 0x9c4a67 expand_gimple_stmt ../../latest-gcc/gcc/cfgexpand.c:4040 0x9cac8b expand_gimple_basic_block ../../latest-gcc/gcc/cfgexpand.c:6082 0x9cc98f execute ../../latest-gcc/gcc/cfgexpand.c:6808 Please submit a full bug report, delete -ftrivial-auto-var-init=zero, the failure is gone. I will study this one to fix it.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #4 from Qing Zhao --- > On Sep 10, 2021, at 5:34 PM, pinskia at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 > > --- Comment #3 from Andrew Pinski --- > I wonder if most of these were fixed by r12-3447-g79f488de3036a There are two patches by Richard Biener last night to fix two bugs: commit 79f488de3036a4a4be08df2a782e6eb02419db19 Author: Richard Biener Date: Fri Sep 10 12:28:09 2021 +0200 middle-end/102273 - avoid ICE with auto-init and nested functions This refactors expansion to consider non-decl LHS. I suspect the is_val argument is not needed. commit 1dae802b685937b1dc52e49d0641c75f3186ba14 Author: Richard Biener Date: Fri Sep 10 10:17:24 2021 +0200 middle-end/102269 - avoid auto-init of empty types This avoids initializing empty types for which we'll eventually leave a .DEFERRED_INIT call without a LHS. I checked the failed testing cases listed by David, many of them have empty types. So, I guess that the above two patches might already fix these failures. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #3 from Andrew Pinski --- I wonder if most of these were fixed by r12-3447-g79f488de3036a
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #2 from qinzhao at gcc dot gnu.org --- I checked all the listed testing cases with the latest GCC + -g -ftrivial-auto-var-init=pattern -O2 all passed without issue.
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #1 from qinzhao at gcc dot gnu.org --- (In reply to David Binderman from comment #0) > For the C source code under gcc/trunk/gcc/testsuite, I did: > > ./c-c++-common/dfp/func-vararg-size0.c:16:5: internal compiler error: > Segmentation fault I just tried: [opc@qinzhao-ol8u3-x86 gcc]$ cat t /home/opc/Work/GCC/build/gcc/xgcc -B/home/opc/Work/GCC/build/gcc/ /home/opc/Work/GCC/latest-gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-size0.c -g -ftrivial-auto-var-init=zero -fdump-tree-gimple -O2 [opc@qinzhao-ol8u3-x86 gcc]$ sh t i.e, I didn't get the segmentation fault. could you list the full command line for the above testing case? Did you check with the latest upstream GCC? there are two bugs that had been fixed by Richard B last night.
