This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] PR18428: use libcpp for preprocessing (review of C/C++ and fortran maintainers needed)
I don't have the code around, but IIRC: the return value sets a
no_backend (or similar) variable in the driver. If 'false' is returned
the backend is initialized, otherwise not. In the latter case,
something somewhere crashed and gave an ICE.
OK, fine with me for now :)
I don't think we want to define __STDC_HOSTED__. On the other
hand, does
your patch still define the CPU, OS and OBJFMT builtins? (macros
TARGET_CPU_CPP_BUILTINS, TARGET_OS_CPP_BUILTINS and
TARGET_OBJFMT_CPP_BUILTINS) I think we should. Other macros that
we used to
emit and I think we will now miss include: __VERSION__,
[...] macros (which are I think potentially useful).
None of these are set. I went with the docs and only implemented those
mentioned. If we want all macros defined by gcc, we probably can
re-use their code.
Yes, that sounds like a good thing to do. Parts of our testsuite and
my own personal codes use CPU and OS macros for conditional
compilation, and I think they're good to have around.
+ /* Supply enough spaces to put this token in its original column,
+ one space per column greater than 2, since
scan_translation_unit
+ will provide a space if PREV_WHITE. Don't bother trying to
+ reconstruct tabs; we can't get it right in general, and
nothing
+ ought to care. Some things do care; the fault lies with
them. */
Can you expand a bit more here? What kind of thing will change or
be broken
exactly?
Errr, please ask the original author. I think, this was copied
verbatim from c-ppoutput.c :)
Yep, I thought that was the case... what I'm worried is that Fortran
isn't C, and tabs are special in Fortran. If you get some time to
check that basic things still work (accepted or rejected correctly),
that would be enough. Maybe it's already covered by the testsuite,
actually...
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/