[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 Dr. Thomas Orgis changed: What|Removed |Added CC||thomas.or...@uni-hamburg.de --- Comment #3 from Dr. Thomas Orgis --- As I already mentioned in the mirrored bug on github (https://github.com/ianlancetaylor/libbacktrace/issues/30), I added those two noclone attributes to edtest and it changed nothing: user@host:/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/libbacktrace$ make edtest /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld -fchecking=1 -DHAVE_CONFIG_H -I. -I../../gcc-9.2.0/libbacktrace -I ../../gcc-9.2.0/libbacktrace/../include -I ../../gcc-9.2.0/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=edtest.o -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -c -o edtest.o ../../gcc-9.2.0/libbacktrace/edtest.c /bin/bash ./libtool --tag=CC --mode=link /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld -fchecking=1 -funwind-tables -frandom-seed=edtest -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -static-libstdc++ -static-libgcc -o edtest edtest.o edtest2_build.o testlib.o libbacktrace.la libtool: link: /dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/xgcc -B/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./prev-gcc/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/bin/ -B/sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/lib/ -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/include -isystem /sw/env/system-gcc/gcc/9.2.0-testing/x86_64-pc-linux-gnu/sys-include -fchecking=1 -funwind-tables -frandom-seed=edtest -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -g -O2 -fchecking=1 -static-libstdc++ -static-libgcc -o edtest edtest.o edtest2_build.o testlib.o -L/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/./ld ./.libs/libbacktrace.a user@host:/dev/shm/sw/env/system-gcc/gcc/9.2.0-testing/build/libbacktrace$ ./edtest test1: [1]: missing file name or function name FAIL: backtrace_full alloc stress So … is this something serious?
[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 --- Comment #5 from Dr. Thomas Orgis --- I traced it down to the gcc build process not applying the -g flag consistently. In my build log, I see the respective objects being built two times (not sure in which directory the second one happens, as the build is parallel and needs enough time as it is …). On the second time, the build includes '-g -O2'. On the first time not (only my own CFLAGS in case I had some set). Same for ttest and ttest_alloc. When I enter the build tree and remove the object files, remaking them does include the correct flags including -g and the testsuite of libbacktrace passes. I bet there is a number of people more intimate with the gcc build system, hopefully able to discern why an intermediate build with missing -g happens. I issue a default bootstrap build with 'make -j8'.
[Bug fortran/67760] New: ICE on contained subroutine in function modifying function return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67760 Bug ID: 67760 Summary: ICE on contained subroutine in function modifying function return value Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thomas.or...@uni-hamburg.de Target Milestone: --- Host: x86_64-unknown-linux-gnu Created attachment 36414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36414&action=edit example code triggering the ICE I get a reliable gfortran internal compiler error with all versions I tried so far (version 5.1.0 picked as the one where the installation reports a backtrace that may be useful). In my tests this affects gcc-4.8.3 (CentOS), gcc-4.1.2 (SLES) and self-compiled vanilla gcc 4.9.2, 5.1.0, 5.2.0 . I therefore conclude that it probably still is there in more current/upcoming releases. The culprit is a contained subroutine inside a function that is accessing the return value of that function through the functions's name: function fancy() !integer :: fancy ! both gcc and icc happy !integer :: fancy(4) ! gcc crash, icc depends on more_fancy integer :: fancy(3,2) ! gcc crash, icc depends on more_fancy call more_fancy contains subroutine more_fancy fancy = 42 ! Fine, generally. !fancy(:) = 42 ! icc giving error about substring !fancy(:,:) = 42 ! icc giving error about function name conflict end subroutine end function I am not really sure what the standard says about this, especially since this works for a scalar return value for both gcc and the Intel compiler, and also for an array if the first assignment in more_fancy is used. For a non-recursive function, I actually don't see any problem when one considers the code of the contained subroutine still being in the scope of the function. But anyhow: At least an error should be produced instead of the compiler crashing. Example from gcc-5.1.0: $ LANG=C gfortran -Wall -Wextra -o gfortran-ice gfortran-ice.f90 gfortran-ice.f90:16:0: function fancy() ^ internal compiler error: Segmentation fault 0x90c276 crash_signal /usr/src/gcc-5.1.0/gcc/toplev.c:383 0x2b47551271ef ??? /usr/src/glibc-2.21/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x97bd0a get_frame_type /usr/src/gcc-5.1.0/gcc/tree-nested.c:263 0x97bd0a get_chain_decl /usr/src/gcc-5.1.0/gcc/tree-nested.c:369 0x97e2ea get_chain_decl /usr/src/gcc-5.1.0/gcc/tree-nested.c:875 0x97e2ea get_nonlocal_debug_decl /usr/src/gcc-5.1.0/gcc/tree-nested.c:880 0x97e408 convert_nonlocal_reference_op /usr/src/gcc-5.1.0/gcc/tree-nested.c:958 0xaff4e4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set*)) /usr/src/gcc-5.1.0/gcc/tree.c:11093 0x74f66c walk_gimple_op(gimple_statement_base*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:235 0x74f8d4 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:575 0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:72 0x74f992 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:585 0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:72 0x74f992 walk_gimple_stmt(gimple_stmt_iterator*, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:585 0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node* (*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) /usr/src/gcc-5.1.0/gcc/gimple-walk.c:72 0x97b7b1 walk_body /usr/src/gcc-5.1.0/gcc/tree-nested.c:628 0x97ba5e walk_function /usr/src/gcc-5.1.0/gcc/tree-nested.c:639 0x97ba5e walk_all_functions /usr/src/gcc-5.1.0/gcc/tree-nested.c:704 0x97d2c7 lower_nested_functions(tree_node*) /usr/src/gcc-5.1.0/gcc/tree-nested.c:3008 0x608d7b cgraph_node::analyze() /usr/src/gcc-5.1.0/gcc/cgraphunit.c:640 Please submit a full bug report, with preprocessed sour
[Bug fortran/67760] ICE on contained subroutine in function modifying function return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67760 --- Comment #2 from Dr. Thomas Orgis --- Am Fri, 09 Oct 2015 13:59:08 + schrieb "dominiq at lps dot ens.fr" : > After including a line > > module fancymod Yeah, sorry about that, but it is kindof obvious that this line is missing from the example;-)
[Bug fortran/69281] New: gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69281 Bug ID: 69281 Summary: gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thomas.or...@uni-hamburg.de Target Milestone: --- Host: x86_64-unknown-linux-gnu Created attachment 37343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37343&action=edit example code triggering the ICE Hi, here I am again crashing the GNU Fortran compiler. The attached code gives an ICE with gfortran from 4.8.3 to 5.3.0 (maybe earlier, too) when activating OpenMP and stack arrays: $ gfortran -fstack-arrays -fopenmp -c -o test/notest_gfortran_ice_omp_add_variable.o .preprocessed/test/notest_gfortran_ice_omp_add_variable.f90 .preprocessed/test/notest_gfortran_ice_omp_add_variable.f90:20:0: call midx_new(midx_counts2ranges(samples)) ^ internal compiler error: in omp_add_variable, at gimplify.c:5644 0x8dd236 omp_add_variable ../../../src/gcc-5.3.0/gcc/gimplify.c:5642 0x8e3de8 gimplify_bind_expr ../../../src/gcc-5.3.0/gcc/gimplify.c:1108 0x8e22e9 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../../src/gcc-5.3.0/gcc/gimplify.c:8297 0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**) ../../../src/gcc-5.3.0/gcc/gimplify.c:5519 0x8e30d3 gimplify_and_add(tree_node*, gimple_statement_base**) ../../../src/gcc-5.3.0/gcc/gimplify.c:423 0x8e30d3 gimplify_and_return_first ../../../src/gcc-5.3.0/gcc/gimplify.c:435 0x8e30d3 gimplify_omp_parallel ../../../src/gcc-5.3.0/gcc/gimplify.c:6901 0x8e30d3 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../../src/gcc-5.3.0/gcc/gimplify.c:8547 0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**) ../../../src/gcc-5.3.0/gcc/gimplify.c:5519 0x8e1d3b gimplify_statement_list ../../../src/gcc-5.3.0/gcc/gimplify.c:1487 0x8e1d3b gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../../src/gcc-5.3.0/gcc/gimplify.c:8515 0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**) ../../../src/gcc-5.3.0/gcc/gimplify.c:5519 0x8e401d gimplify_bind_expr ../../../src/gcc-5.3.0/gcc/gimplify.c:1136 0x8e22e9 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../../src/gcc-5.3.0/gcc/gimplify.c:8297 0x8e3816 gimplify_stmt(tree_node**, gimple_statement_base**) ../../../src/gcc-5.3.0/gcc/gimplify.c:5519 0x8e46c1 gimplify_body(tree_node*, bool) ../../../src/gcc-5.3.0/gcc/gimplify.c:9234 0x8e49e7 gimplify_function_tree(tree_node*) ../../../src/gcc-5.3.0/gcc/gimplify.c:9388 0xaf7cf2 gimplify_all_functions ../../../src/gcc-5.3.0/gcc/tree-nested.c:3021 0xaf7cd7 gimplify_all_functions ../../../src/gcc-5.3.0/gcc/tree-nested.c:3023 0xaf9242 lower_nested_functions(tree_node*) ../../../src/gcc-5.3.0/gcc/tree-nested.c:3040 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. Removing either of -fopenmp or -fstack-arrays prevents the issue, as does programming around the temporary storage created for the function call. I hope that is specific enough to point out the code to blame. Fun fact: I stumbled upon this after experiencing the ridiculously small OpenMP stack size of the Intel compiler despite unlimited stack via ulimit. Because of the random crashes caused by this, they may switch to defaulting to heap arrays like gfortran does. But since Fortran is about efficient numerics, if anything, I very much prefer temporary arrays to be on the stack as I am used to from other compilers. Calling out malloc() for 10 bytes of local storage in a function is not funny. Since I figured out now why my code did not work with -fstack-arrays, I may investigate what limit gfortran has for OpenMP stacks …
