nano printf + powerpc gcc

[Craig Howland]

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.