Conference hylndr::dclreview

It matches the Fortran behavior?  I don't see Fortran doing this (though I
think it's a fine idea.)

				Steve

    This becomes more interesting. I just talked to Steve and
    we found that F77 issues the informational only if the non-default
    value of /IEEE is specified. F90 never issues any message.

    Also both C and Fortran compilers have a related qualifier /ROUNDING_MODE. 
    This qualifier also impacts IEEE behavior only. Currently the
    Fortran compilers issue no message if /ROUNDING_MODE is specified
    without /FLOAT=IEEE. Currently DEC C (and DEC C++) issue an -E-
    level message.

    Steve and I both agreed on the following:

    .DEC C/C++ should go with the proposal in .1

    .DEC C/C++ should be modified so that if /ROUNDING_MODE is specified
     without /FLOAT=IEEE, the message:

	%CC-I-QUACONFL1, /ROUNDING_MODE qualifier implies /FLOAT=IEEE

     will be output instead of the -E- level message DEC C/C++ outputs today.
     This makes /ROUNDING_MODE consistent with /IEEE.

    .The Fortran compilers will be modified (at some point) to issue 
     informationals for all /IEEE values and for /ROUNDING_MODE if
     /FLOAT=IEEE is not specified.
    

    Steve, correct me if I'm wrong.

						Ed

RE .2:

> Way cool!

RE .3:

> I think it's a fine idea.

The proposal suggests that explicitly specifying a qualifier
that only makes sense when another qualifier is specified with
non-default value ought to issue an informational and turn
on the non-default value if that other qualifier was defaulted.

So do Pascal and Fortran agree that if /machine_code is specified
without /list, we should issue an informational and turn on /list?
Lots of people would like that, but if only one of the compilers
did it, I imagine there'd be some grumbling.

    Oh yes please.  

    It isn't quite the same.  With /MACHINE_CODE without /LIST, you
    won't get an object file that does one thing, but you think it
    does something else.
    
    I view this more like the compiler's producing a message with
    /DEBUG and the default optimization.  We're telling you that you
    might be surprised at some point in the future with your choices
    in qualifiers.  The /MACHINE_CODE without /LIST isn't a silent
    killer.
    
    				-John

We've had a long-standing "rule" that one qualifier doesn't affect another,
but that rule has been broken many times by many products.  For example,
Alpha Fortran has /FAST and /VMS which affect several other qualifiers. (The
VAX compiler doesn't have any such interactions, as far as I know.)

Thinking about this some more, I'm not entirely comfortable with the idea of
interactions like this.  I'd feel better about just giving a "conflict" error
and let the user specify things explicitly.

					Steve

    Steve,
    
>Thinking about this some more, I'm not entirely comfortable with the idea of
>interactions like this.  I'd feel better about just giving a "conflict" error
>and let the user specify things explicitly.

    This would mean "breaking" existing Fortran applications that
    currently issue the informational. Do you really want to do this?
    
    					Ed
    
    

RE .7:

> With /MACHINE_CODE without /LIST, you won't get an object file that
> does one thing, but you think it does something else.

True, but it's quite likely you'll get a listing file that shows
machine code that doesn't have anything to do with the object
module you just generated - i.e. the previous version of the listing
file that got generated the last time you actually remembered to
specify /list in addition to /machine_code.

> The /MACHINE_CODE without /LIST isn't a silent killer.

Unless the /ieee application fails or produces inaccurate information
affecting a life-threatening situation, it doesn't kill anything other
than people's time.  And that's exactly the effect of silently allowing
a developer to analyze generated machine code that doesn't correspond
to the object module produced.  Do you get the sense I've killed some
time doing this myself :-)?

I don't think it's all that critical how the conflict gets resolved
(either in terms of which qualifier wins, or even making it a fatal
error), but *silently* producing a surprising result that virtually
every user trips on at some point seems hard to justify.

    The compilers have been very inconsistent on these topics.
    
    For example, on VAX, DEC Pascal always produces an object file
    even if the compilation had errors (the object file is a "minimal"
    object file with a severity set to "E").  We did this so you wouldn't
    just pick up an older .OBJ file lying around from when you didn't
    have syntax errors.  This is the arguement you use in .10 about
    reading old .LIS files that don't match the current compilation.
    However, on VAX, DEC Pascal has been beat up continually over the
    years about our always generating .OBJ files (it confused MMS
    into thinking the compilation was successful).  All the other 
    VAX-based compilers delete don't produce an .OBJ file when there 
    were syntax errors.  If you aren't watching (or have badly written 
    DCL command files, etc.) you can just pick up the old .OBJ file and 
    get real confused.
    
    Thats not to say one is right and the other is wrong, but both
    sides have value.  The behavior of /MACHINE without /LIST had
    been around forever.
    
    				-John