Re: GSoC Questions
On 2/5/20 7:21 AM, Nicholas Krause wrote: Greetings Martin, I won't be applied but it was good to see you at least got some possible ideas out of my research from the make parts. Two questions as related to GSoC, in terms of long term planning for my work: Hello. 1. *Implement something similar to Clang's/-ftime-trace/*is in my view the most important project for GCC multi-threading as having a real profiler in gcc proper is the biggest bottleneck. Here I would definitely recommend perf which can identify bottleneck, as well as locking issues and so on. Finding shared state and having heuristics is a real thorn without it. Is the goal just to support it as a feature similar to Clang or is this intended to be a real profiler, as it seems so? My intention was to do the same what clang does. The format is quite generic and can be easily extended to support more. 2.*Create a general jobserver client/server library *If its planning to be a library then your probably hooking it into the frontends for C/C++. Not sure who the maintainer for that is but is he aware of the possible changes? It may be good to either have him as another mentor or someone to ask about the frontend parts unless you or Martin Liska have that knowledge. No, first consumer of that should be LTO WPA which runs parallel LTO LTRANS during linking. I'm not targeting any hooking into FEs. P.S. Please CC me next time if you speak about me ;) Thanks, Martin Regards and good luck with GSoC, Nick**
Re: GSoC Questions
On 2/5/20 10:34 AM, Martin Liška wrote: On 2/5/20 7:21 AM, Nicholas Krause wrote: Greetings Martin, I won't be applied but it was good to see you at least got some possible ideas out of my research from the make parts. Two questions as related to GSoC, in terms of long term planning for my work: Hello. 1. *Implement something similar to Clang's/-ftime-trace/*is in my view the most important project for GCC multi-threading as having a real profiler in gcc proper is the biggest bottleneck. Here I would definitely recommend perf which can identify bottleneck, as well as locking issues and so on. Perf is fine but because of the complexity of GCC it does not need great data outside of how much time times take and even them its not great. Basically I've only found out that functions and certain core data structures are used. Its a little hard to explain but its a issue that the GSoC student from last semester was/is running into as well. Basically more fine grained internal data is required then perf seems able to give. One example is figuring out the size of SSA nodes to figure out the best ideas in terms of making the dominantor trees multi-threaded safe/aware. The other would be that it states the garbage collector is using only 5% of the time on a machine with over 100GB of ram. However it does not take into account all of the functions that interact with the garbage collector through GTY() in that percent. Finding shared state and having heuristics is a real thorn without it. Is the goal just to support it as a feature similar to Clang or is this intended to be a real profiler, as it seems so? My intention was to do the same what clang does. The format is quite generic and can be easily extended to support more. That's fine and expected as long as we can extend it out. The bigger concern was if we were unable to. 2.*Create a general jobserver client/server library *If its planning to be a library then your probably hooking it into the frontends for C/C++. Not sure who the maintainer for that is but is he aware of the possible changes? It may be good to either have him as another mentor or someone to ask about the frontend parts unless you or Martin Liska have that knowledge. No, first consumer of that should be LTO WPA which runs parallel LTO LTRANS during linking. I'm not targeting any hooking into FEs. That's fine if you want to do LTO first. Didn't know that was the intended first goal. P.S. Please CC me next time if you speak about me ;) Sorry about that and will do it the future, Nick Thanks, Martin Regards and good luck with GSoC, Nick**
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote: > ANd yes, even though I have been a regular ChangeLog user, I rely more > and more on the git log these days. As a reviewer, the changelog is priceless still. We shouldn't drop the changelog before people write *good* commit messages (and we are still quite far from that goal). Segher
[committed] wwwdocs: New GCC mirror from Rabat, Morocco
On Sun, 5 Jan 2020, Gerald Pfeifer wrote: > Happy to have you as a mirror, and if you'd like to submit a patch > for https://gcc.gnu.org/mirrors.html that'd be great. Otherwise we > can create one. I applied this patch that I created on behalf of Sami. Gerald - Log - commit c69ec31fe4eec31ec6f1c76ebec23ad69cfb85d3 Author: Gerald Pfeifer Date: Wed Feb 5 22:38:24 2020 +0100 Add mirror.marwan.ma. diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html index 1917d04a..6813de72 100644 --- a/htdocs/mirrors.html +++ b/htdocs/mirrors.html @@ -30,6 +30,10 @@ mirrors. The following sites mirror the gcc.gnu.org download site Greece: ftp://ftp.ntua.gr/pub/gnu/gcc/";>ftp.ntua.gr, thanks to ftpadm at ntua.gr Hungary, Budapest: http://robotlab.itk.ppke.hu/gcc/";>robotlab.itk.ppke.hu, thanks to Adam Rak (neurhlp at gmail.com) Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp) +Morocco: + https://mirror.marwan.ma/gcc/";>mirror.marwan.ma + (rsync://mirror.marwan.ma/gcc/), + thanks to Sami Ait Ali Oulahcen (s...@marwan.ma) The Netherlands, Dronten: ?? http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ | ?? rsync://mirror.koddos.net/gcc/,
C++ constructors and callgraph interaction ("__ct_comp " vs constructor function body)
When debugging PR analyzer/93288, I'm compiling this test C++ file:
struct a {
a();
};
class foo {
a b;
} c;
I see a cgraph_edge from __static_initialization_and_destruction_0 to
a "__ct_comp ", which I see is a DECL_COMPLETE_CONSTRUCTOR_P.
The "__ct_comp " prints as a "a::a()/2", but its DECL_STRUCT_FUNCTION
has a NULL CFG (which is what's causing the ICE in the analyzer).
The simple fix is to check for NULL, and skip such cases (but that
would fail to analyze the calls).
However, there seems to be a separate a::a in the cgraph with a CFG
containing the body of the ctor.
Looking at the __ct_comp:
(gdb) call edge->callee->debug()
_ZN3fooC1Ev/2 (foo::foo()) @0x7fffe2d0
Type: function definition analyzed alias cpp_implicit_alias
Visibility: externally_visible public weak comdat
comdat_group:_ZN3fooC5Ev one_only artificial
Same comdat group as: _ZN3fooC2Ev/1
References: _ZN3fooC2Ev/1 (alias)
Referring:
Availability: available
Function flags:
Called by: _Z41__static_initialization_and_destruction_0ii/4 (can
throw external)
Calls:
and I note that we have _ZN3fooC1Ev/2 (the __ct_comp) and
_ZN3fooC2Ev/1, which demangle to foo::foo()/2 and foo::foo()/1
respectively.
I'm a bit hazy on the details here, sorry.
Presumably this "__ct_comp " fndecl's cgraph_node is thus linked to the
"real" fndecl as a "cpp_implicit_alias"?
What's the best strategy for the analyzer to follow when it encounters
a DECL_STRUCT_FUNCTION with a NULL CFG?
Should the analyzer:
(a) special-case this (e.g. assume that "cpp_implicit_alias" will have
a single reference I can look up, or get it from the comdat groups, or
somesuch), or
(b) are there some more general semantics I need to implement? (e.g. if
it's weak, look in the comdat group for a non-weak alias, or somesuch?)
(c) not bother exploring those paths
Thanks, and sorry if I'm missing something obvious here (I'm less
familiar with this part of the compiler)
Dave
Re: C++ constructors and callgraph interaction ("__ct_comp " vs constructor function body)
On Wed, 2020-02-05 at 23:07 -0500, David Malcolm wrote:
> When debugging PR analyzer/93288, I'm compiling this test C++ file:
>
> struct a {
> a();
> };
> class foo {
> a b;
> } c;
>
> I see a cgraph_edge from __static_initialization_and_destruction_0 to
> a "__ct_comp ", which I see is a DECL_COMPLETE_CONSTRUCTOR_P.
>
> The "__ct_comp " prints as a "a::a()/2", but its DECL_STRUCT_FUNCTION
> has a NULL CFG (which is what's causing the ICE in the analyzer).
>
> The simple fix is to check for NULL, and skip such cases (but that
> would fail to analyze the calls).
>
> However, there seems to be a separate a::a in the cgraph with a CFG
> containing the body of the ctor.
>
> Looking at the __ct_comp:
>
> (gdb) call edge->callee->debug()
> _ZN3fooC1Ev/2 (foo::foo()) @0x7fffe2d0
> Type: function definition analyzed alias cpp_implicit_alias
> Visibility: externally_visible public weak comdat
> comdat_group:_ZN3fooC5Ev one_only artificial
> Same comdat group as: _ZN3fooC2Ev/1
> References: _ZN3fooC2Ev/1 (alias)
> Referring:
> Availability: available
> Function flags:
> Called by: _Z41__static_initialization_and_destruction_0ii/4 (can
> throw external)
> Calls:
>
> and I note that we have _ZN3fooC1Ev/2 (the __ct_comp) and
> _ZN3fooC2Ev/1, which demangle to foo::foo()/2 and foo::foo()/1
> respectively.
>
> I'm a bit hazy on the details here, sorry.
>
> Presumably this "__ct_comp " fndecl's cgraph_node is thus linked to
> the
> "real" fndecl as a "cpp_implicit_alias"?
>
> What's the best strategy for the analyzer to follow when it
> encounters
> a DECL_STRUCT_FUNCTION with a NULL CFG?
>
> Should the analyzer:
>
> (a) special-case this (e.g. assume that "cpp_implicit_alias" will
> have
> a single reference I can look up, or get it from the comdat groups,
> or
> somesuch), or
>
> (b) are there some more general semantics I need to implement? (e.g.
> if
> it's weak, look in the comdat group for a non-weak alias, or
> somesuch?)
Answering my own question, calling ultimate_alias_target on the
__ct_comp cgraph_node seems to find the "right" cgraph_node.
Is that the right general-purpose answer here?
Thanks
Dave
> (c) not bother exploring those paths
> Thanks, and sorry if I'm missing something obvious here (I'm less
> familiar with this part of the compiler)
>
> Dave
>
