Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

[neil]

Synopsis: [DJGPP] preprocessing fortran files by cpp with extension .f

State-Changed-From-To: analyzed->closed
State-Changed-By: neil
State-Changed-When: Thu Jun 20 16:03:46 2002
State-Changed-Why:
    This is fixed for 3.2; tradcpp0 is dead (yeh!) and the compiler now does all the preprocessing work, including -remap.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4789

Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

[Andris Pavenis]

The following reply was made to PR target/4789; it has been noted by GNATS.

From: Andris Pavenis <pavenis@latnet.lv>
To: Neil Booth <neil@daikokuya.demon.co.uk>, djgpp-workers@delorie.com
Cc: neil@gcc.gnu.org, bonner@ivp.bepr.ethz.ch, gcc-bugs@gcc.gnu.org,
   toon@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f
Date: Wed, 9 Jan 2002 09:45:08 +0200

 On Tuesday 08 January 2002 20:42, Neil Booth wrote:
 > Andris Pavenis wrote:-
 >
 > > The problem appears when -remap is used in specs in cpp_options.
 > > cpp_options settings are common for both tradcpp0 and cpp0. For DJGPP=
  we
 > > need -remap to avoid need to use changed names of include files (DJGP=
 P
 > > can be used under plain MS-DOS when we only have 8+3 filename
 > > limitations). -remap is not recognized by tradcpp0 as valid option.
 > > Unfortunatelly tradcpp0 and cpp0 are used also directly in specs not =
 only
 > > through trad_capable_cpp (otherwise I could change there)
 >
 > Are you saying that getting tradcpp to recognize and ignore -remap
 > would fix it?  Or does tradcpp require a -remap implementation?
 
 The best would be of course the real implementation of -remap in tradcpp0=
 =2E
 However I think even ignoring it silently in tradcpp0 could be Ok at leas=
 t now
 
 C : option -traditional is unusable for DJGPP as header files are incompa=
 tible with it,=20
 so no additional harm from silently ignoring this option in tradcpp0
 
 C++ :  doesn't use tradcpp0 as far as I looked and I really used -remap
 to workaround filename conflicts for libstdc++ header files under plain D=
 OS.
 
 Fortran: here we have some trouble as for FORTRAN tradcpp0 is used=20
 unconditionally. However there should be no harm from ignoring -remap unl=
 ess user=20
 explicitly tries to remap file names to be included
 =20
 So I think it would be sufficient to ignore -remap in tradcpp0 now and ad=
 d=20
 FIXME note there, to remaind about that, so maybe somebody could add supp=
 ort
 in future
 
 >
 > > I tried to fix that for DJGPP port of gcc-3.0.3, but it required to
 > > add options specially for cpp0 only (not for tradcpp0) and to use
 > > this new spec where needed (in cp/lang-specs.h and f/lang-specs.h,
 > > gcc.c, etc)
 >
 > What exactly did you do?
 >
 
 I added cpp0_only_options and used this spec where needed. I'm including =
 diffs
 against trunk for common files (except DJGPP target related ones). Unfort=
 unatelly=20
 I haven't write update for documentation ...
 
 There could be some shift in diffs as I removed unrelated changes for gcc=
 =2Ec with text editor
 
 Andris
 
 --- gcc.c.orig=09Thu Jan  3 04:01:24 2002
 +++ gcc.c=09Mon Jan  7 14:06:44 2002
 @@ -531,6 +538,11 @@
  #define CPP_SPEC ""
  #endif
 =20
 +/* This is for preprocessor options which don't work with tradcpp0  */
 +#ifndef CPP0_ONLY_OPTIONS
 +#define CPP0_ONLY_OPTIONS ""
 +#endif
 +
  /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
     or extra switch-translations.  */
  #ifndef CC1_SPEC
 @@ -663,6 +675,7 @@
  static const char *linker_name_spec =3D LINKER_NAME;
  static const char *link_command_spec =3D LINK_COMMAND_SPEC;
  static const char *link_libgcc_spec =3D LINK_LIBGCC_SPEC;
 +static const char *cpp0_only_options =3D CPP0_ONLY_OPTIONS;
 =20
  /* Standard options to cpp, cc1, and as, to reduce duplication in specs.
     There should be no need to override these in target dependent files,
 @@ -671,7 +684,8 @@
     appropriate -B options.  */
 =20
  static const char *trad_capable_cpp =3D
 -"%{traditional|ftraditional|traditional-cpp:trad}cpp0";
 +"%{traditional|ftraditional|traditional-cpp:trad}cpp0 \
 + %{!traditional:%{!ftraditional:%{!traditional-cpp:%(cpp0_only_options)}=
 }}";
 =20
  static const char *cpp_options =3D
  "%{C:%{!E:%eGNU C does not support -C without using -E}}\
 @@ -840,7 +854,8 @@
  =09=09tradcpp0 -lang-c %{ansi:-std=3Dc89} %(cpp_options) %{!pipe:%g.i} |=
 \n\
  =09=09    cc1 -fpreprocessed %{!pipe:%g.i} %(cc1_options)}\
  =09    %{!traditional:%{!ftraditional:%{!traditional-cpp:\
 -=09=09cc1 -lang-c %{ansi:-std=3Dc89} %(cpp_options) %(cc1_options)}}}}\
 +=09=09cc1 -lang-c %{ansi:-std=3Dc89} %(cpp0_only_options) %(cpp_options)=
  \
 +=09=09    %(cc1_options)}}}}\
          %{!fsyntax-only:%(invoke_as)}}}}", 0},
    {"-",
     "%{!E:%e-E required when input is from standard input}\
 @@ -1369,6 +1389,7 @@
    INIT_STATIC_SPEC ("cpp",=09=09=09&cpp_spec),
    INIT_STATIC_SPEC ("cpp_options",=09=09&cpp_options),
    INIT_STATIC_SPEC ("trad_capable_cpp",=09=09&trad_capable_cpp),
 +  INIT_STATIC_SPEC ("cpp0_only_options", =09&cpp0_only_options),
    INIT_STATIC_SPEC ("cc1",=09=09=09&cc1_spec),
    INIT_STATIC_SPEC ("cc1_options",=09=09&cc1_options),
    INIT_STATIC_SPEC ("cc1plus",=09=09=09&cc1plus_spec),
 --- cp/lang-specs.h.orig=09Sat Jul 21 04:00:44 2001
 +++ cp/lang-specs.h=09Thu Dec  6 13:52:02 2001
 @@ -39,7 +39,8 @@
         %{!Wno-deprecated:-D__DEPRECATED}\
         %{!fno-exceptions:-D__EXCEPTIONS}\
         -D__GXX_ABI_VERSION=3D100\
 -       %{ansi:-D__STRICT_ANSI__ -trigraphs -$} %(cpp_options)}\
 +       %{ansi:-D__STRICT_ANSI__ -trigraphs -$} %(cpp0_only_options) \
 +       %(cpp_options)}\
       %{!E:%{!M:%{!MM:\
         %{save-temps:cpp0 -lang-c++ \
  =09=09    %{!no-gcc:-D__GNUG__=3D%v1}\
 @@ -47,9 +48,9 @@
  =09=09    %{!fno-exceptions:-D__EXCEPTIONS}\
  =09=09    -D__GXX_ABI_VERSION=3D100\
  =09=09    %{ansi:-D__STRICT_ANSI__ -trigraphs -$}\
 -=09=09    %(cpp_options) %b.ii \n}\
 +=09=09     %(cpp0_only_options) %(cpp_options) %b.ii \n}\
        cc1plus %{save-temps:-fpreprocessed %b.ii}\
 -              %{!save-temps:%(cpp_options)\
 +              %{!save-temps: %(cpp0_only_options) %(cpp_options)\
  =09=09=09    %{!no-gcc:-D__GNUG__=3D%v1} \
         =09=09=09    %{!Wno-deprecated:-D__DEPRECATED}\
  =09=09=09    %{!fno-exceptions:-D__EXCEPTIONS}\

Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

[Neil Booth]

The following reply was made to PR target/4789; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Andris Pavenis <pavenis@latnet.lv>
Cc: neil@gcc.gnu.org, bonner@ivp.bepr.ethz.ch, gcc-bugs@gcc.gnu.org,
	toon@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f
Date: Tue, 8 Jan 2002 18:42:31 +0000

 Andris Pavenis wrote:-
 
 > The problem appears when -remap is used in specs in cpp_options. cpp_options
 > settings are common for both tradcpp0 and cpp0. For DJGPP we need -remap
 > to avoid need to use changed names of include files (DJGPP can be used under
 > plain MS-DOS when we only have 8+3 filename limitations). -remap is not 
 > recognized by tradcpp0 as valid option. Unfortunatelly tradcpp0 and cpp0 are
 > used also directly in specs not only through trad_capable_cpp (otherwise I 
 > could change there)
 
 Are you saying that getting tradcpp to recognize and ignore -remap
 would fix it?  Or does tradcpp require a -remap implementation?
 
 > I tried to fix that for DJGPP port of gcc-3.0.3, but it required to
 > add options specially for cpp0 only (not for tradcpp0) and to use
 > this new spec where needed (in cp/lang-specs.h and f/lang-specs.h,
 > gcc.c, etc)
 
 What exactly did you do?
 
 Neil.

Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

[Andris Pavenis]

The following reply was made to PR target/4789; it has been noted by GNATS.

From: Andris Pavenis <pavenis@latnet.lv>
To: neil@gcc.gnu.org, bonner@ivp.bepr.ethz.ch, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, toon@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f
Date: Tue, 8 Jan 2002 13:14:43 +0200

 On Tuesday 08 January 2002 12:26, neil@gcc.gnu.org wrote:
 > Synopsis: [DJGPP] preprocessing fortran files by cpp with extension .f
 >
 > Responsible-Changed-From-To: toon->unassigned
 > Responsible-Changed-By: neil
 > Responsible-Changed-When: Tue Jan  8 02:26:30 2002
 > Responsible-Changed-Why:
 >     Not a fortran issue per-se; a target-specific packaging issue
 >     I think.
 >
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&databas=
 e=3Dgcc&
 >pr=3D4789
 
 The problem appears when -remap is used in specs in cpp_options. cpp_opti=
 ons
 settings are common for both tradcpp0 and cpp0. For DJGPP we need -remap
 to avoid need to use changed names of include files (DJGPP can be used un=
 der
 plain MS-DOS when we only have 8+3 filename limitations). -remap is not=20
 recognized by tradcpp0 as valid option. Unfortunatelly tradcpp0 and cpp0 =
 are
 used also directly in specs not only through trad_capable_cpp (otherwise =
 I=20
 could change there)
 
 I tried to fix that for DJGPP port of gcc-3.0.3, but it required to add=20
 options specially for cpp0 only (not for tradcpp0) and to use this new sp=
 ec=20
 where needed  (in cp/lang-specs.h and f/lang-specs.h, gcc.c, etc)
 
 Andris
 
 

Re: target/4789: [DJGPP] preprocessing fortran files by cpp with extension .f

[neil]

Synopsis: [DJGPP] preprocessing fortran files by cpp with extension .f

Responsible-Changed-From-To: toon->unassigned
Responsible-Changed-By: neil
Responsible-Changed-When: Tue Jan  8 02:26:30 2002
Responsible-Changed-Why:
    Not a fortran issue per-se; a target-specific packaging issue
    I think.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4789