Re: GSoC Blog Post 0 - GCCprefab build system

[Jonathan Wakely via Gcc]

On Tue, 14 Jun 2022 at 01:37, Damian Rouson wrote:
>
>
>
> On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran 
>  wrote:
>>
>>
>> Yes, it does that, but takes 400 lines of shell script to do so.
>>
>> If you want "relatively easy ways to build GCC painlessly" then you
>> can do it with nine lines of shell commands.
>>
>> Or in about 80, for any non-prehistoric version, with no config file
>> needed (just a single option to the script, the release number or
>> snapshot name to build):
>> https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh
>
>
> Do the above 9 lines or 80 lines include the entire prerequisite software 
> stack or just the ones that the download_prerequisites script downloads?  If 
> I recall correctly, building gfortran also requires flex and building flex 
> requires bison and building bison requires m4 and the download_prerequisites 
> script didn't download any of those the last time I checked.

It doesn't include them, but they are standard system packages that
everybody can install without downloading the sources and building
them from scratch. There are no run-time dependencies on flex and
bison, just build-time. GMP, MPFR and MPC regularly cause problems for
people doing it the wrong way and ending up with run-time dependencies
on shared libs in non-standard locations (as described in the
InstallingGCC wiki page).

You still need to have the other prerequisites listed at
https://gcc.gnu.org/install/prerequisites.html

Re: GSoC Blog Post 0 - GCCprefab build system

[Damian Rouson]

On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
fort...@gcc.gnu.org> wrote:

>
> It doesn't include them, but they are standard system packages that
> everybody can install without downloading the sources and building
> them from scratch.


unless the person is on a system on which they are not preinstalled and a
system for which the person doesn’t have the sudo privileges that package
managers often require.  What I’m describing is the norm for a lot of
government employees and even many people at private corporations with
strict security policies.  For what it’s worth, I’ve been assisting someone
who contacted me with this very issue over the past few days.  Building the
entire stack from source is the least painful option for this person.

You still need to have the other prerequisites listed at
> https://gcc.gnu.org/install/prerequisites.html


That is a long and daunting list for a newcomer.  I’ve listened to gfortran
developers describe building gfortran as “easy” for more than a decade
now.  Simply
saying it’s easy doesn’t make it so. I don’t know that I’ve ever met
someone who described the process as easy unless that person was a gfortran
developer.

Damian


>

std::format support?

[Zopolis0 via Gcc]

There was some discussion around std::format support 2 years ago, with
people suggesting to just use the fmt code, and others suggesting that an
independent implementation might be of higher quality. 2 years have since
passed, and we have no implementation, of higher or identical quality.
Could we come to a decision on this? Having no implementation whatsoever is
the worst possible outcome.

Re: std::format support?

[Jonathan Wakely via Gcc]

On Tue, 14 Jun 2022 at 13:15, Zopolis0 via Gcc  wrote:
>
> There was some discussion around std::format support 2 years ago, with
> people suggesting to just use the fmt code, and others suggesting that an
> independent implementation might be of higher quality.

No, that's not what I said.

> 2 years have since
> passed, and we have no implementation, of higher or identical quality.
> Could we come to a decision on this? Having no implementation whatsoever is
> the worst possible outcome.

What good would a decision be? Somebody still has to do the actual
work to add it.

If you want a decision, here you go: we're going to reimplement it for
libstdc++. Happy now?

Re: GSoC Blog Post 0 - GCCprefab build system

[Wileam Yonatan Phan via Gcc]

Hi Jonathan,

I just pushed a commit to update the build script and config files to use the
release tags instead of the tip of the branch. Thanks again for pointing this
out!

Thanks,
Wil

---

Hi Damian,

That's indeed a tricky issue to implement with the build script if the user
doesn't have sudo rights to install software on the system using the package
manager. Maybe I can make the script download the tarballs and build them from
sources.

Full disclosure: the script currently assumes all prerequisites have been
successfully installed, but based on the discussion here, I can add several
lines to check for their existence using `command -v`.

I'll start working on this later tonight.

Thanks,
Wil

On Tue, 2022-06-14 at 04:16 -0700, Damian Rouson wrote:
> On Mon, Jun 13, 2022 at 8:27 AM Jonathan Wakely via Fortran <
> fort...@gcc.gnu.org> wrote:
> > It doesn't include them, but they are standard system packages that
> > everybody can install without downloading the sources and building
> > them from scratch. 
> 
> unless the person is on a system on which they are not preinstalled and a
> system for which the person doesn’t have the sudo privileges that package
> managers often require.  What I’m describing is the norm for a lot of
> government employees and even many people at private corporations with strict
> security policies.  For what it’s worth, I’ve been assisting someone who
> contacted me with this very issue over the past few days.  Building the
> entire stack from source is the least painful option for this person. 
> 
> > You still need to have the other prerequisites listed at
> > https://gcc.gnu.org/install/prerequisites.html
> 
> That is a long and daunting list for a newcomer.  I’ve listened to gfortran
> developers describe building gfortran as “easy” for more than a decade
> now.  Simply saying it’s easy doesn’t make it so. I don’t know that I’ve ever
> met someone who described the process as easy unless that person was a
> gfortran developer. 
> 
> Damian
> 
> 
> 

Re: Question on cgraph_edge::call_stmt during LTO

[Martin Jambor]

Hello Erick,

sorry for a late reply, I've been recovering from an injury recently.

On Thu, Jun 02 2022, Erick Ochoa wrote:
> Hi Martin,
>
> Thanks for the tips! I have implemented an edge summary which:
>
> * is allocated at IPA analysis phase
> * streamed out in ipcp_write_transformation_summaries
> * streamed in in ipcp_read_transformation_summaries
>
> However, before the implementation of this edge summary we had another
> mechanism of propagating the information all the way until it was used in a
> SIMPLE_IPA_PASS executed after all LGEN stages were finished (after
> all_regular_ipa_passes). After changing the implementation to use edge
> summaries, I find that the information is conserved during inlining (the
> duplication hook prints out the new edges that gets formed via inlining
> with the correct information), however it is not found in the
> SIMPLE_IPA_PASS that gets executed after all_regular_ipa_passes.

I have discussed your situation with Honza and we could not think of a
reason why this is happening to you.  Summaries have destructors, so we
suggest you put a breakpoint in there and see where your summaries get
deallocated.

>
> What is perhaps more interesting is that if I run with -fno-ipa-pure-const
> and no -fno-ipa-modref, I can still see the cgraph_nodes and edges of the
> inlined methods, along with the information needed. But not in the ones
> that have been inlined. I believe this could be just that when these
> options are disabled, cgraph_nodes might not be reclaimed.

In a late SIMPLE_IPA_PASS?  That is really weird, the inlining
transformation code quite clearly removes those.  How do you even get at
these nodes and edges, by traversing the call graph?  If not, you might
indeed be looking at stale data structures.

> I understand that there are many differences between SIMPLE_IPA_PASSes and
> regular IPA_PASSes, but at the moment I am unsure how to narrow down my
> search for a fix. Is this something that could be caused by:
>
> * memory management: (I am not familiar with the memory management in GCC
> and it is a bit difficult to understand.) I have removed the bodies of the
> my_edge_summary::remove (cgraph_edge*) and my_edge_summary::remove
> (cgraph_edge *, my_edge_summary_instance *) so I don't think this might be
> it. However, the class my_edge_summary still copies some of the structure
> in the other transformation summaries, so there is a macro GTY((for_user))
> in the class declaration and the information is stored in a vec  va_gc> *my_info.
> * missing implementation details in the duplicate functions: Looking at
> ipa_edge_args_sum_t::duplicate, it is a relatively complex function. I also
> noticed that it does something else when the dst->caller has been inlined.
> Should I also update the cgraph_edge that disappears when dst->caller is
> inlined to its caller?
> * something else?
>

You probably do not need that complexity.
ipa_edge_args_sum_t::duplicate does kind of reference counting so that
it can then estimate what references should look like after cloning and
inlining, and speculation and speculation-resolutions make this complex.
Unless you need to track something similar or treat speculative edges
especially for some reason, you can just copy your data and be done with
it.

> Any direction is greatly appreciated!

Sorry if I did not help much and good luck.

Martin

>
> On Sat, 21 May 2022 at 00:13, Martin Jambor  wrote:
>
>> Hello,
>>
>> On Fri, May 20 2022, Erick Ochoa via Gcc wrote:
>> > Hi,
>> >
>> > I'm working on a pass that looks into the estimated values during ipa-cp
>> > and stores them for a later analyses/pass. I would like to store the real
>> > arguments' estimates in a cgraph_edge::call_stmt or somewhere else that
>> > makes similar sense. (Note, this is different from the formal parameters'
>> > estimates which can be found in the lattice print out of ipa-cp).
>>
>> the statement is not the right place to store such pass-specific
>> information, for reasons you described and more (especially simple
>> memory use efficiency).
>>
>> Instead they should be placed into an "edge summary" (also sometimes
>> called "call summary"), a structure similar to ipa_edge_args_sum (in
>> ipa-prop.h and ipa-prop.cc).  Unlike ipa_edge_args_sum, which is
>> allocated at analysis phase, then streamed out and in in case of LTO,
>> and used thrown away during the IPA analysis phase, your summary would
>> need to be allocated at IPA analysis time, then streamed out in
>> ipcp_write_transformation_summaries, streamed in in
>> ipcp_read_transformation_summaries so that they can be used in the
>> transformation phase.
>>
>> Usually a simple implementation of the duplication hook of an edge
>> summary is enough for the data to survive cloning and inlining and the
>> like.
>>
>> Martin
>>

GCC 10.3.1 Status Report (2022-06-14)

[Jakub Jelinek via Gcc]

Status
==

The GCC 10 branch is in regression and documentation fixing mode.

After the release of GCC 9.5 it's time to do another release
from the 10 branch - GCC 10.4.  I will do a GCC 10.4 release candidate
next week, June 21st, followed by the release a week after that
if no serious problems arise.

If you have pending backports, please commit them to GCC 10 branch
this week or on Monday next week.  In particular I'd like to see
backport of Honza's PR105739 fix and I'll need to backport PR105732
because it is a P1.

It's also a very good point in time to ensure the branch still builds
and has reasonable testresults for the target you maintain.

Quality Data


Priority  #   Change from last report
---   ---
P11   +   1
P2  407   +  81
P3   52   +  21
P4  204   +  26
P5   24   +   1
---   ---
Total P1-P3 460   + 103
Total   688   + 130


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-April/235360.html

Make cp-demangle non-recursive

[Mohamed Atef via Gcc]

Hi,
Are there any further details about this project?
Thanks
   Mohamed