Re: why not optimize static local variables

[Richard Biener via Gcc]

On Sat, Oct 7, 2023 at 3:08 PM Hanke Zhang via Gcc  wrote:
>
> Hi, I've recently been working on static local variables in C. I would
> like to ask about some questions about that.
>
> For example, for the following program,
>
> void foo() {
>   static int x = 0;
>   x++;
> }
>
> int main() {
>   foo();
> }
>
> After optimization with the -O3 -flto option, the entire program will
> look something like this:
>
> int main() {
>   x_foo++;
> }
>
> The question I want to ask is, why not optimize the 'x_foo++' line of
> code out? Because its scope will only be in foo, and it will not be
> read at all for the entire program. Is it because it is stored in the
> global data area? Or are there other security issues?

I think there's bugreports tracking our weak ability to remove
TU local not escaping globals that are both written and read
(we can handle write-only and const fine).

Richard.

>
> Thanks
> Hanke Zhang

Complex numbers support: discussions summary

[Sylvain Noiry via Gcc]

On 9/26/23 20:40, Toon Moene wrote:

/On 9/26/23 09:30, Richard Biener via Gcc wrote: />>//>>>/On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc />>>/ wrote: />>///As I said at the end of the presentation, we have written a paper which //explains //our implementation in details. You can find it on the wiki page of the //Cauldron //(https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf 
). 
/>>>//>>>/Thanks for the detailed presentation at the Cauldron. />>>//>>>/My personal summary is that I'm less convinced delaying lowering is />>>/the way to go. />>//>>/Thanks Sylvain for the quick summary of the discussion - it helps a />>/great deal now that the discussion is still fresh in our memory. />

I found time today to run some tests.

First of all, the result of the gcc test harness as applied to the top 
of the complex/kvx branch in the https://github.com/kalray/gcc  repository:



> https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/797627.html  



I think there are several complex failures here that are not in 
"standard" 12.2 release (for x86_64-linux-gnu).


We have removed some special cases for complex operations outside the cplxlower 
pass (especially in tree-ssa-forwprop.cc), because of it ruined our efforts to 
maintain it not lowered. So the performance is fine on the KVX target, but some 
(SLP) vectorization cases are missed for other targets which do not exploit 
complex patterns.

It may be interesting to add a conditions on theses cases rather than just 
remove them.

I also compiled all of lapack-3.11.0 with that compiler and obtained the 
same results as with gcc/gfortran 13.2:


-->   LAPACK TESTING SUMMARY  <--
Processing LAPACK Testing output found in the TESTING directory
SUMMARY nb test run numerical error other error
=== =   
REAL1327023 0   (0.000%)0   
(0.000%)
DOUBLE PRECISION1300917 6   (0.000%)0   
(0.000%)
COMPLEX 786775  0   (0.000%)0   
(0.000%)
COMPLEX16   787842  0   (0.000%)0   
(0.000%)

--> ALL PRECISIONS   4202557 6   (0.000%)0   (0.000%)   
 


Thank you! It doesn't surprise me because GCC still processed complex 
operations like before when the backend does not exploit complex patterns.

Best regards,

Sylvain

Odd Python errors in the G++ testsuite

[Maciej W. Rozycki]

Hi,

 I'm seeing these tracebacks for several cases across the G++ testsuite:

Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"   
 (timeout = 300)
spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
rules/0/primary-output is ok: p1689-1.o
rules/0/provides/0/logical-name is ok: foo
rules/0/provides/0/is-interface is ok: True
Traceback (most recent call last):
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in 
is_ok = validate_p1689(actual, expect)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in 
validate_p1689
return compare_json([], actual_json, expect_json)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
compare_json
is_ok = _compare_object(path, actual, expect)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
_compare_object
sub_error = compare_json(path + [key], actual[key], expect[key])
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in 
compare_json
is_ok = _compare_array(path, actual, expect)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in 
_compare_array
sub_error = compare_json(path + [str(idx)], a, e)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
compare_json
is_ok = _compare_object(path, actual, expect)
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
_compare_object
sub_error = compare_json(path + [key], actual[key], expect[key])
  File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in 
compare_json
actual = set(actual)
TypeError: unhashable type: 'dict'

and also these intermittent failures for other cases:

Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)"   
 (timeout = 300)
spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
rules/0/primary-output is ok: p1689-2.o
rules/0/provides/0/logical-name is ok: foo:part1
rules/0/provides/0/is-interface is ok: True
ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
version is ok: 0
revision is ok: 0
FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"

This does seem to me like something not working as intended.  As a Python 
non-expert I have troubles concluding what is going on here and whether 
these tracebacks are indeed supposed to be there, or whether it is a sign 
of a problem.  And these failures I don't even know where they come from.  

 Does anyone know?  Is there a way to run the offending commands by hand?  
The relevant invocation lines do not appear in the test log file for one 
to copy and paste, which I think is not the right way of doing things in 
our environment.

 These issues seem independent from the test host environment as I can see 
them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine 
in `riscv64-linux-gnu' target testing.

  Maciej

Re: Odd Python errors in the G++ testsuite

[Ben Boeckel via Gcc]

On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
>  I'm seeing these tracebacks for several cases across the G++ testsuite:
> 
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" 
>(timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)

What version of Python3 do you have? The test suite might not actually
properly handle not having 3.7 (i.e., skip the tests that require it).

> rules/0/primary-output is ok: p1689-1.o

I wrote these tests.

> rules/0/provides/0/logical-name is ok: foo
> rules/0/provides/0/is-interface is ok: True
> Traceback (most recent call last):
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in 
> is_ok = validate_p1689(actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in 
> validate_p1689
> return compare_json([], actual_json, expect_json)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> compare_json
> is_ok = _compare_object(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in 
> compare_json
> is_ok = _compare_array(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in 
> _compare_array
> sub_error = compare_json(path + [str(idx)], a, e)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> compare_json
> is_ok = _compare_object(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in 
> compare_json
> actual = set(actual)
> TypeError: unhashable type: 'dict'

I'm not sure how this ends up with a dictionary in it… Can you
`print(actual)` before this?

> and also these intermittent failures for other cases:
> 
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" 
>(timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> rules/0/primary-output is ok: p1689-2.o
> rules/0/provides/0/logical-name is ok: foo:part1
> rules/0/provides/0/is-interface is ok: True
> ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> version is ok: 0
> revision is ok: 0
> FAIL: ERROR: length mismatch at rules/0/requires: actual: "1" expect: "0"
> 
> This does seem to me like something not working as intended.  As a Python 
> non-expert I have troubles concluding what is going on here and whether 
> these tracebacks are indeed supposed to be there, or whether it is a sign 
> of a problem.  And these failures I don't even know where they come from.  
> 
>  Does anyone know?  Is there a way to run the offending commands by hand?  
> The relevant invocation lines do not appear in the test log file for one 
> to copy and paste, which I think is not the right way of doing things in 
> our environment.
> 
>  These issues seem independent from the test host environment as I can see 
> them on both a `powerpc64le-linux-gnu' and an `x86_64-linux-gnu' machine 
> in `riscv64-linux-gnu' target testing.

Do they all have pre-3.7 Python3 versions?

--Ben

Re: Odd Python errors in the G++ testsuite

[Paul Koning via Gcc]

> On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc  wrote:
> 
> On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
>> I'm seeing these tracebacks for several cases across the G++ testsuite:
>> 
>> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 
>> 6)"(timeout = 300)
>> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> 
> What version of Python3 do you have? The test suite might not actually
> properly handle not having 3.7 (i.e., skip the tests that require it).

But the rule that you can't put a dict in a set is as old as set support (2.x 
for some small x).

paul

Re: Odd Python errors in the G++ testsuite

[Ben Boeckel via Gcc]

On Mon, Oct 09, 2023 at 19:46:37 -0400, Paul Koning wrote:
> 
> 
> > On Oct 9, 2023, at 7:42 PM, Ben Boeckel via Gcc  wrote:
> > 
> > On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> >> I'm seeing these tracebacks for several cases across the G++ testsuite:
> >> 
> >> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 
> >> 6)"(timeout = 300)
> >> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 
> >> 6)
> > 
> > What version of Python3 do you have? The test suite might not actually
> > properly handle not having 3.7 (i.e., skip the tests that require it).
> 
> But the rule that you can't put a dict in a set is as old as set support (2.x 
> for some small x).

Yes. I just wonder how a dictionary got in there in the first place. I'm
not sure if some *other* 3.7-related change makes that work.

--Ben

Re: Odd Python errors in the G++ testsuite

[Ben Boeckel via Gcc]

On Mon, Oct 09, 2023 at 20:12:01 +0100, Maciej W. Rozycki wrote:
> Hi,
> 
>  I'm seeing these tracebacks for several cases across the G++ testsuite:
> 
> Executing on host: python3 -c "import sys; assert sys.version_info >= (3, 6)" 
>(timeout = 300)
> spawn -ignore SIGHUP python3 -c import sys; assert sys.version_info >= (3, 6)
> rules/0/primary-output is ok: p1689-1.o
> rules/0/provides/0/logical-name is ok: foo
> rules/0/provides/0/is-interface is ok: True
> Traceback (most recent call last):
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 218, in 
> is_ok = validate_p1689(actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 182, in 
> validate_p1689
> return compare_json([], actual_json, expect_json)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> compare_json
> is_ok = _compare_object(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 151, in 
> compare_json
> is_ok = _compare_array(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 87, in 
> _compare_array
> sub_error = compare_json(path + [str(idx)], a, e)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 145, in 
> compare_json
> is_ok = _compare_object(path, actual, expect)
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 66, in 
> _compare_object
> sub_error = compare_json(path + [key], actual[key], expect[key])
>   File ".../gcc/testsuite/g++.dg/modules/test-p1689.py", line 149, in 
> compare_json
> actual = set(actual)
> TypeError: unhashable type: 'dict'

So looking at the source…the 3.6 check is not from me. Not sure what's
up there; it's probably not immediately related to the backtrace.

But this backtrace means that we have a list of objects that do not
expect a given ordering that is of JSON objects. I'm not sure why this
never showed up before as all of the existing uses of it are indeed of
objects. Can you try removing `"__P1689_unordered__"` from the
`p1689-1.exp.ddi` file's `requires` array? The
`p1689-file-default.exp.ddi` and `p1689-target-default.exp.ddi` files
need the same treatment.

--Ben