Bug 69539 - ICE in expand_UBSAN_NULL, at internal-fn.c:202
Summary: ICE in expand_UBSAN_NULL, at internal-fn.c:202
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: sanitizer (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, lto
Depends on:
Blocks:
 
Reported: 2016-01-28 14:38 UTC by Sasha Levin
Modified: 2021-12-19 15:10 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.9.3, 5.3.0, 6.0
Last reconfirmed: 2016-01-28 00:00:00


Attachments
preprocessed source (157.09 KB, application/gzip)
2016-01-28 14:38 UTC, Sasha Levin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sasha Levin 2016-01-28 14:38:35 UTC
Created attachment 37508 [details]
preprocessed source

I'm seeing the following ICE:

include/linux/compiler.h: In function ‘__read_once_size_nocheck’:
include/linux/compiler.h:235:44: internal compiler error: in expand_UBSAN_NULL, at internal-fn.c:202
  __READ_ONCE_SIZE;
                                            ^
0x8352b7 expand_UBSAN_NULL
        ../../gcc/internal-fn.c:202
0x633b87 expand_call_stmt
        ../../gcc/cfgexpand.c:2561
0x633b87 expand_gimple_stmt_1
        ../../gcc/cfgexpand.c:3536
0x633b87 expand_gimple_stmt
        ../../gcc/cfgexpand.c:3702
0x6358d1 expand_gimple_basic_block
        ../../gcc/cfgexpand.c:5708
0x63b906 execute
        ../../gcc/cfgexpand.c:6323

with:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/sasha/gcc-inst/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/sasha/gcc-inst/ --with-arch=native --with-tune=native --enable-languages=c --enable-lto --enable-gold --enable-stage1-languages=c
Thread model: posix
gcc version 6.0.0 20160127 (experimental) (GCC)

It is possible to reproduce using the attached preprocessed source file and:

gcc -flto -fsanitize=null  -c -o test test.c; gcc -flto test
Comment 1 Marek Polacek 2016-01-28 14:43:55 UTC
Confirmed (with gcc5 and gcc4.9 as well).
Comment 2 Marek Polacek 2016-01-28 14:49:37 UTC
We have an unexpanded call to internal function because we've never gotten to expanding it in the sanopt pass.
Comment 3 Jakub Jelinek 2016-09-14 08:27:36 UTC
I can't reproduce this, either with 6.x nor trunk, with -O0 I'm getting various
error: call to ‘__compiletime_assert_149’ declared with attribute error: BUILD_BUG_ON failed: MODULES_VADDR < __START_KERNEL_map
like errors, and with -O I'm just getting expected errors due to undefined symbols, but no ICE.
Comment 4 Marek Polacek 2016-09-14 12:17:18 UTC
That's weird, I can still reproduce:

$ xgcc -flto -fsanitize=null  -c -o test test.c
$ xgcc -flto test
include/linux/compiler.h: In function ‘__read_once_size_nocheck’:
include/linux/compiler.h:235:44: internal compiler error: in expand_UBSAN_NULL, at internal-fn.c:204
0xa1a4bd expand_UBSAN_NULL
	/home/marek/src/gcc/gcc/internal-fn.c:204
0xa22ce3 expand_internal_call(internal_fn, gcall*)
	/home/marek/src/gcc/gcc/internal-fn.c:2405
0xa22d0e expand_internal_call(gcall*)
	/home/marek/src/gcc/gcc/internal-fn.c:2413
0x786336 expand_call_stmt
	/home/marek/src/gcc/gcc/cfgexpand.c:2579
0x789cf8 expand_gimple_stmt_1
	/home/marek/src/gcc/gcc/cfgexpand.c:3580
0x78a3ee expand_gimple_stmt
	/home/marek/src/gcc/gcc/cfgexpand.c:3746
0x791c67 expand_gimple_basic_block
	/home/marek/src/gcc/gcc/cfgexpand.c:5753
0x7937e3 execute
	/home/marek/src/gcc/gcc/cfgexpand.c:6367
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.
lto-wrapper: fatal error: /home/marek/x/trunk/gcc/xgcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Comment 5 Martin Liška 2016-09-14 12:36:57 UTC
I can also confirm the ICE on 4.9.0+, as well as on all active branches.
Comment 6 Martin Liška 2016-09-14 12:43:39 UTC
There's a minimal test-case:

int fn1 (void) { return *(volatile int *) fn1; }
Comment 7 Jakub Jelinek 2016-09-26 11:51:38 UTC
Seems to be related to PR69254, either we should force in some flag_sanitize flag whenever we stream in IFN_UBSAN_* builtins (perhaps depending on which option that was), or throw away the IFN_UBSAN_* calls if corresponding flag_sanitize isn't enabled at LTO time.
Comment 8 Jakub Jelinek 2017-01-09 08:57:50 UTC
I think this ought to be fixed by r243514, i.e. PR78708.