Re: [RFC] libstdc++/6720 and libstdc++/6671

[Gabriel Dos Reis <gdr at codesourcery dot com>]

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

| Gabriel Dos Reis wrote:-
| 
| > The standard does specify the effect of #include <cmath> in a program
| > (with on exception, see below): it should make the declarations given
| > in section 26 available to the program.
| > The specification of all standard headers is given in 17.4.1.2.
| > 
| > The exception is 17.4.3.2:
| > 
| >    *If* a file with a name equivalent to the derived file name for one of
| >    the C++ Standard Library headers is *not provided* as part of the
| >    implementation, *and* a file with that name is placed in any of the
| >    standard places for a source file to be included (16.2), the behavior
| >    is undefined. 
| > 
| > (Emphasis is mine).  Therefore, the contexts in which the compiler is
| > granted right to transmute semantics is very limited:
| > 
| >    1) the implementation _doesn't_ provide a file derived from a
| >       standard header as part of its implementation. *and*
| > 
| >    2) a file with a name derived from a standard header should be
| >       placed in any of the standard places for a source file to be
| >       included.
| > 
| > Since we're not doing 1) (i.e. we implement standard headers in terms
| > of actual files), we're not in case where we could legitimately invoke
| > undefined behaviour; that is we have to deliver the semantics
| > according to 17.4. and 16.2 -- we must find the "right" <cmath>.
| 
| Sure.  But how is this different from any other switch you might
| provide G++ like -I. or -ffast-math?

-ffast-math doesn't change the well-formness of a programs.

As of -I., it is precisely its uspposed current meaning that is under
discussion. 

|  My point being that unless
| your command line options are *just* -ansi -pedantic (or equivalent)
| you're effectively giving the implementation leave to do whatever
| it documents for those options.

That point ignores reality.  Although the standard does not mandate
useful implemenations, we should strive for implementing the required
semantics even though we add extensions.  I'm for -I., but I'm against
it behaving like it does currently, because that semantics can be
improved to offer both conformance and usefulness.  I disagree with
the stance that it should be either -ansi -pedantic or else break
expected semantics. 

[...]

|  They're already over-specified and over-complicated.

Actually, they're under-specified and causing more troubles than it
worth.  The standard headers are part of the language, and when the
-I. is added, care should be exercised to deliver expected standard
semantics.

-- Gaby