Re: [GSoC][Improve nothrow detection]: Suggestions to get started
Ping for [GSoC][Improve nothrow detection]: Suggestions to get started. Could you please take a look when you get a chance? Sincerely, Ken Matsui On Wed, Feb 28, 2024 at 8:00 AM Ken Matsui wrote: > > Hi Jan, > > My name is Ken Matsui. I am highly interested in contributing to your > GSoC 2024 project idea, "Improve nothrow detection in GCC." To get > started with understanding your project (and, if possible, making > small patches), could you please give me some suggestions on what > files to read (and edit) and what to do first? > > Thank you for your help! > > Sincerely, > Ken Matsui
[GSoC][Improve nothrow detection]: Suggestions to get started
Hi Jan, My name is Ken Matsui. I am highly interested in contributing to your GSoC 2024 project idea, "Improve nothrow detection in GCC." To get started with understanding your project (and, if possible, making small patches), could you please give me some suggestions on what files to read (and edit) and what to do first? Thank you for your help! Sincerely, Ken Matsui
Re: Compilation Error Regarding RID_MAX
On Wed, Sep 13, 2023 at 9:38 PM Andrew Pinski wrote: > > On Wed, Sep 13, 2023 at 9:35 PM Ken Matsui wrote: > > > > On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > > > > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc > > > wrote: > > > > > > > > Hi, > > > > > > > > I have merged all my patches into a single branch for better > > > > maintainability for me, but I am unable to build GCC. Initially, I > > > > faced an error related to RID_MAX, which was fixed in > > > > https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. > > > > The ICE was caused by gcc_assert (RID_MAX <= 255) in gcc/c/c-parser.c. > > > > At this point, my new built-in exceeded the max keyword bound since > > > > c_token->keyword has 8 bits. This patch increased the bit size to 16 > > > > and compiled GCC successfully. > > > > > > > > However, I still encountered an unusual error and am unable to build > > > > GCC on > > > > https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. > > > > This is the 4th built-in implementation after the previous RID_MAX fix > > > > patch (i.e., this increases the total number of keywords, now RID_MAX > > > > = 260). The error message indicates that there is a missing > > > > parenthesis after 'unsigned' for the expression (unsigned __int128). > > > > > > > > /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:38: error: > > > > expected ‘)’ before ‘__int128’ > > > >86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; > > > > | ~^ > > > > | ) > > > > /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:29: error: > > > > initializer element is not constant > > > >86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; > > > > | > > > > > > > > I reordered the commits, but it seems that the 4th built-in (RID_MAX = > > > > 260) after the RID_MAX tweak fails, regardless of what the 4th is. > > > > (i.e., the __remove_pointer implementation itself is not the reason.) > > > > > > From c-common.h: > > > #define C_SET_RID_CODE(id, code) \ > > > (((struct c_common_identifier *) (id))->node.rid_code = (unsigned char) > > > code) > > > > > > This is definitely incorrect now. It should be using `unsigned short`. > > > > > > > That worked! Thank you so much! > > > > I would like to attribute this change to you, but if you're > > comfortable with it, could you please share the relevant commit > > information (name and email address)? > > Andrew Pinski > Thank you! > Thanks, > Andrew > > > > > > Thanks, > > > Andrew > > > > > > > > > > > I have pushed the > > > > branch to https://github.com/ken-matsui/gcc-gsoc23/commits/me/gsoc23. > > > > Could someone please help me inspect the issue and provide your > > > > suggestions? > > > > > > > > Sincerely, > > > > Ken Matsui
Re: Compilation Error Regarding RID_MAX
On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > > > Hi, > > > > I have merged all my patches into a single branch for better > > maintainability for me, but I am unable to build GCC. Initially, I > > faced an error related to RID_MAX, which was fixed in > > https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. > > The ICE was caused by gcc_assert (RID_MAX <= 255) in gcc/c/c-parser.c. > > At this point, my new built-in exceeded the max keyword bound since > > c_token->keyword has 8 bits. This patch increased the bit size to 16 > > and compiled GCC successfully. > > > > However, I still encountered an unusual error and am unable to build > > GCC on > > https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. > > This is the 4th built-in implementation after the previous RID_MAX fix > > patch (i.e., this increases the total number of keywords, now RID_MAX > > = 260). The error message indicates that there is a missing > > parenthesis after 'unsigned' for the expression (unsigned __int128). > > > > /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:38: error: > > expected ‘)’ before ‘__int128’ > >86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; > > | ~^ > > | ) > > /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:29: error: > > initializer element is not constant > >86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; > > | > > > > I reordered the commits, but it seems that the 4th built-in (RID_MAX = > > 260) after the RID_MAX tweak fails, regardless of what the 4th is. > > (i.e., the __remove_pointer implementation itself is not the reason.) > > From c-common.h: > #define C_SET_RID_CODE(id, code) \ > (((struct c_common_identifier *) (id))->node.rid_code = (unsigned char) > code) > > This is definitely incorrect now. It should be using `unsigned short`. > That worked! Thank you so much! I would like to attribute this change to you, but if you're comfortable with it, could you please share the relevant commit information (name and email address)? > Thanks, > Andrew > > > > > I have pushed the > > branch to https://github.com/ken-matsui/gcc-gsoc23/commits/me/gsoc23. > > Could someone please help me inspect the issue and provide your > > suggestions? > > > > Sincerely, > > Ken Matsui
Compilation Error Regarding RID_MAX
Hi, I have merged all my patches into a single branch for better maintainability for me, but I am unable to build GCC. Initially, I faced an error related to RID_MAX, which was fixed in https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. The ICE was caused by gcc_assert (RID_MAX <= 255) in gcc/c/c-parser.c. At this point, my new built-in exceeded the max keyword bound since c_token->keyword has 8 bits. This patch increased the bit size to 16 and compiled GCC successfully. However, I still encountered an unusual error and am unable to build GCC on https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. This is the 4th built-in implementation after the previous RID_MAX fix patch (i.e., this increases the total number of keywords, now RID_MAX = 260). The error message indicates that there is a missing parenthesis after 'unsigned' for the expression (unsigned __int128). /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:38: error: expected ‘)’ before ‘__int128’ 86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; | ~^ | ) /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:29: error: initializer element is not constant 86 | unsigned __int128 __res = (unsigned __int128) __X * __Y; | I reordered the commits, but it seems that the 4th built-in (RID_MAX = 260) after the RID_MAX tweak fails, regardless of what the 4th is. (i.e., the __remove_pointer implementation itself is not the reason.) I have pushed the branch to https://github.com/ken-matsui/gcc-gsoc23/commits/me/gsoc23. Could someone please help me inspect the issue and provide your suggestions? Sincerely, Ken Matsui
Re: [GSoC] Conflicted Built-in Trait Name
I see. Thank you for the clarification! On Thu, Mar 30, 2023 at 5:23 AM Jonathan Wakely wrote: > > On Thu, 30 Mar 2023 at 09:33, Ken Matsui wrote: > > > > Hi François, > > > > On Wed, Mar 29, 2023 at 10:11 PM François Dumont > > wrote: > > > > > > Hi > > > > > > Do not hesitate to dig into library doc. Especially this page: > > > > > > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html > > > > > > You can also find it in your git clone in > > > /libstdc++-v3/doc/html. > > > > > > You'll see also how to run test in different std modes like --std=c++98 > > > to catch the kind of issue reported by Jonathan. > > > > This is what I wanted to know! Thank you so much! > > > > > Regarding your patches I wonder if it's not too splitted. 1 patch per > > > builtin would sound more logical, at least for an easy one like __is_void. > > > > I see. I will squash is_void-related commits into the commit of > > __is_void implementation. Thank you for pointing it out! > > > Yes, good point, François. These kind of changes for the front-end and > library should be in one patch. Otherwise, if they were committed > separately then you would create a revision where bootstrap fails. If > the front-end change is committed without the library change, then you > can't build the library because it still uses __is_void which is now a > keyword. If the library change is committed first then you don't break > bootstrap, but you're adding support to the library for a new built-in > which doesn't actually exist (yet). They should be a single revision, > so that the tree can always be built. >
Re: [GSoC] Conflicted Built-in Trait Name
Hi François, On Wed, Mar 29, 2023 at 10:11 PM François Dumont wrote: > > Hi > > Do not hesitate to dig into library doc. Especially this page: > > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html > > You can also find it in your git clone in /libstdc++-v3/doc/html. > > You'll see also how to run test in different std modes like --std=c++98 > to catch the kind of issue reported by Jonathan. This is what I wanted to know! Thank you so much! > Regarding your patches I wonder if it's not too splitted. 1 patch per > builtin would sound more logical, at least for an easy one like __is_void. I see. I will squash is_void-related commits into the commit of __is_void implementation. Thank you for pointing it out! Sincerely, Ken Matsui
Re: [GSoC] Conflicted Built-in Trait Name
Oooh, thank you for your help! On Tue, Mar 28, 2023 at 4:25 PM Jonathan Wakely wrote: > > On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++ > wrote: > > > > Hi François, > > > > I tried to use `make check-debug`, but my Makefile does not include > > the target. Could you please tell me how you generated your Makefile? > > It's a target in the libstdc++ makefile, so you need to run it from > the $target/libstdc++-v3 directory. >
Re: [GSoC] Conflicted Built-in Trait Name
Hi François,
I tried to use `make check-debug`, but my Makefile does not include
the target. Could you please tell me how you generated your Makefile?
FYI, I did this command: `../configure --enable-languages=c++
--disable-error --disable-bootstrap`.
Sincerely,
Ken Matsui
On Mon, Mar 27, 2023 at 10:33 AM François Dumont wrote:
>
>
> On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse wrote:
> >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> >>
> >>> Built-in trait naming simply adds two underscores (__) to the original
> >>> trait name. However, the same names are already in use for some
> >>> built-in traits, such as is_void, is_pointer, and is_signed.
> >>>
> >>> For example, __is_void is used in the following files:
> >>>
> >>> * gcc/testsuite/g++.dg/tm/pr46567.C
> >> This is a testcase, you can rename __is_void to whatever in there, it
> >> doesn't matter.
> >>
> >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> >> This __is_void seems to be used in a single place in
> >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> >> becomes unused and can be removed?
> > That worked. Thank you!
> What worked ?
> >
> > So, we can remove a code in a header as long as it is not standard and
> > is not used elsewhere, can't we?
>
> You can do anything you like as long as you run the testsuite before
> presenting your patch. Here note that you'll need to run:
>
> make check-debug
>
> to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> helper_functions.h.
>
> Clearly this usage of std::__is_void could be replaced with your builtin
> by reimplementing _Distance_traits like this:
>
>template typename = typename std::__is_integer<_Iterator>::__type>
> struct _Distance_traits
> {
> private:
>typedef
> typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
>typedef
> typename std::conditional<__is_void<_ItDiffType>,
>std::ptrdiff_t, _ItDiffType>::type _DiffType;
>
> public:
>typedef std::pair<_DiffType, _Distance_precision> __type;
> };
>
> this is untested, just to give you an idea of what your patch could be.
>
> François
>
>
Re: [GSoC] Conflicted Built-in Trait Name
Jacobson's email was treated as spam somehow. Sorry for missing your email. On Mon, Mar 27, 2023 at 2:59 PM Jonathan Wakely wrote: > > On Sat, 25 Mar 2023 at 12:23, Roy Jacobson via Libstdc++ > wrote: > > > > Clang has been providing __is_void for a very long time now, and is > > definitely compatible with libstdc++. Does defining this builtin cause a > > problem? Might be that the lookup rules for builtins are different or > > something. > > > > https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives > > Clang has special hacks that allow it to handle libstdc++ headers. > When it sees the use of a built-in trait like __is_void used as an > identifier, it disables the built-in and treats it as a normal > identifier for the rest of the translation unit. GCC doesn't do that, > so "it compiles with Clang" isn't really relevant here. > > > > > > On Sat, 25 Mar 2023 at 15:08, Ken Matsui via Gcc wrote: > > > > > Hi, > > > > > > I am working on the GSoC project, "C++: Implement compiler built-in > > > traits for the standard library traits". > > > > > > Built-in trait naming simply adds two underscores (__) to the original > > > trait name. However, the same names are already in use for some > > > built-in traits, such as is_void, is_pointer, and is_signed. > > > > > > For example, __is_void is used in the following files: > > > > > > * gcc/testsuite/g++.dg/tm/pr46567.C > > > * libstdc++-v3/include/bits/cpp_type_traits.h > > > > > > In this case, are we supposed to change the existing same name in the > > > code to something like is_void (four underscores)? Or is it better > > > to break the naming convention of built-in traits like > > > __is_void_builtin? > > > > > > Sincerely, > > > Ken Matsui > > > > > >
[GSoC] C++: Compiler Built-in Traits
Hi, I am Ken, an undergraduate student majoring in Computer Science and minoring in Linguistics (because of my interest in syntax from both natural and programming languages prospectives) at University of Washington, Seattle. I am interested in the GSoC project: C++: Implement compiler built-in traits for the standard library traits. I have submitted some patches (but some need fixing) related to this project. I wrote my proposal for GSoC 2023, so could someone please review it at your convenience? https://docs.google.com/document/d/1_ya4oASA8VPI0YJPGHds8OxILt2XgnxAMTWLAWDD860/edit?usp=sharing Sincerely, Ken Matsui
Re: [GSoC] Conflicted Built-in Trait Name
Oh! Thank you!
On Mon, Mar 27, 2023 at 2:49 PM Jonathan Wakely wrote:
>
> On Mon, 27 Mar 2023 at 22:43, Jonathan Wakely wrote:
> >
> > On Mon, 27 Mar 2023 at 21:17, Ken Matsui via Libstdc++
> > wrote:
> > >
> > > On Mon, Mar 27, 2023 at 10:33 AM François Dumont
> > > wrote:
> > > >
> > > >
> > > > On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > > > > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse
> > > > > wrote:
> > > > >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> > > > >>
> > > > >>> Built-in trait naming simply adds two underscores (__) to the
> > > > >>> original
> > > > >>> trait name. However, the same names are already in use for some
> > > > >>> built-in traits, such as is_void, is_pointer, and is_signed.
> > > > >>>
> > > > >>> For example, __is_void is used in the following files:
> > > > >>>
> > > > >>> * gcc/testsuite/g++.dg/tm/pr46567.C
> > > > >> This is a testcase, you can rename __is_void to whatever in there, it
> > > > >> doesn't matter.
> > > > >>
> > > > >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> > > > >> This __is_void seems to be used in a single place in
> > > > >> include/debug/helper_functions.h, couldn't we tweak that code so
> > > > >> __is_void
> > > > >> becomes unused and can be removed?
> > > > > That worked. Thank you!
> > > > What worked ?
> > >
> > > If you meant about the code, I sent a patch series, as you can see in
> > > the following link.
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html
> > >
> > > * In the following patch, I replaced __is_void with std::is_void in
> > > helper_functions.h.
> >
> > You can't do that. std::is_void is not present in C++98 mode, but the
> > code in needs to work for C++98 mode.
> >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
> > > * And then, I deleted __is_void in cpp_type_traits.h.
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
> > > * Also, I replaced __is_void with is_void in the testcase.
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html
> > >
> > > If you meant what tests had been done, I did the following tests
> > > because the header is under libstdc++.
> > >
> > > * make check-gcc-c++ (because the patches involve changes on GCC)
> > > * make check-target-libstdc++-v3
> > >
> > > > > So, we can remove a code in a header as long as it is not standard and
> > > > > is not used elsewhere, can't we?
> > > >
> > > > You can do anything you like as long as you run the testsuite before
> > > > presenting your patch. Here note that you'll need to run:
> > > >
> > > > make check-debug
> > > >
> > > > to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> > > > helper_functions.h.
> > > >
> > > > Clearly this usage of std::__is_void could be replaced with your builtin
> > > > by reimplementing _Distance_traits like this:
> > > >
> > > >template > > > typename = typename std::__is_integer<_Iterator>::__type>
> > > > struct _Distance_traits
> > > > {
> > > > private:
> > > >typedef
> > > > typename std::iterator_traits<_Iterator>::difference_type
> > > > _ItDiffType;
> > > >
> > > >typedef
> > > > typename std::conditional<__is_void<_ItDiffType>,
> > > >std::ptrdiff_t, _ItDiffType>::type _DiffType;
> > > >
> > > > public:
> > > >typedef std::pair<_DiffType, _Distance_precision> __type;
> > > > };
> > > >
> > > > this is untested, just to give you an idea of what your patch could be.
> > > >
> > > > François
> > >
> > > Thank you! I thought the tests that I did included the
> > > hepler_function.h header, but they don’t...? If not, I must check if
> > > std::is_void in the type_traits header was correctly used.
>
> Something like this would work:
>
> --- a/libstdc++-v3/include/debug/helper_functions.h
> +++ b/libstdc++-v3/include/debug/helper_functions.h
> @@ -66,13 +66,12 @@ namespace __gnu_debug
> typedef
>typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
> - template - typename = typename std::__is_void<_DiffType>::__type>
> + template
>struct _DiffTraits
>{ typedef _DiffType __type; };
>
> template
> - struct _DiffTraits<_DiffType, std::__true_type>
> + struct _DiffTraits<_DiffType, const void>
>{ typedef std::ptrdiff_t __type; };
>
> typedef typename _DiffTraits<_ItDiffType>::__type _DiffType;
Re: [GSoC] Conflicted Built-in Trait Name
On Mon, Mar 27, 2023 at 10:33 AM François Dumont wrote:
>
>
> On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse wrote:
> >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> >>
> >>> Built-in trait naming simply adds two underscores (__) to the original
> >>> trait name. However, the same names are already in use for some
> >>> built-in traits, such as is_void, is_pointer, and is_signed.
> >>>
> >>> For example, __is_void is used in the following files:
> >>>
> >>> * gcc/testsuite/g++.dg/tm/pr46567.C
> >> This is a testcase, you can rename __is_void to whatever in there, it
> >> doesn't matter.
> >>
> >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> >> This __is_void seems to be used in a single place in
> >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> >> becomes unused and can be removed?
> > That worked. Thank you!
> What worked ?
If you meant about the code, I sent a patch series, as you can see in
the following link.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html
* In the following patch, I replaced __is_void with std::is_void in
helper_functions.h.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
* And then, I deleted __is_void in cpp_type_traits.h.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
* Also, I replaced __is_void with is_void in the testcase.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html
If you meant what tests had been done, I did the following tests
because the header is under libstdc++.
* make check-gcc-c++ (because the patches involve changes on GCC)
* make check-target-libstdc++-v3
> > So, we can remove a code in a header as long as it is not standard and
> > is not used elsewhere, can't we?
>
> You can do anything you like as long as you run the testsuite before
> presenting your patch. Here note that you'll need to run:
>
> make check-debug
>
> to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> helper_functions.h.
>
> Clearly this usage of std::__is_void could be replaced with your builtin
> by reimplementing _Distance_traits like this:
>
>template typename = typename std::__is_integer<_Iterator>::__type>
> struct _Distance_traits
> {
> private:
>typedef
> typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
>typedef
> typename std::conditional<__is_void<_ItDiffType>,
>std::ptrdiff_t, _ItDiffType>::type _DiffType;
>
> public:
>typedef std::pair<_DiffType, _Distance_precision> __type;
> };
>
> this is untested, just to give you an idea of what your patch could be.
>
> François
Thank you! I thought the tests that I did included the
hepler_function.h header, but they don’t...? If not, I must check if
std::is_void in the type_traits header was correctly used.
Re: [GSoC] Conflicted Built-in Trait Name
On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse wrote: > > On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote: > > > Built-in trait naming simply adds two underscores (__) to the original > > trait name. However, the same names are already in use for some > > built-in traits, such as is_void, is_pointer, and is_signed. > > > > For example, __is_void is used in the following files: > > > > * gcc/testsuite/g++.dg/tm/pr46567.C > > This is a testcase, you can rename __is_void to whatever in there, it > doesn't matter. > > > * libstdc++-v3/include/bits/cpp_type_traits.h > > This __is_void seems to be used in a single place in > include/debug/helper_functions.h, couldn't we tweak that code so __is_void > becomes unused and can be removed? That worked. Thank you! So, we can remove a code in a header as long as it is not standard and is not used elsewhere, can't we?
[GSoC] Conflicted Built-in Trait Name
Hi, I am working on the GSoC project, "C++: Implement compiler built-in traits for the standard library traits". Built-in trait naming simply adds two underscores (__) to the original trait name. However, the same names are already in use for some built-in traits, such as is_void, is_pointer, and is_signed. For example, __is_void is used in the following files: * gcc/testsuite/g++.dg/tm/pr46567.C * libstdc++-v3/include/bits/cpp_type_traits.h In this case, are we supposed to change the existing same name in the code to something like is_void (four underscores)? Or is it better to break the naming convention of built-in traits like __is_void_builtin? Sincerely, Ken Matsui
Re: [GSoC] Question about Relatively Simple Library Traits
On Fri, Mar 24, 2023 at 3:06 AM Jonathan Wakely wrote: > > On Fri, 24 Mar 2023 at 09:58, Jonathan Wakely wrote: > > > > On Fri, 24 Mar 2023 at 07:10, Ken Matsui via Gcc wrote: > > > > > > Hi, > > > > > > I am working on the GSoC project, "C++: Implement compiler built-in > > > traits for the standard library traits". I found the following library > > > traits that I am not sure if implementing built-in traits brings > > > reasonable speed up. > > > > > > * std::is_fundamental > > > * std::is_arithmetic > > > * std::is_scalar > > > * std::is_object > > > * std::is_compound > > > * std::is_scoped_enum > > > > > > For example, std::is_object has no template specializations, but its > > > inheriting class looks complicated. > > > > > > __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type > > > > > > If we define the built-in trait for this trait, we have: (as > > > equivalence of the above code) > > > > > > __bool_constant<__is_object(_Tp)> > > > > > > And __is_object built-in trait should be like: > > > > > > !(type1 == FUNCTION_TYPE || type1 == ...) > > > > > > In this case, could someone tell me which one would be faster? Or, is > > > there no other way to know which but to benchmark? > > > > You should benchmark it anyway, I was always expecting that to be a > > part of this GSoC project :-) > > > > But is_object is NOT a "relatively simple" trait. What you show above > > is very complex. One of the more complex traits we have. Partial > > specializations are quite fast to match (in general) so eliminating > > partial speclializations (e.g. like we have for is_const) should not > > be the goal. > > > > For is_object we instantiate: > > > > is_function > > is_const > > is_reference > > is_void > > __bool_constant > > __or_ > > __not_ > > __bool_constant > > > > This is a ton of work! Instantiating class templates is the slowest > > part of trait evaluation, not matching partial specializations. > > And then if the same program also instantiates is_object (without > the const), then currently we instantiate: > > is_function > is_const > is_reference > is_void > __bool_constant > __or_ > __not_ > __bool_constant > > The first four instantiations are not shared with is_object int>, so we have to instantiate them anew. The last four are common > with is_object so don't need to be instantiated again, the > compiler will have cached those instantiations. > But if the same program also uses is_object then we have another > four new instantiations to generate. And another four for > is_object. And another four for is_object etc. > etc. > > With a built-in they will all use __bool_constant and nothing > else (apart from the top-level is_object specialization itself, > which is unavoidable* since that's the trait actually being > evaluated). > > * In fact, it's not really unavoidable, MSVC avoids it entirely. Their > compiler pattern matches the standard traits and never even > instantiates them, so every use of is_object::value gets expanded > directly to __is_object(T) without instantiating anything. We don't do > that, and if we just replace turn 8 or 9 class template instantiations > into 1 then we'll be doing great. Thank you so much for your detailed explanation! I totally did not understand well what class templates were doing! (And yes, I need to prepare my environment to take benchmarks...) So, do we expect to have __is_object built-in trait? Since std::is_object is a combination of multiple traits, would doing the following be the best implementation over implementing __is_object(T)? (you told me that built-ins make the compiler slightly bigger and slower) __bool_constant This would instantiate only __bool_constant and __bool_constant, which can be mostly shared, and we can also avoid adding an additional built-in. Sincerely, Ken Matsui
[GSoC] Question about Relatively Simple Library Traits
Hi, I am working on the GSoC project, "C++: Implement compiler built-in traits for the standard library traits". I found the following library traits that I am not sure if implementing built-in traits brings reasonable speed up. * std::is_fundamental * std::is_arithmetic * std::is_scalar * std::is_object * std::is_compound * std::is_scoped_enum For example, std::is_object has no template specializations, but its inheriting class looks complicated. __not_<__or_, is_reference<_Tp>, is_void<_Tp>>>::type If we define the built-in trait for this trait, we have: (as equivalence of the above code) __bool_constant<__is_object(_Tp)> And __is_object built-in trait should be like: !(type1 == FUNCTION_TYPE || type1 == ...) In this case, could someone tell me which one would be faster? Or, is there no other way to know which but to benchmark? Sincerely, Ken Matsui
[GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches
Hi, My name is Ken Matsui. I am highly interested in contributing to the project idea, "C++: Implement compiler built-in traits for the standard library traits." To understand how to implement those traits, could you please give me some example implementations of the compiler built-in traits, as well as some recommended traits to get started with making small patches? Also, I would appreciate receiving the contact information for the project mentor, Patrick Palka. Sincerely, Ken Matsui
[GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches
Hi, My name is Ken Matsui. I am highly interested in contributing to the project idea, "C++: Implement compiler built-in traits for the standard library traits." To understand how to implement those traits, could you please give me some example implementations of the compiler built-in traits, as well as some recommended traits to get started with making small patches? Also, I would appreciate receiving the contact information for the project mentor, Patrick Palka. Sincerely, Ken Matsui
