Re: [GSOC] query about C++: Implement compiler built-in traits for the standard library traits

[Anastasia3412 via Gcc]

Thanks, Martin and Jonathan for your suggestion. I have already finished 
building gcc from source. I was looking at other project ideas and found 
"Enable incremental Link Time Optimization (LTO) linking" interesting. Can 
anyone please explain how to proceed further with this? Currently, I am 
watching videos posted in the getting started section.

--- Original Message ---
On Wednesday, March 22nd, 2023 at 5:04 AM, Jonathan Wakely 
 wrote:


> On Tue, 21 Mar 2023 at 21:16, Martin Jambor wrote:
> 
> > Hello Anastasia,
> > 
> > we are very happy that you are considering contributing to GCC.
> > 
> > On Mon, Mar 20 2023, Anastasia3412 via Gcc wrote:
> > 
> > > Hello Everyone I'm Anastasia.
> > > 
> > > I am a prospective GSOC Student. I wish to know if the project C++:
> > > Implement compiler built-in traits for the standard library traits is
> > > still available. I have already build and got my hand dirty on
> > > debugging GCC.
> > 
> > Various prospective contributors have shown interest in it but we have
> > not "promised" it to anyone, I don't think we can, so it is "available."
> > It has been discussed for example here:
> > https://gcc.gnu.org/pipermail/gcc/2023-February/240816.html

> 
> 
> We already have two candidates working on it, before their proposal
> has even been accepted. As a result, I think you'd have to be a very
> strong candidate to get accepted for that project, and it might be
> better to pick another one.

Re: [GSoC] Discussion of warnings and of a first patch (name-hiding)

[Benjamin Priour via Gcc]

Hi Jason,

Sorry for the delayed answer, I was in my exam period!

I've almost finished the patch (PR12341
), and wrote a testcase
to compare it against.
In it I use dejaGNU instructions of the format:
 /* { dg-warning "'C::bbb' might shadow 'B::bbb'." "" { target *-*-* }
C_shadowing_bbb } */
and run the test with:
make check-gcc-c++ RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\}
dg.exp=pr12341-1.C"
I get expected results on most target, except on target hppa*-*-hpux*.
I have been looking around the documentation, yet I cannot find a way to
run on that target specifically, especially considering the wildcards. How
to test GCC on a simulator  don't
specify that target in the bottom table.
Would you have any guidance on how to do so ? I would like to debug the
test on that platform.

Otherwise, I believe it is working just fine, I put it as an enhancement to
-Wshadow. Should I send it to gcc-patches ? I wasn't sure I was supposed to
since it's still buggy, so I preferred to refrain.


>   Up to now I have considered some extra warning

> 1- Warning for NULL smart pointers dereferencing. E.g. when a smart
> > pointer is left uninitialized yet is derefe0renced.
>
> I would expect that to be covered by (enhancements to?) the existing
> -Wuninitialized or -Wmaybe-uninitialized or
> -Wanalyzer-use-of-uninitialized-value.
>

> > 3- Use after move.
>
> Hmm, it might make sense to approach this as an enhancement to the
> uninitialized warnings whereby a move makes us consider the object no
> longer initialized, much like -Wuse-after-free and
> -Wanalyzer-use-after-free.
>
> > 4- Use references or raw pointers as parameters when ownership is not
> > considered. (For general use, take T* or T& arguments rather than smart
> > pointers
> > <
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f7-for-general-use-take-t-or-t-arguments-rather-than-smart-pointers
> >)
>
> This seems feasible to implement in the front-end.
>
>
I will update on these warnings and a few questions on the analyzer
tomorrow, I now got some free time back.
Benjamin

I have questions regarding the 4.3 codebase...

[Sid Maxwell via Gcc]

Is there anyone on the list with experience with the gcc 4.3 codebase?  I'm
currently maintaining a fork of it, with a PDP10 code generator.

I've run into an issue involving the transformation of a movmemhi to a
single PDP10 instruction (an xblt, if you're curious).  The transformation
appears to 'lose' its knowledge of being a store, resulting in certain
following stores being declared dead, and code motion that shouldn't happen
(e.g. a load moved before the xblt that depends on the result of the xblt).

I'm hoping to find someone who can help me diagnose the problem.  We want
to use this instruction rather than the copy-word-loop currently generated
for struct assignments.

Thanks, in advance, for any assistance.

-+- Sid Maxwell

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

[David Malcolm via Gcc]

On Tue, 2023-03-21 at 11:01 +0100, Shengyu Huang wrote:
> Hi Dave,
> 
> > I implemented my own approach, with a "widening_svalue" subclass of
> > symbolic value.  This is widening in the Abstract Interpretation
> > sense,
> > (as opposed to the bitwise operations sense): if I see multiple
> > values
> > on successive iterations, the widening_svalue tries to simulate
> > that we
> > know the start value and the direction the variable is moving in.
> 
> I guess you are using interval domain? I haven’t played with abstract
> interpretation a lot, but I think the polyhedra domain is the more
> popular domain used (but more difficult to implement ofc). In a
> course project I did before, I remember switching to polyhedra domain
> from the interval domain allowed me to prove the properties I wanted
> to prove.

Sorry if what I wrote was misleading: I'm not using abstract
interpretation per se; the analyzer is doing symbolic execution.  It
uses a worklist to explore the exploded_graph of (point, state) pairs,
but I have quite complicated state objects.

What I mean is that the widening_svalue is an abstraction, and the hope
is that it will get reused within the program_state object for
representing the state of the loop variant the next time through the
loop, and thus the program_state is the same as the previous iteration,
and thus we effectively have a cache hit within the exploded_graph (and
can terminate the analysis).  I see this as somewhat analogous to the
convergence that happens in an abstract interpretation approach, in
that we go from the:
  - initial value
  - widened to cover range from initial value up to +infinity
and thus (hopefully) terminate in two steps.

But it doesn't work very well, alas.

As noted in another thread, I've just filed:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109252
with some ideas on better ways of handling loops in the analyzer.

> 
> Also, are you using the same approach maybe to detect nontermination
> of loops? Maybe when you find out you have to widen the variable
> range to (minus) infinity?

For GCC 13 I've added a warning: -Wanalyzer-infinite-recursion
implemented in gcc/analyzer/infinite-recursion.cc which attempts to
detect infinite *recursions* based on states being too similar when
recursing: if nothing can have effectively changed, it's an infinite
recursion (for some definition of "effectively).

I'd hoped to implement something similar for *loop* detection, but it
didn't make feature freeze for GCC 13; see:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
The half-finished prototype I have works in a similar way to the
recursion detection: find loops such as:

for (int i = 0; i < 10; i++)
  for (int j = 0; j < 10; i++)
{
}

where due to the copy-and-paste error of reusing "i++", "j" never
changes after entering the inner loop, and we never leave it.

> 
> > 
> > This doesn't work well; arguably I should rewrite it, perhaps with
> > an
> > iterator_svalue, though I'm not sure how it ought to work.  Some
> > ideas:
> > 
> > * reuse gcc's existing SSA-based loop analysis, which I believe can
> > identify SSA names that are iterator variables, figure out their
> > bounds, and their per-iteration increments, etc.
> > 
> > * rework the program_point or supergraph code to have a notion of
> > "1st
> > iteration of loop", "2nd iteration of loop", "subsequent
> > iterations",
> > or similar, so that the analyzer can explore those cases
> > differently
> > (on the assumption that such iterations hopefully catch the most
> > interesting bugs)
> 
> I haven’t thought about how to do this properly in gcc, but maybe we
> can infer loop invariants (or even allow users to annotate loop
> invariants…but I guess it would change a lot of things outside the
> scope of current analyzer) that can help us do multiple checks for a
> loop. I have only seen this strategy used on the source level before,
> and I don’t know how difficult it will be to implement it on
> gimple…There is a paper I haven’t had the time to read but maybe you
> will find interesting: https://arxiv.org/pdf/1407.5286.pdf

Thanks!
Dave

Re: [Static Analyzer] Loop handling - False positive for malloc-sm

[David Malcolm via Gcc]

On Tue, 2023-03-21 at 09:21 +0100, Pierrick Philippe wrote:
> On 21/03/2023 00:30, David Malcolm wrote:
> > On Mon, 2023-03-20 at 13:28 +0100, Pierrick Philippe wrote:
> > > Hi everyone,
> > > 
> > > I'm still playing around with the analyzer, and wanted to have a
> > > look
> > > at
> > > loop handling.
> > > I'm using a build from /trunk/ branch (/20230309/).
> > > 
> > > Here is my analyzed code:
> > > 
> > > '''
> > > 1| #include 
> > > 2| int main(void) {
> > > 3|    void * ptr = malloc(sizeof(int));
> > > 4|    for (int i = 0; i < 10; i++) {
> > > 5|    if (i == 5) free(ptr);
> > > 6|    }
> > > 7|}
> > > '''
> [stripping]
> > > So, I'm guessing that this false positive is due to how the
> > > analyzer
> > > is
> > > handling loops.
> > > Which lead to my question: how are loops handled by the analyzer?
> > Sadly, the answer is currently "not very well" :/
> > 
> > I implemented my own approach, with a "widening_svalue" subclass of
> > symbolic value.  This is widening in the Abstract Interpretation
> > sense,
> > (as opposed to the bitwise operations sense): if I see multiple
> > values
> > on successive iterations, the widening_svalue tries to simulate
> > that we
> > know the start value and the direction the variable is moving in.
> > 
> > This doesn't work well; arguably I should rewrite it, perhaps with
> > an
> > iterator_svalue, though I'm not sure how it ought to work.  Some
> > ideas:
> > 
> > * reuse gcc's existing SSA-based loop analysis, which I believe can
> > identify SSA names that are iterator variables, figure out their
> > bounds, and their per-iteration increments, etc.
> > 
> > * rework the program_point or supergraph code to have a notion of
> > "1st
> > iteration of loop", "2nd iteration of loop", "subsequent
> > iterations",
> > or similar, so that the analyzer can explore those cases
> > differently
> > (on the assumption that such iterations hopefully catch the most
> > interesting bugs)


I've filed an RFE discussing some of the problems with -fanalyzer's
loop-handling here:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109252

including the idea of making use of GCC's existing SSA-based loop
analysis (which discovers a tree of loops within each function's CFG).

> 
> I see, I don't know if you ever considered allowing state machines to
> deal with loops on their own.
> Such as having an API to allow to register a callback to handle
> loops, 
> but not in a mandatory way.
> Or having a set of APIs to optionally implement for the analyzer to
> call.

I hadn't thought of that, but it sounds like a reasonable idea.

> 
> It would allow state machines to analyze loops with the meaning of
> their 
> inner analysis.
> 
> Which could allow them to try to find a fixed point in the loop 
> execution which doesn't have
> any impact on the program state for that state machine. Kind of like
> a 
> custom loop invariant.
> Because depending of the analysis goal of the state machine, you
> might 
> need to symbolically execute the loop
> only a few times before reentering the loop and having the entry
> state 
> being the same as the end-of-loop state.

The analyzer performs symbolic execution; it tries to achieve a
reasonable balance between:
* precision of state tracking versus
* achieving decent coverage of code and data flow
* ensuring termination
via various heuristics.

Its current loop implementation uses widening_svalue and the complexity
limits on svalues/regions to attempt to have the symbolic execution
terminate due to hitting already-visited nodes in the exploded_graph,
or else hit per-program-point limits.  Unfortuately this often doesn't
work well.

GCC's optimization code has both GIMPLE and RTL loop analysis code. 
The RTL code runs too late for the analyzer, but the GIMPLE loop
analysis code is in cfgloop.{h,cc} and thus we would have access to
information about loops, at least for well-behaved cases - though
possibly only when optimization is enabled.

> 
> In fact, this could be done directly by the analyzer, and only
> calling 
> state machine APIs for loop handling which still has not reached
> such a fixed point in their program state for the analyzed loop, with
> a 
> maximum number of execution fixed by the analyzer to limit execution
> time.
> 
> Does what I'm saying make sense?

I think so, though I'm not sure how it would work in practice. 
Consider e.g. 

  for (int i = 0; i < n; i++)
 head = prepend_node (head, i);

which builds a chain of N dynamically-allocated nodes in a linked list.

> 
> In terms of implementation, loop detection can be done by looking for
> strongly connected components (SCCs)
> in a function graph having more than one node.
> I don't know if this is how it is already done within the analyzer or
> not?

It isn't yet done in the analyzer, but as noted above there is code in
GCC that already does that (in cfgloop.{h,cc}).

Dave

Re: Libgcc divide vectorization question

[Andrew Stubbs]

On 22/03/2023 13:56, Richard Biener wrote:

Basically, the -ffast-math instructions will always be the fastest way,
but the goal is that the default optimization shouldn't just disable
vectorization entirely for any loop that has a divide in it.


We try to express division as multiplication, but yes, I think there's
currently no way to tell the vectorizer that vectorized division is
available as libcall (nor for any other arithmetic operator that is not
a call in the first place).


I have considered creating a new builtin code, similar to the libm 
functions, that would be enabled by a backend hook, or maybe just if 
TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION doesn't return NULL. The 
vectorizer would then use that, somehow. To treat it just like any other 
builtin it would have to be set before the vectorizer pass encounters 
it, which is probably not ideal for all the other passes that want to 
handle divide operators. Alternatively, the vectorizable_operation 
function could detect and introduce the builtin where appropriate.


Would this be acceptable, or am I wasting my time planning something 
that would get rejected?


Thanks

Andrew

[RISC-V] [SIG-toolchain] Meeting will be canceled (March 23, 2023)

[jiawei]

Hi all,




Tomorrow's meeting will be canceled, since there were few new topics to discuss.





The next RISC-V GNU Toolchain meeting is collecting topics:

https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing

Please add what want to discuss in the next meeting.




Best Regards,

Jiawei

Re: Libgcc divide vectorization question

[Richard Biener via Gcc]

On Wed, Mar 22, 2023 at 12:02 PM Andrew Stubbs  wrote:
>
> On 22/03/2023 10:09, Richard Biener wrote:
> > On Tue, Mar 21, 2023 at 6:00 PM Andrew Stubbs  wrote:
> >>
> >> Hi all,
> >>
> >> I want to be able to vectorize divide operators (softfp and integer),
> >> but amdgcn only has hardware instructions suitable for -ffast-math.
> >>
> >> We have recently implemented vector versions of all the libm functions,
> >> but the libgcc functions aren't builtins and therefore don't use those
> >> hooks.
> >>
> >> What's the best way to achieve this? Add a new __builtin_div (and
> >> __builtin_mod) that tree-vectorize can find, perhaps? Or something else?
> >
> > What do you want to do?  Vectorize the out-of-line libgcc copy?  Or
> > emit inline vectorized code for int/softfp operations?  In the latter
> > case just emit the code from the pattern expanders?
>
> I'd like to investigate having vectorized versions of the libgcc
> instruction functions, like we do for libm.
>
> The inline code expansion is certainly an option, but I think there's
> quite a lot of code in those routines. I know how to do that option at
> least (except, maybe not the errno handling without making assumptions
> about the C runtime).
>
> Basically, the -ffast-math instructions will always be the fastest way,
> but the goal is that the default optimization shouldn't just disable
> vectorization entirely for any loop that has a divide in it.

We try to express division as multiplication, but yes, I think there's
currently no way to tell the vectorizer that vectorized division is
available as libcall (nor for any other arithmetic operator that is not
a call in the first place).

> Andrew

Re: Libgcc divide vectorization question

[Andrew Stubbs]

On 22/03/2023 10:09, Richard Biener wrote:

On Tue, Mar 21, 2023 at 6:00 PM Andrew Stubbs  wrote:


Hi all,

I want to be able to vectorize divide operators (softfp and integer),
but amdgcn only has hardware instructions suitable for -ffast-math.

We have recently implemented vector versions of all the libm functions,
but the libgcc functions aren't builtins and therefore don't use those
hooks.

What's the best way to achieve this? Add a new __builtin_div (and
__builtin_mod) that tree-vectorize can find, perhaps? Or something else?


What do you want to do?  Vectorize the out-of-line libgcc copy?  Or
emit inline vectorized code for int/softfp operations?  In the latter
case just emit the code from the pattern expanders?


I'd like to investigate having vectorized versions of the libgcc 
instruction functions, like we do for libm.


The inline code expansion is certainly an option, but I think there's 
quite a lot of code in those routines. I know how to do that option at 
least (except, maybe not the errno handling without making assumptions 
about the C runtime).


Basically, the -ffast-math instructions will always be the fastest way, 
but the goal is that the default optimization shouldn't just disable 
vectorization entirely for any loop that has a divide in it.


Andrew

Re: Libgcc divide vectorization question

[Richard Biener via Gcc]

On Tue, Mar 21, 2023 at 6:00 PM Andrew Stubbs  wrote:
>
> Hi all,
>
> I want to be able to vectorize divide operators (softfp and integer),
> but amdgcn only has hardware instructions suitable for -ffast-math.
>
> We have recently implemented vector versions of all the libm functions,
> but the libgcc functions aren't builtins and therefore don't use those
> hooks.
>
> What's the best way to achieve this? Add a new __builtin_div (and
> __builtin_mod) that tree-vectorize can find, perhaps? Or something else?

What do you want to do?  Vectorize the out-of-line libgcc copy?  Or
emit inline vectorized code for int/softfp operations?  In the latter
case just emit the code from the pattern expanders?

> Thanks
>
> Andrew