Bug 13464 - -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
Summary: -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: tree-ssa
: P2 normal
Target Milestone: 4.0.0
Assignee: Steven Bosscher
URL:
Keywords:
: 18598 20096 20144 20390 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-22 11:50 UTC by Toon Moene
Modified: 2005-04-21 05:06 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-12-22 16:37:21


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toon Moene 2003-12-22 11:50:40 UTC
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.
Comment 1 Andrew Pinski 2003-12-22 16:37:21 UTC
Confirmed.
Comment 2 Neil Booth 2003-12-22 20:37:22 UTC
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.
Comment 3 Toon Moene 2003-12-22 23:22:23 UTC
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.
Comment 4 Neil Booth 2003-12-23 06:39:44 UTC
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.
Comment 5 Toon Moene 2003-12-23 12:59:58 UTC
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 ?
Comment 6 Neil Booth 2003-12-23 22:44:14 UTC
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.
Comment 7 Toon Moene 2003-12-23 23:48:04 UTC
> 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>).
Comment 8 Neil Booth 2003-12-24 06:31:10 UTC
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.
Comment 9 Andrew Pinski 2004-03-03 03:47:30 UTC
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.
Comment 10 Steven Bosscher 2004-03-03 06:53:17 UTC
i'll have a look. 
Comment 11 Carsten Lemmen 2004-08-25 13:04:25 UTC
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.
Comment 12 Andrew Pinski 2004-11-21 16:18:29 UTC
*** Bug 18598 has been marked as a duplicate of this bug. ***
Comment 13 Toon Moene 2005-01-07 21:58:49 UTC
This really, really is a driver issue.

AFAICS, we stick to the correct definitions ...
Comment 14 Andrew Pinski 2005-02-19 23:13:55 UTC
*** Bug 20096 has been marked as a duplicate of this bug. ***
Comment 15 Andrew Pinski 2005-02-22 15:55:54 UTC
*** Bug 20144 has been marked as a duplicate of this bug. ***
Comment 16 Steve Kargl 2005-03-08 23:52:14 UTC
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.
Comment 17 Steve Kargl 2005-03-08 23:53:39 UTC
*** Bug 20390 has been marked as a duplicate of this bug. ***
Comment 18 Jim Wilson 2005-03-11 05:31:37 UTC
See
    http://gcc.gnu.org/ml/gcc/2005-03/msg00513.html
for relevant comments.
Comment 19 Andrew Pinski 2005-04-21 05:06:23 UTC
These options has changed to -fdefault-double-8, -fdefault-integer-8, and -fdefault-real-8. so 
closing as will not fix.