#3715 Crash with "internal compiler error" when compiling

[Diego Argueta]

I have some code that worked on SDCC 4.2 and now no longer compiles under 4.4.0. I don't know why the compiler is convinced there's nothing in annotations.h because I added in a typedef at the bottom of the file specifically to make this error go away. (The only SDCC-specific stuff is at the bottom of that file.)

The only code you need to repro this error is:

#include "annotations.h"

int main() {
    return 0;
}

Command: sdcc -I. --std-c99 -mz80 -c test.c

Output

unreachable dummy in cc1get_identifier
untested in cc1: warn_if_plugins
untested in cc1: emergency_dump_function
In file included from test.c:1:
annotations.h:1: internal compiler error: in get_identifier, at cc1_dummies.cc:131
    1 | // Copyright 2020-2024 by Diego Argueta
      | 
0x7f343b22814f __libc_start_call_main
    ../sysdeps/nptl/libc_start_call_main.h:58
0x7f343b228208 __libc_start_main_impl
    ../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://sourceforge.net/tracker/?atid=100599&group_id=599&func=browse> for instructions.
annotations.h:1: warning 190: ISO C forbids an empty translation unit
subprocess error 256

It still crashes when running it through the preprocessor with -E:

#line 0 "test.c"
#line 0 "<built-in>"
#line 0 "<command-line>"
#line 1 "test.c"
#line 1 "annotations.h" 1
unreachable dummy in cc1get_identifier
untested in cc1: warn_if_plugins
untested in cc1: emergency_dump_function
In file included from test.c:1:
annotations.h:1: internal compiler error: in get_identifier, at cc1_dummies.cc:131
    1 | // Copyright 2020-2024 by Diego Argueta
      | 
0x7f9be4c2814f __libc_start_call_main
    ../sysdeps/nptl/libc_start_call_main.h:58
0x7f9be4c28208 __libc_start_main_impl
    ../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://sourceforge.net/tracker/?atid=100599&group_id=599&func=browse> for instructions.

The target architecture doesn't appear to matter. I've tried hc08, ds390, mmos6502, and a couple others. All exhibit the same behavior.

Notably, I tried this on a clean install of Debian 12.5 in a Docker container and got a different stack trace:

unreachable dummy in cc1get_identifier
untested in cc1: warn_if_plugins
untested in cc1: emergency_dump_function
In file included from test.c:1:
annotations.h:1: internal compiler error: in get_identifier, at cc1_dummies.cc:131
    1 | // Copyright 2020-2024 by Diego Argueta
      | 
0x431c87 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t)
    ???:0
0x432957 internal_error(char const*, ...)
    ???:0
0x404865 fancy_abort(char const*, int, char const*)
    ???:0
0x40d53f get_identifier(char const*)
    ???:0
0x40cd32 c_common_has_attribute(cpp_reader*, bool)
    ???:0
0x45dc17 _cpp_builtin_macro_text
    ???:0
0x45dfc9 builtin_macro(cpp_reader*, cpp_hashnode*, unsigned int, unsigned int) [clone .constprop.0]
    ???:0
0x45c2e8 cpp_get_token_1(cpp_reader*, unsigned int*)
    ???:0
0x448d94 _cpp_parse_expr
    ???:0
0x442a91 do_if(cpp_reader*)
    ???:0
0x444a41 _cpp_handle_directive
    ???:0
0x455da0 _cpp_lex_token
    ???:0
0x45c077 cpp_get_token_1(cpp_reader*, unsigned int*)
    ???:0
0x40b57f preprocess_file(cpp_reader*)
    ???:0
0x40a922 c_common_init()
    ???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <http://sourceforge.net/tracker/?atid=100599&group_id=599&func=browse> for instructions.
annotations.h:1: warning 190: ISO C forbids an empty translation unit
subprocess error 256

sdcc -v: SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02 TD- 4.4.0 #14620 (Linux)

uname -a:

• (My laptop) : Linux tux 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 14:17:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
• (Debian 12.5 Docker image) Linux 046aba0a969b 6.5.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 14:17:40 UTC 2024 x86_64 GNU/Linux

[Diego Argueta]

Okay yes I just rebuilt the Docker container with 4.2.0 and it works just fine. Changing nothing in the image except the SDCC precompiled download breaks on 4.3.0 and 4.4.0, including all their release candidates.

[Benedikt Freisen]

While a fix is still pending, the problem has been identified a couple of days ago: The code uses the GCC extension __has_attribute, which SDCPP recognizes (it is a fork of GCC CPP, after all), but chokes on.

[Diego Argueta]

Okay, I've confirmed that the problem can be fixed by changing this:

#if defined(__has_attribute)

to this:

#if defined(__has_attribute) && !defined(__SDCC)

[Christopher Bazley]

The standard C23 operator __has_c_attribute fails in the same way. It does not seem worth filing a separate bug report.

1: Sample code that reproduces the problem.

#if __has_c_attribute(nodiscard)
#endif
int audit_nonempty;

2: Exact command used to run SDCC on this sample code.

sdcc -mz80 --std=c2y --nostdinc -E bug.c

3: SDCC version tested.

SDCC 4.6.4 #17068 (Linux), tested 23 October 2026.

4: Observed and expected behaviour.

The bundled preprocessor reports an internal compiler error in get_identifier at cc1_dummies.cc:132. Its stack includes c_common_has_attribute. The driver exits with status 1. The same failure occurs when compiling to assembly; it is already reproducible with preprocessing alone.

This is a valid standard __has_c_attribute expression. N3886 6.10.2 paragraph 9 requires a nonzero integer result if the named attribute is supported, or zero otherwise. A syntactically valid query should not produce an internal error, including for an unknown attribute name.

Reference: N3886, 6.10.2 paragraph 9.

5: Additional checks.

The seven standard names nodiscard, deprecated, fallthrough, maybe_unused, noreturn, unsequenced and reproducible, plus the unknown name sdcc_audit_unknown, all reach the internal compiler error on Z80, MCS51, STM8, PDK14 and MOS65C02 in both C23 and C2Y (80 checks). The original GNU query __has_attribute(unused) also fails in the same ten configurations, giving 90 reproduced error paths in total.

The malformed __has_c_attribute(123) expression receives ordinary syntax diagnostics. It is recorded separately as negative syntax-check evidence; that does not excuse the failure of valid queries.

GCC 13.3.0 with -std=c2x -pedantic-errors -E accepts the nodiscard query, the unknown-name query and the GNU unused query. GCC 16.2 and Clang were not tested.