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
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
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. 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. François On 29/03/2023 01:33, Ken Matsui wrote: 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
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
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 > > > > > >
Re: [GSoC] Conflicted Built-in Trait Name
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 > > >
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, 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::__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, 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.
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 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::__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
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?
Re: [GSoC] Conflicted Built-in Trait Name
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? -- Marc Glisse
Re: [GSoC] Conflicted Built-in Trait Name
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 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] 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
