Re: nano printf + powerpc gcc

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

On 2018-01-29 12:01, Craig Howland wrote:
> On 01/24/2018 07:44 PM, Brian Inglis wrote:
>> On 2018-01-24 11:25, Craig Howland wrote:
>>> On 01/24/2018 11:46 AM, Andre Vieira (lists) wrote:
>>>> I looked a bit further into this and I can't reproduce this behavior for
>>>> the i386 backend. So I had a look through GCC's parser implementation for
>>>> _Generic and it seems GCC evaluates the expressions in each matching case,
>>>> that is to say it will also parse the default case. In arm, the type of
>>>> va_list is a struct, since it is invalid to cast structs to pointers, the
>>>> c-parser will error out when it parses this cast in the default case. For
>>>> an i386 gcc, and I'm guessing your case is the same, the type of va_list
>>>> can be cast to a pointer type, so it parses it without errors.
>>>>
>>>> I don't know if parsing the expression of default if another case has
>>>> matched is intended behavior. I will investigate this further and if I can
>>>> convince myself this is wrong behavior I'll chase it with upstream gcc.
>>>>
>>> The final draft of the C11 standard, which I assume was not changed in the
>>> final release, does say that only the chosen expression is evaluated.  (Which
>>> is as it must be.  If it is choosing function names, for example, it can
>>> hardly evaluate a non-chosen option, as that means calling the function.  The
>>> example they give is actually choosing a function.)  A cast is an expression,
>>> so it appears that you do need to chase it with upstream GCC.  It obviously
>>> has to parse each selection, but it must only evaluate one.
>> FYI for _Generic definition and issues see:
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf   ; [CD]
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1650.htm   ; [DR original]
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_423.htm   ; [DR discussion]
>> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01054.html   ; [GCC response]
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1930.htm   ; [followup]
>>
>> The official standard agrees with you at the end of #3, but see note (91 below;
>> selectively quoting from ISO/IEC 9899:2011[2012] thru TC3:
>> "
>> 6 A generic selection is a primary expression. Its type and value depend on
>> the selected generic association, as detailed in the following subclause.
>> Forward references: declarations (6.7).
>>
>> 6.5.1.1 Generic selection
>>
>> Syntax
>>
>> 1 generic-selection:
>>     _Generic ( assignment-expression , generic-assoc-list )
>> generic-assoc-list:
>>     generic-association
>>     generic-assoc-list , generic-association
>> generic-association:
>>     type-name : assignment-expression
>>     default : assignment-expression
>>
>> 91) Thus, an undeclared identifier is a violation of the syntax.
>>
>> Constraints
>>
>> 2 A generic selection shall have no more than one default generic association.
>> The type name in a generic association shall specify a complete object type
>> other than a variably modified type. No two generic associations in the same
>> generic selection shall specify compatible types. The controlling expression of
>> a generic selection shall have type compatible with at most one of the types
>> named in its generic association list. If a generic selection has no default
>> generic association, its controlling expression shall have type compatible with
>> exactly one of the types named in its generic association list.
>>
>> Semantics
>>
>> 3 The controlling expression of a generic selection is not evaluated. If a
>> generic selection has a generic association with a type name that is compatible
>> with the type of the controlling expression, then the result expression of the
>> generic selection is the expression in that generic association. Otherwise, the
>> result expression of the generic selection is the expression in the default
>> generic association. None of the expressions from any other generic association
>> of the generic selection is evaluated.
>>
>> 4 The type and value of a generic selection are identical to those of its
>> result expression. It is an lvalue, a function designator, or a void expression
>> if its result expression is, respectively, an lvalue, a function designator, or
>> a void expression.
>>
>> 5 EXAMPLE The cbrt type-generic macro could be implemented as follows:
>> #define cbrt(X) _Generic((X), \
>>         long double: cbrtl, \
>>         default: cbrt, \
>>         float: cbrtf \
>>     )(X)
>> "
>       Sorry for the delay in responding to this, but it took a while to have
> enough time to read the given references.
>       I believe that the given references don't apply to the case under
> consideration.  The primary problem being discussed in them is qualifiers and
> how they relate to rvalue versus lvalue for _Generic() evaluation, but
> qualifiers don't come into play for the specific point under consideration here,
> namely evaluation of an association other than the one chosen.  (That is, after
> an association has been selected for evaluation, then the complications in DR
> 423 and the followup come into play.  Whether qualifiers are applied are not are
> moot if the expression is not evaluated.)  So Andre's thought about chasing GCC
> with it does still seem to be appropriate.

As each expression has to be valid syntax, I question whether the parser can
treat ap being both a va_list or a va_list * as valid?
But IANALL.
I think Joseph Myers may have been making the same point in his slightly later
post, and was the GCC responder above, so will be very familiar with this area.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada