Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Tobias Burnus]

On 10.06.21 08:17, Martin Liška wrote:


Yes, we currently only support automatic extraction from comments from
test-cases.
How does your commit title look like? Note that we require bugzilla
components
being part of PR entry, which is not commonly used in git titles due
to length
limitation.


One options would be to require a 'PR /' line if there is
'PRn+' in the commit title, rejecting the commit otherwise.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Xionghu Luo via Gcc]

On 2021/6/10 14:17, Martin Liška wrote:
> On 6/10/21 7:22 AM, Xionghu Luo wrote:
>> Sorry, should be sent to this mail-list.
>>
>>
>> On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote:
>>> Hi,
>>> I noticed that the "git gcc-commit-mklog" command doesn't extract PR
>>> number from title to ChangeLog automatically, then the committed patch
>>> doesn't update the related bugzilla PR website after check in the patch?
> 
> Hello.
> 
> Yes, we currently only support automatic extraction from comments from 
> test-cases.
> How does your commit title look like? Note that we require bugzilla 
> components
> being part of PR entry, which is not commonly used in git titles due to 
> length
> limitation.
> 
>>> Martin, what's your opinion about this since you are much familar about
>>> this? Thanks.
> 
> Please provide few examples of existing commits?

Thanks. For example:

rs6000: Support doubleword swaps removal in rot64 load store [PR100085]

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f700e4b0ee3ef53b48975cf89be26b9177e3a3f3


> 
> Thanks,
> Martin
> 
>>>
>>>
>>
> 

-- 
Thanks,
Xionghu

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Liška]

On 6/10/21 7:22 AM, Xionghu Luo wrote:

Sorry, should be sent to this mail-list.


On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote:

Hi,
I noticed that the "git gcc-commit-mklog" command doesn't extract PR
number from title to ChangeLog automatically, then the committed patch
doesn't update the related bugzilla PR website after check in the patch?


Hello.

Yes, we currently only support automatic extraction from comments from 
test-cases.
How does your commit title look like? Note that we require bugzilla components
being part of PR entry, which is not commonly used in git titles due to length
limitation.


Martin, what's your opinion about this since you are much familar about
this? Thanks.


Please provide few examples of existing commits?

Thanks,
Martin

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Xionghu Luo via Gcc]

Sorry, should be sent to this mail-list.


On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote:

Hi,
I noticed that the "git gcc-commit-mklog" command doesn't extract PR
number from title to ChangeLog automatically, then the committed patch
doesn't update the related bugzilla PR website after check in the patch?
Martin, what's your opinion about this since you are much familar about
this? Thanks.




--
Thanks,
Xionghu

Mission Statement

[Christopher Dimech via Gcc]

> Sent: Thursday, June 10, 2021 at 9:07 AM
> From: "Aaron Gyes via Gcc" 
> To: "GCC Administrator via Gcc" 
> Subject: Re: Mission Statement
>
> > In this state of making something right, and making
> > something wrong, there is no way for inclusiveness.
>
> Are you familiar with the tolerance paradox?
>
> Aaron

Yes, but I don't actually see how anybody in the hacker culture
has ever done that.  Do you?

Licensing Complications

[Christopher Dimech via Gcc]

A thing to seriously tackle is how the Gnu GPL permits making a
modified version and letting the public access it on a server
without ever releasing its source code.  The focus must really be
on ending any ownership on software.

This problem necessitates the production of additional
legal instruments that would allow the amalgamation of source
code from certain free licenses that could well be incompatible
but still fall within the free software definition.

Additionally, there exists the real possibility that source code
amalgamation could be allowed in one direction, but not the other.
I have experienced the problem regarding the impossibility of reaching,
locating or engaging the copyright holder.

Orphan works are a frustration, a liability risk, and a major cause of
gridlock in the market-place.

Please refer to

https://www.copyright.gov/orphan/reports/orphan-works2015.pdf


- Christopher Dimech
Administrator General - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/ https://www.gnu.org/

Re: Mission Statement

[Aaron Gyes via Gcc]

> In this state of making something right, and making
> something wrong, there is no way for inclusiveness.

Are you familiar with the tolerance paradox?

Aaron

Mission Statement

[Christopher Dimech via Gcc]

> Sent: Thursday, June 10, 2021 at 3:49 AM
> From: "Aaron Gyes via Gcc" 
> To: "GCC Administrator via Gcc" 
> Subject: Re: Mission Statement
>
> On Jun 9, 2021, at 8:30 AM, Christopher Dimech  wrote:
> > 
> > Besides inspiring a sceptic attitude, Cicero made the language of
> > the civilized world.
> 
> Yes
> 
> > This has nothing to do with any complaints
> > of mistreatment, but mostly about belief systems that have taken
> > over many people's lives.  That's what is most embarrassing.
> 
> Huh

> > After all, it was yourself who criticised my attitude towards Liu
> > Hao, who had stated on 4/10/2021 the greatness of chairman mao
> > and how he eradicated discrimination from chinese society.  Once
> > you take on such zeal, you will get so badly identified with it,
> > that you yourself will became a social problem.
> > 
> > The chinese communist party killed thousands of people every year
> > by firing squads, lethal injection and mobile death vans.  Not to
> > mention the horrifying child-killing policy during china's
> > draconian one-child system.  It has recently also became infamous
> > for forced uighur sterilisation.  How can I ever agree with
> > someone who thinks the suppression of others is good!
> 
> Are you asserting I was wrong in my observations that day? Do you
> think I disagree with anything in the second quoted paragraph?
> Would it matter? Oh, why do I let myself get sucked in?

Absolutely.  You were wrong that day in attributing my comments
as personal criticisms based on country of origin.  Rather, it
was Liu Hao who started with group-based rhetoric that is the
mainstream position of the Chinese Communist Party.  One would be 
a fool to disagree with the second paragraph.  It was an argument
of how Liu Hao was wrong.
 
> What even is that kind of argument occurring post “After all,”?

It was a rejection of how things could be categorised as awkward. 
And an opportunity to set things right after the great controversies
we got embroiled into then. 
 
> I can’t figure out if this is just a non-sequitur, and/or a straw
> man, or part of a gish gallop? Something just pathological?
> Perhaps I should go get checked and make sure I didn’t have a stroke
> since it seems like I must be having trouble processing my
> environment: it seems like you’ve been behaving this way on the
> mailing list for months and apparently nobody in charge has asked
> you to do better or stop and everyone here is pretty smart and
> professional.

On the contrary, I have received a number of personal
correspondence questioning why I continue expressing my point of
view, or support people such as Richard Stallman and
others (within the Free Software Foundation; and among the open
source chiefs), from other prominent individuals leading software
projects around the world.

> Aaron

Such discussions have only come from cultures which are steeped
in morality.  As to something has to be good, and something has to
be bad.  In this state of making something right, and making
something wrong, there is no way for inclusiveness.

Every master has his own way.  You don't like my way as has been
evident by your implications that I am somehow diseased.  There
are whole academic dissertations on this inappropriate,
segregation-minded black-white dualism.  Such deliberate
segregation is something that has to be tackled.

I am very clear on what I am doing.  What somebody says, good or
bad things, it does not matter.  The best things that have ever
been done on this planet have always had bad press.  Today the
cycle has changed, but it will come back.  Soon the appreciation
will come.  Although my involvement is not about appreciation or
fear of criticism, I will not fall short of myself.  What I can
do must happen.

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/9/2021 2:39 PM, Aldy Hernandez wrote:



On 6/9/21 9:47 PM, Jeff Law wrote:



On 6/9/2021 9:34 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high 
level
discussion.  But if it helps, I could post what I have, which just 
needs
some cleanups and porting to the latest trunk changes Andrew has 
made.


Currently the backwards threader works by traversing DEF chains 
through

PHIs leading to possible paths that start in a constant. When such a
path is found, it is checked to see if it is profitable, and if 
so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now 
possible

to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual 
jump
threading code.  I have leveraged this to write a ranger-based 
threader
that gets every single thread the current code gets, plus 90-130% 
more.


Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain 
Andrew's

upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it 
reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% 
from the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM 
and VRP
now get are not because they're smarter, but because they're 
picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could 
actually get.
   This is too expensive to do in real life, but it at least shows 
what

the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some 
info.
I'll save you some time.  The jump threaders in VRP are doing the 
least amount of lifting and the ones we want to kill first. IIRC the 
one from vrp2 is doing nearly nothing at this point.


Sure, that was going to be my next target.

What are your thoughts on replacing the current backwards threader, 
though?  That's basically ready to go.

Going to take a deep dive into it Saturday.

Jeff

Re: replacing the backwards threader and more

[Aldy Hernandez via Gcc]

On 6/9/21 9:47 PM, Jeff Law wrote:



On 6/9/2021 9:34 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high level
discussion.  But if it helps, I could post what I have, which just 
needs

some cleanups and porting to the latest trunk changes Andrew has made.

Currently the backwards threader works by traversing DEF chains through
PHIs leading to possible paths that start in a constant.  When such a
path is found, it is checked to see if it is profitable, and if so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now possible
to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual jump
threading code.  I have leveraged this to write a ranger-based threader
that gets every single thread the current code gets, plus 90-130% more.

Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain Andrew's
upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% from 
the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and 
VRP

now get are not because they're smarter, but because they're picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could actually 
get.

   This is too expensive to do in real life, but it at least shows what
the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some info.
I'll save you some time.  The jump threaders in VRP are doing the least 
amount of lifting and the ones we want to kill first.  IIRC the one from 
vrp2 is doing nearly nothing at this point.


Sure, that was going to be my next target.

What are your thoughts on replacing the current backwards threader, 
though?  That's basically ready to go.


Aldy

Re: replacing the backwards threader and more

[Jeff Law via Gcc]

On 6/9/2021 9:34 AM, Aldy Hernandez wrote:



On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc 
 wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high level
discussion.  But if it helps, I could post what I have, which just 
needs

some cleanups and porting to the latest trunk changes Andrew has made.

Currently the backwards threader works by traversing DEF chains through
PHIs leading to possible paths that start in a constant.  When such a
path is found, it is checked to see if it is profitable, and if so, the
constant path is threaded.  The current implementation is rather 
limited

since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

    if (a && b)
  foo ();
    if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now possible
to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual jump
threading code.  I have leveraged this to write a ranger-based threader
that gets every single thread the current code gets, plus 90-130% more.

Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain Andrew's
upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043    (+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
    Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% from 
the

VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and 
VRP

now get are not because they're smarter, but because they're picking up
opportunities that the new code exposes.  I experimented with 
running an
iterative threader, and then seeing what VRP and DOM could actually 
get.

   This is too expensive to do in real life, but it at least shows what
the effect of the new code is on DOM/VRP's abilities:

    Iterative threader:
  ethread:65043    (+3.06%)
  dom:31170    (-16.7%)
  thread:86717    (+127%)
  vrp:33851    (-42.2%)
    Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some info.
I'll save you some time.  The jump threaders in VRP are doing the least 
amount of lifting and the ones we want to kill first.  IIRC the one from 
vrp2 is doing nearly nothing at this point.



Jeff

Dear Hohnka M.J., Miller J.A., Dacumos K.M., Fritton T.J., Erdley J.D., Long L.N.: Ԝеlϲomе to Сontrіbսte Your Original Manսsᴄriрts - Evaluation of compiler-induced vulnerabilities

[Andrew Chang]

If you no longer wish to receive such kind of еmаіls from us, you can ᴄliᴄκ
here  to unѕuƄѕcriƄе.

Jοᴜrnаl of Electrical and Electronic Engineering
ІЅЅΝ Online: ᒿЗᒿ9-160ƼІЅЅΝ Print: ᒿЗᒿ9-161З
Jοᴜrnаl of Electrical and Electronic Engineering is a peer-rеvіеwed and
open aᴄᴄeѕѕ international rҽsҽarϲһ ϳоսrnal, sparing no effort to provide a
high-level sϲհоlarly exchange platform for the practitioners, consultants,
rҽsҽarϲһers, асаԀemiсs and the ones interested in current and emerging
iѕѕυҽs in electrical and electronic engineering.

Dear Hohnka M.J., Miller J.A., Dacumos K...,
Hope that you are having a good day.
Your рареr entіtlҽd "Evaluation of compiler-induced vulnerabilities" ρᴜblisһed
in Jοᴜrnаl of Aerospace Information Systems has impressed us profoundly. *Here,
we strongly іnνіtҽ you to сontriƄսte other unρᴜblisһed рареrs to our
ϳоսrnal.*
Іnνіtatіons for Ƥαpеrs ЅuЬmіtting
The ϳоսrnal iѕѕυҽs theoretical and empirical рареrs that include
Communications, Original Ƥαpеrs, Ɍҽviҽѡ Ƥαpеrs, Case Studies and so on.
ЅuЬmіtted mαnᴜѕcripts will be possibly adopted if they are well written and
meet the ρᴜblisһing requirements of our ϳоսrnal.
The lіnκ below can help you to know more about the ѕuƅmіѕѕіon guidelines:
http://www.jo3e.com/sv2lf/eHXbo
Other Recommended Jοᴜrnаls:
We have no less than 300 peer rеvіеwed, open aᴄᴄeѕѕ multidisciplinary
science ϳоսrnals. Based on your rҽsҽarϲһ field, other four ϳоսrnals are
suggested:
(1)  American Jοᴜrnаl of Electrical and Computer Engineering
(2)  Engineering Science
(3)  American Jοᴜrnаl of Engineering and Technology Management
(4)  American Jοᴜrnаl of Management Science and Engineering
You can also find your аrtiсlе's tіtlҽ and αƄstrαϲt in the following part:
The tіtlҽ of the рареr: Evaluation of compiler-induced vulnerabilities
The αƄstrαϲt of the рареr: This рареr explores computer security
vulnerabilities that are generated inadvertently by a compiler. By using a
novel approach of examining the assembly language and other intermediate
files generated by the compilation process, it has been successfully
demonstrated that the compiler’s processing of the high-level source code
can create a vulnerable end product. Proper software assurance is intended
to provide confidence that software is frее from vulnerabilities, and
compiler-induced vulnerabilities reduce this confidence level. The
discovered vulnerabilities can be related to standard vulnerability
classes, side channel attacks, undefined behavior, and persistent state
violations. Additionally, the rҽsҽarϲһ revealed that the executable machine
code generated by the compiler can differ in structure from the original
source code due to simplifications and optimizations performed during the
compilation process that cannot be disabled. This rҽsҽarϲһ examined both
the open-source GNU C compiler and the Microsoft C/C++ compiler that is
part of the Microsoft Visual Studio package. Both of these compilers are
widely used and represent typical compilers in use today. ? 2019 American
Institute of Aeronautics and Astronautics Inc.. All rights reѕҽrνҽd.
Please kindly let us know if you have any doubt.
Assistant from EԀіtоrial Office of Jοᴜrnаl of Electrical and Electronic
Engineering

Empty structures extensions

[Jonathan Wakely via Gcc]

Should the docs at
https://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html mention that
you can use {} to initialize such structs?

Re: replacing the backwards threader and more

[Richard Biener via Gcc]

On June 9, 2021 5:34:03 PM GMT+02:00, Aldy Hernandez  wrote:
>
>
>On 6/9/21 2:09 PM, Richard Biener wrote:
>> On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
> wrote:
>>>
>>> Hi Jeff.  Hi folks.
>>>
>>> What started as a foray into severing the old (forward) threader's
>>> dependency on evrp, turned into a rewrite of the backwards threader
>>> code.  I'd like to discuss the possibility of replacing the current
>>> backwards threader with a new one that gets far more threads and can
>>> potentially subsume all threaders in the future.
>>>
>>> I won't include code here, as it will just detract from the high
>level
>>> discussion.  But if it helps, I could post what I have, which just
>needs
>>> some cleanups and porting to the latest trunk changes Andrew has
>made.
>>>
>>> Currently the backwards threader works by traversing DEF chains
>through
>>> PHIs leading to possible paths that start in a constant.  When such
>a
>>> path is found, it is checked to see if it is profitable, and if so,
>the
>>> constant path is threaded.  The current implementation is rather
>limited
>>> since backwards paths must end in a constant.  For example, the
>>> backwards threader can't get any of the tests in
>>> gcc.dg/tree-ssa/ssa-thread-14.c:
>>>
>>> if (a && b)
>>>   foo ();
>>> if (!b && c)
>>>   bar ();
>>>
>>> etc.
>>>
>>> After my refactoring patches to the threading code, it is now
>possible
>>> to drop in an alternate implementation that shares the profitability
>>> code (is this path profitable?), the jump registry, and the actual
>jump
>>> threading code.  I have leveraged this to write a ranger-based
>threader
>>> that gets every single thread the current code gets, plus 90-130%
>more.
>>>
>>> Here are the details from the branch, which should be very similar
>to
>>> trunk.  I'm presenting the branch numbers because they contain
>Andrew's
>>> upcoming relational query which significantly juices up the results.
>>>
>>> New threader:
>>>ethread:65043(+3.06%)
>>>dom:32450  (-13.3%)
>>>backwards threader:72482   (+89.6%)
>>>vrp:40532  (-30.7%)
>>> Total threaded:  210507 (+6.70%)
>>>
>>> This means that the new code gets 89.6% more jump threading
>>> opportunities than the code I want to replace.  In doing so, it
>reduces
>>> the amount of DOM threading opportunities by 13.3% and by 30.7% from
>the
>>> VRP jump threader.  The total  improvement across the jump threading
>>> opportunities in the compiler is 6.70%.
>>>
>>> However, these are pessimistic numbers...
>>>
>>> I have noticed that some of the threading opportunities that DOM and
>VRP
>>> now get are not because they're smarter, but because they're picking
>up
>>> opportunities that the new code exposes.  I experimented with
>running an
>>> iterative threader, and then seeing what VRP and DOM could actually
>get.
>>>This is too expensive to do in real life, but it at least shows
>what
>>> the effect of the new code is on DOM/VRP's abilities:
>>>
>>> Iterative threader:
>>>   ethread:65043(+3.06%)
>>>   dom:31170(-16.7%)
>>>   thread:86717(+127%)
>>>   vrp:33851(-42.2%)
>>> Total threaded:  216781 (+9.90%)
>>>
>>> This means that the new code not only gets 127% more cases, but it
>>> reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
>>> respectively).   The end result is that we have the possibility of
>>> getting almost 10% more jump threading opportunities in the entire
>>> compilation run.
>> 
>> Yeah, DOM once was iterating ...
>> 
>> You probably have noticed that we have very man (way too many)
>> 'thread' passes, often in close succession with each other or
>> DOM or VRP.  So in the above numbers I wonder if you can break
>> down the numbers individually for the actual passes (in their order)?
>
>Sure, I can do that.  Let me whip up the old branch and gather some
>info.
>
>> 
>>> (Note that the new code gets even more opportunities, but I'm only
>>> reporting the profitable ones that made it all the way through to
>the
>>> threader backend, and actually eliminated a branch.)
>>>
>>> The overall compilation hit from this work is currently 1.38% as
>>> measured by callgrind.  We should be able to reduce this a bit, plus
>we
>>> could get some of that back if we can replace the DOM and VRP
>threaders
>>> (future work).
>>>
>>> My proposed implementation should be able to get any threading
>>> opportunity, and will get more as range-ops and ranger improve.
>>>
>>> I can go into the details if necessary, but the gist of it is that
>we
>>> leverage the import facility in the ranger to only look up paths
>that
>>> have a direct repercussion in the conditional being threaded, thus
>>> reducing the search space.  This enhanced path discovery, plus an
>engine
>>> to resolve conditionals based on knowledge from a CFG path, is all
>that
>>> is needed to register new paths.  There is no limit to how far back
>we
>>>

Re: Mission Statement

[Aaron Gyes via Gcc]

On Jun 9, 2021, at 8:30 AM, Christopher Dimech  wrote:
> 
> Besides inspiring a sceptic attitude, Cicero made the language of
> the civilized world.

Yes

> This has nothing to do with any complaints
> of mistreatment, but mostly about belief systems that have taken
> over many people's lives.  That's what is most embarrassing.

Huh

> 
> After all, it was yourself who criticised my attitude towards Liu
> Hao, who had stated on 4/10/2021 the greatness of chairman mao
> and how he eradicated discrimination from chinese society.  Once
> you take on such zeal, you will get so badly identified with it,
> that you yourself will became a social problem.
> 
> The chinese communist party killed thousands of people every year
> by firing squads, lethal injection and mobile death vans.  Not to
> mention the horrifying child-killing policy during china's
> draconian one-child system.  It has recently also became infamous
> for forced uighur sterilisation.  How can I ever agree with
> someone who thinks the suppression of others is good!

Are you asserting I was wrong in my observations that day? Do you
think I disagree with anything in the second quoted paragraph?
Would it matter? Oh, why do I let myself get sucked in?

What even is that kind of argument occurring post “After all,”?

I can’t figure out if this is just a non-sequitur, and/or a straw
man, or part of a gish gallop? Something just pathological?
Perhaps I should go get checked and make sure I didn’t have a stroke
since it seems like I must be having trouble processing my
environment: it seems like you’ve been behaving this way on the
mailing list for months and apparently nobody in charge has asked
you to do better or stop and everyone here is pretty smart and
professional.

Aaron

GCC Mission Statement

[Christopher Dimech via Gcc]

> Sent: Thursday, June 10, 2021 at 3:26 AM
> From: "Giacomo Tesio" 
> To: "Richard Biener" 
> Cc: "gcc@gcc.gnu.org" , "Valentino Giudice" 
> 
> Subject: Re: GCC Mission Statement
>
> Sure Richard, I know.
>
> On June 9, 2021 2:32:22 PM UTC, Richard Biener  wrote:
> >
> > You are free to create "DCO-free" branches for the GCC 11 series
> > (and older), reverting any DCO "incumbered" backports that reach
> > the official GCC branches for those series.
>
> I could.
>
> Like all other people affected by the change.
> If they know they should.
>
> But isn't this a responsibility inversion?
>
>
> I wonder: is this how you treat your users?
>
> "Go fuck yourself" but politely stated?
>
> To be honest, this comes to me as a great surprise.
>
>
> That's what one would expect by the random guy on github, not by employees
> of RedHat or Google serving as the Steering Committee of GCC.
>
>
> Giacomo

We could start all over again.  We have already done it once with just one man.
And he shocked the world!

Re: replacing the backwards threader and more

[Aldy Hernandez via Gcc]

On 6/9/21 2:09 PM, Richard Biener wrote:

On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc  wrote:


Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code.  I'd like to discuss the possibility of replacing the current
backwards threader with a new one that gets far more threads and can
potentially subsume all threaders in the future.

I won't include code here, as it will just detract from the high level
discussion.  But if it helps, I could post what I have, which just needs
some cleanups and porting to the latest trunk changes Andrew has made.

Currently the backwards threader works by traversing DEF chains through
PHIs leading to possible paths that start in a constant.  When such a
path is found, it is checked to see if it is profitable, and if so, the
constant path is threaded.  The current implementation is rather limited
since backwards paths must end in a constant.  For example, the
backwards threader can't get any of the tests in
gcc.dg/tree-ssa/ssa-thread-14.c:

if (a && b)
  foo ();
if (!b && c)
  bar ();

etc.

After my refactoring patches to the threading code, it is now possible
to drop in an alternate implementation that shares the profitability
code (is this path profitable?), the jump registry, and the actual jump
threading code.  I have leveraged this to write a ranger-based threader
that gets every single thread the current code gets, plus 90-130% more.

Here are the details from the branch, which should be very similar to
trunk.  I'm presenting the branch numbers because they contain Andrew's
upcoming relational query which significantly juices up the results.

New threader:
   ethread:65043(+3.06%)
   dom:32450  (-13.3%)
   backwards threader:72482   (+89.6%)
   vrp:40532  (-30.7%)
Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading
opportunities than the code I want to replace.  In doing so, it reduces
the amount of DOM threading opportunities by 13.3% and by 30.7% from the
VRP jump threader.  The total  improvement across the jump threading
opportunities in the compiler is 6.70%.

However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and VRP
now get are not because they're smarter, but because they're picking up
opportunities that the new code exposes.  I experimented with running an
iterative threader, and then seeing what VRP and DOM could actually get.
   This is too expensive to do in real life, but it at least shows what
the effect of the new code is on DOM/VRP's abilities:

Iterative threader:
  ethread:65043(+3.06%)
  dom:31170(-16.7%)
  thread:86717(+127%)
  vrp:33851(-42.2%)
Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it
reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
respectively).   The end result is that we have the possibility of
getting almost 10% more jump threading opportunities in the entire
compilation run.


Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?


Sure, I can do that.  Let me whip up the old branch and gather some info.




(Note that the new code gets even more opportunities, but I'm only
reporting the profitable ones that made it all the way through to the
threader backend, and actually eliminated a branch.)

The overall compilation hit from this work is currently 1.38% as
measured by callgrind.  We should be able to reduce this a bit, plus we
could get some of that back if we can replace the DOM and VRP threaders
(future work).

My proposed implementation should be able to get any threading
opportunity, and will get more as range-ops and ranger improve.

I can go into the details if necessary, but the gist of it is that we
leverage the import facility in the ranger to only look up paths that
have a direct repercussion in the conditional being threaded, thus
reducing the search space.  This enhanced path discovery, plus an engine
to resolve conditionals based on knowledge from a CFG path, is all that
is needed to register new paths.  There is no limit to how far back we
look, though in practice, we stop looking once a path is too expensive
to continue the search in a given direction.

The solver API is simple:

// This class is a thread path solver.  Given a set of BBs indicating
// a path through the CFG, range_in_path() will return the range
// of an SSA as if the BBs in the path would have been executed in
// order.
//
// Note that the blocks are in reverse order, thus the exit block is
path[0].

class thread_solver : go

Re: GCC Mission Statement

[Giacomo Tesio]

Sure Richard, I know.

On June 9, 2021 2:32:22 PM UTC, Richard Biener  wrote:
> 
> You are free to create "DCO-free" branches for the GCC 11 series
> (and older), reverting any DCO "incumbered" backports that reach
> the official GCC branches for those series.  

I could.

Like all other people affected by the change.
If they know they should.

But isn't this a responsibility inversion?


I wonder: is this how you treat your users?

"Go fuck yourself" but politely stated?

To be honest, this comes to me as a great surprise.


That's what one would expect by the random guy on github, not by employees
of RedHat or Google serving as the Steering Committee of GCC.


Giacomo

Re: GCC Mission Statement

[Richard Biener via Gcc]

On Wed, Jun 9, 2021 at 4:22 PM Giacomo Tesio  wrote:
>
> Hi Gabriel,
>
> On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier 
> wrote:
> >
> > I do consider that a lack of transparency is pretty bad, and that
> > discussions on subjects like this should be done in public, but I
> > wouldn't say it's just as bad as the potential risk that a fork would
> > incur.
>
> I really wonder what kind of risks are you thinking about.
>
> Really, I could not see anyone.
>
> Two organizations with different goals and values that explore
> different ways to implement a compiler collection cannot cause any harm.
>
>
> > As for a lack of professionalism, I think it's pretty clear that GCC
> > 11 is the cutoff point here
>
> May you point me to the line in the GCC 11.1's Changelog that
> document this?
>
> I cannot find anything!

Because GCC 11.1 was not affected by this change though GCC 11.1.1+
will.

You are free to create "DCO-free" branches for the GCC 11 series
(and older), reverting any DCO "incumbered" backports that reach
the official GCC branches for those series.  git should make that
easy up to the first major conflict / dependence issue.

Richard.

Re: GCC Mission Statement

[Giacomo Tesio]

Hi Gabriel,

On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier 
wrote:
> 
> I do consider that a lack of transparency is pretty bad, and that 
> discussions on subjects like this should be done in public, but I 
> wouldn't say it's just as bad as the potential risk that a fork would
> incur.

I really wonder what kind of risks are you thinking about.

Really, I could not see anyone.

Two organizations with different goals and values that explore
different ways to implement a compiler collection cannot cause any harm.


> As for a lack of professionalism, I think it's pretty clear that GCC
> 11 is the cutoff point here

May you point me to the line in the GCC 11.1's Changelog that
document this?

I cannot find anything!

Please give it a look: https://gcc.gnu.org/gcc-11/changes.html

> and although there might be some problems with 
> licensing bug fixes to old versions (which could not be reasonably 
> avoided unless GCC made no major releases until GCC 11.5 is out),
> there isn't much reason to make a major version just for this when
> there was a major version a month ago. 

GCC 11.1 is the first release of the 11 series.

In a professional environment more respectful of downstream users,
such major change would have been announced for the 12 series and
applied only to it an successive ones.

It would be very easy to achieve, allowing people around the
world to properly assess and handle the subtle legal risk introduced.


I mean: are we talking about GCC or a random hobby compiler on github?


> Note that releases are done ~1 time per year, 
> so there isn't much FSF-copyrighted work "lost" with this.

To be honest, I do not see the change as an issue for FSF.

The new legal risks affect users.


> > Unilateral undiscussed changes by the Steering Committe is the new
> norm.
> >
> > And such Steering Committee is in no way representing the interests
> > of the worldwide users of GCC, first because its members do not know
> > them (the vast majority is from the US, work for US corporations or
> > both) and second because they do not listen to any objection /
> > request that does not comes from their own circle / social group.
> 
> From what I know on this subject, the SC is meant to represent the GCC

The steering committee was founded in 1998 with the intent of
preventing any particular individual, group or organization from
getting control over the project [1].

But as Juvenal wrote "Quis custodiet ipsos custodes?"

I argued that FSF had such role (through RMS [2]), but now the members
of Steering Committee itself are "getting control over the project".


> community (those that actively participate in GCC development, at 
> least), and they are composed of well-recognized members of that 
> community. Adding in random unknown people to represent the 
> "world wideusers" of GCC would

Strawman: nobody ever suggested this.

You could radically increase SC diversity very easily, by removing
people who comes from the same corporation and adding people who are
well respected but do NOT share the exact same demographics and
interests of the other SC members.

Do you really think that ONLY white men working for a US tech company
or another ought to be "well-recognized members of that community"?

If not, they need not to be "random unknown people".

> certainly not be taken well by the community and 
> would heavily hurt the credibility of the SC in the eyes of everyone 
> involved in working on GCC, which would consequently hurt the project.

I always love how diversity completely stop being important when called
on the right group of good ol' well-respected US-centric white men! :-D
 

> You might have your own views on the subject, but I would prefer
> having a credible SC that might not represent everyone in the world
> well than have an SC representing everyone in the world that isn't
> trusted by the people involved with the project 

This is a false dilemma.

GCC could have a diverse AND trustworthy Steering Committee.
The current one is not diverse at all.

And if it was trustworthy they would have had no issue in discussing
this major change BEFORE applying it.


> > Are you sure that an explicit fork with two projects with different
> > names and governance would had been worse than what GCC has become?
> 
> To be clear: From what I can see, the GCC project has effectively 
> declared their independence (which they already pretty much had,
> they've just made it publicly clear) from the FSF in terms of who is
> at the helm of the project. It is their right to do so

Sure!

It's called "forking" and usually comes with a clear change in name.

GNU Compiler Collection is... uhm... a GNU project.



> they certainly had the power to do so when the only power the FSF
> could exert over them was very minor, with as the only leverage some
> minor reputation loss from the loss of association with GNU and the
> DNS records for gcc.gnu.org.

Well, you are right, it's plain clear: all of this has been a power p

Re: Mission Statement

[Aaron Gyes via Gcc]

On Jun 9, 2021, at 6:48 AM, Christopher Dimech via Gcc mailto:gcc@gcc.gnu.org>> wrote
> All this could became meaningless in ten years time because major
> changes have resulted from division.  If we go on dividing the
> world using a knife rather than stitching it together, everything
> will be left in tatters.  The more effort taken in this direction,
> the more destructive things will become.  Rather, we must touch
> deeper dimensions of our intelligence which is naturally
> unifying.
> 
> For the sake of study, we initially divided things.  With time we
> start believing that's how things work.  But nature is such that
> without inclusiveness, there is no possibility.  If people do not
> understand what I am talking about, they only have to keep their
> mouth shut and hold their nose, and became totally exclusive.
> And in a few minutes they will be dead.
> 
> The question is whether we are conscious about what is happening
> or not.  Otherwise, inclusiveness will only be for survival
> purposes.  The recent changes in the control of Gcc have all been
> about survival.  Although, the change in copyright assignment can
> prove beneficial to everybody, this assumes that the people in
> the Gcc Steering Committee are actually capable of formally
> understanding and operating the appropriate legal instruments (or
> getting people who do the capability) to move the world closer to
> a freedom respecting technological culture.
> 
> It is undeniable that the driving force behind the change was not
> communal at all.  The aim was to loosen the bonds between the GCC
> Projects and the FSF, pushed by the drive to impose the most
> extreme form of censure to an individual and declare him "Persona
> Non-Grata".
> 
> As for the way forward in the next ten years, software must
> became much leaner and effective because of technological
> capabilities.  There is no other way.  Software has not moved
> fast as it should be for users.  The trend in the world in the
> area of technology is that most things are becoming very lean and
> mean.  One of the greatest injustices I see is that many things
> are made in a hurry.


I imagine a person who could write this sort of thing in this context might
imagine themselves a prescient voice of reason, along the lines of Cicero or 
something or perhaps imagine the writings one day being read it and readers 
shaking
their heads sadly at how they were treated just as they do when reading about 
Socrates’
Apology, or Tacitus about suffering under the emperors. Instead, I suspect this
will be tossed in a very different, more awkward category.

Aaron

Mission Statement

[Christopher Dimech via Gcc]

All this could became meaningless in ten years time because major
changes have resulted from division.  If we go on dividing the
world using a knife rather than stitching it together, everything
will be left in tatters.  The more effort taken in this direction,
the more destructive things will become.  Rather, we must touch
deeper dimensions of our intelligence which is naturally
unifying.

For the sake of study, we initially divided things.  With time we
start believing that's how things work.  But nature is such that
without inclusiveness, there is no possibility.  If people do not
understand what I am talking about, they only have to keep their
mouth shut and hold their nose, and became totally exclusive.
And in a few minutes they will be dead.

The question is whether we are conscious about what is happening
or not.  Otherwise, inclusiveness will only be for survival
purposes.  The recent changes in the control of Gcc have all been
about survival.  Although, the change in copyright assignment can
prove beneficial to everybody, this assumes that the people in
the Gcc Steering Committee are actually capable of formally
understanding and operating the appropriate legal instruments (or
getting people who do the capability) to move the world closer to
a freedom respecting technological culture.

It is undeniable that the driving force behind the change was not
communal at all.  The aim was to loosen the bonds between the GCC
Projects and the FSF, pushed by the drive to impose the most
extreme form of censure to an individual and declare him "Persona
Non-Grata".

As for the way forward in the next ten years, software must
became much leaner and effective because of technological
capabilities.  There is no other way.  Software has not moved
fast as it should be for users.  The trend in the world in the
area of technology is that most things are becoming very lean and
mean.  One of the greatest injustices I see is that many things
are made in a hurry.

> Sent: Wednesday, June 09, 2021 at 4:56 PM
> From: "Siddhesh Poyarekar" 
> To: "Valentino Giudice" , gcc@gcc.gnu.org
> Subject: 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
>



- Christopher Dimech
Administrator General - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/ https://www.gnu.org/

GNAT Reference Manual: Typos in chapter 1

[Michael Siegel]

I've found some typos, etc. in chapter 1 ("About This Guide") of the
GNAT Reference Manual.

Here they come in order of appearance:

#1

  This manual contains useful information in writing programs using the
  GNAT compiler.

  s/in writing/on writing

#2

  It includes information on implementation dependent characteristics
  of GNAT…

  s/implementation dependent/implementation-dependent

#3

  GNAT implements Ada 95, Ada 2005 and Ada 2012, and it may also be
  invoked in Ada 83 compatibility mode.

  s/Ada 2005 and Ada 2012, and/Ada 2005, and Ada 2012, but

#4

  By default, GNAT assumes Ada 2012, but you can override with a
  compiler switch to explicitly specify the language version.

  s/override/override that

#5

  Throughout this manual, references to ’Ada’ without a year suffix
  apply to all the Ada versions of the language.

  s/’Ada’ without a year suffix/Ada, without a year suffix,

  or
  
  s/’Ada’ without a year suffix/’Ada’ – i.e., without a year suffix –

#6

  However, since Ada is designed to be used in a wide variety of
  applications, it also contains a number of system dependent features
  to be used in interfacing to the external world.

  s/system dependent/system-dependent

  s/interfacing to/interfacing with


Maybe someone can take the time to fix these.


Thanks.
Michael

Re: GCC Mission Statement

[Gabriel Ravier via Gcc]

On 6/9/21 12:11 PM, Giacomo Tesio wrote:

Hi Gabriel,

On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote:

Speaking on the "change it recklessly" issue, I would personally say
that SC has indeed arguably done this [...]
some people threatened to pull away from GCC entirely if it remained
tied to the FSF. I personally happen to agree with the change (which
seems to have especially avoided what would have been a painful split
that could have had disastrous consequences for GCC as a whole), but
find it rather disconcerting that such changes with potentially major
consequences were done without any direct discussion of them with the
community whatsoever.

Did you consider that, in fact, the lack of transparency of the
Steering Committee has shown since then (or even just the lack of
professionalism, when it comes to explicit intruduce major changes in
major versions) is a "disastrous consequence for GCC as a whole"?


I do consider that a lack of transparency is pretty bad, and that 
discussions on subjects like this should be done in public, but I 
wouldn't say it's just as bad as the potential risk that a fork would incur.


As for a lack of professionalism, I think it's pretty clear that GCC 11 
is the cutoff point here, and although there might be some problems with 
licensing bug fixes to old versions (which could not be reasonably 
avoided unless GCC made no major releases until GCC 11.5 is out), there 
isn't much reason to make a major version just for this when there was a 
major version a month ago. Note that releases are done ~1 time per year, 
so there isn't much FSF-copyrighted work "lost" with this.




Unilateral undiscussed changes by the Steering Committe is the new norm.


And such Steering Committee is in no way representing the interests of
the worldwide users of GCC, first because its members do not know them
(the vast majority is from the US, work for US corporations or both)
and second because they do not listen to any objection / request that
does not comes from their own circle / social group.


From what I know on this subject, the SC is meant to represent the GCC 
community (those that actively participate in GCC development, at 
least), and they are composed of well-recognized members of that 
community. Adding in random unknown people to represent the "worldwide 
users" of GCC would certainly not be taken well by the community and 
would heavily hurt the credibility of the SC in the eyes of everyone 
involved in working on GCC, which would consequently hurt the project.


You might have your own views on the subject, but I would prefer having 
a credible SC that might not represent everyone in the world well than 
have an SC representing everyone in the world that isn't trusted by the 
people involved with the project (which could then result in the SC 
becoming trusted... by the few people who remain after all those that 
don't trust it leave).




Are you sure that an explicit fork with two projects with different
names and governance would had been worse than what GCC has become?


To be clear: From what I can see, the GCC project has effectively 
declared their independence (which they already pretty much had, they've 
just made it publicly clear) from the FSF in terms of who is at the helm 
of the project. It is their right to do so, and they certainly had the 
power to do so when the only power the FSF could exert over them was 
very minor, with as the only leverage some minor reputation loss from 
the loss of association with GNU and the DNS records for gcc.gnu.org. If 
RMS wants to try to do anything, the most he can do is expel the SC as 
the maintainers of the "GNU Compiler Collection", take the DNS records 
for gcc.gnu.org and make a fork that would most certainly be considered 
by everybody to be "FSF GCC" or something like that to distinguish it 
from what would most certainly be the GCC basically everyone uses. The 
only result of this would be that basically everyone would move over to 
gcc-compiler.org or something like that, and the situation would be 
functionally unchanged from what it is now.


Note: GCC as it has been for the past 2 decades was already a fork of 
the original GCC: RMS just decided to accept EGCS (former name of the 
current GCC) as the official version of GCC endorsed by GNU (this is why 
it was already effectively independent).




Giacomo

Re: replacing the backwards threader and more

[Richard Biener via Gcc]

On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc  wrote:
>
> Hi Jeff.  Hi folks.
>
> What started as a foray into severing the old (forward) threader's
> dependency on evrp, turned into a rewrite of the backwards threader
> code.  I'd like to discuss the possibility of replacing the current
> backwards threader with a new one that gets far more threads and can
> potentially subsume all threaders in the future.
>
> I won't include code here, as it will just detract from the high level
> discussion.  But if it helps, I could post what I have, which just needs
> some cleanups and porting to the latest trunk changes Andrew has made.
>
> Currently the backwards threader works by traversing DEF chains through
> PHIs leading to possible paths that start in a constant.  When such a
> path is found, it is checked to see if it is profitable, and if so, the
> constant path is threaded.  The current implementation is rather limited
> since backwards paths must end in a constant.  For example, the
> backwards threader can't get any of the tests in
> gcc.dg/tree-ssa/ssa-thread-14.c:
>
>if (a && b)
>  foo ();
>if (!b && c)
>  bar ();
>
> etc.
>
> After my refactoring patches to the threading code, it is now possible
> to drop in an alternate implementation that shares the profitability
> code (is this path profitable?), the jump registry, and the actual jump
> threading code.  I have leveraged this to write a ranger-based threader
> that gets every single thread the current code gets, plus 90-130% more.
>
> Here are the details from the branch, which should be very similar to
> trunk.  I'm presenting the branch numbers because they contain Andrew's
> upcoming relational query which significantly juices up the results.
>
> New threader:
>   ethread:65043(+3.06%)
>   dom:32450  (-13.3%)
>   backwards threader:72482   (+89.6%)
>   vrp:40532  (-30.7%)
>Total threaded:  210507 (+6.70%)
>
> This means that the new code gets 89.6% more jump threading
> opportunities than the code I want to replace.  In doing so, it reduces
> the amount of DOM threading opportunities by 13.3% and by 30.7% from the
> VRP jump threader.  The total  improvement across the jump threading
> opportunities in the compiler is 6.70%.
>
> However, these are pessimistic numbers...
>
> I have noticed that some of the threading opportunities that DOM and VRP
> now get are not because they're smarter, but because they're picking up
> opportunities that the new code exposes.  I experimented with running an
> iterative threader, and then seeing what VRP and DOM could actually get.
>   This is too expensive to do in real life, but it at least shows what
> the effect of the new code is on DOM/VRP's abilities:
>
>Iterative threader:
>  ethread:65043(+3.06%)
>  dom:31170(-16.7%)
>  thread:86717(+127%)
>  vrp:33851(-42.2%)
>Total threaded:  216781 (+9.90%)
>
> This means that the new code not only gets 127% more cases, but it
> reduces the DOM and VRP opportunities considerably (16.7% and 42.2%
> respectively).   The end result is that we have the possibility of
> getting almost 10% more jump threading opportunities in the entire
> compilation run.

Yeah, DOM once was iterating ...

You probably have noticed that we have very man (way too many)
'thread' passes, often in close succession with each other or
DOM or VRP.  So in the above numbers I wonder if you can break
down the numbers individually for the actual passes (in their order)?

> (Note that the new code gets even more opportunities, but I'm only
> reporting the profitable ones that made it all the way through to the
> threader backend, and actually eliminated a branch.)
>
> The overall compilation hit from this work is currently 1.38% as
> measured by callgrind.  We should be able to reduce this a bit, plus we
> could get some of that back if we can replace the DOM and VRP threaders
> (future work).
>
> My proposed implementation should be able to get any threading
> opportunity, and will get more as range-ops and ranger improve.
>
> I can go into the details if necessary, but the gist of it is that we
> leverage the import facility in the ranger to only look up paths that
> have a direct repercussion in the conditional being threaded, thus
> reducing the search space.  This enhanced path discovery, plus an engine
> to resolve conditionals based on knowledge from a CFG path, is all that
> is needed to register new paths.  There is no limit to how far back we
> look, though in practice, we stop looking once a path is too expensive
> to continue the search in a given direction.
>
> The solver API is simple:
>
> // This class is a thread path solver.  Given a set of BBs indicating
> // a path through the CFG, range_in_path() will return the range
> // of an SSA as if the BBs in the path would have been executed in
> // order.
> //
> // Note that the blocks are in reverse order, thus the exit blo

replacing the backwards threader and more

[Aldy Hernandez via Gcc]

Hi Jeff.  Hi folks.

What started as a foray into severing the old (forward) threader's 
dependency on evrp, turned into a rewrite of the backwards threader 
code.  I'd like to discuss the possibility of replacing the current 
backwards threader with a new one that gets far more threads and can 
potentially subsume all threaders in the future.


I won't include code here, as it will just detract from the high level 
discussion.  But if it helps, I could post what I have, which just needs 
some cleanups and porting to the latest trunk changes Andrew has made.


Currently the backwards threader works by traversing DEF chains through 
PHIs leading to possible paths that start in a constant.  When such a 
path is found, it is checked to see if it is profitable, and if so, the 
constant path is threaded.  The current implementation is rather limited 
since backwards paths must end in a constant.  For example, the 
backwards threader can't get any of the tests in 
gcc.dg/tree-ssa/ssa-thread-14.c:


  if (a && b)
foo ();
  if (!b && c)
bar ();

etc.

After my refactoring patches to the threading code, it is now possible 
to drop in an alternate implementation that shares the profitability 
code (is this path profitable?), the jump registry, and the actual jump 
threading code.  I have leveraged this to write a ranger-based threader 
that gets every single thread the current code gets, plus 90-130% more.


Here are the details from the branch, which should be very similar to 
trunk.  I'm presenting the branch numbers because they contain Andrew's 
upcoming relational query which significantly juices up the results.


New threader:
 ethread:65043(+3.06%)
 dom:32450  (-13.3%)
 backwards threader:72482   (+89.6%)
 vrp:40532  (-30.7%)
  Total threaded:  210507 (+6.70%)

This means that the new code gets 89.6% more jump threading 
opportunities than the code I want to replace.  In doing so, it reduces 
the amount of DOM threading opportunities by 13.3% and by 30.7% from the 
VRP jump threader.  The total  improvement across the jump threading 
opportunities in the compiler is 6.70%.


However, these are pessimistic numbers...

I have noticed that some of the threading opportunities that DOM and VRP 
now get are not because they're smarter, but because they're picking up 
opportunities that the new code exposes.  I experimented with running an 
iterative threader, and then seeing what VRP and DOM could actually get. 
 This is too expensive to do in real life, but it at least shows what 
the effect of the new code is on DOM/VRP's abilities:


  Iterative threader:
ethread:65043(+3.06%)
dom:31170(-16.7%)
thread:86717(+127%)
vrp:33851(-42.2%)
  Total threaded:  216781 (+9.90%)

This means that the new code not only gets 127% more cases, but it 
reduces the DOM and VRP opportunities considerably (16.7% and 42.2% 
respectively).   The end result is that we have the possibility of 
getting almost 10% more jump threading opportunities in the entire 
compilation run.


(Note that the new code gets even more opportunities, but I'm only 
reporting the profitable ones that made it all the way through to the 
threader backend, and actually eliminated a branch.)


The overall compilation hit from this work is currently 1.38% as 
measured by callgrind.  We should be able to reduce this a bit, plus we 
could get some of that back if we can replace the DOM and VRP threaders 
(future work).


My proposed implementation should be able to get any threading 
opportunity, and will get more as range-ops and ranger improve.


I can go into the details if necessary, but the gist of it is that we 
leverage the import facility in the ranger to only look up paths that 
have a direct repercussion in the conditional being threaded, thus 
reducing the search space.  This enhanced path discovery, plus an engine 
to resolve conditionals based on knowledge from a CFG path, is all that 
is needed to register new paths.  There is no limit to how far back we 
look, though in practice, we stop looking once a path is too expensive 
to continue the search in a given direction.


The solver API is simple:

// This class is a thread path solver.  Given a set of BBs indicating
// a path through the CFG, range_in_path() will return the range
// of an SSA as if the BBs in the path would have been executed in
// order.
//
// Note that the blocks are in reverse order, thus the exit block is 
path[0].


class thread_solver : gori_compute
{

public:
  thread_solver (gimple_ranger &ranger);
  virtual ~thread_solver ();
  void set_path (const vec *, const bitmap_head *imports);
  void range_in_path (irange &, tree name);
  void range_in_path (irange &, gimple *);
...
};

Basically, as we're discovering paths, we ask the solver what the value 
of the final conditional in a BB is in a given path.  If it resolves, we 
register the path.


A follow-up project would be to analyze wh

Re: GCC Mission Statement

[Giacomo Tesio]

Hi Gabriel,

On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote:
> Speaking on the "change it recklessly" issue, I would personally say 
> that SC has indeed arguably done this [...]
> some people threatened to pull away from GCC entirely if it remained
> tied to the FSF. I personally happen to agree with the change (which
> seems to have especially avoided what would have been a painful split
> that could have had disastrous consequences for GCC as a whole), but
> find it rather disconcerting that such changes with potentially major
> consequences were done without any direct discussion of them with the
> community whatsoever.

Did you consider that, in fact, the lack of transparency of the
Steering Committee has shown since then (or even just the lack of
professionalism, when it comes to explicit intruduce major changes in
major versions) is a "disastrous consequence for GCC as a whole"?

Unilateral undiscussed changes by the Steering Committe is the new norm.


And such Steering Committee is in no way representing the interests of
the worldwide users of GCC, first because its members do not know them
(the vast majority is from the US, work for US corporations or both)
and second because they do not listen to any objection / request that
does not comes from their own circle / social group.


Are you sure that an explicit fork with two projects with different
names and governance would had been worse than what GCC has become?


Giacomo

Re: GCC Mission Statement

[Gabriel Ravier via Gcc]

On 6/9/21 7:09 AM, Valentino Giudice via Gcc wrote:

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?


In essence, a mission statement is just that, a statement of the mission 
that the SC aims to follow. If the SC wishes to change that mission, it 
follows that the statement should be adjusted to adapt. The statement 
serves as any other statement serves: it gives information to others.


Of course, the mission statement is also binding on the SC itself, in a 
more social way: If it does not wish to lose faith of the GCC community, 
it should not go against the mission statement nor should it change it 
recklessly.


Speaking on the "change it recklessly" issue, I would personally say 
that SC has indeed arguably done this: I believe there should have been 
discussion of this change in the mailing list before it occurred, as 
essentially the only discussion on the mailing list that could have 
implied something like this would happen was the discussion from a while 
back about RMS and the FSF where some people threatened to pull away 
from GCC entirely if it remained tied to the FSF. I personally happen to 
agree with the change (which seems to have especially avoided what would 
have been a painful split that could have had disastrous consequences 
for GCC as a whole), but find it rather disconcerting that such changes 
with potentially major consequences were done without any direct 
discussion of them with the community whatsoever.