This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch] Separate {OS,CPU}_CPP_BUILTINS macros into C-family and language-independent macros


See below for the description of the patch; this take n+1 incorporates suggestions by Michael Meissner and Rainer Orth, with the following exceptions:

  -- As avr.c includes new headers (cpplib.h and cppbuiltin.h), I wanted to update its dependencies in the target configuration file (t-avr), but to my surprise, this file doesn't contain any mention of avr.o. In fact, I failed to find any by grepping the whole tree, so I'm a little unsure how this can work (and apparently it does). Could the maintainers help me here?

  -- Michael is worried about splitting all this stuff:

>> Unless I don't see what you're talking about, this is not possible: the Fortran front-end is not linked with the *-c.c files, only with *.c, so the language-independent functions need to be moved there.
> 
> Yes, but if fortran is going to use the preprocessor, maybe they should be
> linked in.  I'm just worried about the possibility of a macro getting lost in
> the movement.


Well, we do need some separation between CPP built-in macros that are only relevant for C-family languages (for example, because they depend on flag variables that are only declared for C) and the others. Now that the job is done, was discussed beforehand, and it fixes the regression experienced by Fortran, I'd be glad to just have it work.


Tested as indicated below, OK to commit? (needs a global reviewer; pretty pretty please, don't let it bitrot again)  I'd like to highlight that it's nothing conceptualy major, and it'll be easy to fix any eventual fallout.

FX




------------------

The attached patch fixes PR 42954: when Fortran moved to using libcpp directly from the front-end (instead of calling cc1 to do its preprocessing), we lost all target-specific CPP built-in macros. The issue is that part of the code in TARGET_OS_CPP_BUILTINS and TARGET_CPU_CPP_BUILTINS depends on C-only flags, and thus cannot be moved to a directory outside gcc/c-family/.

The patch moves this C-only code to specific TARGET_OS_CPP_BUILTINS_CFAMILY and TARGET_CPU_CPP_BUILTINS_CFAMILY macros. I manually audited all the targets in config/ twice, to check that I did not leave any code behind. I have bootstrapped and regtested an all-language compiler on x86_64-linux and i686-darwin. I have also built C and Fortran cross-compilers (make all-gcc && make fortran) for the following targets (which cover all gcc/config/ files changed):

avr-elf
frv-elf
spu-elf
i386-pc-netware
alpha-linux
alpha-dec-osf5.1
ia64-hpux
mips-linux
mips-sgi-irix6.5
hppa2.0w-hp-hpux11.00
sparc-sun-solaris2.10
i686-pc-mingw32
powerpc-darwin

In all cases, the cross-compiler built successfully and seemed to work. In each case, I checked a few of the target-specific macros (but did not check all of them).



Attachment: cpp-2.ChangeLog
Description: Binary data

Attachment: cpp-2.diff.txt
Description: Text document



OK to commit?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]