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.
