Re: GSoC 2021 - Fortran run-time argument checking

[Tobias Burnus]

Hi Krishna,

On 03.04.21 13:52, Krishna Kariya wrote:

I am Krishna, a final-year undergraduate student from India. I am
interested in the project “Fortran – run-time argument checking” for
GSoC 2021. Please share some resources about the project. Please point
to some issues or programming tasks that I can try out to understand
the project better.


In older Fortran program, no modules were used and, hence, no argument
checking was possible. Think of:

subroutine caller()
  external callee
  integer :: A(5), b(4)
  call callee(A, B, 5.0, "Hello")
end

Here, the compiler only knows that 'callee' is a subroutine but has no
idea about the actual arguments. Alternatively, in semi-modern code, it
could use:

subroutine caller()
  integer :: A(5), b(4)
  interface
subroutine callee(w,x,y,z)
  integer :: w(*), x(*)
  real :: y
  character(*) :: z
end
  end interface
  call callee(A, B, 5.0, "Hello")
end

The idea is that the caller now fills global variables:
  __gfortran_called_proc = callee  ! function pointer
  __gfortran_called_interface = ... pointer to a struct/derived type
and afterwards, it would set both to null.

The latter contains then:
- a version number (to be able to add more data later on)
- file name, function name and line number of the caller
- information about the arguments:
- 4 arguments
- first: integer array of size 4
- ...

And in
  subroutine callee()
it would check:
  if (__gfortran_called_proc == callee)
and then fill a similar struct with similar data
(version number, filename, proc name, line number, arguments)
and then call the library function
 __libgfortran_check_args(
   __gfortran_called_interface,
   callee_interface);
which then checks whether the arguments match.

Internal procedures and module procedures can be excluded as
those can not be access from the outside.

Minimal check would be:
- number of arguments
- data type
- array + array size
- caller/callee is a function – and expected return values (type, array)
but that can be extended especially in the context of an interface block
(with a zoo of attributes, additional array types etc.) and with intent
handling (intent(out) in caller but constant or intent(in) as argument,
intent(out) argument to intent(in) etc.)

Tobias

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

Re: Remove RMS from the GCC Steering Committee

[Richard Biener via Gcc]

On Thu, Apr 1, 2021 at 9:21 PM Ian Lance Taylor via Gcc  wrote:
>
> On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell  wrote:
> >
> > Richard Biener pointed out dysfunction in the SC.  The case of the
> > missing question I asked in 2019 also points to that.  This response
> > gives me no confidence that things will materially change.  I call for
> > the dissolution of the SC, replacing it with a more open, functional and
> > inclusive body (which includes, nothing).
>
> I'm fine with that in principle.  But it's like everything else with
> GCC, and with free software in general: someone has to do the work.
> We can't literally replace the SC with nothing, at least not unless we
> do a much bigger overhaul of the GCC development process: someone has
> to decide who is going to have maintainership rights and
> responsibilities for different parts of the compiler.

Seeing the word "dysfunction" I don't remember using I want to clarify
the non-openess which I intended to criticize.  The SC is not "open" because:
- it appoints itself (new members, that is) - in fact in theory it
should be appointed
  by the FSF because the SC is the GNU maintainer of GCC
- all requests and discussions are _private_ - the SC does not report to the
  GCC project (it might report to the FSF which it is formally a delegate of)
- you can reach the SC only indirectly (unless you know the secret mailing list
  it operates on) - CC an SC member and hope a request is forwarded

now I understand the SC sees itself as buffer between GCC and the FSF (RMS
in particular) and it thinks we need to be protected from direct engagement.  I
think this is wrong.  I can very well say NO to RMS myself.

I'm actually curious how many of the 13 SC members actively contribute or
whether the "SC show" is a one or two persons game and the "13" is just
to make the SC appear as a big representative group of people.

Thus I request an archive of the SC mailing list be made publically available
and the SC discussion from now on take place in an open forum (you can
choose to moderate everybody so the discussion while carried out in open
is still amongst SC members only).

Richard.

Re: Default debug format for AVR

[Richard Biener via Gcc]

On Mon, Apr 5, 2021 at 10:56 PM Simon Marchi via Gcc  wrote:
>
> On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM 
> Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
> >
> > The default debug format (when using only -g) for the AVR target is
> > stabs.  Is there a reason for it not being DWARF, and would it be
> > possible to maybe consider possibly thinking about making it default to
> > DWARF?  I am asking because the support for stabs in GDB is pretty much
> > untested and bit-rotting, so I think it would be more useful for
> > everyone to use DWARF.
> >
> >
> > I tried to deprecate the stabs support a little over 4 years ago.
> > https://gcc.gnu.org/pipermail/gcc-patches/2017-December/489296.html 
> > 
> > There was a suggestion to change the error to a warning, but my startup 
> > company job kept me so busy I never had a chance to follow up on this.
> >
> > I would like to see the stabs support deprecated and the later removed from 
> > gcc.  No new features have been added in a long time, and it is only being 
> > maintained in the sense that when it fails it is fixed to ignore source 
> > code constructs that it doesn't support.  The longer it survives in this 
> > state, the less useful it becomes.
> >
> > Jim
>
> You have 100% my suppose on this.  The longer stabs survives (especially
> as the default for an arch), the longer some people who don't know the
> intricacies of debug formats could use it without knowing, and that
> does them a disservice.

Patches to kill STABS (and related/derived formats) are pre-approved for stage1.

Richard.

> Simon

Re: Remove RMS from the GCC Steering Committee

[Mark Wielaard]

Hi Richard,

On Wed, Mar 31, 2021 at 03:21:01PM +0200, Richard Biener via Gcc wrote:
> That's all true.  It's still true that since GCC is a GNU project, formally
> its maintainers are appointed by RMS (I've just read the official governance
> structure document!).

I think this is unfair to the steering committee and misrepresents
what it means to be a GNU project. That "gnu-stucture" document was
written by RMS a couple of months ago and doesn't represent how the
GNU project and its maintainers have worked for years. It seems to
have been a reaction to various GNU maintainers getting together and
discussing how the GNU project should actually be governed and how it
should interact with the FSF as summarized here:
https://gnu.wildebeest.org/blog/mjw/2019/12/27/proposals-for-the-new-gnu-fsf-relationship/

RMS indeed claims to be the "Chief GNUisance" of the GNU project and
that that title somehow makes him the leader of the project and that
he appoints GNU maintainers. But that isn't how things work in
practice. GNU projects (packages) have almost total autonomy and in
general decide themselves who the maintainers are. RMS simply records
their decissions in the maintainer file so the FSF knows who the
volunteers responsible are. In the past when RMS was the FSF president
it was sometimes an advantage to discuss some (legal) issues with him,
but in practice the FSF staff often had more time to actually help.

I am pretty sure that is how the steering committee has worked
too. Yes they involved RMS from time to time to update the FSF records
for the current steering committee members and to have a more direct
line to the FSF when it needed to involve the FSF for legal guidance,
but that was more to make sure the FSF was up to date than to give RMS
any leadership role. I do think Nathan is right that the Steering
Committee should have been more clear about this up front and
especially two years ago when RMS stepped down as president of the
FSF. But that is water under the bridge now and the steering committee
did clarify the relationship.

> It's also true that the SC is only indirectly reachable,
> that we didn't vote on our representatives, or that there's no traces of
> its work (assuming it does any).  Just to point to the pieces that
> make it "not open".
> 
> > The reality is that the governance of GCC is extremely open because
> > it's performed by the developers in the community, not the GCC SC.
> > And GCC is much less bureaucratic than other, large Open Source
> > projects.  It doesn't have multiple committees and SIGs.  Everything
> > is worked out among the developers.  Projects are started by
> > developers who take the initiative to start a project.
> >
> > Be careful what you wish for because it may be much worse than the
> > freedom that you currently enjoy.
> 
> I'm actually enjoying not needing to interact with RMS or the FSF
> and indeed the SC appears to handle things well.  But since people
> are throwing in ideas to disassociate GCC from GNU I wanted to
> point out that GCC needs to think of its own governance structure.

I do think you have a point here. If GCC is going to disassociate
itself from the FSF it needs to find a different fiscal sponsor and
legal guardian for the project and that would be a good time to
re-formalize the GCC Steering Committee setup. But I also think David
is right. Be careful what you wish for :)

Cheers,

Mark

GSoC 2021 Application - Mihnea Robert Gogu

[Mihnea Gogu via Gcc]

Dear reader,

My name is Mihnea Robert Gogu and it is my pleasure to confirm my
application for GSoC 2021, more specifically taking on a task as part of
the gcc rust compiler. I am a second year Computing student at Imperial
College London, most passionate about programming languages, by extension
compilers themselves and Rust and low-level, non-GCed languages.

My proposal (which can be found via my GSoC application) aims to improve
the HIR representation dump of gccrs, including type information. All the
relevant information regarding my application can be found on the submitted
proposal. Should there be any questions, I am more than happy to answer
them.

I am looking forward to contributing to the GCC project!

Have a wonderful day,
Mihnea (Mike) Gogu

Re: Remove RMS from the GCC Steering Committee

[Matthias Klose]

On 4/6/21 12:27 PM, Richard Biener via Gcc wrote:
> On Thu, Apr 1, 2021 at 9:21 PM Ian Lance Taylor via Gcc  
> wrote:
>>
>> On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell  wrote:
>>>
>>> Richard Biener pointed out dysfunction in the SC.  The case of the
>>> missing question I asked in 2019 also points to that.  This response
>>> gives me no confidence that things will materially change.  I call for
>>> the dissolution of the SC, replacing it with a more open, functional and
>>> inclusive body (which includes, nothing).
>>
>> I'm fine with that in principle.  But it's like everything else with
>> GCC, and with free software in general: someone has to do the work.
>> We can't literally replace the SC with nothing, at least not unless we
>> do a much bigger overhaul of the GCC development process: someone has
>> to decide who is going to have maintainership rights and
>> responsibilities for different parts of the compiler.
> 
> Seeing the word "dysfunction" I don't remember using I want to clarify
> the non-openess which I intended to criticize.  The SC is not "open" because:
> - it appoints itself (new members, that is) - in fact in theory it
> should be appointed
>   by the FSF because the SC is the GNU maintainer of GCC
> - all requests and discussions are _private_ - the SC does not report to the
>   GCC project (it might report to the FSF which it is formally a delegate of)
> - you can reach the SC only indirectly (unless you know the secret mailing 
> list
>   it operates on) - CC an SC member and hope a request is forwarded
> 
> now I understand the SC sees itself as buffer between GCC and the FSF (RMS
> in particular) and it thinks we need to be protected from direct engagement.  
> I
> think this is wrong.  I can very well say NO to RMS myself.
> 
> I'm actually curious how many of the 13 SC members actively contribute or
> whether the "SC show" is a one or two persons game and the "13" is just
> to make the SC appear as a big representative group of people.
> 
> Thus I request an archive of the SC mailing list be made publically available
> and the SC discussion from now on take place in an open forum (you can
> choose to moderate everybody so the discussion while carried out in open
> is still amongst SC members only).

Not sure if a completely open SC list would help, seeing other SC's or tech
boards having a private communication channel as well.  But +1 on a public point
of contact, with a ML archive behind.  Issues are involuntarily dropped, or not
communicated like last year's gm2 contribution which stayed silent for quiet a
while and the SC thought that a resolution had been communicated.

Matthias

Re: Question about reading LTO function summaries

[Martin Jambor]

Hi,

On Fri, Mar 26 2021, Erick Ochoa via Gcc wrote:
> I already have some experience developing SIMPLE_IPA_PASSes, but I am
> looking to understand IPA_PASSes better. I have made a hello world ipa
> pass that stores "hello world $FUNCTION_NAME" in the function
> summaries; however, I am having trouble reading this information back.
> Can someone help me understand how to use these interfaces correctly?
>
> At the moment, it **seems** to be writing information correctly.
> (I.e., it doesn't segfault when attempting to write data.) However, in
> my read summary function (ipa_hello_world_read_summary (void)) the
> function `lto_get_summary_section_data (file_data,
> LTO_section_ipa_hello_world, &len);` always returns NULL and
> `file_data_vec` is of size 1. This means that at run time, there is
> only one call to `lto_get_summary_section_data` and it returns NULL.

I looked at the code you posted and compared it with streaming in
ipa-sra.c and did not spot any difference that could result in this
behavior.

I guess you have checked that the functions are called from proper
hooks?  (I.e. from write_summary and read_summary or
write_optimization_summary and read_optimization_summary, depending on
what you are trying to do, and not some mixture of these combinations?)

You can try and send the whole patch (hopefully a hello world pass would
not be too large) and I can have a look.

Martin

Re: GSoC 2021 - Static analyzer project

[Ankur Saini via Gcc]

> On 30-Mar-2021, at 7:27 PM, David Malcolm  wrote:

>> This gave rise to some questions
>> 
>> 1. why does the analyzer make exceptions with the main() function ?
> 
> The user's attention is important - we don't want to spam the user with
> unnecessary reports if we can help it.

make sense. 

——

After fiddling around with a lot of C codes, I switched to C++ programs  
in-order to find how exactly the analyzer doesn’t understand exception handling 
and more interestingly calls to virtual functions ( which I am thinking to work 
on this summer ). 

It was comparatively harder to find such an example where it would fail as 
looks like gcc do amazingly nice job at devirtualising the function calls ( 
even with -O0 option ) but finally after a lot of attempts and reading online 
about devirtualisation, I found this particular example where the analyzer 
generates a false positive

#include 

struct A
{
virtual int foo (void) 
{
return 42;
}
};

struct B: public A
{
int *ptr;
void alloc ()
{
ptr = (int*)malloc(sizeof(int));
}
int foo (void) 
{ 
free(ptr);
return 0;
}
};

int test()
{
struct B b, *bptr=&b;
b.alloc();
bptr->foo();
return bptr->foo();
}

int main()
{
test();
}

working link of the above code (https://godbolt.org/z/n17WK4MxG 
)

here as the analyzer doesn’t understand the call to virtual function, wasn’t 
able to locate a double free in the program which was found at runtime.

so I went through it’s exploded graph to see how exactly is this being 
processed. And from the looks of things the anayzer doesn’t understood the 
function call which according to me was the following part in gimple 
representation :

1 = bptr_8->D.3795._vptr.A;
 _2 = *_1;
OBJ_TYPE_REF(_2;(struct B)bptr_8->0) (bptr_8)

after scanning the source-code a bit i found out that such calls were being 
processed by "region_model::handle_unrecognized_call()” where it just keeps 
track of reachable states from that node.

——

Questions 

1. The link to the bug tracker for vfunc() [ 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114 
 ] says that for vfuncs() 
to be understood by anayzer, it ought to be able to devirtualize calls, but is 
it possible to devirtualise all the calls ? what if it is random or depends on 
user input ?

2. Even though analyzer didn’t understood calls to virtual function, it didn’t 
gave warning about a memory leak either which according to it, should exist if 
the functions were never called to deallocate the pointer ( after exploded node 
152 and 118, the state of malloc changes automatically ) ?

sorry if I am asking a lot of questions.

Thank you

- Ankur

Re: GSoC 2021 - Static analyzer project

[David Malcolm via Gcc]

On Tue, 2021-04-06 at 17:56 +0530, Ankur Saini wrote:

Hi Ankur.

Various replies inline below throughout.

> > On 30-Mar-2021, at 7:27 PM, David Malcolm 
> > wrote:
> 
> > > This gave rise to some questions
> > > 
> > > 1. why does the analyzer make exceptions with the main() function
> > > ?
> > 
> > The user's attention is important - we don't want to spam the user
> > with
> > unnecessary reports if we can help it.
> 
> make sense. 
> 
> ——
> 
> After fiddling around with a lot of C codes, I switched to C++
> programs  in-order to find how exactly the analyzer doesn’t
> understand exception handling and more interestingly calls to virtual
> functions ( which I am thinking to work on this summer ). 

Sounds like a good focus.

> It was comparatively harder to find such an example where it would
> fail as looks like gcc do amazingly nice job at devirtualising the
> function calls ( even with -O0 option ) but finally after a lot of
> attempts and reading online about devirtualisation, I found this
> particular example where the analyzer generates a false positive
> 
> #include 
> 
> struct A
> {
>     virtual int foo (void) 
>     {
>     return 42;
>     }
> };
> 
> struct B: public A
> {
>     int *ptr;
>     void alloc ()
>     {
>     ptr = (int*)malloc(sizeof(int));
>     }
> int foo (void) 
>     { 
>     free(ptr);
>     return 0;
>     }
> };
> 
> int test()
> {
>     struct B b, *bptr=&b;
>     b.alloc();
>     bptr->foo();
>     return bptr->foo();
> }
> 
> int main()
> {
>     test();
> }
> 
> working link of the above code (https://godbolt.org/z/n17WK4MxG < 
> https://godbolt.org/z/n17WK4MxG>)
> 
> here as the analyzer doesn’t understand the call to virtual function,
> wasn’t able to locate a double free in the program which was found at
> runtime.

Good work.

> so I went through it’s exploded graph to see how exactly is this
> being processed. And from the looks of things the anayzer doesn’t
> understood the function call which according to me was the following
> part in gimple representation :
> 
> 1 = bptr_8->D.3795._vptr.A;
>  _2 = *_1;
> OBJ_TYPE_REF(_2;(struct B)bptr_8->0) (bptr_8)
> 
> after scanning the source-code a bit i found out that such calls were
> being processed by "region_model::handle_unrecognized_call()” where
> it just keeps track of reachable states from that node.

Again, good detective work.

Right - the analyzer "sees" the jump through a function pointer, and it
doesn't yet have any special knowledge about what that function pointer
might be.

Given that we know we have a B, we ought to be able to assume that B::B
initializes the vtable of the instance, and make assumptions about what
the values in that vtable are.  The analyzer doesn't have any of this
special-case knowledge yet - hence bug 97114.

> ——
> 
> Questions 
> 
> 1. The link to the bug tracker for vfunc() [   
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114 <  
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97114> ] says that for
> vfuncs() to be understood by anayzer, it ought to be able to
> devirtualize calls, but is it possible to devirtualise all the calls
> ? what if it is random or depends on user input ?

It's not possible for the general case.  Consider that there could be
other subclasses of A that we don't about in this translation unit.

But for this case, -fdump-ipa-analyzer=stderr shows this gimple at the
start of "test":

  B::B (&b);
  bptr_8 = &b;
  B::alloc (&b);
  _1 = bptr_8->D.3290._vptr.A;
  _2 = *_1;
  OBJ_TYPE_REF(_2;(struct B)bptr_8->0) (bptr_8);

As noted above, I think that we can add enough logic to the analyzer to
so that it "knows" that B::B should stores a vtable ptr, and then when
that vtable is accessed, it should know what functions are being
pointed to.  I think it would mean adding a new region subclass in the
analyzer, where an instance represents the vtable for a given class in
the user's code.

For cases where we have a "base *" and don't know which subclass the
instance is, we could potentially have the analyzer speculate about the
subclasses it knows about, adding exploded edges to speculated calls
for the various subclasses.  I don't yet know if this is a good idea,
but it seems worth experimenting with.

> 2. Even though analyzer didn’t understood calls to virtual function,
> it didn’t gave warning about a memory leak either which according to
> it, should exist if the functions were never called to deallocate the
> pointer ( after exploded node 152 and 118, the state of malloc
> changes automatically ) ?

If the analyzer "sees" a call to an unknown function (either through a
unknown function pointer, or to a function it doesn't have the body
of), it acts conservatively by resetting all of the state-machine state
for the values that are reachable by the function call, to avoid false
leak reports.  Hence it resets the state of B's ptr from the
"unchecked" allocation state back to the "start" state.

> sorry if I am asking a lot of quest

Re: Remove RMS from the GCC Steering Committee

[Siddhesh Poyarekar]

On 4/6/21 3:57 PM, Richard Biener via Gcc wrote:

Seeing the word "dysfunction" I don't remember using I want to clarify
the non-openess which I intended to criticize.  The SC is not "open" because:
- it appoints itself (new members, that is) - in fact in theory it
should be appointed
   by the FSF because the SC is the GNU maintainer of GCC
- all requests and discussions are _private_ - the SC does not report to the
   GCC project (it might report to the FSF which it is formally a delegate of)
- you can reach the SC only indirectly (unless you know the secret mailing list
   it operates on) - CC an SC member and hope a request is forwarded

now I understand the SC sees itself as buffer between GCC and the FSF (RMS
in particular) and it thinks we need to be protected from direct engagement.  I
think this is wrong.  I can very well say NO to RMS myself.


FWIW, the glibc FSF stewards are analogous to the SC and pretty much all 
of those points apply to them.  My impression is that it's a symptom of 
governance style of GNU projects (or maybe GNU *toolchain* projects due 
to shared history) and not specifically anything to do with the steering 
committee or the glibc FSF stewards.  Perhaps (and I guess it's more 
hope than knowledge) dissociation from GNU/FSF will make it easier to 
change the nature of the SC/steward governance.


Siddhesh

Re: Question about reading LTO function summaries

[Erick Ochoa via Gcc]

Hi Martin,

thanks for taking some time to help me. I think I accidentally deleted
the original hello world pass, but I have re-made it and I still have
the same problem. I copy paste the patch at the bottom. Just to give
some more context:

I am running the following command:

$PATH_TO_GCC/gcc -fipa-hello-world -flto main.c -fdump-ipa-hello-world

With the following simple main.c file:

```
int
foo ()
{
return 0;
}

int bar()
{
return 1;
}

int
main()
{
foo();
bar();
}

```

And I get the following output from the dump files:
a-main.c.079i.hello-world:
```
name of cgraph: main
name of cgraph: bar
name of cgraph: foo
hello world from write summary
writing 3
writing bar
writing foo
writing main
```

a.wpa.079i.hello-world:
```
hello from read summary
iteration = 1, data = f
hello from wpa
```

Many thanks again, and do let me know if there's anything I can do to help.


>From 8e0e2c7d821baab8ac6dbdd6fad590e8332b Mon Sep 17 00:00:00 2001
From: Erick Ochoa 
Date: Tue, 6 Apr 2021 16:34:48 +0200
Subject: [PATCH] Simple hello world for IPA_PASS

---
 gcc/Makefile.in   |   1 +
 gcc/common.opt|   4 ++
 gcc/ipa-hello-world.c | 159 ++
 gcc/lto-streamer.h|   1 +
 gcc/passes.def|   1 +
 gcc/tree-pass.h   |   1 +
 6 files changed, 167 insertions(+)
 create mode 100644 gcc/ipa-hello-world.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8a5fb3fd99c..567505e61f7 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1438,6 +1438,7 @@ OBJS = \
 incpath.o \
 init-regs.o \
 internal-fn.o \
+ipa-hello-world.o \
 ipa-cp.o \
 ipa-sra.o \
 ipa-devirt.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index a75b44ee47e..d221a4bf05c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3490,4 +3490,8 @@ fipa-ra
 Common Var(flag_ipa_ra) Optimization
 Use caller save register across calls if possible.

+fipa-hello-world
+Common Var(flag_ipa_hello_world) Optimization
+Hello world example.
+
 ; This comment is to ensure we retain the blank line above.
diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
new file mode 100644
index 000..dcaf8238d6c
--- /dev/null
+++ b/gcc/ipa-hello-world.c
@@ -0,0 +1,159 @@
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple-expr.h"
+#include "predict.h"
+#include "alloc-pool.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "diagnostic.h"
+#include "fold-const.h"
+#include "gimple-fold.h"
+#include "symbol-summary.h"
+#include "tree-vrp.h"
+#include "ipa-prop.h"
+#include "tree-pretty-print.h"
+#include "tree-inline.h"
+#include "ipa-fnsummary.h"
+#include "ipa-utils.h"
+#include "tree-ssa-ccp.h"
+#include "stringpool.h"
+#include "attribs.h"
+#include "gimple.h"
+#include "lto-streamer.h"
+#include "data-streamer.h"
+
+
+hash_map *hello_summaries = NULL;
+
+static void
+ipa_hello_world_generate_summary (void)
+{
+  hello_summaries = new hash_map;
+  struct cgraph_node *node = NULL;
+  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
+  {
+  if (dump_file) fprintf(dump_file, "name of cgraph: %s\n", node->name());
+  hello_summaries->put(node, node->name());
+  }
+}
+
+static void
+ipa_hello_world_write_summary (void)
+{
+  gcc_assert(hello_summaries);
+  struct output_block *ob = create_output_block (LTO_section_hello_world);
+  gcc_assert(ob);
+  if (dump_file) fprintf(dump_file, "hello world from write summary\n");
+  lto_symtab_encoder_t encoder = ob->decl_state->symtab_node_encoder;
+  if (dump_file) fprintf(dump_file, "writing %ld\n",
hello_summaries->elements());
+  streamer_write_uhwi (ob, hello_summaries->elements());
+
+  for (auto i = hello_summaries->begin(), e = hello_summaries->end();
+i != e; ++i)
+  {
+if (dump_file) fprintf(dump_file, "writing %s\n", (*i).second);
+streamer_write_uhwi(ob, lto_symtab_encoder_encode(encoder, (*i).first));
+streamer_write_string (ob, ob->main_stream, (*i).second, true);
+  }
+  produce_asm (ob, NULL);
+  destroy_output_block (ob);
+  //delete hello_summaries;
+}
+
+static void
+ipa_hello_world_read_summary (void)
+{
+  struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
+  struct lto_file_decl_data *file_data;
+  unsigned int j = 0;
+  if (dump_file) fprintf(dump_file, "hello from read summary\n");
+  while ((file_data = file_data_vec[j++]))
+  {
+size_t len;
+const char *data =
+  lto_get_summary_section_data (file_data, LTO_section_hello_world, &len);
+if (dump_file) fprintf(dump_file, "iteration = %d, data = %s\n",
j, data ? "t" : "f");
+if (!data) continue;
+
+// This has not been executed with my simple example programs
+const struct lto_function_header *header = (const struct
lto_function_header*) data;
+gcc_assert(header);
+gcc_assert(header->cfg_size);
+const int cfg_offset = sizeof (struct lto_function_header);
+const int main_offset = cfg_offse

Re: Remove RMS from the GCC Steering Committee

[Ian Lance Taylor via Gcc]

On Tue, Apr 6, 2021 at 3:28 AM Richard Biener
 wrote:
>
> Seeing the word "dysfunction" I don't remember using I want to clarify
> the non-openess which I intended to criticize.  The SC is not "open" because:
> - it appoints itself (new members, that is) - in fact in theory it
> should be appointed
>   by the FSF because the SC is the GNU maintainer of GCC
> - all requests and discussions are _private_ - the SC does not report to the
>   GCC project (it might report to the FSF which it is formally a delegate of)
> - you can reach the SC only indirectly (unless you know the secret mailing 
> list
>   it operates on) - CC an SC member and hope a request is forwarded
>
> now I understand the SC sees itself as buffer between GCC and the FSF (RMS
> in particular) and it thinks we need to be protected from direct engagement.  
> I
> think this is wrong.  I can very well say NO to RMS myself.
>
> I'm actually curious how many of the 13 SC members actively contribute or
> whether the "SC show" is a one or two persons game and the "13" is just
> to make the SC appear as a big representative group of people.
>
> Thus I request an archive of the SC mailing list be made publically available
> and the SC discussion from now on take place in an open forum (you can
> choose to moderate everybody so the discussion while carried out in open
> is still amongst SC members only).

To a first approximation, the only thing that the SC does is approve
maintainers.  Questions like Nathan's example of libcody are rare.  To
be pedantically clear, by "maintainers" I mean the people listed in
the MAINTAINERS file who have the right to approve and commit changes
to various parts of the compiler.

While most discussion about approving maintainers is pro forma, there
are sometimes discussions as to whether a particular person has the
appropriate knowledge and sense of responsibility for the role.  I
don't think it would be appropriate to require that those discussions
be held publically.  In any case it wouldn't work; if they were
required to be public, SC members would resort to private e-mail for
anything they didn't want to be public.

So perhaps one thing we should be talking about is: can we develop a
mechanism for approving maintainers that does not involve the SC?

For example, I am also involved with the Go language project.  In that
project, any existing maintainer (that is, any person with the right
to commit changes to the repo) can approve any person to be a new
maintainer.  However, all changes require approval from at least two
maintainers, and, of course there are people who take at least a quick
look at every commit after it happens.  The two maintainer rule is
enforced by tooling, as all changes to Go must be made through Gerrit
(https://www.gerritcodereview.com/).  I'm not suggesting that we adopt
this for GCC, just mentioning as an example of a different approach
that does not require anything like the SC.

I'm sure other people on this list can give examples of other
approaches used by other free software projects.

Ian

Re: [GSoC-2021] Interested in project `Extend the static analysis pass`

[Saloni Garg via Gcc]

Hi, apologies for the delayed reply. I was having some college commitments.
On Wed, Mar 31, 2021 at 11:22 PM David Malcolm  wrote:

> On Wed, 2021-03-31 at 21:41 +0530, Saloni Garg wrote:
> > On Tue, Mar 30, 2021 at 6:42 PM David Malcolm 
> > wrote:
> >
> > > On Tue, 2021-03-30 at 16:06 +0530, Saloni Garg wrote:
> > > > On Sun, Mar 28, 2021 at 8:03 PM David Malcolm <
> > > > dmalc...@redhat.com>
> > > > wrote:
>
> [...snip...]
>
> > > >
> > No, it's actually fun learning all this. Thank you for sharing all
> > the
> > references. Although, I was already using gdb to travel inside the
> > code.
>
> Great!
>
> > >
> > > > > > Please, let me know your thoughts on this.
> > > > >
> > > > > Looks like you're making a great start.
> > > > >
> > > > Thanks for the feedback.  In parallel, can I start working on the
> > > > Gsoc
> > > > proposal as well?
> > >
> > > Please do work on the formal proposal - without it we can't accept
> > > you
> > > as a GSoC student.  The window for submitting proposals opened
> > > yesterday, and I believe it closes in a couple of weeks, and you
> > > need
> > > to do that, so any experimentation you do now should really just be
> > > in
> > > support of writing a good proposal.  It would be a shame to not
> > > have a
> > > good prospective candidate because they didn't allow enough time to
> > > do
> > > the proper GSoC paperwork before the deadline.
> > >
> > Thanks for understanding. Here is an initial draft (
> >
> >
> https://docs.google.com/document/d/1inkkU5B55s_FOWRzUuf38s7XEet65kc0dW3yFn0yh1M/edit?usp=sharing
> > )
> > of my GSoC proposal. I am yet to fill in the missing blocks.
> > Please, let me know if you have any comments on the document itself.
>
> Caveat: I'm not familiar with the expected format of such documents.
>
> Looks like a good first draft.

I don't think there is any such expected format(I checked some previous
years accepted proposals). I believe if we clearly write the expected goal
and the tentative approach to reach it, that would be okay for the proposal.

>
> Some notes:
> - maybe update the title to be more specific (i.e. that it's about
> extending the pass to support C++ exception-handling)
>
Done.

> - my email address is misspelled (missing the leading "d")
>
Really sorry. Done.

> - in Example 2, maybe spell out why it's a leak - when does the
> allocated buffer stop being referenceable?
>
Explained. Please let me know if you feel it has any loose ends.

> - you have a simple example of a false negative; is it possible to give
> a simple example of a false positive?  (I think "new" is meant to raise
> an exception if it fails, so a diagnostics about a NULL-deref on
> unchecked new might be a false positive.  I'm not sure)
>
I tried the following example:

#include 
#include 
using namespace std;
int *p;
int* alloc() {
   return new int;
}
void free() {
   delete p;
}
int main()
{
   try {
 p = alloc();
 free();
   } catch(...) {
   }
   return 0;
}
Please, have a look here (https://godbolt.org/z/8WvoaP67n). I believe it is
a false positive, I am not sure, please confirm.

> - maybe specify that this is exception-handling specifically for C++
> code (GCC supports many languages)
>
Done.

> - "sample example programs": for "sample" did you mean to write
> "simple" here?
>
By sample examples, I meant the test cases that shall be used to prove the
correctness of the patches during the course.

> - as well as understanding code, you'll need to understand data,
> specifically getting a feel for the kinds of control flow graphs that
> the analyzer is receiving as inputs i.e. what the analyzer "sees" when
> the user inputs various C++ language constructs; what interprocedural
> vs intraprocedural raise/try/catch situations look like, etc.
>
I am in the process to understand how the analyzer works. I believe I have
just got a gist of the approach being used. The gimple graph has been
processed in a Worklist manner. We analyze each statement and add
predecessors/successors if there is some new information coming out of the
analyzed statement. For example, In the memory leak examples discussed
here, if at a statement I see a *new *expression, then I need to add all
the nodes where this value can flow into, to find out a possible *free
*expression
to block the possible memory leak.
In the case of interprocedural, I need to incorporate the effects of any
function calls in between and see if it changes my analysis result or not.

Please, let me know if I am wrong somewhere.
-Saloni

>
> Hope this makes sense and is helpful
> Dave
>
>

GCC association with the FSF

[Mark Wielaard]

Hi,

Lets change the subject now that this is about GCC and the FSF.

On Wed, Mar 31, 2021 at 01:46:29PM +0100, Jonathan Wakely via Gcc wrote:
> Probably unintentionally, but he has allowed the GNU Project to become
> a nasty cult of personality. The FSF seems to be imploding (with mass
> resignations in the past week). I don't think GCC benefits from being
> associated with either of them.

I admit it isn't looking very good and their last announcement is
certainly odd: https://status.fsf.org/notice/3833062

But apparently the board is still meeting this week to discuss and
might provide a better statement about the way out of this. So lets
give them a couple more days before writing them off completely.

> Is there any incident where FSF being the copyright holder for GCC has
> made a difference?

Yes, at least in my experience it has been helpful that the FSF held
copyright of code that had been assigned by various individuals and
companies. It allowed the merger of GNU Classpath and libgcj for
example. There have been various intances where it was helpful that
the FSF could unilatrally adjust the license terms especially when the
original contributor couldn't be found or didn't exist (as company)
anymore.

And it is really helpful that we don't have to ask permission of every
individual contributor to be able to create the GCC manual (because
the GPL code and GFDL text could otherwise not be combined) but that
the FSF can grant an exception to one of the developers to create it.

> Are there any GPL violations involving GCC code
> that were resolved only because all copyright resides with a single
> entity, that couldn't have been resolved on behalf of individual
> copyright holders?

I think it has been very helpful preventing those violations. If you
only have individual copyright holders instead of an organisation with
the means to actually resolve such violations people pay much more
attention to play by the rules. See for example the linux kernel
project. I believe there are so many GPL violations precisely because
almost no individual has the means to take up a case.

> Are we still worried about BigCorp trying to do a proprietary fork of
> GCC? Because BigCorp, OtherCorp etc. have shown that they would prefer
> to create a new toolchain from scratch rather than use GNU code. And
> if EvilCorp want to make their own proprietary compiler with secret
> optimizations, they'll just use LLVM instead of bothering to violate
> the GPL. The work done to make it impossible to steal GCC code was a
> success: nobody is even interested in stealing it now. There is an
> easier option.

I admit that the only way proprietary compiler writers can compete
with GCC is by producing a lax-permissive licensed compiler is an odd
way to win for Free Software. But we should still make sure that GCC
itself makes it so that users can actually get the sources of the
compiler they are using and not just some sources that might or might
not correspond to the binary they are using. Making sure that the code
reaches actual users and not just some corporate hackers to create a
proprietary compiler is what counts IMHO. And using strong copyleft
and having a shared copyright pool of code held by an entity that can
enforce that is still necessary IMHO.

> Can we break our (already weak) ties to GNU?

I hope GCC stays part of GNU, but that we might reconsider whether it
is in the best interest of GNU and GCC as Free Software project to
still be associated with the FSF. The GNU Assembly is having a similar
discussion right now
https://lists.gnu.tools/postorius/lists/assembly.lists.gnu.tools/

Cheers,

Mark

Re: GCC association with the FSF

[Christopher Dimech via Gcc]

> Sent: Wednesday, April 07, 2021 at 10:22 AM
> From: "Mark Wielaard" 
> To: "Jonathan Wakely" 
> Cc: "GCC Development" 
> Subject: GCC association with the FSF
>
> Hi,
>
> Lets change the subject now that this is about GCC and the FSF.
>
> On Wed, Mar 31, 2021 at 01:46:29PM +0100, Jonathan Wakely via Gcc wrote:
> > Probably unintentionally, but he has allowed the GNU Project to become
> > a nasty cult of personality. The FSF seems to be imploding (with mass
> > resignations in the past week). I don't think GCC benefits from being
> > associated with either of them.
>
> I admit it isn't looking very good and their last announcement is
> certainly odd: https://status.fsf.org/notice/3833062
>
> But apparently the board is still meeting this week to discuss and
> might provide a better statement about the way out of this. So lets
> give them a couple more days before writing them off completely.
>
> > Is there any incident where FSF being the copyright holder for GCC has
> > made a difference?
>
> Yes, at least in my experience it has been helpful that the FSF held
> copyright of code that had been assigned by various individuals and
> companies. It allowed the merger of GNU Classpath and libgcj for
> example. There have been various intances where it was helpful that
> the FSF could unilatrally adjust the license terms especially when the
> original contributor couldn't be found or didn't exist (as company)
> anymore.
>
> And it is really helpful that we don't have to ask permission of every
> individual contributor to be able to create the GCC manual (because
> the GPL code and GFDL text could otherwise not be combined) but that
> the FSF can grant an exception to one of the developers to create it.

I have been discussing with Richard Stallman how we could get compatibility
between the GFDL and the other licences.

> > Are there any GPL violations involving GCC code
> > that were resolved only because all copyright resides with a single
> > entity, that couldn't have been resolved on behalf of individual
> > copyright holders?
>
> I think it has been very helpful preventing those violations. If you
> only have individual copyright holders instead of an organisation with
> the means to actually resolve such violations people pay much more
> attention to play by the rules. See for example the linux kernel
> project. I believe there are so many GPL violations precisely because
> almost no individual has the means to take up a case.
>
> > Are we still worried about BigCorp trying to do a proprietary fork of
> > GCC? Because BigCorp, OtherCorp etc. have shown that they would prefer
> > to create a new toolchain from scratch rather than use GNU code. And
> > if EvilCorp want to make their own proprietary compiler with secret
> > optimizations, they'll just use LLVM instead of bothering to violate
> > the GPL. The work done to make it impossible to steal GCC code was a
> > success: nobody is even interested in stealing it now. There is an
> > easier option.
>
> I admit that the only way proprietary compiler writers can compete
> with GCC is by producing a lax-permissive licensed compiler is an odd
> way to win for Free Software. But we should still make sure that GCC
> itself makes it so that users can actually get the sources of the
> compiler they are using and not just some sources that might or might
> not correspond to the binary they are using. Making sure that the code
> reaches actual users and not just some corporate hackers to create a
> proprietary compiler is what counts IMHO. And using strong copyleft
> and having a shared copyright pool of code held by an entity that can
> enforce that is still necessary IMHO.
>
> > Can we break our (already weak) ties to GNU?
>
> I hope GCC stays part of GNU, but that we might reconsider whether it
> is in the best interest of GNU and GCC as Free Software project to
> still be associated with the FSF. The GNU Assembly is having a similar
> discussion right now
> https://lists.gnu.tools/postorius/lists/assembly.lists.gnu.tools/
>
> Cheers,
>
> Mark
>