Re: GCC Mission Statement
Le 09/06/2021 à 07:09, Valentino Giudice via Gcc a écrit : > If the Steering Committee updates the mission statement, it may appear > that the mission statement follows the decisions of the steering > committee (in place of the contrary). In that case, what would be the > purpose of a mission statement? A chicken and egg question, hey (~: -- Didier
Re: GCC Mission Statement
On 6/9/21 10:39 AM, Valentino Giudice wrote: I was aware of that announcement, but it doesn't mention the mission statement at all. It appears that the decision in question was, at the time, in contrast with the mission statement (rather than guided by it). If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? The mission statement was also updated beyond simply making it consistent with the change: in "Supporting the goals of the GNU project, as defined by the FSF" the reference to the FSF was removed. Quite a few projects under the GNU project[1] have dissociated themselves from the FSF, so "as defined by the FSF" perhaps doesn't apply as consistently as it did before. That is my understanding anyway; maybe there's more context that others may be able to add. Siddhesh [1] https://gnu.tools/en/software/
Re: GCC Mission Statement
Thank you. > Well there was an announcement; the changes in the mission statement reflect > the new reality introduced by that announcement: > > https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html > > Siddhesh I was aware of that announcement, but it doesn't mention the mission statement at all. It appears that the decision in question was, at the time, in contrast with the mission statement (rather than guided by it). If the Steering Committee updates the mission statement, it may appear that the mission statement follows the decisions of the steering committee (in place of the contrary). In that case, what would be the purpose of a mission statement? The mission statement was also updated beyond simply making it consistent with the change: in "Supporting the goals of the GNU project, as defined by the FSF" the reference to the FSF was removed. Was there any announcement about the update of the mission statement itself? On what basis does the Steering Committee change the mission statement?
Re: GCC Mission Statement
On 6/9/21 10:13 AM, Valentino Giudice via Gcc wrote: Hi. The Mission Statement of the GCC project recently changed without any announcement. Well there was an announcement; the changes in the mission statement reflect the new reality introduced by that announcement: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html Siddhesh
GCC Mission Statement
Hi. The Mission Statement of the GCC project recently changed without any announcement. I am not a contributor to GCC, merely a user. However, I'd like to understand more, especially about the transparency of the project. The GCC Steering Committee is supposed to follow the mission statement as a guide for its decision. Who changes the mission statement, and for what reason? How can a modification of the statement be guided by the mission statement? How were users and contributors informed of this? Thank you in advance for your response. Best regards. For reference: - The GCC homepage states the SC is "guided by the mission statement": https://gcc.gnu.org/ - The mission statement before the update: https://web.archive.org/web/20210331192925/https://gcc.gnu.org/gccmission.html
Re: progress update after initial GSoC virtual meetup
On Tue, 2021-06-08 at 21:20 +0530, Ankur Saini wrote:
>
>
> > On 01-Jun-2021, at 6:38 PM, David Malcolm
> > wrote:
> >
[...snip...]
> > Maybe it's best to have an
> > account on the GCC compile farm for this:
> > https://gcc.gnu.org/wiki/CompileFarm
> > IIRC you already have such an account. It might be worth trying
> > out a
> > full bootstrap and testsuite run on one of the powerful machines in
> > the
> > farm. I tend to use "screen" in case my ssh connection drops
> > during
> > through a build, so that losing the ssh connection doesn't kill the
> > build.
>
> I tried this, and it’s awesome :D , I was able to complete the either
> bootstrap build on one of the powerful machine there with almost
> similar time to that of what my laptop takes to build with bootstrap
> disabled.
Great.
[...snip...]
>
> > - it might be good to create a personal branch on the gcc git
> > repository that you can push your work to. I'm in two minds about
> > this, in that ideally you'd just commit your work to trunk once
> > each
> > patch is approved, but maybe it's good to have a public place as a
> > backup of the "under development" stuff? Also, at some point we
> > want
> > you to be pushing changes to the trunk, so we'll want your account
> > to
> > be able to do that.
>
> I already did that when I was fiddling around with the source code
> and track my changes seperately
Is there a URL for your branch?
> >
> > If you're *really* eager to start, you might want to look at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
> > This is a case where the analyzer "sees" a call through a function
> > pointer, and, despite figuring out what the function pointer
> > actually
> > points to, entirely fails to properly handle the call, since the
>
> > supergraph and engine.cc code is looking at the static callgraph,
> > and
> > needs work to handle such calls through function pointers. I
> > started
> > debugging this a couple of weeks ago, and realized it has a *lot*
> > of
> > similarities to the vtable case, so thought I might leave it so you
> > can
> > have a go at it once the project starts properly.
>
> yes, looking at exploded graph, the analyzer is not able to
> understand the call to function “noReturn()” when called via a
> function pointer ( noReturnPtr.0_1 ("”); ) at all. I would be
> looking into it and will report back as soon as I find something
> useful.
The issue is that the analyzer currently divides calls into
(a) calls where GCC's middle-end "knows" which function is called, and
thus the call site has a cgraph_node.
(b) calls where GCC's middle-end doesn't "know" which function is
called.
The analyzer handles
(a) by building call and return edges in the supergraph, and
processing them, and
(b) with an "unknown call" handler, which conservatively sets lots of
state to "unknown" to handle the effects of an arbitrary call, and
where the call doesn't get its own exploded_edge.
In this bug we have a variant of (b), let's call it (c): GCC's middle-
end doesn't know which function is called, but the analyzer's
region_model *does* know at a particular exploded_node. I expect this
kind of thing will also arise for virtual function calls. So I think
you should look at supergraph.cc at where it handles calls; I think we
need to update how it handles (b), so that it can handle the (c) cases,
probably by splitting supernodes at all call sites, rather than just
those with cgraph_edges, and then creating exploded_edges (with custom
edge info) for calls where the analyzer "figured out" what the function
pointer was in the region_model, even if there wasn't a cgraph_node.
Does that make sense?
Or you could attack the problem from the other direction, by looking at
what GCC generates for a vfunc call, and seeing if you can get the
region_model to "figure out" what the function pointer is at a
particular exploded_node.
>
> also, should I prefer discussing about this bug here( gcc mailing
> list) or on the bugzilla itself ?
Either way works for me. Maybe on this list? (given that this feels
like a design question)
Hope this is helpful
Dave
Re: progress update after initial GSoC virtual meetup
> On 01-Jun-2021, at 6:38 PM, David Malcolm wrote:
>
> - able to build the analyzer from source *quickly*, for hacking on the
> code. i.e. with --disable-bootstrap. We want to minimize the time it
> takes to, say, hack in a print statement into a single .cc file in the
> analyzer subdirectory, rebuild, and rerun. With bootstrapping
> disabled, if you run "make -jsome-number-of-cores" from the build
> directory's "gcc" subdirectory, it should merely rebuild the .o file
> for the .cc you touched, and do some relinking (and rerun the
> selftests); hopefully such an edit should take less than a minute
> before you're able to run the code and see the results.
>
> It sounds like you're close to being able to do that.
>
> (FWIW I tend to use gdb rather than putting in print statements, I tend
> to hack in gcc_unreachable into conditions that I hope are being hit,
> so that execution will stop at that point in gdb if my assumptions are
> correct, and then I can print things, inject calls, etc in gdb)
>
> - able to build the analyzer with a full bootstrap (--enable-bootstrap
> is the default) and running the regression test suites ("make check -
> jnumber-of-cores"), On the fastest box I have this (64 cores, 128 GB
> ram) this takes about 45 minutes to do the build and about 45 minutes
> to do the testsuites; it used to take up to three hours total when I
> was running it on a laptop (and thus was a major pain as it's no fun to
> have a hot noisy laptop for several hours). Maybe it's best to have an
> account on the GCC compile farm for this:
> https://gcc.gnu.org/wiki/CompileFarm
> IIRC you already have such an account. It might be worth trying out a
> full bootstrap and testsuite run on one of the powerful machines in the
> farm. I tend to use "screen" in case my ssh connection drops during
> through a build, so that losing the ssh connection doesn't kill the
> build.
I tried this, and it’s awesome :D , I was able to complete the either bootstrap
build on one of the powerful machine there with almost similar time to that of
what my laptop takes to build with bootstrap disabled.
>
> - able to step through the code in the debugger. IIRC you've already
> been doing that.
>
> - copyright assignment paperwork to the FSF. IIRC you've already done
> that.
done
>
> - ability to run just a single test in the testsuite, rather than the
> whole lot (so that you can easily develop new tests without having to
> run everything each time you make an edit to a test). As you say
> above, you've done that.
done
>
> - the analyzer has testcases for C, C++ and Fortran, so you might want
> to figure out the argument you need for --enable-languages= when
> configuring GCC to enable those languages (but probably no others when
> hacking, to speed of rebuilding GCC). Obviously you'll need C++, as
> C++ support is the point of your project.
Right now I only enable C and C++ when building.
>
> - it might be good to create a personal branch on the gcc git
> repository that you can push your work to. I'm in two minds about
> this, in that ideally you'd just commit your work to trunk once each
> patch is approved, but maybe it's good to have a public place as a
> backup of the "under development" stuff? Also, at some point we want
> you to be pushing changes to the trunk, so we'll want your account to
> be able to do that.
I already did that when I was fiddling around with the source code and track my
changes seperately
>
> If you're *really* eager to start, you might want to look at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546
> This is a case where the analyzer "sees" a call through a function
> pointer, and, despite figuring out what the function pointer actually
> points to, entirely fails to properly handle the call, since the
> supergraph and engine.cc code is looking at the static callgraph, and
> needs work to handle such calls through function pointers. I started
> debugging this a couple of weeks ago, and realized it has a *lot* of
> similarities to the vtable case, so thought I might leave it so you can
> have a go at it once the project starts properly.
yes, looking at exploded graph, the analyzer is not able to understand the call
to function “noReturn()” when called via a function pointer ( noReturnPtr.0_1
("”); ) at all. I would be looking into it and will report back as soon
as I find something useful.
also, should I prefer discussing about this bug here( gcc mailing list) or on
the bugzilla itself ?
> That said, before
> the 7th you're meant to be focusing on schoolwork, I think, so we
> really ought to be merely just sorting out accounts, ensuring your
> coding environment is set up, etc.
ok
>
> Hope this is helpful
Thanks,
- Ankur
Re: GCC 10.2: undefined reference to vtable: missing its key function
(This should have been on the gcc-help list.) > I may be remembering wrong, but -- doesn't dynamic_cast look for a vtable? It uses a vtable if one is present, it can't cause one to be introduced, so ... >So if you do a dynamic cast mentioning that class you'd get such a reference. No. > Or is that an error when applied to a non-polymorphic class? You can use dynamic_cast to upcast (i.e. from derived to base) for non-polymorphic class types. It is an error to downcast (from base to derived) for a non-polymorphic class type.
Re: Update to GCC copyright assignment policy
>> Also, are there many non-FSF-assigned contribution in the development >> branch already? > >I'm not aware of any anywhere yet. adec14811714e22a6c1f7f0199adc05370f0d8b0 96963713f6a648a0ed890450e02ebdd8ff583b14 621ea10ca060ba19ec693aa73b5e29d553cca849 3e5f2425f80aedd00f28235022a2755eb46f310d ee9548b36a7f17e8a63585b58f340c93dcba95d8 f6bb145c0bff19767931d37733be11c8acc6fa00 (*) f78f25f43864f38ae5a6a9fcce8f26c94fe45bcd The one marked (*) is particularly significant because it's from a new contributor who has no FSF assignment. He contributed a 5-10x optimization for std::any_cast, which was accepted into the GCC tree within 24 hours of the patch being received. I consider this a great success for the project. I have more than 30 commits adding significant new C++23 features to libstdc++ which will be merged soon under the DCO.
Update to GCC copyright assignment policy
> Sent: Tuesday, June 08, 2021 at 2:17 AM > From: "Giacomo Tesio" > To: "David Edelsohn" > Cc: "Jakub Jelinek" , "gcc Mailing List" > Subject: Re: Update to GCC copyright assignment policy > > Hi David, > > On June 7, 2021 1:26:52 PM UTC, David Edelsohn wrote: > > > > > It's a breaking change, after all. > > > > It's not a new or different license (unlike GPLv2->GPLv3). It's not > > reverting the existing copyrights and assignments. > > For sure, but it IS a different legal framework anyway. > > Before there was only one, well known no-profit copyright holder. > > After, there will be MANY copyright holders, just like in Linux. What we wish is that there will be no copyright holders at all. > And as you might know, many corporate Linux adopter have been sued > for copyright violation by individual copyright holders (often referred as > "copyright trolls") and settled the cases out of court for money. > > > > As Eben Moglen > > stated in the ZDNet article: "the FSF will long remain the > > preponderant copyright holder in GCC and related projects... No > > downstream user, modifier or redistributor of GCC is facing any > > changes whatsoever." > For now and for most of downstream users, Moglen is right. > > But in the long term, what happens in Linux is likely to happen in GCC too. > > Introducing such legal risk on users without writing anything in the Changelog > an without proper notice has not been much respectful. > > GCC is one of core components of today's infrastructure. > > It's used all over the world and in many different way and legal envirnment. > > > > The break mostly is psychological, not technical or legal. > > Do you mean such change was just introduced to address a psycological issue? > > I've never listen about such kind of therapy, but I know nothing about > psychology. > > > Anyway, to most people it's just a matter of risk assesment. > > GCC will now come with a new legal risk that was absemt before, thus > it should be handled properly, with a proper notice and incapaulated > in a new major version. The responsibility will now get transferred to the maintainers. And we all know how great most maintainers are with legal instruments. I can then be entitled to insult maintainers Ad Nausium about the licensing problems that occur, because I long got fed up of maintainers thinking too highly of themselves, and and other contributors telling me to shut up because I am not the major maintainer of Gcc. > And tbh, it doesn't look such an unreasonable request, after all. > > > Giacomo >
Re: [RFP] Toolchains and Kernel MC in LPC 2021
ping. There is still time to add more topics/key participants to the MC proposal. If interested in participating, please let us know in jema...@gnu.org and ndesaulni...@google.com. Thanks! > Hi people! > > This year the Linux Plumbers Conference (https://linuxplumbersconf.org) will > be fully virtual, and will happend from 20 to 24 September 2021. > > As part of the event, we are organizing a `Toolchains and Kernel > Micro-conference' devoted to discuss specific topics involving kernel and > toolchain. It will cover both the GNU Toolchain and LLVM. > > As in previous years, the emphasis will be in discussing specific topics that > require collaboration/interaction between the kernel and the toolchain chaps. > Examples of topics are wrapping of syscalls, specific features in the > compiler/linker/etc that are used by the kernel, desired optimizations, > features to alleviate security concerns on the kernel side, and the like. > > In order to get the Micro-Conference accepted we need to provide a list of > both topics and prospective attendants, so thats why I am reaching out to you > asking for: > > 1) Topics your project may want to discuss with the kernel hackers, during the >event. > > 2) Whether you are willing to contribute and/or participate in the >micro-conference. > > Please let me know in jose.march...@oracle.com or jema...@gnu.org. > Thanks!
Re: Update to GCC copyright assignment policy
> Sent: Tuesday, June 08, 2021 at 6:10 AM
> From: "Giacomo Tesio"
> To: "Jason Merrill"
> Cc: "Jakub Jelinek" , "gcc Mailing List"
> Subject: Re: Update to GCC copyright assignment policy
>
> Hi Jason,
>
> On June 7, 2021 5:24:12 PM UTC, Jason Merrill wrote:
> >
> > Why would someone bother to hassle a redistributor who can just say
> > "nonsense, we're in compliance, the corresponding source is at this
> > URL"?
>
> Usually it's a matter of money AND details.
>
> > What return on their time can they reasonably expect?
>
> Money.
>
> You are overly underestimating how long in takes to get a sentence over the
> world.
> In Italy it could literally take a decade.
>
> Also there is ALWAYS uncertaintly when in comes to courts.
What me strive for is for the Gpl to became irrelevant. Whan there are
no arguments against copyleft.
>
> That's why in most cases, these matters do not reach a sentence.
>
> For most corporations over the world it's way cheaper to pay the "troll",
> be him right or wrong.
>
>
> With the previous CA policy, this could not happen.
>
> That's why it should be managed like a major breaking change.
>
>
> > The Linux kernel community adopted the GPL3 curing process ("GPL
> > cooperation commitment") as a remedy for the troll problem. Do you
> > think this was a pointless exercise?
>
> At best, it's more a form risk mitigation to the corporate needs of the first
> world
> than a solution to the "copyright troll" problem.
>
> But the fact is that GCC was completely unaffected with the previous policy.
>
> And I'm not even arguing agaist the new one!
>
> I'm just asking to clearly mark with a new version its application.
>
> In a few years, as the existing versions will be deprecated, the new policy
> will
> become the only one, but at least users will have had time to assess their
> business with GCC.
>
>
> > > And also because there are many fewer redistributors of GCC, and
> > they are
> > > in the business of distributing software.
> > >
> > > And why GCC redistribution should be discouraged?
> > >
> >
> > It shouldn't! My point is that businesses redistributing GCC are such
> > that compliance with the GPL is natural for them, unlike, say,
> > manufacturers of smart toasters running Linux.
>
> Oh, I misunderstood what you meant, sorry.
>
> Well, maybe not a toaster, but imagine a cheap low-energy eink-based
> zen-mode writing/programming machine running gcc-emacs as sole program.
>
> Why such kind of gcc-distribution business should be discouraged by these
> legal issues?
>
> Yes, it's an hypothetical example, but you know... Twitter is a business too:
> anything can happen, however unpredictable.
>
> That's why I think the Steering Committee should be very careful while
> changing the legal framework of GCC.
>
>
> Giacomo
>
Re: RFC: Sphinx for GCC documentation
On 6/7/21 11:26 PM, Bernhard Reutner-Fischer wrote: On Mon, 7 Jun 2021 15:30:22 +0200 Martin Liška wrote: Anyway, this is resolved as I use more appropriate directive: https://splichal.eu/scripts/sphinx/gfortran/_build/html/intrinsic-procedures/access-checks-file-access-modes.html ISTM there's a typo s/Tailing/Trailing/ in gcc/fortran/intrinsic.texi Yes, it is :) git grep -wi Tailing seems to highlight a couple more. Maybe you have time to fix these? PS: The occurrence in gcc/testsuite/gcc.dg/format/strfmon-1.c sounds odd. TIA, Fixed that with a commit I've just pushed. Martin
