Bug 13464

Confirmed.

Subject: Re:  New: [gfortran options] -d8, -i8 and -r8 not passed correctly to compiler proper.

toon at moene dot indiv dot nluug dot nl wrote:-

> The Fortran options -d8, -i8 and -r8 are not passed to f951 correctly.
> 
> The option processor thinks that -d8 is a form of the -d dump options, in spite
> of the fact that there is no such  -d8 option.  -i8 is simply consumed without
> ever resurfacing. -r8 is simply an `unrecognized option'.
> 
> I tried to debug this, but got lost in all the routines that look at or mangle
> the options.  However, one thing is clear:
> 
> In options.c we find:
> 
>   { "-d8",
>     N_("Set the default real and integer kinds to double precision"),
>     OPT_d, 2, CL_F95 | CL_REJECT_NEGATIVE },
>     ^^^^^ this is wrong.

I don't believe I introduced this problem; indeed this switch is new to
me.  I suggest you speak to the g95 people.

Neil.

Well, this is the relevant content of fortran/lang.opt:

d8
F95 RejectNegative
Set the default real and integer kinds to double precision

That's, as far as I can see, correct.

Subject: Re:  [gfortran options] -d8, -i8 and -r8 not passed correctly to compiler proper.

toon at moene dot indiv dot nluug dot nl wrote:-

> 
> ------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2003-12-22 23:22 -------
> Well, this is the relevant content of fortran/lang.opt:
> 
> d8
> F95 RejectNegative
> Set the default real and integer kinds to double precision
> 
> That's, as far as I can see, correct.

RejectNegative only applies to -f and -W switches, but it shouldn't
hurt.  You need to figure out why this is being converted to OPT_d
rather than OPT_d8 by opts.sh.

Neil.

Isn't this caused by the following in opts.sh

            # If this switch takes joined arguments, back-chain all
            # subsequent switches to it for which it is a prefix.  If
            # a later switch S is a longer prefix of a switch T, T
            # will be back-chained to S in a later iteration of this
            # for() loop, which is what we want.
            if (flags[i] ~ "Joined") {
                for (j = i + 1; j < n_opts; j++) {
                    if (substr (opts[j], 1, len) != opts[i])
                        break;
                    back_chain[j] = enum;
                }
            }

and is this really what we want ?

Subject: Re:  [gfortran options] -d8, -i8 and -r8 not passed correctly to compiler proper.

toon at moene dot indiv dot nluug dot nl wrote:-

> 
> ------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2003-12-23 12:59 -------
> Isn't this caused by the following in opts.sh
> 
>             # If this switch takes joined arguments, back-chain all
>             # subsequent switches to it for which it is a prefix.  If
>             # a later switch S is a longer prefix of a switch T, T
>             # will be back-chained to S in a later iteration of this
>             # for() loop, which is what we want.
>             if (flags[i] ~ "Joined") {
>                 for (j = i + 1; j < n_opts; j++) {
>                     if (substr (opts[j], 1, len) != opts[i])
>                         break;
>                     back_chain[j] = enum;
>                 }
>             }
> 
> and is this really what we want ?

I believe this is what we want.  -d8 shouldn't be Joined though.

Neil.

> I believe this is what we want.  -d8 shouldn't be Joined though.

Well, yes, obviously - unfortunately, it *is*:

"a prefix [for -d<letters>]"

and therefore eaten (while it shouldn't, because '8' isn't one of the <letters>).

Subject: Re:  [gfortran options] -d8, -i8 and -r8 not passed correctly to compiler proper.

toon at moene dot indiv dot nluug dot nl wrote:-

> 
> ------- Additional Comments From toon at moene dot indiv dot nluug dot nl  2003-12-23 23:48 -------
> > I believe this is what we want.  -d8 shouldn't be Joined though.
> 
> Well, yes, obviously - unfortunately, it *is*:
> 
> "a prefix [for -d<letters>]"
> 
> and therefore eaten (while it shouldn't, because '8' isn't one of the <letters>).

Um, -d8 is only Joined if you specified that in your .opt file.  Nothing
in opts.sh is magically adding the Joined flag for you.

-dumpbase in common.opt works fine, right?  Why can't you get d8 to work the same?
Or is -dumpbase broken too?

Neil.

This looks like still problem on the tree-ssa, but only for -i8 and -r8, the driver does not pass them to 
the compiler but the problem comes from fortran specific code in gfortranspec.c: lang_specific_driver.

i'll have a look. 

Well, those options are still not recognized as of gcc version 3.5.0 20040823
In reply to <a
href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464#c2>#2</a>, the g95
people <emph>do not</emph> have this problem.

*** Bug 18598 has been marked as a duplicate of this bug. ***

This really, really is a driver issue.

AFAICS, we stick to the correct definitions ...

*** Bug 20096 has been marked as a duplicate of this bug. ***

*** Bug 20144 has been marked as a duplicate of this bug. ***

The gfortran frontend defines the two options -i8 and -r8 in gfortran/lang.opt. 
gcc/opts.sh appears to process lang.opt without a problem, because the produced
options.h file contains OPT_i8 and OPT_r8.  However, neither -i8 nor -r8 is
passed to gfc_handle_option, which is defined to LANG_HOOKS_HANDLE_OPTION
in f95-lang.c.
  
I have added some debugging printfs to gfc_handle_option
  
int
gfc_handle_option (size_t scode, const char *arg, int value)
{
  int result = 1;
  enum opt_code code = (enum opt_code) scode;
  
 printf("code = %d ", code);
 if (arg != NULL) printf("arg = %s ", arg); 
 printf("value = %d\n", value);
  
The execution of gfortran shows that gfc_handle_option is
never called if -i8 or -r8 is specified.
  
troutmask:sgk[307] gfc41 -static -o kl -d8 kl.f90
code = 138 value = 1
troutmask:sgk[308] gfc41 -static -o kl -r8 kl.f90
gfc41: unrecognized option '-r8'
troutmask:sgk[309] gfc41 -static -o kl -i8 kl.f90

Note, -d8 is OPT_d8 in options.h and it is passed to gfc_handle_option.

So, it appears that some magic parsing of command line arguments occurs
before gfc_handle_option is called.  Is there someway to inhibit this
magic??

BTW, I have a patch that actually makes -d8 work.

*** Bug 20390 has been marked as a duplicate of this bug. ***

See
    http://gcc.gnu.org/ml/gcc/2005-03/msg00513.html
for relevant comments.

These options has changed to -fdefault-double-8, -fdefault-integer-8, and -fdefault-real-8. so 
closing as will not fix.