Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Paul,

> Wouldn't it be easiest to simply stop the g77 driver passing 
> -ffixed-* to cc1 -E, using %<fixed-*.

> The patch below works for me, it prevents -ffixed-* being passed 
> to cc1 -E, but still passes them to f771.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are you sure that's true ?

When I tried that approach (which Steven Bosscher pointed out to me), I
couldn't get the -ffixed-<blah> being passed to f771.

Try this source:

$ cat aap.F
      PROGRAM AAP
#define PI 3.1415926535897932
      PARAMETER (PYECUBE = PI * PI * PI)
      END
$ g77 -ffixed-line-length-none aap.F

[note that we exceed the standard line end of column 72 here]

Thanks in advance,

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam
--------------------------------------------------------------
Zie ook/see also: http://www.knmi.nl/maildisclaimer.html 

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Paul Brook]

On Tuesday 18 February 2003 8:54 am, Toon Moene wrote:
> Paul,
>
> > Wouldn't it be easiest to simply stop the g77 driver passing
> > -ffixed-* to cc1 -E, using %<fixed-*.
> >
> > The patch below works for me, it prevents -ffixed-* being passed
> > to cc1 -E, but still passes them to f771.
>
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Are you sure that's true ?

Apparently not. I thought I'd checked that, but when I try it now it doesn't 
work:(

You could replace '%(cc1_options)' with
'%(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} \
 %{O*} %{undef}'
(taken from gcc.c, removing -f)

However this stops any -f options getting passed to the propocessor. AFAIK 
cc1 -E doesn't use any -f options anyway. Any -f options it does need could 
of course be added explicitly.

Paul

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Paul Brook wrote:-

> Apparently not. I thought I'd checked that, but when I try it now it doesn't 
> work:(
> 
> You could replace '%(cc1_options)' with
> '%(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} \
>  %{O*} %{undef}'
> (taken from gcc.c, removing -f)
> 
> However this stops any -f options getting passed to the propocessor. AFAIK 
> cc1 -E doesn't use any -f options anyway. Any -f options it does need could 
> of course be added explicitly.

Nope, cc1 -E uses all -f options.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Neil Booth wrote:

> Paul Brook wrote:-

>>Apparently not. I thought I'd checked that, but when I try it now it doesn't 
>>work:(
>>
>>You could replace '%(cc1_options)' with
>>'%(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} \
>> %{O*} %{undef}'
>>(taken from gcc.c, removing -f)
>>
>>However this stops any -f options getting passed to the propocessor. AFAIK 
>>cc1 -E doesn't use any -f options anyway. Any -f options it does need could 
>>of course be added explicitly.

> Nope, cc1 -E uses all -f options.

OK, that means that I have to go with your original suggestion; 
unfortunately, that one wasn't exactly clear to me - what function do I 
have to supply (and where ?) and what should it do ?

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> OK, that means that I have to go with your original suggestion; 
> unfortunately, that one wasn't exactly clear to me - what function do I 
> have to supply (and where ?) and what should it do ?
> 
> Thanks in advance,

I wrote a big comment in c-opts.c explaining how to add an option.
There are plenty of examples, too 8-)

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Neil Booth wrote:
> Toon Moene wrote:-

>>OK, that means that I have to go with your original suggestion; 
>>unfortunately, that one wasn't exactly clear to me - what function do I 
>>have to supply (and where ?) and what should it do ?

> I wrote a big comment in c-opts.c explaining how to add an option.
> There are plenty of examples, too 8-)

OK, do you mean I just have to "fake" -ffixed-line-length-<blah> being a 
"Only C" option ?  How does this cope with the fact that <blah> might be 
a number or "none" ?

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> >I wrote a big comment in c-opts.c explaining how to add an option.
> >There are plenty of examples, too 8-)
> 
> OK, do you mean I just have to "fake" -ffixed-line-length-<blah> being a 
> "Only C" option ?  How does this cope with the fact that <blah> might be 
> a number or "none" ?

Is there more than one -ffixed-?  If so, just add -ffixed- to take an
optional joined argument (CL_JOINED), and ignore it.  This kills all
the birds with one stone.

If we're just talking about -ffixed-line-length-, then do it for that
instead (best to be specific if there's just one switch, of course).

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

Neil Booth wrote:

> Is there more than one -ffixed-?  If so, just add -ffixed- to take an
> optional joined argument (CL_JOINED), and ignore it.  This kills all
> the birds with one stone.
> 
> If we're just talking about -ffixed-line-length-, then do it for that
> instead (best to be specific if there's just one switch, of course).

Apparently I still don't understand how this piece of c-opts.c works, 
because the attached patch doesn't solve the problem.

Thoughts ?

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

[-- Attachment #2: fixed.patch --]
[-- Type: text/plain, Size: 878 bytes --]

*** c-opts.c.orig	Tue Jan 28 23:51:27 2003
--- c-opts.c	Wed Feb 19 00:17:56 2003
*************** static void sanitize_cpp_opts PARAMS ((v
*** 213,216 ****
--- 213,218 ----
    OPT("fenum-int-equiv",	CL_CXX,   OPT_fenum_int_equiv)		     \
    OPT("fexternal-templates",	CL_CXX,   OPT_fexternal_templates)	     \
+   OPT("ffixed-form",		CL_C,	  OPT_ffixed_form)		     \
+   OPT("ffixed-line-length-",	CL_C | CL_JOINED, OPT_ffixed_line_length)    \
    OPT("ffor-scope",		CL_CXX,   OPT_ffor_scope)		     \
    OPT("ffreestanding",		CL_C,     OPT_ffreestanding)		     \
*************** c_common_decode_option (argc, argv)
*** 1143,1146 ****
--- 1145,1153 ----
        goto cp_deprecated;
  
+     case OPT_ffixed_form:
+     case OPT_ffixed_line_length:
+       /* Fortran front end options IGNORED.  */
+       break;
+ 
      case OPT_ffor_scope:
        flag_new_for_scope = on;

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> Neil Booth wrote:
> 
> >Is there more than one -ffixed-?  If so, just add -ffixed- to take an
> >optional joined argument (CL_JOINED), and ignore it.  This kills all
> >the birds with one stone.
> >
> >If we're just talking about -ffixed-line-length-, then do it for that
> >instead (best to be specific if there's just one switch, of course).
> 
> Apparently I still don't understand how this piece of c-opts.c works, 
> because the attached patch doesn't solve the problem.

How does it not work?

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Neil Booth wrote:

> Toon Moene wrote:-

> > Neil Booth wrote:
> >
> > >Is there more than one -ffixed-?  If so, just add -ffixed- to take
an
> > >optional joined argument (CL_JOINED), and ignore it.  This kills
all
> > >the birds with one stone.
> > >
> > >If we're just talking about -ffixed-line-length-, then do it for
that
> > >instead (best to be specific if there's just one switch, of
course).
> >
> > Apparently I still don't understand how this piece of c-opts.c
works,
> > because the attached patch doesn't solve the problem.
> 
> How does it not work?

cc1 still gives the warning:

unknown register: line-length-none.

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam
--------------------------------------------------------------
Zie ook/see also: http://www.knmi.nl/maildisclaimer.html 

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> > > Apparently I still don't understand how this piece of c-opts.c
> works,
> > > because the attached patch doesn't solve the problem.
> > 
> > How does it not work?
> 
> cc1 still gives the warning:
> 
> unknown register: line-length-none.

Hmm.  That's coming from something else; definitely not C switch
handling.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Neil Booth wrote:
> Toon Moene wrote:-
> 
> 
>>>>Apparently I still don't understand how this piece of c-opts.c
>>>
>>works,
>>
>>>>because the attached patch doesn't solve the problem.
>>>
>>>How does it not work?
>>
>>cc1 still gives the warning:
>>
>>unknown register: line-length-none.

> Hmm.  That's coming from something else; definitely not C switch
> handling.

Definitely.  So the question is: how do we prevent the passing on of 
this switch to the rest of cc1 in case cc1 is called with the -E switch ....

In f771, we just return -1 from ffe_decode_option - does that mean that 
setting `result' to -1 in c_common_decode_option will have the same effect ?

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> >Hmm.  That's coming from something else; definitely not C switch
> >handling.
> 
> Definitely.  So the question is: how do we prevent the passing on of 
> this switch to the rest of cc1 in case cc1 is called with the -E switch ....
> 
> In f771, we just return -1 from ffe_decode_option - does that mean that 
> setting `result' to -1 in c_common_decode_option will have the same effect ?

I don't understand the problem.  I thought the original problem was that
the C front end doesn't accept the switch.  So I tell you how to get it
to accept it.  Then you say the problem is that the C front end accepts
the switch?

The correct place to modify C front end options is the big table in
c-opts.c; nowhere else.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Geoff Keating]

Neil Booth <neil@daikokuya.co.uk> writes:

> Toon Moene wrote:-
> 
> > >Hmm.  That's coming from something else; definitely not C switch
> > >handling.
> > 
> > Definitely.  So the question is: how do we prevent the passing on of 
> > this switch to the rest of cc1 in case cc1 is called with the -E switch ....
> > 
> > In f771, we just return -1 from ffe_decode_option - does that mean that 
> > setting `result' to -1 in c_common_decode_option will have the same effect ?
> 
> I don't understand the problem.  I thought the original problem was that
> the C front end doesn't accept the switch.  So I tell you how to get it
> to accept it.  Then you say the problem is that the C front end accepts
> the switch?
> 
> The correct place to modify C front end options is the big table in
> c-opts.c; nowhere else.

The problem is that the C frontend accepts -ffixed-<regname>, not
-ffixed-line-length-<n> or -ffixed-form.  I await the day that some
chip has a register named 'form'...

We have a lot of problems in this area; for instance,
-dynamic can mean 'pass -dynamic to the linker' or 'please switch on
all these -d options'.  I'm not sure what can be done about it other
than a complete redesign of GCC's options handling.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Geoff Keating wrote:-

> > I don't understand the problem.  I thought the original problem was that
> > the C front end doesn't accept the switch.  So I tell you how to get it
> > to accept it.  Then you say the problem is that the C front end accepts
> > the switch?
> > 
> > The correct place to modify C front end options is the big table in
> > c-opts.c; nowhere else.
> 
> The problem is that the C frontend accepts -ffixed-<regname>, not
> -ffixed-line-length-<n> or -ffixed-form.  I await the day that some
> chip has a register named 'form'...
> 
> We have a lot of problems in this area; for instance,
> -dynamic can mean 'pass -dynamic to the linker' or 'please switch on
> all these -d options'.  I'm not sure what can be done about it other
> than a complete redesign of GCC's options handling.

Ah, I see.  Unless c-opts.c returns -1 then independent_decode_option
looks at it too, and gets confused.

This is easy to fix: handle them in c-opts.c so they set result to -1.
No?  Toon?

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Geoff Keating wrote:-

> We have a lot of problems in this area; for instance,
> -dynamic can mean 'pass -dynamic to the linker' or 'please switch on
> all these -d options'.  I'm not sure what can be done about it other
> than a complete redesign of GCC's options handling.

I intend to unify all switch handling in the front ends.  The driver
will remain a mess, but that's SPECS.  The technique of c-opts.c can
easily handle the whole compiler proper, in one place too.

It'll be one of the first things I do once I get my employer's
disclaimer.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

[  I'll take Paul out of the loop ]

Neil Booth wrote:

> Toon Moene wrote:

>>Definitely.  So the question is: how do we prevent the passing on of 
>>this switch to the rest of cc1 in case cc1 is called with the -E switch ....
>>
>>In f771, we just return -1 from ffe_decode_option - does that mean that 
>>setting `result' to -1 in c_common_decode_option will have the same effect ?

> I don't understand the problem.  I thought the original problem was that
> the C front end doesn't accept the switch.  So I tell you how to get it
> to accept it.  Then you say the problem is that the C front end accepts
> the switch?
> 
> The correct place to modify C front end options is the big table in
> c-opts.c; nowhere else.

OK - I start to see the mismatch in our descriptions what the problem is.

Prior to 3.3, preprocessing Fortran source (e.g., when the source file's 
name ends in .F) was taken care of by a separate preprocessor that 
*only* performed preprocessing.  So any option that didn't make sense to 
preprocessing was "automagically" ignored by this program.

Nowadays - i.e., from 3.3 onwards - preprocessing is performed by cc1 -E.

That in itself wouldn't be a problem, if not every option that's passed 
to g77 gets passed to *both* cc1 -E and f771 by virtue of the way specs 
is written.

f771 knows that it shouldn't hand down -ffixed-form and 
-ffixed-line-length-<blah> options to other option processors, because 
they only have a definite meaning to the Fortran front end, and would 
give rise to spurious "unknown register: form" messages if not stopped 
short in the option processing for Fortran.

Now what I want to accomplish is to teach cc1 the same.  In fact, it 
would only be necessary to teach cc1 if -E is specified, but it probably 
won't hurt to simply prevent passing -ffixed-form and 
-ffixed-line-length-<blah> downwards to other option processors.

Hope this explanation helps,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> Now what I want to accomplish is to teach cc1 the same.  In fact, it 
> would only be necessary to teach cc1 if -E is specified, but it probably 
> won't hurt to simply prevent passing -ffixed-form and 
> -ffixed-line-length-<blah> downwards to other option processors.
> 
> Hope this explanation helps,

Yeah, sorry, I didn't realise toplev.c wanted to jump in too.

What I mentioned in the other mail should work.  Whatever your original
c-opts.c patch was  probably just needs one extra line:

	case OPT_ffixed:
+	result = -1;
	break;
	
Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

Neil Booth wrote:

> Ah, I see.  Unless c-opts.c returns -1 then independent_decode_option
> looks at it too, and gets confused.
> 
> This is easy to fix: handle them in c-opts.c so they set result to -1.
> No?  Toon?

I'll try that route.  Results tomorrow morning ...

Thanks,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Neil Booth wrote:-

> Toon Moene wrote:-
> 
> > Now what I want to accomplish is to teach cc1 the same.  In fact, it 
> > would only be necessary to teach cc1 if -E is specified, but it probably 
> > won't hurt to simply prevent passing -ffixed-form and 
> > -ffixed-line-length-<blah> downwards to other option processors.
> > 
> > Hope this explanation helps,
> 
> Yeah, sorry, I didn't realise toplev.c wanted to jump in too.
> 
> What I mentioned in the other mail should work.  Whatever your original
> c-opts.c patch was  probably just needs one extra line:
> 
> 	case OPT_ffixed:
> +	result = -1;
> 	break;

But that'll stop -ffixed-<reg> working for C compilations.

We really want

	if (fortran)
	  result = -1;

but we don't have such a flag.  I've no good ideas I'm afraid.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

> We really want
>
> 	if (fortran)
> 	  result = -1;
>
> but we don't have such a flag.  I've no good ideas I'm afraid.

if (-E switch) result = -1; 

?

zw

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[snyder]

hi -

FYI -- here's the workaround for this problem that i've been using
in my local tree.  I thought that this was too ugly to propose as a fix ---
but since nothing better has come up, i figured i'd pass this along.
sss

Index: gcc/f/lang-specs.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/f/lang-specs.h,v
retrieving revision 1.37
diff -u -p -r1.37 lang-specs.h
--- gcc/f/lang-specs.h	26 Jan 2003 19:26:35 -0000	1.37
+++ gcc/f/lang-specs.h	20 Feb 2003 01:47:06 -0000
@@ -29,7 +29,7 @@ the Free Software Foundation, 59 Temple 
   {".fpp", "@f77-cpp-input", 0},
   {".FPP", "@f77-cpp-input", 0},
   {"@f77-cpp-input",
-   "cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options) \
+   "cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN %:clean-f(%(cpp_options)) \
         %{E|M|MM:%(cpp_debug_options)}\
         %{!M:%{!MM:%{!E: %|.f |\n\
     f771 %|.f %(cc1_options) %{I*} %{!fsyntax-only:%(invoke_as)}}}}", 0},
Index: gcc/f/g77spec.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/f/g77spec.c,v
retrieving revision 1.40
diff -u -p -r1.40 g77spec.c
--- gcc/f/g77spec.c	16 Dec 2002 18:22:28 -0000	1.40
+++ gcc/f/g77spec.c	20 Feb 2003 01:47:14 -0000
@@ -96,6 +96,9 @@ static void lookup_option PARAMS ((Optio
 				   const char *));
 static void append_arg PARAMS ((const char *));
 
+static const char*
+clean_f_spec_function PARAMS ((int argc, const char** argv));
+
 /* The new argument list will be built here.  */
 static int g77_newargc;
 static const char **g77_newargv;
@@ -556,6 +559,36 @@ or type the command `info -f g77 Copying
   *in_argv = g77_newargv;
 }
 
+
+static const char*
+clean_f_spec_function (argc, argv)
+     int argc;
+     const char** argv;
+{
+  int totlen = 0;
+  int i;
+  char* ret;
+  for (i=0; i < argc; i++)
+    totlen += strlen (argv[i]) + 1;
+  ret = xmalloc (totlen + 1);
+  ret[0] = '\0';
+  for (i=0; i < argc; i++) {
+    if (strcmp (argv[i], "-") == 0) {
+      if (i < argc-1 && strncmp (argv[i+1], "ffixed", 6) == 0) {
+        ++i;
+        continue;
+      }
+      strcat (ret, "-");
+    }
+    else {
+      strcat (ret, argv[i]);
+      strcat (ret, " ");
+    }
+  }
+  return ret;
+}
+
+
 /* Called before linking.  Returns 0 on success and -1 on failure. */
 int lang_specific_pre_link ()  /* Not used for F77. */
 {
@@ -568,5 +601,6 @@ int lang_specific_extra_outfiles = 0;  /
 /* Table of language-specific spec functions.  */ 
 const struct spec_function lang_specific_spec_functions[] =
 {
+  { "clean-f",  clean_f_spec_function},
   { 0, 0 }
 };

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Zack Weinberg wrote:-

> Neil Booth <neil@daikokuya.co.uk> writes:
> 
> > We really want
> >
> > 	if (fortran)
> > 	  result = -1;
> >
> > but we don't have such a flag.  I've no good ideas I'm afraid.
> 
> if (-E switch) result = -1; 

Yes, that should work given that -E is passed first by the driver.

I was going to suggest re-introducing -lang-fortran, but I prefer your
idea.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

Neil Booth wrote:

> What I mentioned in the other mail should work.  Whatever your original
> c-opts.c patch was  probably just needs one extra line:
> 
> 	case OPT_ffixed:
> +	result = -1;
> 	break;

OK, the following patch works, bootstrapped on 
powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?

Thanks,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

[-- Attachment #2: fixed.patch --]
[-- Type: text/plain, Size: 1089 bytes --]

2003-02-20  Toon Moene  <toon@moene.indiv.nluug.nl>

	PR fortran/9038
	* c-opts.c (sanitize_cpp_opts): Add Fortran front end
	options to be ignored.
	(c_common_decode_option): Ignore them.

*** c-opts.c.orig	Tue Jan 28 23:51:27 2003
--- c-opts.c	Wed Feb 19 22:18:51 2003
*************** static void sanitize_cpp_opts PARAMS ((v
*** 213,216 ****
--- 213,218 ----
    OPT("fenum-int-equiv",	CL_CXX,   OPT_fenum_int_equiv)		     \
    OPT("fexternal-templates",	CL_CXX,   OPT_fexternal_templates)	     \
+   OPT("ffixed-form",		CL_C,	  OPT_ffixed_form)		     \
+   OPT("ffixed-line-length-",	CL_C | CL_JOINED, OPT_ffixed_line_length)    \
    OPT("ffor-scope",		CL_CXX,   OPT_ffor_scope)		     \
    OPT("ffreestanding",		CL_C,     OPT_ffreestanding)		     \
*************** c_common_decode_option (argc, argv)
*** 1143,1146 ****
--- 1145,1154 ----
        goto cp_deprecated;
  
+     case OPT_ffixed_form:
+     case OPT_ffixed_line_length:
+       /* Fortran front end options IGNORED.  */
+       result = -1;
+       break;
+ 
      case OPT_ffor_scope:
        flag_new_for_scope = on;

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> Neil Booth wrote:
> 
> >What I mentioned in the other mail should work.  Whatever your original
> >c-opts.c patch was  probably just needs one extra line:
> >
> >	case OPT_ffixed:
> >+	result = -1;
> >	break;
> 
> OK, the following patch works, bootstrapped on 
> powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?

No it doesn't work, as I explained.  You should do what Zack suggested.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Daniel Jacobowitz]

On Thu, Feb 20, 2003 at 06:51:16AM +0000, Neil Booth wrote:
> Toon Moene wrote:-
> 
> > Neil Booth wrote:
> > 
> > >What I mentioned in the other mail should work.  Whatever your original
> > >c-opts.c patch was  probably just needs one extra line:
> > >
> > >	case OPT_ffixed:
> > >+	result = -1;
> > >	break;
> > 
> > OK, the following patch works, bootstrapped on 
> > powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?
> 
> No it doesn't work, as I explained.  You should do what Zack suggested.

Neil,

Actually, if you read Toon's patch, I believe it will work.  He didn't
do what you suggested above; he added two new options instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Daniel Jacobowitz wrote:-

> > > OK, the following patch works, bootstrapped on 
> > > powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?
> > 
> > No it doesn't work, as I explained.  You should do what Zack suggested.
> 
> Neil,
> 
> Actually, if you read Toon's patch, I believe it will work.  He didn't
> do what you suggested above; he added two new options instead.

Indeed.  Sorry Toon; feel free to apply to 3.4.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Mark Mitchell]

--On Thursday, February 20, 2003 08:06:03 PM +0000 Neil Booth 
<neil@daikokuya.co.uk> wrote:

> Daniel Jacobowitz wrote:-
>
>> > > OK, the following patch works, bootstrapped on
>> > > powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark)
>> > > ?
>> >
>> > No it doesn't work, as I explained.  You should do what Zack suggested.
>>
>> Neil,
>>
>> Actually, if you read Toon's patch, I believe it will work.  He didn't
>> do what you suggested above; he added two new options instead.
>
> Indeed.  Sorry Toon; feel free to apply to 3.4.

And to 3.3.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> Yep, I like Zack's suggestion (even considering your later e-mail to me 
> personally).
> 
> The following attached patch implements it; bootstrapped and make -k 
> check'd (C and Fortran) on powerpc-unknown-linux-gnu.
> 
> OK this way ?

Of course!

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

Neil Booth wrote:

> Toon Moene wrote:

>>Neil Booth wrote:

>>>What I mentioned in the other mail should work.  Whatever your original
>>>c-opts.c patch was  probably just needs one extra line:
>>>
>>>	case OPT_ffixed:
>>>+	result = -1;
>>>	break;
>>
>>OK, the following patch works, bootstrapped on 
>>powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?

> No it doesn't work, as I explained.  You should do what Zack suggested.

Yep, I like Zack's suggestion (even considering your later e-mail to me 
personally).

The following attached patch implements it; bootstrapped and make -k 
check'd (C and Fortran) on powerpc-unknown-linux-gnu.

OK this way ?

Thanks,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

[-- Attachment #2: fixed.patch --]
[-- Type: text/plain, Size: 1168 bytes --]

2003-02-20  Toon Moene  <toon@moene.indiv.nluug.nl>

	PR fortran/9038
	* c-opts.c (sanitize_cpp_opts): Add Fortran front end
	options to be ignored.
	(c_common_decode_option): Ignore them when preprocessing.

*** c-opts.c.orig	Tue Jan 28 23:51:27 2003
--- c-opts.c	Thu Feb 20 17:57:58 2003
*************** static void sanitize_cpp_opts PARAMS ((v
*** 213,216 ****
--- 213,218 ----
    OPT("fenum-int-equiv",	CL_CXX,   OPT_fenum_int_equiv)		     \
    OPT("fexternal-templates",	CL_CXX,   OPT_fexternal_templates)	     \
+   OPT("ffixed-form",		CL_C,	  OPT_ffixed_form)		     \
+   OPT("ffixed-line-length-",	CL_C | CL_JOINED, OPT_ffixed_line_length)    \
    OPT("ffor-scope",		CL_CXX,   OPT_ffor_scope)		     \
    OPT("ffreestanding",		CL_C,     OPT_ffreestanding)		     \
*************** c_common_decode_option (argc, argv)
*** 1143,1146 ****
--- 1145,1155 ----
        goto cp_deprecated;
  
+     case OPT_ffixed_form:
+     case OPT_ffixed_line_length:
+       /* Fortran front end options ignored when preprocessing only.  */
+       if (flag_preprocess_only)
+         result = -1;
+       break;
+ 
      case OPT_ffor_scope:
        flag_new_for_scope = on;

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Mark Mitchell]

--On Thursday, February 20, 2003 10:16:05 PM +0100 Toon Moene 
<toon@moene.indiv.nluug.nl> wrote:

> Neil Booth wrote:
>
>> Toon Moene wrote:
>
>>> Neil Booth wrote:
>
>>>> What I mentioned in the other mail should work.  Whatever your original
>>>> c-opts.c patch was  probably just needs one extra line:
>>>>
>>>>	case OPT_ffixed:
>>>> +	result = -1;
>>>>	break;
>>>
>>> OK, the following patch works, bootstrapped on
>>> powerpc-unknown-linux-gnu.  Is this OK for 3.4 (Neil) and 3.3 (Mark) ?
>
>> No it doesn't work, as I explained.  You should do what Zack suggested.
>
> Yep, I like Zack's suggestion (even considering your later e-mail to me
> personally).
>
> The following attached patch implements it; bootstrapped and make -k
> check'd (C and Fortran) on powerpc-unknown-linux-gnu.
>
> OK this way ?

Yup.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Paul Brook wrote:-

> Wouldn't it be easiest to simply stop the g77 driver passing -ffixed-* to 
> cc1 -E, using %<fixed-*.
> 
> The patch below works for me, it prevents -ffixed-* being passed to cc1 -E, 
> but still passes them to f771.

Certainly, I wasn't aware that was possible.  It's up to Toon to review
your patch.

Neil.

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Paul Brook]

On Monday 17 February 2003 8:49 pm, Toon Moene wrote:
> L.S.,
>
> [ cc'd to Neil because he's the cc -E expert ]
<snip>
> However, as shown above, cc1 -E -ffixed-line-length-none will provoke
> the warning message, which is bogus, because cc1 -E has no valid
> interpretation for -ffixed-<anything> anyway - it should just run the
> preprocessor !
>
> How do we get rid of the inappropriate "consumption" of
> -ffixed-<anything> options by cc1 -E ?
>
> Any insight appreciated.

Wouldn't it be easiest to simply stop the g77 driver passing -ffixed-* to 
cc1 -E, using %<fixed-*.

The patch below works for me, it prevents -ffixed-* being passed to cc1 -E, 
but still passes them to f771.

Paul Brook

Index: lang-specs.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/f/lang-specs.h,v
retrieving revision 1.32.2.5
diff -c -3 -p -r1.32.2.5 lang-specs.h
*** lang-specs.h	3 Feb 2003 17:09:18 -0000	1.32.2.5
--- lang-specs.h	17 Feb 2003 23:43:09 -0000
*************** the Free Software Foundation, 59 Temple 
*** 29,35 ****
    {".fpp", "@f77-cpp-input", 0},
    {".FPP", "@f77-cpp-input", 0},
    {"@f77-cpp-input",
!    "cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN %(cpp_options) \
          %{E|M|MM:%(cpp_debug_options)}\
          %{!M:%{!MM:%{!E: %|.f |\n\
      f771 %|.f %(cc1_options) %{I*} %{!fsyntax-only:%(invoke_as)}}}}", 0},
--- 29,35 ----
    {".fpp", "@f77-cpp-input", 0},
    {".FPP", "@f77-cpp-input", 0},
    {"@f77-cpp-input",
!    "cc1 -E -traditional-cpp -D_LANGUAGE_FORTRAN %<ffixed-* %(cpp_options) 
\
          %{E|M|MM:%(cpp_debug_options)}\
          %{!M:%{!MM:%{!E: %|.f |\n\
      f771 %|.f %(cc1_options) %{I*} %{!fsyntax-only:%(invoke_as)}}}}", 0},

Re: PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Neil Booth]

Toon Moene wrote:-

> $ g77 -ffixed-line-length-none aap.F
> cc1: warning: unknown register name: line-length-none
> 
> However, f771 accepts this compiler option, as you can deduce from the 
> silence after the cc1 warning.
> 
> The cc1 warning is caused by the fact that source files ending in .F (as 
>  opposed to .f) require preprocessing by the C preprocessor.  As of 3.3 
> this is implemented by calling cc1 -E on the source file and passing the 
> result on to f771.
> 
> However, as shown above, cc1 -E -ffixed-line-length-none will provoke 
> the warning message, which is bogus, because cc1 -E has no valid 
> interpretation for -ffixed-<anything> anyway - it should just run the 
> preprocessor !
> 
> How do we get rid of the inappropriate "consumption" of 
> -ffixed-<anything> options by cc1 -E ?

The driver passes anything with -f to cc1.  You will need to add a dummy
handler to c-opts.c, unfortunately.

Neil.

PR fortran/9038, a regression in 3.3/3.4 with respect to 3.2.

[Toon Moene]

L.S.,

[ cc'd to Neil because he's the cc -E expert ]

PR fortran/9038 is about the following:

Given

$ cat aap.F  # Note uppercase .F
       SUBROUTINE AAP
       END

we get the following when compiling:

$ g77 -ffixed-line-length-none aap.F
cc1: warning: unknown register name: line-length-none

However, f771 accepts this compiler option, as you can deduce from the 
silence after the cc1 warning.

The cc1 warning is caused by the fact that source files ending in .F (as 
  opposed to .f) require preprocessing by the C preprocessor.  As of 3.3 
this is implemented by calling cc1 -E on the source file and passing the 
result on to f771.

However, as shown above, cc1 -E -ffixed-line-length-none will provoke 
the warning message, which is bogus, because cc1 -E has no valid 
interpretation for -ffixed-<anything> anyway - it should just run the 
preprocessor !

How do we get rid of the inappropriate "consumption" of 
-ffixed-<anything> options by cc1 -E ?

Any insight appreciated.

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)