GSoC 2023
Dear all, I am a student of computer science and I was thinking about applying for Google Summer of Code 2023. Naturally, I wanted to reach out to you before applying for GCC projects. >From selected topics you are interested in, several grabbed my attention: 1. Bypass assembler when generating LTO object file 2. Extend the static analysis pass 3. Rust Front-End: HIR Dump 4. Rust Front-End: Improving user errors I have to admit that I feel a bit intimidated by projects of "hard difficulty", because I have seen how hard it is to find your way in a large codebase (which GCC definitely is). Therefore, I would like to ask you for your opinion about these topics and the level of theoretical/practical experience with compilers you are expecting. As for the languages used, I have advanced knowledge of C and intermediate knowledge of C++. Thank you very much for your time. Best regards, Igor Putovný
GSoC Rust : Metadata exports for Rust frontend
Hello GCC developers, I am Omkar Mohanty, currently an undergrad in CS. I have contributed to a number of open Source organizations for the past one year and I have one year experience programming in both Rust and C++. I have attached my proposal for GSoC 2023, I hope it meets the standards of GCC. link : https://docs.google.com/document/d/1CC6OdB3U1TK4e9enFbvjr4XCy2X0Ys_M22NnE5oy5Nc/edit?usp=sharing Thanks
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 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 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, 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
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 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
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 2023
Dear all, I am an undergraduate student of computer science and I am interested in GCC projects for Google Summer of Code 2023. >From selected topics you are interested in, several grabbed my attention: 1. Bypass assembler when generating LTO object file 2. Rust Front-End: HIR Dump 3. Rust Front-End: Improving user errors May I ask you for more information about these projects and other knowledge or skills you are expecting? Thank you very much for your time. Best regards, Igor Putovný
Re: cgraph: does node->inlined_to imply node->clones is non-empty?
Hi,
Martin Jambor writes:
> Hi,
>
> On Sat, Mar 18 2023, Arsen Arsenović wrote:
>> Martin Jambor writes:
>
> [...]
>
For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function.
>>>
>>> No, it fails to remove it. It is still there but should not have been,
>>> that is the problem.
>>
>> Ah - I see.
>>
This decision later trips up the gcc_assert in:
/* Inline clones might be kept around so their materializing allows
further
cloning. If the function the clone is inlined into is removed, we
need
to turn it into normal cone. */
FOR_EACH_FUNCTION (node)
{
if (node->inlined_to
&& !node->callers)
{
gcc_assert (node->clones);
node->inlined_to = NULL;
update_inlined_to_pointer (node, node);
}
node->aux = NULL;
}
.. because it is expecting that an inlined function without callers
(which is necessarily true here as this function is unreachable and so
was ->remove ()'d earlier) has clones.
>>>
>>> The assert makes sure that if we encounter an inlined-to node without
>>> any caller, that it merely holds as the holder of the function body for
>>> its other specialized (think IPA-CP) or inline clones. If node->clones
>>> is false, there are no such clones and it was a bug to mark the node as
>>> required during the removal of unreachable nodes.
>>
>> I see. That makes sense. So, this assert is placed here by convenience
>> rather than being this invariant being absolutely required for the
>> purpose of the loop? (it is related, so this placement makes sense, I
>> just want to confirm whether it's a "mandatory" invariant)
>
> If the assert fails, the algorithm does not work as intended. OTOH, It
> could be a gcc_checking_assert only since user compiled code would still
> work, just would be unnecessarily bigger.
Yes, that is what I was trying to ask ;-) Apologies for failing to
articulate so.
>>
>>> It is correct. An inlined function without a caller is even a logical
>>> oxymoron and can only exist if it has the purpose described above (and
>>> even then probably only in a fairly special circumstances).
>>
>> Right. I wasn't quite sure whether setting inlined_to would remove that
>> caller, but if I understood right, it should not.
>>
>> What is interesting, though, is that there is an attempt to remove this
>> node during ipa_inline:
>
> IPA-inline calls remove_unreachable_nodes to get rid of call graph nodes
> which are known not to be necessary after inlining (inlining can lead to
> redirection of some call graph edges to __builtin_unreachable) and
> unreachable removal... well.. removes nodes.
>
>>
>> (gdb) bt
>> #0 cgraph_edge::remove_callee (
>> this=> "__ct_base "/18> -> )>)
>> at ../../gcc/gcc/cgraph.h:3299
>> #1 0x00d03c37 in cgraph_node::remove_callees (this=> * const 0x76dedaa0 "__ct_base "/18>) at
>> ../../gcc/gcc/cgraph.cc:1743
>> #2 0x00d04387 in cgraph_node::remove (this=> 0x76dedaa0 "__ct_base "/18>) at ../../gcc/gcc/cgraph.cc:1884
>> #3 0x010da74f in symbol_table::remove_unreachable_nodes
>> (this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
>> ../../gcc/gcc/ipa.cc:518
>> #4 0x02b51e53 in ipa_inline () at
>> ../../gcc/gcc/ipa-inline.cc:2761
>> #5 0x02b52cf7 in (anonymous
>> namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
>> ../../gcc/gcc/ipa-inline.cc:3153
>> (etc)
>>
>> ... I presume that my assumption that cgraph_node::remove () should
>> remove nodes from the cgraph_node::next chain is wrong?
>
> Ummm the function does that through the call to
> symtab_node::unregister. But how is that related?
Oh - my bad. I seem to have broken on the wrong condition here.
"value"/28 is *not* removed.
That makes more sense, it'd be confusing if remove() still lead to
FOR_EACH_FUNCTION touching a node.
>>
And as a side question, do all clone nodes have a ->clones pointing to
the same list of all clones, or are they in a tree-ish arrangement,
where clones of clones end up forming a tree, with the clone_of pointer
being a pointer to the parent?
>>>
>>> The latter, they form a tree.
>>
>> I see, that makes sense. Thanks.
>>
(in this instance, the node that trips
the assert has a nullptr clone_of and clones value, which would AIUI
imply that it is the original)
>>>
>>> Yes.
>>>
This train of thinking doesn't end up involving any devirtualization
code, which the PR was originally reproduced with, but my current theory
is that devirtualizing here just exposed an edge case that is decently
well hidden, rather than it playing a crucial role.
>>>
>>> The inlined function is - I believe erroneously - marked as reachable by
>
[GSoC 2023] Rust front-end: HIR dump
Hello, I am writing to express my interest in the HIR dump project in GCC this year. My name is Jiakun Fan, and I am a 3rd year undergraduate student majoring in Computer Science. I believe that this project presents an excellent opportunity for me to make a contribution to the GCC community. I have already done some work about the HIR dump and had discussions with GCCRust developers, which has given me the confidence to tackle this project successfully. If you have any concerns or feedback regarding my proposal, please do not hesitate to contact me. You can find the link to my proposal here: https://hackmd.io/UM6GOcOCRHSl8Ph2rocdVQ?view Best regards, Jiakun Fan
