cgraph: does node->inlined_to imply node->clones is non-empty?

[Arsen Arsenović via Gcc]

Hi,

I was debugging PR96059 and ran into a question which does not seem
obvious from the code.

For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function.  When the original inline
happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
a clone, since the function being cloned is a master clone but with no
non-inline clones.

This decision later trips up the gcc_assert in:

  /* Inline clones might be kept around so their materializing allows further
 cloning.  If the function the clone is inlined into is removed, we need
 to turn it into normal cone.  */
  FOR_EACH_FUNCTION (node)
{
  if (node->inlined_to
  && !node->callers)
{
  gcc_assert (node->clones);
  node->inlined_to = NULL;
  update_inlined_to_pointer (node, node);
}
  node->aux = NULL;
}

.. because it is expecting that an inlined function without callers
(which is necessarily true here as this function is unreachable and so
was ->remove ()'d earlier) has clones.

Either removing the assertion or making clone_inline_nodes clone when
there are no existing clones 'fixes' (suppresses, but I haven't verified
whether the results are correct) the problem.

Is this gcc_assert correct in that an inlined function without callers
necessarily must have clones?

And as a side question, do all clone nodes have a ->clones pointing to
the same list of all clones, or are they in a tree-ish arrangement,
where clones of clones end up forming a tree, with the clone_of pointer
being a pointer to the parent?  (in this instance, the node that trips
the assert has a nullptr clone_of and clones value, which would AIUI
imply that it is the original)

This train of thinking doesn't end up involving any devirtualization
code, which the PR was originally reproduced with, but my current theory
is that devirtualizing here just exposed an edge case that is decently
well hidden, rather than it playing a crucial role.

Thanks in advance, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Regarding GSOC

[Megha Raj via Gcc]

Respected sir/mam,

Actually I want to know what are skills you desire to have in the members
of your organization as I’m aware with c &c++ so, can you please let me
know other than this what knowledge should I know for getting selected in
your franchise in deep

Re: No warning about duplicate values in enum

[Marek Polacek via Gcc]

On Sat, Mar 11, 2023 at 04:48:14PM +, Jonathan Wakely via Gcc wrote:
> On Sat, 11 Mar 2023, 12:53 Basile Starynkevitch, 
> wrote:
> 
> > Hello all,
> >
> >
> > Andrea observed that:
> >
> > In gcc 8.3.0, compiling
> >
> >
> > enum
> > test
> >{
> >  FIRST = 1,
> >  SECOND = 1,
> >  THIRD = 2
> >};
> >
> > int
> > main (void)
> > {
> >return 0;
> > }
> >
> >
> > generates no warning even with -Wextra.
> >
> > I believe that the C standard (which I don't have here, but see also
> > https://port70.net/~nsz/c/c11/n1570.html or buy it from ISO) explicitly
> > allow duplicate values in enum.
> >
> 
> 
> Of course it does, it's perfectly valid. Nobody has said it should be
> rejected. The request is for a warning, because for *some* uses of enums
> duplicates are not wanted.

And as I said in the other thread about the very same issue, it's
 which is assigned to me and I hope to
implement it for GC 14.

Marek

Re: No warning about duplicate values in enum

[Basile Starynkevitch]

On 3/13/23 14:29, Marek Polacek wrote:

On Sat, Mar 11, 2023 at 04:48:14PM +, Jonathan Wakely via Gcc wrote:

On Sat, 11 Mar 2023, 12:53 Basile Starynkevitch, 
wrote:


Hello all,


Andrea observed that:

In gcc 8.3.0, compiling


enum
test
{
  FIRST = 1,
  SECOND = 1,
  THIRD = 2
};

int
main (void)
{
return 0;
}


generates no warning even with -Wextra.

I believe that the C standard (which I don't have here, but see also
https://port70.net/~nsz/c/c11/n1570.html or buy it from ISO) explicitly
allow duplicate values in enum.



Of course it does, it's perfectly valid. Nobody has said it should be
rejected. The request is for a warning, because for *some* uses of enums
duplicates are not wanted.

And as I said in the other thread about the very same issue, it's
 which is assigned to me and I hope to
implement it for GCC 14.

Marek



Then consider perhaps:

prototyping that warning in your own GCC plugin (and test it on a bunch 
of existing open source software).


adding some explicit new warning option to enable that new warning or 
adding another option to disable that warning in a compilation unit.


adding some explicit #pragma to disable that new warning (with the hope 
that tools generating C++ code would later -in 2024- emit the pragma 
appropriately)


Since there are some valid, probably weird, cases (notably generated C++ 
code, or low level driver code where two different enum names need to 
share some common values, ) where having duplicate values in enum 
may make sense.


Regards

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: [GSoC][Static Analyzer] Ideas for proposal

[David Malcolm via Gcc]

On Sun, 2023-03-12 at 23:20 +0100, Shengyu Huang wrote:
> Hi Dave,
> 
> > > 
> > > 4. What’s the most interesting to me are PR103533
> > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533),
> > 
> > Turning on taint detection by default would be a great project.  It
> > would be good to run the integration tests:
> >  https://github.com/davidmalcolm/gcc-analyzer-integration-tests
> > to see if anything regresses, or if it adds noise - so this might
> > be a
> > bit of an open-ended project, in that we'd want to fix whatever
> > issues
> > show up there, as well as the known ones that are documented in
> > that
> > bug.
> > 
> 
> Sorry for replying to you late due to another project from my
> university. 
> 
> Since most other ideas are being worked on by you or not big enough
> to make a GSoC project, I decided to take on this project and have
> been getting familiar with the analyzer this weekend. 

Excellent; thanks.

> I want to sort several things out before writing the proposal.
> 
> 1. What should I do with the integration tests?

First of all, AFAIK I'm the only person who's tried running the
integration tests.  They're the test scripts I wrote to help me
validate my own patches, so there will be rough edges; please let me
know as you run into them, so I can fix/document them.

I have scripts that run the integration test's test.py, passing in the
path to the built gcc and a "run directory" where the builds happen; I
do this for a "control" build of gcc, and for an "experiment" build
that has a patch (each with their own run directory).  This script
attempts to use that gcc to build the various projects, capturing the
diagnostics as lots of little .sarif files in the build dir.

One of these run directories takes about 17G of drive space, and takes
about an hour for me on a fast machine I have (64 cores).  We'll
probably need to get you set up with an account on the gcc compile
farm, which has lots of powerful machines that you can ssh into, unless
your university has something powerful you can use (with plenty of
cores, RAM, and free disk space, e.g. at least 60G of disk)

I then have a script that runs compare-by-warning.py, passing in the
paths to the two run dirs; this recurses through the two rundirs,
loading the .sarif files, and attempts to compare the before vs after
diagnostics.  I've attempted to classify the results I've seen via the
known-issues/*.txt files, so that the comparison has some knowledge
about whether the changes we've seen are e.g.:
- new false positives vs 
- new true positives vs
- false positives going away vs 
- true positives going away 
(etc)

That said, the "Juliet" results are currently rather unwieldy (many
more results than for the other projects, and 9.1G of the 17G by
space), so I tend to move them out of the way before doing the
comparison.

> 
> 2. I ran gcc -fanalyzer -fanalyzer-checker=taint ./gcc-
> src/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools-signed-char.c , but
> I got different results from what you documented in PR103533:
> 
> /usr/bin/ld: /lib/x86_64-linux-gnu/crt1.o: in function `_start':
> (.text+0x17): undefined reference to `main'
> collect2: error: ld returned 1 exit status

gcc's default is to try to compile, assemble, and link into an
executable.  This testcase doesn't have a "main" function, hence the
linker complains.  If you pass "-S", it will merely compile the .c to a
.s assembler file whilst still running the analyzer.

In terms of actually running the test suite via DejaGnu, see:
https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html

I typically use:

  make -k -jN \
  && time make check-gcc \
 RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\} 
analyzer-torture.exp=*.c analyzer.exp=*.c"

when testing the analyzer regression test suite, where N is the number
of cores on my box

When I run an individual testcase, I do something like:

./xgcc -B. -S -fanalyzer ../../src/PATH_TO_TEST_CASE

in the "gcc" subdirectory of the build directory.


> 
> 3. What does “ICE” mean when you said “ICE in alt_get_inherited_state
> in abs-1.c, …”?

ICE is our jargon for "internal compiler error" i.e. a crash of gcc
itself.

> 
> 4. For the following program, nothing is reported with the taint mode
> turned on. But there is -Wanalyzer-tained-divisor, is it expected?
> 
> __attribute__((tainted_args))
> int fun0(int a)
> { return a; }
> 
> int main()
> {
>   int b = 3 / fun0(0);
>   return b;
> }

Yes: in that the 0 came from the source of the program, rather than
from an attacker, so it's not tainted.  The analyzer doesn't have a
good way to attach state-machine state to a constant, only to other
kinds of symbolic value.

See
  gcc/testsuite/gcc.dg/analyzer/taint-divisor-1.c 
  gcc/testsuite/gcc.dg/plugin/taint-antipatterns-1.c
for examples that ought to report tainted divisors (the former from
"fread", the latter from "copy_from_user" via a plugin)


> 
> 5. I guess the project would mostly modify constraint-ma

[GSoC] gccrs Unicode support

[Raiki Tamura via Gcc]

Hello,

My name is Raiki Tamura, an undergraduate student at Kyoto University in
Japan and I want to work on Unicode support in gccrs this year.
I have already written my proposal (linked below) and shared it with the
gccrs team in Zulip.
In the project, I am planning to use the GNU unistring library to handle
Unicode characters and the GNU IDN library to normalize identifiers.
According to my potential mentor, it would provide Unicode libraries for
all frontends in GCC. If there are concerns or feedback about this, please
tell me about it.
Thank you.

Link to my proposal:
https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing

Raiki Tamura

Re: GSoC'2023: Separate Host Process Offloading: GCC

[Thomas Schwinge]

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
--- Begin Message ---
Hi Madhu!

(As you've sent your equally worded
"GSoC'2023: Bypass assembler when generating LTO object files: GCC" email
to , let me also Cc my reply here to that list, so that
others may contribute, too.)


On 2023-03-09T01:36:02+0530, Madhu patel  wrote:
> I'm interested in working on the project `Separate Host Process Offloading`
> in the GCC organization through GSoC'2023.

Great, and welcome to GCC!  :-)

> Please suggest a few initial tasks I can work on during the application
> period and attach them to my application.

Building GCC and producing test results would be one obvious first task,
have you worked on that already?
 has some
pointers to get started.  If you have specific questions, we're happy to
help, of course.

Then, get familiar with the basic concepts of code offloading in GCC.
 is the best (only?) we have,
unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c', and
actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
the API you need to care about (for OpenACC; but OpenMP 'target' also
won't require much more, for a start).

Make some thoughts (or actual experiments) about how we could
use/implement a separate host process for code offloading.

> I have already prepared a
> timeline/planner, great if you could have a look at it and suggest any
> enhancements.

That wasn't attached to or referred to in your email?

> Additionally, I have signed in to the mailing lists, and IRCs
> and done the initial tasks as described on the project page [1]
> .

Which specifically?


Grüße
 Thomas


signature.asc
Description: PGP signature
--- End Message ---

Re: GSoC'2023: Separate Host Process Offloading: GCC

[Thomas Schwinge]

Hi!

Sorry, let me try again -- our IT department likes to garble emails in
order to attach a "disclaimer"...


On 2023-03-13T21:37:24+0100, I wrote:
> Hi Madhu!
>
> (As you've sent your equally worded
> "GSoC'2023: Bypass assembler when generating LTO object files: GCC" email
> to , let me also Cc my reply here to that list, so that
> others may contribute, too.)
>
>
> On 2023-03-09T01:36:02+0530, Madhu patel  wrote:
>> I'm interested in working on the project `Separate Host Process Offloading`
>> in the GCC organization through GSoC'2023.
>
> Great, and welcome to GCC!  :-)
>
>> Please suggest a few initial tasks I can work on during the application
>> period and attach them to my application.
>
> Building GCC and producing test results would be one obvious first task,
> have you worked on that already?
>  has some
> pointers to get started.  If you have specific questions, we're happy to
> help, of course.
>
> Then, get familiar with the basic concepts of code offloading in GCC.
>  is the best (only?) we have,
> unfortunately, and it's somewhat out of date, so beware, sorry.  Looking
> at existing libgomp plugins may help: 'libgomp/plugin/plugin-*.c', and
> actually also the very simple 'libgomp/oacc-host.c'.  That's essentially
> the API you need to care about (for OpenACC; but OpenMP 'target' also
> won't require much more, for a start).
>
> Make some thoughts (or actual experiments) about how we could
> use/implement a separate host process for code offloading.
>
>> I have already prepared a
>> timeline/planner, great if you could have a look at it and suggest any
>> enhancements.
>
> That wasn't attached to or referred to in your email?
>
>> Additionally, I have signed in to the mailing lists, and IRCs
>> and done the initial tasks as described on the project page [1]
>> .
>
> Which specifically?


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955