Re: microblaze ASM_OUTPUT_IDENT Was: RFA: hookize BOOL_TYPE_SIZE and ADA_LONG_TYPE_SIZE

[Joern Rennecke <amylaar at spamcop dot net>]

Quoting Laurent GUERBY <laurent@guerby.net>:

> On Wed, 2010-12-01 at 00:32 -0500, Joern Rennecke wrote:
> > bootstrapped & regtested on x86_64-pc-linux-gnu
> > cross-tested on x86_64-pc-linux-gnu for the following targets:
> > ppc-darwin
> > alpha-linux-gnu hppa-linux-gnu mips-elf sh-elf arc-elf ia64-elf sparc-elf
> > arm-eabi iq2000-elf mn10300-elf spu-elf avr-elf lm32-elf moxie-elf v850-elf
> > m32c-elf pdp11-aout cris-elf m32r-elf picochip-elf xstormy16-elf
> > crx-elf m68hc11-elf ppc-elf xtensa-elf fr30-elf m68k-elf rx-elf
> > mcore-elf
> > s390-linux-gnu h8300-elf mep-elf score-elf
> >
> > bootstrapped on i686-pc-linux-gnu
> > cross-tested on i686-pc-linux-gnu for targets:
> > bfin-elf frv-elf mmix-knuth-mmixware vax-linux-gnu
> >
> > Ada testing for microblaze is currently not possible because of PR46738.
>
> This one looks like a missing include (again): the macro
> ASM_OUTPUT_IDENT is visible and defined in microblaze.h calling
> microblaze_asm_output_ident from microblaze.c which is not visible from
> microblaze.h but from microblaze-protos.h which for some reason
> end up not included from ada/gcc-interface/trans.c
>
> What are the include rules in GCC? Why would a macro in one .h do not
> include what's needed to implement it? Is it a microblaze issue
> or a trans.c issue?

In general, if you use any tm.h macro, besides tm.h, you also have to
include tm_h, and if the macro involves a type from tree.h / rtl.h, you
have to include tree.h / rtl.h between including tm.h and tm_p.h .

But frontend maintainers often get this wrong, and also there are often
ways in which type, value ranges, constantness or non-constantness of
macro definitions by particular targets cause warnings in frontends,
which causes bootstraps to fail.  The interfaces are not defined
rigerously enough to avoid such failures without testing every possible
target with every frontend first.

These are just two of the reasons why it would be better for our users if
frontends would not use target macros, and reducing the number of target
macros in frontends by replacing them with hooks also generally reduces
this instability.
Once all target macros are eliminated from a frontend file, the way to
avoid regressions is to eliminate all direct and indirect includes of
tm.h.  And once we have archived that for all frontend files, we can poison
the include guards of tm.h and its friends for frontends, i.e. TM_H,
HARD_REG_SET_H etc. .
Target macros in the rtl optimizers are a lesser concern because they get
better test coverage than the less-frequently built frontends, like ada.