Re: Possible bug in preprocessor
Jim Wilson wrote: > JoseD wrote: > > @James > > What do you mean by 16.3.3/3? GCC's version ? > > This is a reference to the ISO C standard. No. It's a reference to the ISO C++ standard. 16.3.3/3 includes the sentence "If the result [of the ## operator] is not a valid preprocessing token, the behavior is undefined." The passage in the ISO C standard is 6.10.3.3/3, and includes the same text. -- Richard Smith
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: > > On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: > > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: > >> > >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely > >> wrote: > >> > On 8 February 2016 at 19:23, Richard Smith wrote: > >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: > >> >> > >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions > >> > > >> > Thanks. So there's no problem using "POD for the purposes of layout", > >> > and the change to "POD for the purpose of standard-layout" was > >> > unnecessary and just confused things. > >> > >> Here is the revised proposal: > >> > >> 1. "class type". A class type is a structure, union or C++ class. > >> 2. "empty class type". An empty class type is: > >>a. A class type without member. Or > >>b. A class type with only members of empty class types. Or > > > > > > (a) is a special case of (b). > > > >>c. An array of empty class types. > > > > > > It seems confusing to call an array a class type. Instead, how about: > > > > 2. An empty type is either an array of empty types or a class type where > > every member is of empty type. > > > >> 3. "empty record". An empty record is Plain Old Data (POD) for the > >>purposes of layout and > >>a. A class type without member. Or > >>b. A class type with only members of empty class types. > > > > > > (a) is a special case of (b). > > > >> 4. No memory slot nor register should be used to pass or return an object > >> of empty record. > > > > > > Objects of array type are never passed or returned (but if through some > > language extension they were, we'd want this rule to apply). So you don't > > need rule 3 and this can be just: > > > > 3. No memory slot nor register should be used to pass or return an object > > of empty type. > > Thanks very much for your inputs. Here is the proposal: > > 1. "class type". A class type is a structure, union or C++ class. > 2. "empty type". An empty type is either an array of empty types or a > class type where every member is of empty type. > 3. No memory slot nor register should be used to pass or return an object > of empty type. David Majnemer points out that we also need to say something about base classes. We could handle that case like this: 2. "empty type". An empty type is a type where it and all of its subobjects are of class or array type. Following the C++ rules, this also means that a class that contains only unnamed bitfields is empty, because unnamed bitfields are not subobjects, but might be worth explicitly stating for the C case. That also matches Clang's behavior.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Do we really need an 'empty type' special case? The x86_64 psABI already seems clear that empty types with size <= 16 are not passed at all. Following the algorithm in section 3.2.3, each eightbyte is classified as NO_CLASS, and thus is not passed. So the proposed change would only affect the behavior of types larger than 16 bytes that contain no data. It doesn't seem worth breaking ABI to more efficiently pass those. On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: > On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >> >> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote: >> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >> >> wrote: >> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> >> >> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >> >> > >> >> > Thanks. So there's no problem using "POD for the purposes of layout", >> >> > and the change to "POD for the purpose of standard-layout" was >> >> > unnecessary and just confused things. >> >> >> >> Here is the revised proposal: >> >> >> >> 1. "class type". A class type is a structure, union or C++ class. >> >> 2. "empty class type". An empty class type is: >> >>a. A class type without member. Or >> >>b. A class type with only members of empty class types. Or >> > >> > >> > (a) is a special case of (b). >> > >> >>c. An array of empty class types. >> > >> > >> > It seems confusing to call an array a class type. Instead, how about: >> > >> > 2. An empty type is either an array of empty types or a class type where >> > every member is of empty type. >> > >> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >> >>purposes of layout and >> >>a. A class type without member. Or >> >>b. A class type with only members of empty class types. >> > >> > >> > (a) is a special case of (b). >> > >> >> 4. No memory slot nor register should be used to pass or return an object >> >> of empty record. >> > >> > >> > Objects of array type are never passed or returned (but if through some >> > language extension they were, we'd want this rule to apply). So you don't >> > need rule 3 and this can be just: >> > >> > 3. No memory slot nor register should be used to pass or return an object >> > of empty type. >> >> Thanks very much for your inputs. Here is the proposal: >> >> 1. "class type". A class type is a structure, union or C++ class. >> 2. "empty type". An empty type is either an array of empty types or a >> class type where every member is of empty type. >> 3. No memory slot nor register should be used to pass or return an object >> of empty type. > > David Majnemer points out that we also need to say something about > base classes. We could handle that case like this: > > 2. "empty type". An empty type is a type where it and all of its > subobjects are of class or array type. > > Following the C++ rules, this also means that a class that contains > only unnamed bitfields is empty, because unnamed bitfields are not > subobjects, but might be worth explicitly stating for the C case. That > also matches Clang's behavior.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>> >>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>> wrote: >>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>> >> >>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>> >> wrote: >>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI >>> >> >> here: >>> >> >> >>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>> >> > >>> >> > Thanks. So there's no problem using "POD for the purposes of layout", >>> >> > and the change to "POD for the purpose of standard-layout" was >>> >> > unnecessary and just confused things. >>> >> >>> >> Here is the revised proposal: >>> >> >>> >> 1. "class type". A class type is a structure, union or C++ class. >>> >> 2. "empty class type". An empty class type is: >>> >>a. A class type without member. Or >>> >>b. A class type with only members of empty class types. Or >>> > >>> > >>> > (a) is a special case of (b). >>> > >>> >>c. An array of empty class types. >>> > >>> > >>> > It seems confusing to call an array a class type. Instead, how about: >>> > >>> > 2. An empty type is either an array of empty types or a class type where >>> > every member is of empty type. >>> > >>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>> >>purposes of layout and >>> >>a. A class type without member. Or >>> >>b. A class type with only members of empty class types. >>> > >>> > >>> > (a) is a special case of (b). >>> > >>> >> 4. No memory slot nor register should be used to pass or return an object >>> >> of empty record. >>> > >>> > >>> > Objects of array type are never passed or returned (but if through some >>> > language extension they were, we'd want this rule to apply). So you don't >>> > need rule 3 and this can be just: >>> > >>> > 3. No memory slot nor register should be used to pass or return an object >>> > of empty type. >>> >>> Thanks very much for your inputs. Here is the proposal: >>> >>> 1. "class type". A class type is a structure, union or C++ class. >>> 2. "empty type". An empty type is either an array of empty types or a >>> class type where every member is of empty type. >>> 3. No memory slot nor register should be used to pass or return an object >>> of empty type. >> >> David Majnemer points out that we also need to say something about >> base classes. We could handle that case like this: >> >> 2. "empty type". An empty type is a type where it and all of its >> subobjects are of class or array type. >> >> Following the C++ rules, this also means that a class that contains >> only unnamed bitfields is empty, because unnamed bitfields are not >> subobjects, but might be worth explicitly stating for the C case. That >> also matches Clang's behavior. > > Like this? > > 1. "class type". A class type is a structure, union or C++ class. > 2. "empty type". An empty type is >a. A type where it and all of its subobjects are of class or array >type. And >b. Either an array of empty types or a class type where every member >is of empty type. You don't need (b). It's implied by (a). > 3. No memory slot nor register should be used to pass or return an object > of empty type. > > > -- > H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote: >> Do we really need an 'empty type' special case? >> >> The x86_64 psABI already seems clear that empty types with size <= 16 >> are not passed at all. Following the algorithm in section 3.2.3, each >> eightbyte is classified as NO_CLASS, and thus is not passed. So the >> proposed change would only affect the behavior of types larger than 16 >> bytes that contain no data. It doesn't seem worth breaking ABI to more >> efficiently pass those. >> > > Clang isn't consistent between ia32 and x86-64. GCC isn't compatible > with clang. My proposal will make GCC and clang compatible. It also > makes GCC and clang behave the same on both ia32 and x86-64. OK, but if the ABI is already saying what we want, and the only problem is that GCC and Clang don't conform to the ABI in some cases, then we just need to fix the compilers and not the ABI. Which cases do we think the existing ABI rule misclassifies?
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote: >>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>>> >>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>>> wrote: >>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>>>> >> >>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>>> >> >>>>> >> wrote: >>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI >>>>> >> >> here: >>>>> >> >> >>>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>>> >> > >>>>> >> > Thanks. So there's no problem using "POD for the purposes of layout", >>>>> >> > and the change to "POD for the purpose of standard-layout" was >>>>> >> > unnecessary and just confused things. >>>>> >> >>>>> >> Here is the revised proposal: >>>>> >> >>>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>>> >> 2. "empty class type". An empty class type is: >>>>> >>a. A class type without member. Or >>>>> >>b. A class type with only members of empty class types. Or >>>>> > >>>>> > >>>>> > (a) is a special case of (b). >>>>> > >>>>> >>c. An array of empty class types. >>>>> > >>>>> > >>>>> > It seems confusing to call an array a class type. Instead, how about: >>>>> > >>>>> > 2. An empty type is either an array of empty types or a class type >>>>> > where >>>>> > every member is of empty type. >>>>> > >>>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>>> >>purposes of layout and >>>>> >>a. A class type without member. Or >>>>> >>b. A class type with only members of empty class types. >>>>> > >>>>> > >>>>> > (a) is a special case of (b). >>>>> > >>>>> >> 4. No memory slot nor register should be used to pass or return an >>>>> >> object >>>>> >> of empty record. >>>>> > >>>>> > >>>>> > Objects of array type are never passed or returned (but if through some >>>>> > language extension they were, we'd want this rule to apply). So you >>>>> > don't >>>>> > need rule 3 and this can be just: >>>>> > >>>>> > 3. No memory slot nor register should be used to pass or return an >>>>> > object >>>>> > of empty type. >>>>> >>>>> Thanks very much for your inputs. Here is the proposal: >>>>> >>>>> 1. "class type". A class type is a structure, union or C++ class. >>>>> 2. "empty type". An empty type is either an array of empty types or a >>>>> class type where every member is of empty type. >>>>> 3. No memory slot nor register should be used to pass or return an object >>>>> of empty type. >>>> >>>> David Majnemer points out that we also need to say something about >>>> base classes. We could handle that case like this: >>>> >>>> 2. "empty type". An empty type is a type where it and all of its >>>> subobjects are of class or array type. >>>> >>>> Following the C++ rules, this also means that a class that contains >>>> only unnamed bitfields is empty, because unnamed bitfields are not >>>> subobjects, but might be worth explicitly stating for the C case. That >>>> also matches Clang's behavior. >>> >>> Like this? >>> >>> 1. "class type". A class type is a structure, union or C++ class. >>> 2. "empty type". An empty type is >>>a. A type where it and all of its subobjects are of class or array >>>type. And >>>b. Either an array of empty types or a class type where every member >>>is of empty type. >> >> You don't need (b). It's implied by (a). > > Does (a) cover empty type? Yes, (a) is a complete definition of "empty type" by itself: the definition is, essentially, that a complete recursive walk of the type and all its subobjects never sees anything that would require any storage (that is, it only sees class types and array types).
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote: >> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote: >>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote: >>>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith >>>>> wrote: >>>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote: >>>>>>> >>>>>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith >>>>>>> wrote: >>>>>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote: >>>>>>> >> >>>>>>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely >>>>>>> >> >>>>>>> >> wrote: >>>>>>> >> > On 8 February 2016 at 19:23, Richard Smith wrote: >>>>>>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI >>>>>>> >> >> here: >>>>>>> >> >> >>>>>>> >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions >>>>>>> >> > >>>>>>> >> > Thanks. So there's no problem using "POD for the purposes of >>>>>>> >> > layout", >>>>>>> >> > and the change to "POD for the purpose of standard-layout" was >>>>>>> >> > unnecessary and just confused things. >>>>>>> >> >>>>>>> >> Here is the revised proposal: >>>>>>> >> >>>>>>> >> 1. "class type". A class type is a structure, union or C++ class. >>>>>>> >> 2. "empty class type". An empty class type is: >>>>>>> >>a. A class type without member. Or >>>>>>> >>b. A class type with only members of empty class types. Or >>>>>>> > >>>>>>> > >>>>>>> > (a) is a special case of (b). >>>>>>> > >>>>>>> >>c. An array of empty class types. >>>>>>> > >>>>>>> > >>>>>>> > It seems confusing to call an array a class type. Instead, how about: >>>>>>> > >>>>>>> > 2. An empty type is either an array of empty types or a class type >>>>>>> > where >>>>>>> > every member is of empty type. >>>>>>> > >>>>>>> >> 3. "empty record". An empty record is Plain Old Data (POD) for the >>>>>>> >>purposes of layout and >>>>>>> >>a. A class type without member. Or >>>>>>> >>b. A class type with only members of empty class types. >>>>>>> > >>>>>>> > >>>>>>> > (a) is a special case of (b). >>>>>>> > >>>>>>> >> 4. No memory slot nor register should be used to pass or return an >>>>>>> >> object >>>>>>> >> of empty record. >>>>>>> > >>>>>>> > >>>>>>> > Objects of array type are never passed or returned (but if through >>>>>>> > some >>>>>>> > language extension they were, we'd want this rule to apply). So you >>>>>>> > don't >>>>>>> > need rule 3 and this can be just: >>>>>>> > >>>>>>> > 3. No memory slot nor register should be used to pass or return an >>>>>>> > object >>>>>>> > of empty type. >>>>>>> >>>>>>> Thanks very much for your inputs. Here is the proposal: >>>>>>> >>>>>>> 1. "class type". A class type is a structure, union or C++ class. >>>>>>> 2. "empty type". An empty type is either an array of empty types or a >>>>>>> class type where every member is of empty type. >>>>>>> 3. No memory slot nor register should be used to pass or return an >>>>>>> object >>>>>>> of empty type. >>>>>> >>>>>> David Majnemer points out that we also need to say something about >>>>>> base classes. We could handle that case like this: >>>>>> >>>>>> 2. "empty type". An empty type is a type where it and all of its >>>>>> subobjects are of class or array type. >>>>>> >>>>>> Following the C++ rules, this also means that a class that contains >>>>>> only unnamed bitfields is empty, because unnamed bitfields are not >>>>>> subobjects, but might be worth explicitly stating for the C case. That >>>>>> also matches Clang's behavior. >>>>> >>>>> Like this? >>>>> >>>>> 1. "class type". A class type is a structure, union or C++ class. >>>>> 2. "empty type". An empty type is >>>>>a. A type where it and all of its subobjects are of class or array >>>>>type. And >>>>>b. Either an array of empty types or a class type where every member >>>>>is of empty type. >>>> >>>> You don't need (b). It's implied by (a). >>> >>> Does (a) cover empty type? >> >> Yes, (a) is a complete definition of "empty type" by itself: the >> definition is, essentially, that a complete recursive walk of the type >> and all its subobjects never sees anything that would require any >> storage (that is, it only sees class types and array types). > > Is there a definition of subobject? Yes, the C++ standard defines the term (as an object that is contained within another via member, base class, and array element relationships). The C standard uses it in 6.7.9 to mean the same thing (recursing into class and array elements) but doesn't provide a formal definition.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> > wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>> };
> >>
> >> What about it? It's an empty struct. (And it declares a function and
> >> a variable in the namespace of A, which however do not have any
> >> relevant impact here.)
> >>
> >
> > Thanks for all the feedbacks. Here is the new proposal:
> >
> > 1. "empty type". An empty type is a trivially-copyable aggregate
> > occupying zero bytes (excluding any padding).
> > 2. No memory slot nor register should be used to pass or return an object
> > of empty type.
> >
> > Footnote: Array of empty type can only passed by reference in C/C++.
> >
>
> I updated intel386, x86-64 and IA MCU psABIs:
>
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>
> to specify:
>
> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
> (excluding any padding).
I think this is now extremely unclear. Does an empty struct in C++
occupy zero bytes? sizeof applied to it will produce at least 1.
> No memory slot nor register should be used to pass or
> return an object object of empty type.
>
> with footnote: Array of empty type can only passed by reference in C and C++.
>
> Any comments?
>
> Thanks.
>
>
> --
> H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>
>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>> > wrote:
>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>> >>> struct A {
>>> >>> static void foo (void) ();
>>> >>> static int xxx;
>>> >>> };
>>> >>
>>> >> What about it? It's an empty struct. (And it declares a function and
>>> >> a variable in the namespace of A, which however do not have any
>>> >> relevant impact here.)
>>> >>
>>> >
>>> > Thanks for all the feedbacks. Here is the new proposal:
>>> >
>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>> > occupying zero bytes (excluding any padding).
>>> > 2. No memory slot nor register should be used to pass or return an object
>>> > of empty type.
>>> >
>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>> >
>>>
>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>
>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>
>>> to specify:
>>>
>>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>>> (excluding any padding).
>>
>> I think this is now extremely unclear. Does an empty struct in C++
>> occupy zero bytes? sizeof applied to it will produce at least 1.
>
> Can it be considered as padding?
Perhaps, but I would contend that that's unclear in at least some
cases (when the class is used as the type of a member, ...). What
about this case:
struct X { unsigned : 15; };
Is that empty or not? Do we have a formal definition somewhere of what
does, and does not, count as padding?
>>> No memory slot nor register should be used to pass or
>>> return an object object of empty type.
>>>
>>> with footnote: Array of empty type can only passed by reference in C and
>>> C++.
>>>
>>> Any comments?
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> H.J.
>
>
>
> --
> H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>
>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>> > wrote:
>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>> >>> struct A {
>>>>> >>> static void foo (void) ();
>>>>> >>> static int xxx;
>>>>> >>> };
>>>>> >>
>>>>> >> What about it? It's an empty struct. (And it declares a function and
>>>>> >> a variable in the namespace of A, which however do not have any
>>>>> >> relevant impact here.)
>>>>> >>
>>>>> >
>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>> >
>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>> > occupying zero bytes (excluding any padding).
>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>> > object
>>>>> > of empty type.
>>>>> >
>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>> >
>>>>>
>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>
>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>
>>>>> to specify:
>>>>>
>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>> bytes
>>>>> (excluding any padding).
>>>>
>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>
>>> Can it be considered as padding?
>>
>> Perhaps, but I would contend that that's unclear in at least some
>> cases (when the class is used as the type of a member, ...). What
>> about this case:
>>
>> struct X { unsigned : 15; };
>>
>> Is that empty or not? Do we have a formal definition somewhere of what
>> does, and does not, count as padding?
>
> How about this?
>
> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
> (excluding any padding or contributing zero bytes to the size of derived
> classes in C++).
>
> This will cover
>
> struct dummy0
> {
> void bar (void);
> };
> struct dummy1
> {
> void foo (void);
> };
> struct dummy : dummy0, dummy1 { };
>
> But not
>
> struct dummy0
> {
> };
> struct dummy1
> {
> unsigned : 15;
> };
> struct dummy : dummy0, dummy1
> {
> };
Why not? That looks empty to me. The ABI will classify the
corresponding eightbyte as NO_CLASS, as it has no members, so it
should not be passed.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>>>> wrote:
>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>>>
>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>> > wrote:
>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>>>> >>> struct A {
>>>>>>> >>> static void foo (void) ();
>>>>>>> >>> static int xxx;
>>>>>>> >>> };
>>>>>>> >>
>>>>>>> >> What about it? It's an empty struct. (And it declares a function and
>>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>>> >> relevant impact here.)
>>>>>>> >>
>>>>>>> >
>>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>>> >
>>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>>> > occupying zero bytes (excluding any padding).
>>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>>> > object
>>>>>>> > of empty type.
>>>>>>> >
>>>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>>>> >
>>>>>>>
>>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>>
>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>>
>>>>>>> to specify:
>>>>>>>
>>>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>>>> bytes
>>>>>>> (excluding any padding).
>>>>>>
>>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>>
>>>>> Can it be considered as padding?
>>>>
>>>> Perhaps, but I would contend that that's unclear in at least some
>>>> cases (when the class is used as the type of a member, ...). What
>>>> about this case:
>>>>
>>>> struct X { unsigned : 15; };
>>>>
>>>> Is that empty or not? Do we have a formal definition somewhere of what
>>>> does, and does not, count as padding?
>>>
>>> How about this?
>>>
>>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>>> (excluding any padding or contributing zero bytes to the size of derived
>>> classes in C++).
>>>
>>> This will cover
>>>
>>> struct dummy0
>>> {
>>> void bar (void);
>>> };
>>> struct dummy1
>>> {
>>> void foo (void);
>>> };
>>> struct dummy : dummy0, dummy1 { };
>>>
>>> But not
>>>
>>> struct dummy0
>>> {
>>> };
>>> struct dummy1
>>> {
>>> unsigned : 15;
>>> };
>>> struct dummy : dummy0, dummy1
>>> {
>>> };
>>
>> Why not? That looks empty to me. The ABI will classify the
>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>> should not be passed.
>
> Do you have a wording to describe it?
Yes, something like what you had before was fine:
"empty type". An empty type is a type where it and all of its
subobjects (recursively) are of class, structure, union, or array
type.
Or, if you think it makes the intent clearer, reverse the sense:
A type is non-empty if it or any subobject (recursively) is of any
type other than class, structure, union, or array type.
If you like, you could add notes that a parameter type is never an
array type, and that unnamed bit-fields are not subobjects, but they
seem redundant given the wording of the relevant standards. (You don't
need to say anything about "POD for the purpose of layout", or
destructors, or whatever else, because the C++ ABI only delegates to
the C psABI for cases that are valid to pass in registers from a C++
language semantics point of view.)
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>>>> wrote:
>>>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>>>>>> wrote:
>>>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>>>> > wrote:
>>>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>>>>>>>> >>> struct A {
>>>>>>>>> >>> static void foo (void) ();
>>>>>>>>> >>> static int xxx;
>>>>>>>>> >>> };
>>>>>>>>> >>
>>>>>>>>> >> What about it? It's an empty struct. (And it declares a function
>>>>>>>>> >> and
>>>>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>>>>> >> relevant impact here.)
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>>>>> >
>>>>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>>>>> > occupying zero bytes (excluding any padding).
>>>>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>>>>> > object
>>>>>>>>> > of empty type.
>>>>>>>>> >
>>>>>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>>>>
>>>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>>>>
>>>>>>>>> to specify:
>>>>>>>>>
>>>>>>>>> Empty type is defined as a trivially-copyable aggregate occupying
>>>>>>>>> zero bytes
>>>>>>>>> (excluding any padding).
>>>>>>>>
>>>>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>>>>
>>>>>>> Can it be considered as padding?
>>>>>>
>>>>>> Perhaps, but I would contend that that's unclear in at least some
>>>>>> cases (when the class is used as the type of a member, ...). What
>>>>>> about this case:
>>>>>>
>>>>>> struct X { unsigned : 15; };
>>>>>>
>>>>>> Is that empty or not? Do we have a formal definition somewhere of what
>>>>>> does, and does not, count as padding?
>>>>>
>>>>> How about this?
>>>>>
>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>> bytes
>>>>> (excluding any padding or contributing zero bytes to the size of derived
>>>>> classes in C++).
>>>>>
>>>>> This will cover
>>>>>
>>>>> struct dummy0
>>>>> {
>>>>> void bar (void);
>>>>> };
>>>>> struct dummy1
>>>>> {
>>>>> void foo (void);
>>>>> };
>>>>> struct dummy : dummy0, dummy1 { };
>>>>>
>>>>> But not
>>>>>
>>>>> struct dummy0
>>>>> {
>>>>> };
>>>>> struct dummy1
>>>>> {
>>>>> unsigned : 15;
>>>>> };
>>>>> struct dummy : dummy0, dummy1
>>>>> {
>>>>> };
>>>>
>>>> Why not? That looks empty to me. The ABI will classify the
>>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>>> should not be passed.
>>>
>>> Do you have a wording to describe it?
>>
>> Yes, something like what you had before was fine:
>>
>> "empty type". An empty type is a type where it and all of its
>> subobjects (recursively) are of class, structure, union, or array
>> type.
>>
>> Or, if you think it makes the intent clearer, reverse the sense:
>>
>> A type is non-empty if it or any subobject (recursively) is of any
>> type other than class, structure, union, or array type.
>
> Does the above cover
>
> struct dummy0
> {
> void bar (void);
> };
> struct dummy1
> {
> void foo (void);
> };
> struct dummy : dummy0, dummy1 { };
Yes
>> If you like, you could add notes that a parameter type is never an
>> array type, and that unnamed bit-fields are not subobjects, but they
>> seem redundant given the wording of the relevant standards. (You don't
>> need to say anything about "POD for the purpose of layout", or
>> destructors, or whatever else, because the C++ ABI only delegates to
>> the C psABI for cases that are valid to pass in registers from a C++
>> language semantics point of view.)
>
>
>
> --
> H.J.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Thu, Feb 18, 2016 at 6:35 AM, Michael Matz wrote: > Hi, > > On Tue, 16 Feb 2016, H.J. Lu wrote: > >> Here is the new definition: >> >> An empty type is a type where it and all of its subobjects (recursively) >> are of class, structure, union, or array type. No memory slot nor >> register should be used to pass or return an object of empty type. > > The trivially copyable is gone again. Why is it not necessary? The C++ ABI doesn't defer to the C psABI for types that aren't trivially-copyable. See http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Feb 2016, Richard Smith wrote:
>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively) are of class, structure, union, or array type. No
>> >> memory slot nor register should be used to pass or return an object
>> >> of empty type.
>> >
>> > The trivially copyable is gone again. Why is it not necessary?
>>
>> The C++ ABI doesn't defer to the C psABI for types that aren't
>> trivially-copyable. See
>> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
>
> Hmm, yes, but we don't want to define something for only C and C++, but
> language independend (so far as possible). And given only the above
> language I think this type:
>
> struct S {
> S() {something();}
> };
>
> would be an empty type, and that's not what we want.
Yes it is. Did you mean to give S a copy constructor, copy assignment
operator, or destructor instead?
> "Trivially copyable"
> is a reasonably common abstraction (if in doubt we could even define it in
> the ABI), and captures the idea that we need well (namely that a bit-copy
> is enough).
>
>
> Ciao,
> Michael.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On Tue, Feb 23, 2016 at 8:28 AM, H.J. Lu wrote:
> On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> I thought
>>>
>>> ---
>>> An empty type is a type where it and all of its subobjects (recursively)
>>> are of class, structure, union, or array type.
>>> ---
>>>
>>> excluded
>>>
>>> struct empty
>>> {
>>> empty () = default;
>>> };
>>
>>
>> Why would that be excluded? There are no subobjects, hence all of them
>> are of class, structure, union or array type, hence this is an empty type.
>> (And that's good, it indeed looks quite empty to me). Even if you would
>> add a non-trivial copy ctor, making this thing not trivially copyable
>> anymore, it would still be empty. Hence, given your proposed language in
>> the psABI, without reference to any other ABI (in particular not to the
>> Itanium C++ ABI), you would then need to pass it without registers. That
>> can't be done, and that's exactly why I find that wording incomplete. It
>> needs implicit references to other languages ABIs to work.
>>
>
> It is clear to me now. Let's go with
>
> ---
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type. No memory slot nor
> register should be used to pass or return an object of empty type that's
> trivially copyable.
> ---
>
> Any comments?
Yes. "trivially copyable" is the wrong restriction. See
http://mentorembedded.github.io/cxx-abi/abi.html#normal-call for the
actual Itanium C++ ABI rule.
It's also completely nonsensical to mention this as a special case in
relation to empty types. The special case applies to all function
parameters, irrespective of whether they're empty -- this rule applies
*long* before you consider whether the type is empty. For instance, in
the x86-64 psABI, this should go right at the start of section 2.2.3
("Parameter Passing and Returning Values"). But please don't add it
there -- it's completely redundant, as section 5.1 already says that
the Itanium C++ ABI is used, so it's not necessary to duplicate rules
from there.
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote: > Here is the link: > > https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4 The document contains this claim (as do many other psABI documents): "Bit-fields that are neither signed nor unsigned always have non-negative values. Although they may have type char, short, int, or long (which can have negative values), these bit-fields have the same range as a bit-field of the same size with the corresponding unsigned type." This does not reflect the ABI as widely implemented, and is incompatible with C++ (in which plain bit-fields are required to be signed). GCC documents why they ignore the psABI in this regard here: https://gcc.gnu.org/onlinedocs/gcc/Non-bugs.html#Non-bugs I would suggest either removing this specification from the psABI or correcting it to reflect actual implementation practice: plain bit-fields are signed.
Re: [LLVMdev] FYI: IA-32 psABI draft version 0.1
On Thu, Jan 22, 2015 at 12:05 PM, H.J. Lu wrote:
> On Thu, Jan 22, 2015 at 12:00 PM, H.J. Lu wrote:
>> On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith
>> wrote:
>>> On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote:
>>>> Here is the link:
>>>>
>>>> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
>>>
>>> The document contains this claim (as do many other psABI documents):
>>>
>>> "Bit-fields that are neither signed nor unsigned
>>> always have non-negative values. Although they may have type char,
>>> short, int, or long (which can have negative values), these bit-fields
>>> have the same range as a bit-field of the same size with the
>>> corresponding unsigned type."
>>>
>>
>> Can you show me where this paragraph in IA-32 psABI?
>> I couldn't find it in my copy.
>>
>
> FYI :-):
>
> commit 2496a6db377b489668e49c39b6f477a4f8f0ec22
> Author: H.J. Lu
> Date: Wed Jan 7 13:05:49 2015 -0800
>
> Remove Bit-Fields
Ah, I was looking at the wrong branch ('master' instead of
'hjl/x86/master'). Thanks =)
Re: __builtin_dynamic_object_size
[Please CC me; I'm not subscribed] On Thu, 24 Jan 2019 11:59 at Richard Biener wrote: > On Wed, Jan 23, 2019 at 12:33 PM Jakub Jelinek wrote: > > On Wed, Jan 23, 2019 at 10:40:43AM +, Jonathan Wakely wrote: > > > There's a patch to add __builtin_dynamic_object_size to clang: > > > https://reviews.llvm.org/D56760 > > > > > > It was suggested that this could be done via a new flag bit for > > > __builtin_object_size, but only if GCC would support that too > > > (otherwise it would be done as a separate builtin). > > > > > > Is there any interest in adding that as an option to > > > __builtin_object_size? > > > > > > I know Jakub is concerned about arbitrarily complex expressions, when > > > __builtin_object_size is supposed to always be efficient and always > > > evaluate at compile time (which would imply the dynamic behaviour > > > should be a separate builtin, if it exists at all). > > > > The current modes (0-3) certainly must not be changed and must return a > > constant, that is what huge amounts of code in the wild relies on. > > I wouldn't overload _bos but only use a new builtin. Clang provides another useful attribute in this space: __attribute__((pass_object_size(N))), when applied to a pointer parameter to a function, causes the compiler to evaluate __builtin_object_size in the caller, and pass the result to the callee (see https://clang.llvm.org/docs/AttributeReference.html#pass-object-size). This allows many of the _FORTIFY_SOURCE checks to be implemented without forcibly inlining. One reason we'd like to see this added as a flag bit rather than as a separate builtin is that it would then also naturally extend to the pass_object_size attribute. But we certainly don't want to conflict with any potential future GCC extension. If the GCC devs aren't interested in adding similar functionality, could we reserve a bit for this behavior? Eg, if GCC would promise to never use the values 4-7 for any other purpose, I expect that'd work for us, but I'd certainly understand if you don't want to guarantee that. > > The reason to choose constants only was the desire to make _FORTIFY_SOURCE > > cheap at runtime. For the dynamically computed expressions, the question > > is how far it should go, how complex expressions it wants to build and how > > much code and runtime can be spent on computing that. > > > > The rationale for __builtin_dynamic_object_size lists only very simple > > cases, where the builtin is just called on result of malloc, so that is > > indeed easy, the argument is already evaluated before the malloc call, so > > you can just save it in a temporary and use later. Slightly more complex > > is calloc, where you need to multiply two numbers (do you handle overflow > > somehow, or not?). But in real world, it can be arbitrarily more complex, > > there can be pointer arithmetics with constant or variable offsets, > > there can be conditional adjustments of pointers or PHIs with multiple > > "dynamic" expressions for the sizes (shall the dynamic expression evaluate > > as max over expressions for different phi arguments (that is essentially > > what is done for the constant __builtin_object_size, but for dynamic > > expressions max needs to be computed at runtime, or shall it reconstruct > > the conditional or remember it and compute whatever ? val1 : val2), > > loops which adjust pointers, etc. and all that can be done many times in > > between where the objects are allocated and where the builtin is used. > > Which means I'd like to see a thorough specification of the builtin. How far you go is a quality of implementation issue, just like with all the existing __builtin_object_size modes -- you're always permitted to return a conservatively-correct answer, for any mode. (Ignoring the new flag bit would be a correct implementation, for example.) But the intent is for this to be used in cases where users want the security benefits more than they want a modicum of performance. > If it is allowed to return "failure" in any event then of what use is > the builtin in practice? The same question can be asked of the existing builtin, which has the same property that it is allowed to return "failure" in any event. That's already useful in practice, and it's hopefully also apparent that catching just the easy non-constant cases (eg, a parameter passed to malloc also gets used as the object size of the returned pointer) would also be useful in practice.
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Fri, Oct 19, 2012 at 10:53 PM, Chandler Carruth wrote:
>
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith
> wrote:
> >
> > [Crossposted to both GCC and Clang dev lists]
> >
> > Hi,
> >
> > One issue facing library authors wanting to use C++11's constexpr
> > feature is that the same implementation must be provided for both the case
> > of function invocation substitution and for execution at runtime. Due to the
> > constraints on constexpr function definitions, this can force an
> > implementation of a library function to be inefficient. To counteract this,
> > I'd like to propose the addition of a builtin:
> >
> > bool __builtin_constexpr_p()
> >
> > This builtin would only be supported within constexpr function
> > definitions. If the containing function is undergoing function invocation
> > substitution, it returns true. Otherwise, it returns false. Hence we can
> > implement library functions with a pattern like:
> >
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t
> > n) {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 :
> > constexpr_strncmp(p+1, q+1, n-1);
> > }
> > __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> > const char *q, size_t n) {
> > return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) :
> > strncmp(p, q, n);
> > }
> >
> > Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some
> concerns about the interface. Let me hypothesize a different
> interface:
>
> This stays the same...
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t n)
> > {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> > q+1, n-1);
> > }
>
>
> But here we do something different on the actual declaration:
> >
> > [[constexpr_alias(constexpr_strncmp)]]
> > int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the
> function name passed to constexpr_alias. We must find a constexpr
> function with an identical signature. Then, at function invocation
> substitution of strncmp, we instead substitute the body of
> constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also
> provides a specific advantage of allowing this to be easily added to
> an existing declaration in a declaration-only header file without
> impacting or changing the name of the runtime executed body or
> definition.
I really like this approach.
> -Chandler
>
> PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail
> client.
(Likewise)
Re: [cfe-dev] C++11: new builtin to allow constexpr to be applied to performance-critical functions
On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis wrote: > On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote: >> While throwing things out there, why not just optionally allow constexpr >> functions to coexist with non-constexpr functions of the same name, like >> inline and non-inline? I think this is fundamentally the wrong approach. Constexpr functions aren't a different kind of function, they're just functions for which are sometimes required to be evaluated at translation time. Hence overload resolution should not depend on whether a function is constexpr. Also, this approach tends to require two definitions of constexpr functions even where the definitions are the same (if one calls a constexpr overload and the other calls a non-constexpr overload). What we want is just a mechanism to make function invocation substitution take a different path if it encounters a function which it can't process (because the runtime form of that function is somehow written in a way that it can't handle). > Or remove most of the restrictions on constexpr functions that were necessary > only to win approval for C++11. This case doesn't strike me as one of > those where you fight complexity with even greater complexity. > > Allow loops and the like in constexpr functions and be done with it. See my > comments on the C++ Extension Working Group when these (and related) > issues where brought up. Yes, I completely agree, but I don't think this solves the whole problem. There are certain constructs which we are unlikely to *ever* permit in constexpr functions, such as (as an extreme case) inline assembly. Where possible, we should share an implementation between compile time and runtime. This proposal is for the exceptional cases (which, over time, should become fewer and fewer), and as a stopgap measure while we work towards the right solution.
Re: C++ ABI: name mangling of operator new [bug 6057]
Doug Gregor wrote:
> Now, we're saying that any expressions are valid in
> sizeof, decltype, and constant expressions. If those
> expressions fail to type-check during substitution, it
> will be a SFINAE case.
Just to be sure we're not talking at cross purposes, can I
check that the current thinking on DR 339 is that type
traits such as the following should be legal (and do the
obvious thing):
template
class is_default_constructible {
template struct helper {};
typedef char no; typedef char yes[2];
static no fn(...);
static yes fn( helper* );
public:
static const bool value = sizeof(fn(0)) == sizeof(yes);
};
If so, that's excellent news.
Richard Smith
Re: C++ ABI: name mangling of operator new [bug 6057]
Gabriel Dos Reis wrote:
> On Wednesday July 18, 2007 I brought factual evidence to
> that claim by showing g++ behaviour on all of the examples
> discussed (including those from the "decltype" proposal).
> (All I did was to encode call expressions, new expressions
> and a few other tree nodes).
I'm curious as to how this works with overloaded functions.
The general philosophy in the current ABI would seem to be
that the expression is encoded in terms of its template
parameters, and not with the evaluated expression with the
subsituted argument. That is, for
template void fn( A<-I> );
the specialisation fn<1> would be mangled as
_Z2fnILi1EEv1AIXngT_EE void fn( A<-I> ) [with I=1]
instead of, say,
_Z2fnILi1EEv1AILin1EEvoid fn( A<-1> ) [with I=1]
This has the result that all specialisations of this
template have the mangled form
_Z2fnI{parameters}Ev1AIXngT_EE
(I'm not convinced this is absolutely necessary, even though
it seems a good idea. The oft-quoted example is
template A fn(A, A);
template A fn(A, A);
and then setting I=J=0. If you substuted the arguments,
you'd get _Z2fnILi0ELi0EE1AILi0EES0_ILi0EES0_ILi0EE for
both. However, by my reading of 14.5.5.1, these are
functionally equivalent but not equivalent and thus render
the program ill-formed; no diagnostic required.)
However, the obvious strategy for dealing with overloaded
functions is to perform overload resolution and then mangle
the selected overload. For example, if we make up the
syntax
::= ...
::= cl
_
::= + _
to mangle a function call, and you could mangle the
call to the non-overloaded function, foo:
template int foo(T);
template A {};
template void bar( A );
The obvious strategy is to encode bar as (I think)
_Z3barIiLi42EEv1AIXszclL_Z3fooIiEiT_ET0__EE
where _Z3fooIiEiT_ is the result of subsituting T=int into
the definition of foo. But this means that the template
parameters of bar are repeated and all the specialisations
of bar no longer have the form
_Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
... because the 'i' from T=int is repeated. (Again, this is
only a problem if one wants to mangle two 'functionally
equivalent' overloads.) An alernative is to propagate bar's
parameter into foo's argument:
_Z3barIiLi42EEv1AIXszclL_Z3fooIT_EiT_ET0__EE
But then extending this to an overloaded function call of
foo looks very hard, as you no longer know the function is
being called when you want to mangle the expression
'foo(V)'. Effectively, you have a choice: mangle the whole
of the candidate set (or enough information to regenerate
it); or mangle the name after overload resolution and loose
the ability to mangle 'functionally equivalent' expressions
accurately. The latter sounds far easier, but is contrary
to the spirit of the existing ABI.
Richard Smith
C++ ABI: name mangling of operator new [bug 6057]
About five years ago, I reported a bug about an ICE when
trying to mangle expressions involving operator new.
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01417.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6057
A three line example exhibiting the ICE is:
template struct helper {};
template void check( helper* );
int main() { check(0); }
As I understand it, the reason that this has never been
fixed is that a full fix requires either an extension/change
to the ABI which presumably requires collaboration between
the eight organisations that produced it.
I'm wondering whether there's any prospect of this
happening, and if not, whether GCC should use the vendor
extension syntax (v ) to provide a fix?
As it stands, the ABI's definition of mangling a new
expression makes no sense as it has no way of folding the
type into the mangled name. (It doesn't even say whether
operator new is to be regarded as a unary operator, per the
C++ standard, or binary or ternary. In terms of the
information needed in the mangled name, it should be ternary
as there are placement arguments, the type, and constructor
arguments.)
Although the bug only manifests in fairly arcane code, it
can nevertheless occur in legal code: I've generally
encountered it when developing type traits using template
metaprogramming.
Richard Smith
Re: C++ ABI: name mangling of operator new [bug 6057]
Doug Gregor wrote:
> Hi Richard,
>
> On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
>
> > A three line example exhibiting the ICE is:
> >
> > template struct helper {};
> > template void check( helper* );
> > int main() { check(0); }
> >
[...]
>
> This kind of thing came up that the last C++ committee meeting, as
> part of core issue 339:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#339
>
> Name mangling is part of the problem, but not all of it. There is also
> the issue of what happens when there is an error in the expression
> "new T": is it part of the Substitution Failure Is Not An Error
> (SFINAE) rule, meaning that the function would not enter the overload
> set, or does it trigger an error immediately? That's actually the more
> complicated issue.
Thanks for pointing DR 339 out to me; whilst I had read it
before, it was before the note from the Apr 2007 meeting was
added.
Although the 'compromise proposal' appears to avoid all of
these problems by making my example illegal, it would appear
that N2235 'Generalized Constant Expressions' reintroduces
many of them again. To give an example,
constexpr long foo( long l ) { return l; }
constexpr int foo( int i ) { return i; }
template struct helper {};
template
void check( helper* );
int main() { check(0); }
In this case, I think we need to mangle the call to (the
candidate set for the unqualified name) foo before carrying
out overload resolution. (And it would be possible to
produce a similar example involving ADL of a type with a
constexpr constructor, we don't necessarily even know the
scope of foo.)
This resolution to DR 339 would remove the need to handle
the mangling of new, new[], delete, delete[], dynamic_cast
and throw, but as constructor calls (i.e. T()), and calls to
possibly-overloaded functions (including member functions
and template functions), and calls to operator() remain,
this seems like very little significant gain.
In any case, it seems hard to justify not compiling (with
-std=c++98) the example quoted at the top of this email as,
notwithstanding DR 339, it's hard to think of an
interpretation of the current standard under which it is
illegal. (Even if this was not the intention.)
Richard Smith
Re: C++ ABI: name mangling of operator new [bug 6057]
Gabriel Dos Reis wrote:
> At the C++ language level, there are concerns of how to specify the
> interaction. All I claimed was that the observable semantics
> does not need further specification to make the examples work.
>
> At the compiler internals level, how overloads are handled has a much
> wider variety of practice and I do not think we should have a standard
> that says exactly how that should be implemented, as opposed to what the
> end behaviour should be.
Agreed.
> At the moment, GCC/g++ would ICE claiming that it does not know how
> mangle a call expression (and a few othr nodes). My claim is that if
> that problem is solved (by whatever means), the overload and template
> machinery does not need further modification to handle all the examples
> officially presented so far.
That sounds a reasonable claim.
> | The general philosophy in the current ABI would seem to be
> | that the expression is encoded in terms of its template
> | parameters, and not with the evaluated expression with the
> | subsituted argument.
>
> That is correct. For a compiler, such as GCC, that uses parse trees
> to represent a template declaration there is no additional
> difficultly in mangling the expression, compared to the 'ordinary' case.
My concern is how, practically, to mangle a call to an
overloaded function, as, if the philosophy of encoding the
expression in terms of template parameters is continued, you
have to introduce ways of mangling the linked list of
FUNCTION_DECLs in an OVERLOAD node. This is certainly not
impossible, but likely to be long-winded. And the
possibility of ADL means that the overload set won't be the
same for each instantiation of the template
E.g. in
int foo(int); long foo(long);
template A {};
template void bar( A );
we could introduce
O E
to represent a overload set and represent the sizeof
expression as
szcl2OL_Z3fooiEL_Z3foolEET0_
(where I've adopted your mangling of call expression rather
than the one I suggested).
A better approach might be to fall back to the token stream
and mangle the token stream representing the function being
called. E.g. in the same way that
sr
gives you a way of mangling sizeof( T::foo() ), a variant
could be introduced for unqualified names, e.g.
su
which would allow the original sizeof(foo(V)) to be mangled
as
szcl2su3fooT0_
which is much more concise than mangling the overload set,
and more accurately reflects the 'same token stream'
requirement of the standard. (Though, 14.6.4.1/7 already
makes the program ill-formed, no diagnostic required, if a
specialisation has different meanings at different points of
instantiation, so the difference can only affect ill-formed
programs, I think.)
> | to mangle a function call, and you could mangle the
> | call to the non-overloaded function, foo:
> |
> | template int foo(T);
> | template A {};
> | template void bar( A );
> |
> | The obvious strategy is to encode bar as (I think)
> |
> | _Z3barIiLi42EEv1AIXszclL_Z3fooIiEiT_ET0__EE
> |
> | where _Z3fooIiEiT_ is the result of subsituting T=int into
> | the definition of foo. But this means that the template
> | parameters of bar are repeated and all the specialisations
> | of bar no longer have the form
> |
> | _Z3barI{parameters}Ev1AIXszclL_Z3fooIiEiT_ET0__EE
> |
> | ... because the 'i' from T=int is repeated. (Again, this is
> | only a problem if one wants to mangle two 'functionally
> | equivalent' overloads.)
>
> The killing point for GCC/g++ is to mangle the original template
> declaration -- not just the result of instantiation -- that is close
> to the 'same token stream' requirement of the C++ definition.
But does this have to be a killing point for GCC?
Although it seems preferable to stick as close to the
original template declaration as possible, and the note in
14.5.5.8 suggests that as a QoI issue, a compiler should aim
to treat functionally equivalent declarations that are not
equivalent as distinct, the 'functionally equivalent not not
equivalent' [14.5.5.1/7] rule grants compilers licence to
ignore any particularly tricky cases. That said, I think
my suggestion, above, of mangling the unmangled, unqualified
name gets around this.
Richard Smith
