[patch, fortran] PR18428: use libcpp for preprocessing (review of C/C++ and fortran maintainers needed)

[Daniel Franke]

Follow-up to:
	http://gcc.gnu.org/ml/fortran/2008-05/msg00039.htm

On Sunday 04 May 2008 17:29:52 FX wrote:
> The Fortran parts are OK provided you answer the questions below and:
>    -- provide a patch for the news page (http://gcc.gnu.org/gcc-4.4/
> changes.html),
>    -- rewrite the doc for preprocessing (http://gcc.gnu.org/
> onlinedocs/gfortran/Preprocessing-and-conditional-compilation.html);

See additional mail for the doc/wwwdocs changes.
Questions are answered below.


> > @@ -354,6 +357,9 @@ gfc_post_options (const char **pfilename
> > +/* FIXME: return gfc_cpp_preprocess_only (); */
> I don't understand this FIXME: why should we do that? And why isn't
> it done here?

Added the explanation given in the mail cited above to the comment.


> > +d
> > +Fortran Joined
> > +-d[DIMN]	Dump details about macro names and definitions during
> > preprocessing
>
> Aren't you missing the 'U' in that list?

Yes. The patch was also lacking handling of 'U' - added.


> > +/* Objects defined in libcpp:  */
> > +static cpp_options *cpp_option = NULL;
> > +static cpp_reader *cpp_in = NULL;
>
> [...] another wording would be clearer.

This now reads: "/* Structures used with libcpp:  */"


> > +  /* Initialize CPP built-ins; '1' corresponds to 'flag_hosted'
> > +     in C, defines __STDC_HOSTED__?!  */
> > +  cpp_init_builtins (cpp_in, 1);
>
> 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__, _LP64
> and __LP64__, __OPTIMIZE_SIZE__, __OPTIMIZE__, __FAST_MATH__,
> __SUPPORT_SNAN__, __FINITE_MATH_ONLY__, __pic__, __PIC__, __pie__,
> __PIE__, and the __SIZEOF_*__ macros (which are I think potentially
> useful).

I don't know what __STDC_HOSTED__ is used for, but cpp_init_builtins() defines 
it by default. Added as much as of the other macros as I could. See 
cpp_define_builtins() for more specific information. 

Please note that due to __SIZEOF_*, the initializaiton sequence had to 
reorganized slightly. The way it was, *_type_node were not initialized 
properly before using them in cpp_init_builtins().


> > +  if (gfc_cpp_option.working_directory
> > +      && gfc_cpp_option.preprocess_only && !
> > gfc_cpp_option.no_line_commands)
> > +    pp_dir_change (cpp_in, get_src_pwd ());
>
> I don't understand why it only happens with
> gfc_cpp_option.preprocess_only: what happens to debugging
> information? The documentation says that "This option is implicitly
> enabled if debugging information is enabled", is this also the case
> here?

No. I missed that completly; c-opts (sanitize_cpp_opts) had the corresponding 
snippet which I added to cpp.c (gfc_cpp_post_options). Thanks for catching 
this!


Attached update of the Fortran side of the previous patch not only fixes FX' 
requests, but also adds yet another option, namely -nocpp. Tobias B. asked 
for this as a possibility to disable preprocessing if it would otherwise be 
enabled by the respective file extensions.

Btw, the C-side of things still needs reviewing. Condensed patch:
	http://gcc.gnu.org/ml/fortran/2008-05/msg00248.html
	
Bootstrapped and regression tested on i686-pc-linux-gnu. Ok for trunk?

Regards

	Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr18428-2.diff
Type: text/x-diff
Size: 36268 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20080521/b4e34adf/attachment.bin>