Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm: > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote: > >> I was hoping Joseph would chime in here - I recollect debugging this kind >> of thing and a thread about this a while back but unfortunately I do not >> remember the details here (IIRC some things get included where they >> better should not be). > > See <https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582563.html>. > Is there some reason it's problematic to avoid having defaults.h or > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only > include D-specific headers? >
In targets such as arm-elf, we still need to pull in definitions from ${cpu_type}/${cpu_type}-d.cc into default-d.cc. All I can think that might suffice is having D-specific prototype headers in all targets as ${cpu_type}/${cpu_type}-d.h. At this location: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=1104508488818ff589dbc0890cf3fc475ae5977a;hb=refs/heads/master#l560 if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-d.h then tm_d_file=${cpu_type}/${cpu_type}-d.h fi Looks like RustFE ripped out their target support for now. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=1c8ebf66965509008329b6e0425ffda407265263 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3cd9342634e38100a9fa6a4bec4d958ca3a4ab60 https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a15ee6c3e5d710556d145e6af499b09993c4ee64 Iain.