[Bug gcov-profile/100788] New: Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 Bug ID: 100788 Summary: Internal compiler error related to #line macros(?) Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: sebastian-gcc at sipsolutions dot net CC: marxin at gcc dot gnu.org Target Milestone: --- I first thought this might have been the identical issue as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847 as it seemed similar. There is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96353, but I do not think this is the same issue. We have a large file in NumPy which generates compile errors on gcc 9+ (gcc 8 seems fine as far as I can tell). The issue on NumPy is: https://github.com/numpy/numpy/issues/18529 (It is not a major issue, but I fear it might get problematic for our coverage tools when they stop using GCC 8, which I think they are still using.) I have attached the source file that generates the issue. Note that it is generated by a custom templating language, so I can't fully rule out that the inserted `#line` directives are incorrect. The one clear thing I know is that removing all `#line` directives makes the coverage compilation successfully. I expect you may need more information, but am not sure how to best provide it, considering that the file is part of the larger project. The error/log is (this one with gcc (Debian 10.2.1-6) 10.2.1 20210110, but confirmed on a gcc 11: ... x86_64-linux-gnu-gcc: numpy/core/src/common/python_xerbla.c during IPA pass: profile numpy/core/src/multiarray/einsum_sumprod.c.src: In function ‘longdouble_sum_of_products_contig_three’: numpy/core/src/multiarray/einsum_sumprod.c.src:1264:1: internal compiler error: in coverage_begin_function, at coverage.c:656 1264 | } | ^ 0x7ff60fe2cd09 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. error: Command "x86_64-linux-gnu-gcc -pthread --coverage -Wno-unused-result -Wsign-compare -O0 -ggdb -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -Werror=vla -Werror=nonnull -Werror=pointer-arith -Wlogical-op -Werror=unused-function -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-3.9/numpy/core/include/numpy -Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/usr/include/python3.9 -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/npymath -c build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.c -o build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o -MMD -MF build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o.d -msse -msse2 -msse3" failed with exit status 1
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #1 from seberg --- Created attachment 50875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50875&action=edit preprocessed_file
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #3 from seberg --- Created attachment 50878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50878&action=edit actual_preprocessed_with_gcc Sorry, I think this is what you are looking for now, adding -E to it.
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #5 from seberg --- > Now I miss the command line. Do you mean more than the failing call?: x86_64-linux-gnu-gcc -pthread --coverage -O0 -ggdb -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -g -fwrapv -O2 -D_FORTIFY_SOURCE=2 -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-3.9/numpy/core/include/numpy -Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/usr/include/python3.9 -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/npymath -c build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.c -o build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o -msse2 -msse3 (with some warning flags removed compared to the initial report; I can try to zip up the dependencies tomorrow. To make it reproducable)
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #7 from seberg --- Oh, interesting. You are right, if I run it on the preprocessed file it succeeds (note the `tmp/preprocessed.c`: x86_64-linux-gnu-gcc -pthread --coverage -O0 -ggdb -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -g -fwrapv -O2 -D_FORTIFY_SOURCE=2 -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-3.9/numpy/core/include/numpy -Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/usr/include/python3.9 -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/npymath -c /tmp/preprocessed.c -o build/temp.linux-x86_64-3.9/build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.o -msse2 -msse3 Just to cover my ground the preprocessed file was generated with: x86_64-linux-gnu-gcc -pthread --coverage -Wno-unused-result -Wsign-compare -O0 -ggdb -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -Werror=vla -Werror=nonnull -Werror=pointer-arith -Wlogical-op -Werror=unused-function -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DNPY_INTERNAL_BUILD=1 -DHAVE_NPY_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_CBLAS -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-3.9/numpy/core/include/numpy -Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -Inumpy/core/src/common -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/src/_simd -I/usr/include/python3.9 -Ibuild/src.linux-x86_64-3.9/numpy/core/src/common -Ibuild/src.linux-x86_64-3.9/numpy/core/src/npymath -c build/src.linux-x86_64-3.9/numpy/core/src/multiarray/einsum_sumprod.c -E > /tmp/preprocessed.c
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #9 from seberg --- NumPy is pretty light weight (at least on linux systems, and if you do not care about setting up BLAS manually). You probably only need the Python dev headers, that I expect you already have. Hopefully, the following will just work for you: git clone https://github.com/numpy/numpy cd numpy python runtests.py --show-build-log --gcov # If you got problems due to blas/lapack, try with NPY_BLAS_ORDER="" which will leave all the temporary files on error and print out the compiler options. (There is some spammy output at the very end to scroll past, and the exact commands are the concatenation of the print out -- but the erroring one is printed in full after the GCC error.)
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788 --- Comment #11 from seberg --- Does that mean that fixing the `#line` directives (or inserting additional ones) should be able to fix the issue? (Or work around it, if you consider it a bug.) I tried to figure out where the `#line` directives currently causes this situation, and add new ones in some places in the templater. But I don't really see where it goes wrong. That is, unless `#if 0` causes the directives within the block to be ignored?
[Bug target/105480] New: Vectorized `isnan` appears to trigger FPE on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480 Bug ID: 105480 Summary: Vectorized `isnan` appears to trigger FPE on ppc64le Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian-gcc at sipsolutions dot net Target Milestone: --- Compiling for ppc64le with `-O3` seems to use the `xvcmpgedp` instruction which ends up setting the FPE flags. I have created an example in godbolt: https://godbolt.org/z/n8PfPPP1d Clang will produce similar code (using the same instruction), but when enabling `-ftrapping-math` (as they always want...) will switch to `vcmpgtud`. I think the same issue happens with `==` and `!=` which (IIRC) should not trap.
[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #1 from seberg ---
Actually, I think I likely misanalyzed, the actual code in question where I
found this was doing something like:
while (n--) {
if (isnan(*input)) {
*out = 1;
}
else {
*out = (long)(*input)
}
}
So probably it is rather the branch that gets optimized away. I will try to
post a better example.
[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480 --- Comment #2 from seberg --- I still owed the correct example: https://godbolt.org/z/33Pj6xvPr Now I think the cause is the indeed (somewhat understandandable) desire to optimize away the branching. And not the instruction (I am not sure how the comparison instruction deals with trapping, so it could be both).
