Originally observed on freetype-2.10.2 package. Here is the minimal reproducer: // x86_64-pc-linux-gnu-gcc -m32 -c -O2 bug.c -o a.o void a(char *__restrict, const long *, unsigned) __attribute__((__access__(__write_only__, 1))); void a(char *, const long *, unsigned); const char b[]; const char b[] = {}; $ ./xgcc -B. -c bug.c -o a.o bug.c:6:1: internal compiler error: in composite_type, at c/c-typeck.c:447 6 | const char b[] = {}; | ^~~~~ 0x44f412 composite_type(tree_node*, tree_node*) ../../gcc/gcc/c/c-typeck.c:447 0x426a0c finish_decl(tree_node*, unsigned int, tree_node*, tree_node*, tree_node*) ../../gcc/gcc/c/c-decl.c:5356 0x4a04f0 c_parser_declaration_or_fndef ../../gcc/gcc/c/c-parser.c:2289 0x49f01b c_parser_external_declaration ../../gcc/gcc/c/c-parser.c:1777 0x49eb6a c_parser_translation_unit ../../gcc/gcc/c/c-parser.c:1650 0x4df8f5 c_parse_file() ../../gcc/gcc/c/c-parser.c:21821 0x5727e0 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1188 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ ./xgcc -B. -v Reading specs from /home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/specs COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/xgcc COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick-ggdb3/gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-native-quick-ggdb3/../gcc-native-quick-installed-ggdb3 --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS='-O0 -ggdb3 ' CXXFLAGS='-O0 -ggdb3 ' --enable-valgrind-annotations Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20200925 (experimental) (GCC)
Testcase 2: something related happens to wavpack-5.3.2 package where gcc stopped typechecking array declarations: char *a(char *__restrict, int); __attribute__((__access__(__write_only__, 1))) char *a(char *, int); extern const char b[6]; extern const char b[]; $ gcc-10.2.0 -c a.c -o a.o $ gcc-11.0.0 -c a.c -o a.o a.c:4:19: error: conflicting type qualifiers for 'b' 4 | extern const char b[]; | ^ a.c:3:19: note: previous declaration of 'b' was here 3 | extern const char b[6]; | ^ Note: presence of seemingly unrelated 'a' declaration affects 'b' typechecking.
Confirmed, started with r11-3303-g6450f07388f9fe57.
Hmm, this one is strange. Somehow the qualifiers on the pointer argument (but not the type it points to) in the function argument list are ending up in the type of the array with unspecified bound. The error is then issued in diagnose_mismatched_decls when verifying that the qualifiers on the array type are the same between the two declarations of b. Something about the change to handle_access_attribute in r11-3303 is causing the restrict qualifier (or any other qualifier on the pointer argument, including const and volatile) to be set on the type of the array. Another test case that reproduces it is: $ cat pr97206.c && gcc -O2 -S -Wall pr97206.c void a (char * volatile); __attribute__((__access__ (__read_only__, 1))) void a (char *volatile); extern const char b[]; extern const char b[1]; pr97206.c:5:19: error: conflicting type qualifiers for ‘b’ 5 | extern const char b[1]; | ^ pr97206.c:4:19: note: previous declaration of ‘b’ was here 4 | extern const char b[]; | ^
A different/simpler test case that doesn't involve a call to handle_access_attribute(): $ cat pr97206.c && gcc -O2 -S -Wall pr97206.c void a (char *); void a (char [restrict]); extern const char b[]; extern const char b[1]; pr97206.c:5:19: error: conflicting type qualifiers for ‘b’ 5 | extern const char b[1]; | ^ pr97206.c:4:19: note: previous declaration of ‘b’ was here 4 | extern const char b[]; | ^
Joseph, any idea what might be causing this? The test case in comment #4 has me stumped.
Testing this fix: diff --git a/gcc/attribs.c b/gcc/attribs.c index abc75368e6c..262e4b8f7b9 100644 --- a/gcc/attribs.c +++ b/gcc/attribs.c @@ -2278,7 +2278,7 @@ attr_access::array_as_string (tree type) const else if (minsize) index_type = build_index_type (size_int (minsize - 1)); - artype = build_array_type (eltype, index_type); + artype = build_nonshared_array_type (eltype, index_type); if (static_p || vla_p) {
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555125.html
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>: https://gcc.gnu.org/g:e808f3fdfa8f31066da19011b55acb8c0446c72d commit r11-3570-ge808f3fdfa8f31066da19011b55acb8c0446c72d Author: Martin Sebor <msebor@redhat.com> Date: Wed Sep 30 09:31:29 2020 -0600 PR c/97206 - ICE in composite_type on declarations of a similar array types gcc/ChangeLog: PR c/97206 * attribs.c (attr_access::array_as_string): Avoid modifying a shared type in place and use build_type_attribute_qual_variant instead. gcc/testsuite/ChangeLog: PR c/97206 * gcc.dg/Warray-parameter-7.c: New test. * gcc.dg/Warray-parameter-8.c: New test. * gcc.dg/Wvla-parameter-5.c: New test.
Fixed in r11-3570.