Hello, I have encountered a bug where #including files from /sys causes gcc to have an internal compiler error: In file included from bug.c:1:0: bug.c:1:0: internal compiler error: Aborted #include "/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size" ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. Ths seems to cause an abort on gcc 5.1.1 and a segfault on gcc 4.8. Clang manages to #include the file, but produces about 4000 some warnings about null characters, so this might be a hint about what's going wrong. Now of course I don't think there is any practical reason to #include files from /sys. But it still shouldn't cause a compiler crash. The bug can be reproduced with a source file #including any file from /sys For example: bug.c: #include "/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size" Here is the .i file. bug.i: # 1 "bug.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "bug.c" Here is gcc -v: Using built-in specs. COLLECT_GCC=/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) My uname -a: Linux localhost.localdomain 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Confirmed.
It seems that clang has a similar issue. I added an entry on their bug tracker here: https://llvm.org/bugs/show_bug.cgi?id=24168 As mentioned in clang's bug tracker: I think the problem is related to the use of stat. For example, the manpage for stat() mentions: "For most files under the /proc directory, stat() does not return the file size in the st_size field; instead the field is returned with the value 0." To test this out I wrote another test that tries to #include a file from /proc. #include "/proc/meminfo" However this did not #include the text from the /proc/meminfo at all. Running the preprocessor on this produced an empty file. This is presumably because stat() is saying /proc/meminfo has zero bytes. I don't know if this #including files from proc bug should have its own issue or not, as it seems to be related to the same underlying issue of stat() behaving differently on procfs, sysfs, and maybe others. Like I said before though, I don't have any practical use for #including files from /proc or /sys. But the preprocessor should still be able to do this textual inclusion correctly. I haven't tried this out yet, but now I'm wondering if #include will have issues on other special files on Linux: pipes, sockets, dev files, etc.
Here is 4.7 backtrace: t65.c:1:0: internal compiler error: Segmentation fault 0x7547af crash_signal /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/toplev.c:348 0xa55004 linemap_macro_map_lookup /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/line-map.c:583 0xa55004 linemap_lookup /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/line-map.c:514 0xa551ca linemap_macro_loc_to_spelling_point /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/line-map.c:919 0xa551ca linemap_resolve_location /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/line-map.c:1069 0xa5524b linemap_location_in_system_header_p /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/line-map.c:758 0xa4066e diagnostic_report_diagnostic /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/diagnostic.c:524 0x4dd784 c_cpp_error /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/c-family/c-common.c:8944 0xa4a3fd cpp_diagnostic /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/errors.c:64 0xa4a556 cpp_error /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/errors.c:79 0xa4ec4f read_file_guts /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/files.c:645 0xa4ec4f read_file /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/files.c:678 0xa4f6bd should_stack_file /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/files.c:723 0xa4f6bd _cpp_stack_file /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/files.c:801 0xa47b35 do_include_common /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/directives.c:792 0xa487e0 _cpp_handle_directive /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/directives.c:491 0xa5443c _cpp_lex_token /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/lex.c:1952 0xa583c7 cpp_get_token_1 /bajas/pinskia/src/toolchain-47/scripts/../src/libcpp/macro.c:2245 0x4e8044 c_lex_with_flags /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/c-family/c-lex.c:302 0x4a651f c_lex_one_token /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/c-parser.c:219
So the problem is when it is warning: if (regular && total != size && STAT_SIZE_RELIABLE (file->st)) cpp_error (pfile, CPP_DL_WARNING, "%s is shorter than expected", file->path); So I think it was fixed by r7-1651.