On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote: > 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.
As long as those prototypes don't involve any types that depend on an inclusion of tm.h, that should be fine. -- Joseph S. Myers jos...@codesourcery.com
