Re: Intel AVX10.1 Compiler Design and Support

[Richard Biener via Gcc-patches]

> Am 20.08.2023 um 00:45 schrieb ZiNgA BuRgA via Gcc-patches 
> :
> 
> Hi,
> 
> With the proposed design of these switches, how would I restrict AVX10.1 to 
> particular AVX-512 subsets?
> 
> For example, usage of the |_mm256_rol_epi32| intrinsic should be compatible 
> on any AVX10/256 implementation, /as well as /any AVX-512VL without AVX10 
> implementation (e.g. Skylake-X).  But how do I signal that I want 
> compatibility with both these targets?
> 
> * |-mavx512vl| lets the compiler use 512-bit registers -> incompatible
>   with 256-bit AVX10.
> * |-mavx512vl -mprefer-vector-width=256| might steer the compiler away
>   from 512-bit registers, but I don't think it guarantees it.

We’ve been taking these cases as bugs (but yes, intrinsics are still allowed, 
so in some cases it might prove difficult to guarantee this).

I don’t see any other way of doing what you want within the constraints of this 
design.

> * |-mavx10.1-256| lets the compiler use all Sapphire Rapids AVX-512
>   features at 256-bit wide (so in theory, it could choose to compile
>   it with |vpshldd|) -> incompatible with Skylake-X.
> * |-mavx10.1-256 -mno-avx512fp16 -mno-avx512...| will emit a warning
>   and ignore the attempts at disabling AVX-512 subsets.
> * |-mavx10.1-256 -mavx512vl| takes the /union/ of the features, not
>   the /intersection./
> 
> Is there something like |-mavx512vl -mmax-vector-width=256|, or am I 
> misunderstanding the situation?
> 
> Thanks!

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   Assignee|egallager at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #36 from Eric Gallager  ---
ok I've done as much as I feel like doing for the moment with
r14-3335-g9a5d1fceb86a61, so I'm unassigning for now; leaving open, though, as
Iain had some suggestions for improving things further...

Re: [PATCH] improve error for when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

On Thu, Aug 17, 2023 at 11:38 PM Eric Gallager  wrote:
>
> On Thu, Aug 17, 2023 at 4:05 PM Iain Sandoe  wrote:
> >
> > Hi Eric,
> >
> > thanks for working on this.
> >
> > > On 17 Aug 2023, at 20:35, Eric Gallager  wrote:
> > >
> > > This is a pretty simple patch that ought to help Darwin users understand
> > > better why their build is failing when they forget to pass the
> > > --with-sysroot= flag to configure.
> > >
> > > gcc/ChangeLog:
> > >
> > >PR target/90835
> > >* Makefile.in: improve error message when /usr/include is
> > >missing
> >
> > 1. the main issue with this approach is that the error does not happen 
> > until after the
> >user has waited for the whole of the stage 1 build.
> >
> >(I had in mind the idea that top level configure can identify that the 
> > platform
> > is Darwin, and that there is no sysroot configured;
> >  then [for bootstrap] complain if there is no /use/include
> >  els [for non-bootstrap] complain always)
> >
> > - this would mean that the fail occurs at initial configure time.
> >
> > 2. if we went with this patch as an incremental improvement:
> >
> > + case ${build_os} in \
> > +   darwin*) \
> > + echo "(on darwin this usually means you need to pass the 
> > --with-sysroot flag to configure to point it to where the system headers 
> > are actually put)" >&2; \
> >
> > I think we need to put this in terms that relate to the system and things 
> > the user can find, so ;
> > “on Darwin this usually means you need to pass the --with-sysroot= flag to 
> > point to a valid MacOS SDK”
> >
>
> OK, so would it be ok with that change in wording?
>
> > (In practice, the headers cause the first fail, but we also need to find 
> > the libraries when linking)
> >
> > Iain
> >

Committed with your proposed change in wording as
r14-3335-g9a5d1fceb86a61:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
(Jeff approved in reply to one of the other copies)

Re: [PATCH] improve error when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

Thanks, I committed the version with Iain's suggested change in wording:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627796.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
(sorry that this got sent multiple times; I thought the email hadn't
gone through properly...)

On Sat, Aug 19, 2023 at 4:11 PM Jeff Law  wrote:
>
>
>
> On 8/17/23 12:59, Eric Gallager via Gcc-patches wrote:
> > Subject:
> > [PATCH] improve error when /usr/include isn't found [PR90835]
> > From:
> > Eric Gallager via Gcc-patches 
> > Date:
> > 8/17/23, 12:59
> >
> > To:
> > gcc-patches@gcc.gnu.org
> > CC:
> > ia...@gcc.gnu.org, Eric Gallager 
> >
> >
> > This is a pretty simple patch that ought to help Darwin users understand
> > better why their build is failing when they forget to pass the
> > --with-sysroot= flag to configure.
> >
> > gcc/ChangeLog:
> >
> >  PR target/90835
> >  * Makefile.in: improve error message when /usr/include is
> >  missing
> OK.
> jeff

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from CVS Commits  ---
The master branch has been updated by Eric Gallager :

https://gcc.gnu.org/g:9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5

commit r14-3335-g9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
Author: Eric Gallager 
Date:   Wed May 25 12:45:33 2022 -0400

improve error when /usr/include isn't found [PR90835]

This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

PR target/90835
* Makefile.in: improve error message when /usr/include is
missing

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #13 from Jiang An  ---
This is not completely fixed.

See
- https://github.com/microsoft/STL/issues/3970#issuecomment-1681524306
- https://gcc.godbolt.org/z/3fsdbTx5Y

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Jonathan Yong :

https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3

commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
Author: Tomas Kalibera 
Date:   Sun Aug 20 02:16:16 2023 +

Fix format attribute for printf

Since a long time (GCC 4.4?) GCC does support annotating functions
with either the format attribute "gnu_printf" or "ms_printf" to
distinguish between different format string interpretations.

However, it seems like the attribute is ignored for the "printf"
symbol; regardless what the function declaration says, GCC treats
it as "ms_printf". This has become an issue now that mingw-w64
supports using the UCRT instead of msvcrt.dll, and in this case
the stdio functions are declared with the gnu_printf attribute,
and inttypes.h uses the same format specifiers as in GNU mode.

A reproducible example of the problem:

$ cat format.c
__attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
*__format, ...);
__attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
*__format, ...);

void function(void) {
long long unsigned x = 42;
othername("%llu\n", x);
printf("%llu\n", x);
}
$ x86_64-w64-mingw32-gcc -c -Wformat format.c
format.c: In function 'function':
format.c:7:15: warning: unknown conversion type character 'l' in format
[-Wformat=]
7 | printf("%llu\n", x);
  |   ^
format.c:7:12: warning: too many arguments for format [-Wformat-extra-args]
7 | printf("%llu\n", x);
  |^~~~

Note how both functions, printf and othername, are declare with
identical gnu_printf format attributes - GCC does take this into
account for "othername" and doesn't produce a warning, but GCC
seems to disregard the attribute in the printf declaration and
behave as if it was declared as ms_printf.

If the printf function declaration is changed into a static inline
function, the actual attribute used is honored though.

gcc/c-family/ChangeLog:

PR c/95130
* c-format.cc: skip default format for printf symbol if
explicitly declared by prototype.

Signed-off-by: Tomas Kalibera 
Signed-off-by: Jonathan Yong <10wa...@gmail.com>

Re: Intel AVX10.1 Compiler Design and Support

[ZiNgA BuRgA via Gcc-patches]

Hi,

With the proposed design of these switches, how would I restrict AVX10.1 
to particular AVX-512 subsets?


For example, usage of the |_mm256_rol_epi32| intrinsic should be 
compatible on any AVX10/256 implementation, /as well as /any AVX-512VL 
without AVX10 implementation (e.g. Skylake-X).  But how do I signal that 
I want compatibility with both these targets?


 * |-mavx512vl| lets the compiler use 512-bit registers -> incompatible
   with 256-bit AVX10.
 * |-mavx512vl -mprefer-vector-width=256| might steer the compiler away
   from 512-bit registers, but I don't think it guarantees it.
 * |-mavx10.1-256| lets the compiler use all Sapphire Rapids AVX-512
   features at 256-bit wide (so in theory, it could choose to compile
   it with |vpshldd|) -> incompatible with Skylake-X.
 * |-mavx10.1-256 -mno-avx512fp16 -mno-avx512...| will emit a warning
   and ignore the attempts at disabling AVX-512 subsets.
 * |-mavx10.1-256 -mavx512vl| takes the /union/ of the features, not
   the /intersection./

Is there something like |-mavx512vl -mmax-vector-width=256|, or am I 
misunderstanding the situation?


Thanks!

gcc-13-20230819 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20230819 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20230819/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision b823634589d5f3fa98e5d904e3b4680b23fc7ba9

You'll find:

 gcc-13-20230819.tar.xz   Complete GCC

  SHA256=0ddc4dcfab3120064a8c6712986a75891d1c77d4e3c19f3003292d87bb19692c
  SHA1=37deb4a9a4277b5325f33585d78772941bcafcff

Diffs from 13-20230812 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH] Testsuite: fix analyzer tests on Darwin

[Iain Sandoe via Gcc-patches]

Hi FX,

thanks for chasing these fails down,

> On 19 Aug 2023, at 22:28, FX Coudert  wrote:
> 

> gcc.dg/analyzer/ currently has 80 failures on Darwin (both 
> x86_64-apple-darwin and aarch64-apple-darwin). All those come from two issues:
> 
> 1. Many tests use memset() without including the  header. We can 
> fix that easily.
> 
> 2. Other tests fail because of the use of macOS headers, which redefine 
> functions like memcpy and others to “checked”/fortified versions 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Instead of correcting 
> this on a case-by-case basis, add the -D_FORTIFY_SOURCE=0 flag systematically 
> on Darwin.
> 
> With that, all 80 failures are silenced and that part of the testsuite is now 
> clean:
> 
> # of expected passes 5238
> # of expected failures 194
> # of unsupported tests 12

> OK to commit?

LGTM,

Iain

> FX
> 
> <0001-Testsuite-fix-analyzer-tests-on-Darwin.patch>

[Bug tree-optimization/106677] Abstraction overhead with std::views::join

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
On the trunk we now get:
  _25 = SR.116_117 == 0;
  _27 = (unsigned char) _25;
  _32 = _27 | SR.116_117;

Rather than:
  _119 = MAX_EXPR <1, SR.115_117>;

But we should instead just get:
SR.116_117 | 1

Though that should still be transformed into 1 (will fix that seperately).

I have a quick patch which fixes that, we need to move `a ? zero_one_value :
zero_one_value` part of match.pd below the min/max detection.

[Bug c++/111079] New: Failing to reject a defaulted/deleted local function definition if it is a friend of a local class

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 111079
   Summary: Failing to reject a defaulted/deleted local function
definition if it is a friend of a local class
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

## Code to Reproduce A (https://godbolt.org/z/ar34vn5dT)

void foo() {
struct A;
bool operator ==(const A&, const A&);
struct A { 
friend bool operator ==(const A&, const A&);
};
bool operator ==(const A&, const A&) = default;
}

## Code to Reproduce B (https://godbolt.org/z/sdo9fhacb)

void foo() {
struct A;
bool bar(const A&, const A&);
struct A { 
friend bool bar(const A&, const A&);
};
bool bar(const A&, const A&) = delete;
}

## Expected Output

Compiler error.

## Actual Output

: In function 'void foo()':
:7:40: warning: declaration of 'bool operator==(const foo()::A&, const
foo()::A&)' has 'extern' and is initialized
7 | bool operator ==(const A&, const A&) = default;
  | 

## Explanation

According to [dcl.fct.def.general] p2:
> A function shall be defined only in namespace or class scope.

There is a definition of `operator==` at block scope, which is obviously
invalid. Operator overloads are also considered functions
([over.oper.general]), so they should be subject to the same rules.

[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Francois-Xavier Coudert  ---
Patch posted for Darwin at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627923.html

[PATCH] Testsuite: fix analyzer tests on Darwin

[FX Coudert via Gcc-patches]

Hi,

gcc.dg/analyzer/ currently has 80 failures on Darwin (both x86_64-apple-darwin 
and aarch64-apple-darwin). All those come from two issues:

1. Many tests use memset() without including the  header. We can fix 
that easily.

2. Other tests fail because of the use of macOS headers, which redefine 
functions like memcpy and others to “checked”/fortified versions 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Instead of correcting this 
on a case-by-case basis, add the -D_FORTIFY_SOURCE=0 flag systematically on 
Darwin.

With that, all 80 failures are silenced and that part of the testsuite is now 
clean:

# of expected passes 5238
# of expected failures 194
# of unsupported tests 12



OK to commit?
FX



0001-Testsuite-fix-analyzer-tests-on-Darwin.patch
Description: Binary data

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #11 from waffl3x  ---
(In reply to Jonathan Wakely from comment #9)
> If we're right about that, then I agree that a warning would be useful for
> classes that have no such implicit conversion from S to S*.
> 
> I think the warning would give a false positive in the case below, so a way
> to disable it locally would be needed (e.g. via a diagnostic pragma).
> 
> struct S {
>   int f(this S*); // warning: explicit object parameter of pointer type can
> only match if an implicit conversion to S* exists
> };
> 
> struct T : S {
>   operator T*();
> };
> 
> T t;
> int i = t.f(); // derived class has the required conversion

I've ran some ideas in my head, no matter what is the decided upon design I
fully agree that all the warnings must be implemented with flags so they can be
suppressed, each independent of the other. I explain the warning I would
propose below, and I will make sure each one is properly documented, especially
since one of them has a clear risk of false positives, as you demonstrated.

(In reply to Gašper Ažman from comment #10)
> S* is not that useful as a
> type of an explicit object parameter, implicit conversions to pointer to
> yourself are probably about as weird as overloading operator&().

The only compelling case I can think of for such a thing would be passing a
pointer type that isn't related by inheritance anyway. That is to say, I'm not
disagreeing with you, I just stopped to think about it and came up with this,
consider the following example.

struct my_function {
using func_ptr = void(*)(int);
func_ptr _f;

void operator()(this func_ptr f, int a) {
return f(a);
}

operator func_ptr() const {
return _f;
}
};

I'm mostly just excited to share what I finally thought of as a good example
for an explicit object parameter that is not of a deduced or base type, but
it's never the less a pointer type.
Granted, I think this type of use should also have some sort of warning
available as it is still weird.

I think a warning for declaring an explicit object parameter as a pointer to
base, derived, or deduced type should be in, since a reference is probably the
best choice in that case. Perhaps deduced type shouldn't be included in that
warning, as there are cases that are kind of compelling for having that, one
could trap implicit conversions to any pointer type that way on derived
classes.

To elaborate on what I said above, I still think a warning when using a type
that is not related to the class should be provided. Even given that my example
above presents a legitimate pattern, I think it's use is infrequent enough to
provide an optional warning for this. I question if there's any value in
suppressing the warning when there are legitimate conversions present, as it
would no longer inform the user that they might have done something by mistake.
Essentially, since it's not possible to warn that there are no viable
conversions without false positives occurring, I think the warning should be
present simply because you are doing something weird, not because you are
declaring a function that won't be selected by overload resolution.

Just to reiterate, I fully agree that both warnings should be behind a flag. I
think I would propose that the first (warning for pointer to base, derived, or
deduced type in an explicit object parameter) should be turned on by default,
while the second should be turned off by default.

struct S : B {
int f0(this B*) {} // warning 1, on by default
int f1(this S*) {} // warning 1, on by default 
int f2(this auto*) {} // warning 1, on by default?, separate warning?

int f3(this int) {} // warning 2, off by default(?)
};

On the other hand, warning 2 could be split into 2 warnings, where one would
warn for a "weird" explicit object parameter, while the other would warn for
uncallable functions due to a lack of implicit conversions.
warning 2: weird explicit object parameter
warning 3: uncallable function (possibly has false positives)

struct S {
operator int() const {}

int f0(this int) {} // emits warning 2
int f1(this some_type) {} // emits warning 2 or 3
};

I imagine my proposed warnings 2 and 3 should be mutually exclusive, but I'm
not sure which should take precedence.

I suppose I've bikeshedded this a bit but I wanted to get my ideas up here
before I start working on things again today.


> Also, don't forget explicit object function bodies and their type behave a
> lot more like static functions than member functions.

Yes, that is one of the next thing's on my list to implement. At the moment
they are still member function pointer types.
My current plan is;
1. Pass reference to object when calling explicit object member functions.
2. Convert the function type of explicit object member functions to regular
function types.
3. Make sure calling explicit object member functions as member functions still
works.
4. finally, 

[Bug target/111078] csneg is not used for (cset) * 2 - 1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Another form:
```
int f1(int a, int b)
{
  int t = a != b;
  return (-t)|1;
}
```

[Bug target/111078] New: csneg is not used for (cset) * 2 - 1

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 111078
   Summary: csneg is not used for (cset) * 2 - 1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
int f(int a, int b)
{
return a == b ? 1 : -1;
}


int f0(int a, int b)
{
int t = a == b;
return t * 2 - 1;
}
```

These 2 should produce the same code on aarch64 but currently only the first
one produces:
```
cmp w0, w1
mov w0, 1
csneg   w0, w0, w0, eq
ret
```

[Bug testsuite/111066] g++.dg/special/initpri3.C fails on darwin

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Francois-Xavier Coudert  ---
Makes sense, patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627922.html

Testsuite: fix contructor priority test

[FX Coudert via Gcc-patches]

Bordering on obvious, tested on darwin where the test case fails before (and 
now passes).

OK to commit?
FX



0001-Testsuite-fix-contructor-priority-test.patch
Description: Binary data

[Bug libstdc++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
See 
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054899.html

Also

[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages

[mark at gcc dot gnu.org via Gcc-bugs]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #6 from Mark Wielaard  ---
(In reply to Richard Biener from comment #5)
> The resource issue is probably a non-issue these days

Yes, we have more hardware these these. Even a separate machine just to create
snapshots. Thanks to OSUOSL we now have https://snapshots.sourceware.org/ to
publish static artifacts from current git repos created in isolated containers.
It can be used as alternative to cron jobs on the main machine to generate
snapshots and documentation. The container files and build steps are defined
through the builder project.

We could do both. Have the current snapshots once a week. And have a full
"release snapshot" through snapshorts.sourceware.org whenever the sources
change (every hour) that regenerates all generated files (so we also know
whenever manual creation is broken).

[Bug testsuite/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Francois-Xavier Coudert  ---
I tried with:

diff --git a/gcc/testsuite/g++.dg/opt/icf1.C b/gcc/testsuite/g++.dg/opt/icf1.C
index fbb275e635a..d4e4bbf91b9 100644
--- a/gcc/testsuite/g++.dg/opt/icf1.C
+++ b/gcc/testsuite/g++.dg/opt/icf1.C
@@ -1,6 +1,7 @@
 // Test that -fipa-icf combines i and j.
 // { dg-do run { target c++11 } }
 // { dg-options -fipa-icf }
+// { dg-add-options bind_pic_locally }

 [[no_unique_address]] extern const int i[] = { 1,2,3 };
 [[no_unique_address]] extern const int j[] = { 1,2,3 };

and similarly on the other files, but it does not make the tests pass.

[Bug libstdc++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
reading through all of these discussions almost want to say the paper on
atomic_ref and padding bits of compare_and_exchange still missed the point of
this issue. Maybe this is undefined and maybe this is defect in the library
part of C++ standard even ...

Re: [PATCH] improve error when /usr/include isn't found [PR90835]

[Jeff Law via Gcc-patches]

On 8/17/23 12:59, Eric Gallager via Gcc-patches wrote:

Subject:
[PATCH] improve error when /usr/include isn't found [PR90835]
From:
Eric Gallager via Gcc-patches 
Date:
8/17/23, 12:59

To:
gcc-patches@gcc.gnu.org
CC:
ia...@gcc.gnu.org, Eric Gallager 


This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

 PR target/90835
 * Makefile.in: improve error message when /usr/include is
 missing

OK.
jeff

[Bug libstdc++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #3 from Andrew Pinski  ---
https://lists.llvm.org/pipermail/cfe-dev/2018-December/060605.html

[Bug c++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
https://lists.llvm.org/pipermail/cfe-dev/2018-December/060537.html

Re: [PATCH] sso-string@gnu-versioned-namespace [PR83077]

[François Dumont via Gcc-patches]

Here is a rebased patch following the resize_and_overwrite change.

I confirm that tests are now fixed after the change in tzdb.cc.

I'll prepare a fix for those tests still but preparing also a test to 
detect allocations in the lib.


François

On 17/08/2023 21:44, Jonathan Wakely wrote:

On Thu, 17 Aug 2023 at 20:37, Jonathan Wakely  wrote:

On Thu, 17 Aug 2023 at 19:59, Jonathan Wakely  wrote:

On Thu, 17 Aug 2023 at 18:40, François Dumont  wrote:


On 17/08/2023 19:22, Jonathan Wakely wrote:

On Sun, 13 Aug 2023 at 14:27, François Dumont via Libstdc++
 wrote:

Here is the fixed patch tested in all 3 modes:

- _GLIBCXX_USE_DUAL_ABI

- !_GLIBCXX_USE_DUAL_ABI && !_GLIBCXX_USE_CXX11_ABI

- !_GLIBCXX_USE_DUAL_ABI && _GLIBCXX_USE_CXX11_ABI

I don't know what you have in mind for the change below but I wanted to
let you know that I tried to put COW std::basic_string into a nested
__cow namespace when _GLIBCXX_USE_CXX11_ABI. But it had more impact on
string-inst.cc so I preferred the macro substitution approach.

I was thinking of implementing the necessary special members functions
of __cow_string directly, so they are ABI compatible with the COW
std::basic_string but don't actually reuse the code. That would mean
we don't need to compile and instantiate the whole COW string just to
use a few members from it. But that can be done later, the macro
approach seems OK for now.

You'll see that when cow_string.h is included while
_GLIBCXX_USE_CXX11_ABI == 1 then I am hiding a big part of the
basic_string definition. Initially it was to avoid to have to include
basic_string.tcc but it is also a lot of useless code indeed.



There are some test failing when !_GLIBCXX_USE_CXX11_ABI that are
unrelated with my changes. I'll propose fixes in coming days.

Which tests? I run the entire testsuite with
-D_GLIBCXX_USE_CXX11_ABI=0 several times per day and I'm not seeing
failures.

I'll review the patch ASAP, thanks for working on it.


So far the only issue I found are in the mode !_GLIBCXX_USE_DUAL_ABI &&
!_GLIBCXX_USE_CXX11_ABI. They are:

23_containers/unordered_map/96088.cc
23_containers/unordered_multimap/96088.cc
23_containers/unordered_multiset/96088.cc
23_containers/unordered_set/96088.cc
ext/debug_allocator/check_new.cc
ext/malloc_allocator/check_new.cc
ext/malloc_allocator/deallocate_local.cc
ext/new_allocator/deallocate_local.cc
ext/pool_allocator/allocate_chunk.cc
ext/throw_allocator/deallocate_local.cc

Ah yes, they fail for !USE_DUAL_ABI builds, I wonder why.

/home/test/src/gcc/libstdc++-v3/testsuite/23_containers/unordered_map/96088.
cc:44: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
FAIL: 23_containers/unordered_map/96088.cc execution test

It's due to this global object in src/c++20/tzdb.cc:
1081const string tzdata_file = "/tzdata.zi";

When the library uses COW strings that requires an allocation before
main, which uses the replacement operator new in the tests, which
fails to allocate. For example, in 22_locale/locale/cons/12352.cc we
have this function used by operator new:

int times_to_fail = 0;

void* allocate(std::size_t n)
{
   if (!times_to_fail--)
 return 0;

The counter is initially zero, so if we try to allocate before it gets
set to a non-zero value in test01() then we fail.

The test should not assume no allocations before main() begins. The
simplest way to do that is with another global that says "we have
started testing" e.g.

--- a/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc
@@ -26,11 +26,12 @@
  #include 
  #include 

+bool tests_started = false;
  int times_to_fail = 0;

  void* allocate(std::size_t n)
  {
-  if (!times_to_fail--)
+  if (tests_started && !times_to_fail--)
  return 0;

void* ret = std::malloc(n ? n : 1);
@@ -106,6 +107,8 @@ void operator delete[](void* p, const
std::nothrow_t&) throw()
  // libstdc++/12352
  void test01(int iters)
  {
+  tests_started = true;
+
for (int j = 0; j < iters; ++j)
  {
for (int i = 0; i < 100; ++i)


This way the replacement operator new doesn't start intentionally
failing until we ask it to do so.

I'll replace the global std::string objects with std::string_view
objects, so that they don't allocate even if the library only uses COW
strings.

We should still fix those tests though.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index b25378eaace..322f1e42611 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4875,12 +4875,16 @@ dnl
 AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_DUAL_ABI], [
   GLIBCXX_ENABLE(libstdcxx-dual-abi,$1,,[support two versions of std::string])
   if test x$enable_symvers = xgnu-versioned-namespace; then
-# gnu-versioned-namespace is incompatible with the dual ABI.
-enable_libstdcxx_dual_abi="no"
-  fi
-  if test x"$enable_libstdcxx_dual_abi" != xyes; then
+# gnu-versioned-namespace is incompatible with the dual ABI...
 

[Bug c++/111077] atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  ---
The calls for clearing the padding are there before eiline:
```
  std::__atomic_impl::__clear_padding (__exp_28);
  _4 = (int) __is_weak_30(D);
  _5 = std::__atomic_impl::__clear_padding (__i_31(D));
  _6 = VIEW_CONVERT_EXPR(*_5);
  _7 = std::__addressof (__val_33(D));
  retval.11_37 = __atomic_compare_exchange_4 (_7, __exp_28, _6, _4, __s_35(D),
__f_16(D));
```

Oh we are not clearing the padding of the reference ...


Is this even well defined?

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Tomas Kalibera  ---
(In reply to Julian Waters from comment #19)
> (In reply to Tomas Kalibera from comment #17)
> > (In reply to Tomas Kalibera from comment #16)
> > > (In reply to Julian Waters from comment #15)
> > > > It seems like the patch also doesn't fix the strftime case too, 
> > > > strangely
> > > > enough. gcc with that patch applied still causes a compilation failure 
> > > > in
> > > > the Windows JDK when encountering strftime with the %T specifier
> > > 
> > >
> > > I don't easily see why the patch doesn't help with %T in strftime. In
> > > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> > > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> > > attribute is present.
> > 
> > The older version of the patch I use with gcc 12 doesn't seem to be helping
> > with %T, but the newer one (patch_master.diff) helps with %T on the current
> > gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with
> > MinGW-W64 11.0.1.
> 
> If I may ask, could I have the link to patch_master.diff?

It is one of the attachments of this report,
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53778

This patch has not been reviewed. I am not an expert on GCC internals and I
cannot guarantee that adding meta-data this way to the AST is safe. So please
use with care.

[Bug libstdc++/111077] New: atomic_ref compare_exchange_strong doesn't properly ignore padding bits

[comexk at gmail dot com via Gcc-bugs]

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

Bug ID: 111077
   Summary: atomic_ref compare_exchange_strong doesn't properly
ignore padding bits
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: comexk at gmail dot com
  Target Milestone: ---

C++20 requires that the functions `std::atomic::compare_exchange_strong` and
`std::atomic_ref::compare_exchange_strong` ignore any padding bits that
exist in T.  libstdc++ implements this by relying on the invariant that
`std::atomic` values in memory always have zeroed padding bits.  All methods
of `std::atomic`  that store values to memory (including the constructor)
zero the padding bits first.  Then, `std::atomic::compare_exchange_strong`
zeroes the padding bits of the `expected` value, allowing it to assume that the
native atomic compare-exchange won't fail due to padding bits.

However, this doesn't work correctly for `std::atomic_ref`.  All methods of
`std::atomic_ref` that store to memory do zero the padding bits.  But what
about the initial value of the object, before the first atomic_ref pointing to
it was created?  That value could be anything.

As a result, this code (compiled with -std=c++20) incorrectly prints 0, even
though the only difference between `value` and `expected` is in a padding byte:

#include 
#include 
int main() {
struct HasPadding { char a; short b; };
HasPadding value = {};
((char *))[1] = 0x42; // update padding byte
HasPadding expected = {};
printf("%d\n",
std::atomic_ref(value).compare_exchange_strong(
expected, expected));
}

This could be fixed by reimplementing
`std::atomic_ref::compare_exchange_strong` to use a loop, as in this
pseudocode:

bool compare_exchange_strong(std::atomic_ref ref, T& expected, T
desired) {
T orig = expected;
while (1) {
if (ref.compare_exchange_weak_including_padding(expected, desired))
{
return true;
}
if (!equal_ignoring_padding(orig, expected)) {
return false;
}
}
}

[See also:
https://github.com/rust-lang/unsafe-code-guidelines/issues/449#issuecomment-1677985851,
which has a comparison of different compilers.]

[Bug rtl-optimization/111076] New: RISC-V: segmentation fault during RTL pass: shorten (debug build)

[maksim.shabunin at gmail dot com via Gcc-bugs]

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

Bug ID: 111076
   Summary: RISC-V: segmentation fault during RTL pass: shorten
(debug build)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maksim.shabunin at gmail dot com
  Target Milestone: ---

Created attachment 55765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55765=edit
Preprocessed source file

We are experiencing an issue when building the OpenCV library for RISC-V with
RVV support in DEBUG configuration using GCC 13.2.1:

/work/chains/riscv-gcc-13.2.1/bin/riscv64-unknown-linux-gnu-g++
--sysroot=/work/chains/riscv-gcc-13.2.1/sysroot
-DOPENCV_ALLOCATOR_STATS_COUNTER_TYPE=int -D_USE_MATH_DEFINES
-D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -I/work/opencv/modules/core/include
-I/work/build-opencv-rvv/modules/core -I/work/opencv/3rdparty/zlib
-I/work/build-opencv-rvv/3rdparty/zlib -isystem /work/build-opencv-rvv
-march=rv64gc  -fmax-errors=1 -Wfatal-errors -fsigned-char -W -Wall
-Wreturn-type -Wnon-virtual-dtor -Waddress -Wsequence-point -Wformat
-Wformat-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith
-Wshadow -Wsign-promo -Wuninitialized -Wsuggest-override
-Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3
-Wno-strict-overflow -fdiagnostics-show-option -pthread -fomit-frame-pointer
-ffunction-sections -fdata-sections  -march=rv64gcv1p0 -DCV_RVV_SCALABLE
-fvisibility=hidden -fvisibility-inlines-hidden -g  -O0 -DDEBUG -D_DEBUG -fPIC
-std=c++11 -MD -MT
modules/core/CMakeFiles/opencv_core.dir/src/count_non_zero.dispatch.cpp.o -MF
modules/core/CMakeFiles/opencv_core.dir/src/count_non_zero.dispatch.cpp.o.d -o
modules/core/CMakeFiles/opencv_core.dir/src/count_non_zero.dispatch.cpp.o -c
/work/opencv/modules/core/src/count_non_zero.dispatch.cpp -freport-bug

<... several -Wsign-compare warnings ...>

during RTL pass: shorten
In file included from
/work/opencv/modules/core/include/opencv2/core/hal/intrin_rvv_scalable.hpp:146:
   
/work/opencv/modules/core/include/opencv2/core/hal/intrin_rvv_compat_overloaded.hpp:
In function 'cv::hal_baseline::VTraits<__rvv_uint64m1_t>::lane_type
cv::hal_baseline::__riscv_vmv_x(const v_uint64&)':
   
/work/opencv/modules/core/include/opencv2/core/hal/intrin_rvv_compat_overloaded.hpp:154:1:
internal compiler error: Segmentation fault
  154 | }
  | ^
   
/work/opencv/modules/core/include/opencv2/core/hal/intrin_rvv_compat_overloaded.hpp:167:1:
note: in expansion of macro 'OPENCV_HAL_IMPL_RVV_FUN_EXTRACT'
  167 | OPENCV_HAL_IMPL_RVV_FUN_EXTRACT(v_uint64, u64)
  | ^~~
0xe038c3 crash_signal
../.././gcc/gcc/toplev.cc:314
0x7f445264251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x16038c4 const_csr_operand(rtx_def*, machine_mode)
../.././gcc/gcc/config/riscv/predicates.md:44
0x16038c4 csr_operand(rtx_def*, machine_mode)
../.././gcc/gcc/config/riscv/predicates.md:46
0x166e88d recog_157
../.././gcc/gcc/config/riscv/iterators.md:72
0x167c247 recog(rtx_def*, rtx_insn*, int*)
../.././gcc/gcc/config/riscv/iterators.md:58
0x147f00d recog_memoized(rtx_insn*)
../.././gcc/gcc/recog.h:273
0x147f00d insn_default_length(rtx_insn*)
../.././gcc/gcc/config/riscv/riscv.md:451
0xac4ea5 shorten_branches(rtx_insn*)
../.././gcc/gcc/final.cc:1088
0xac4ef3 rest_of_handle_shorten_branches
../.././gcc/gcc/final.cc:4336
0xac4ef3 execute
../.././gcc/gcc/final.cc:4365
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

* Version: riscv64-unknown-linux-gnu-g++ (g91a5bdf2941) 13.2.1 20230818
* Preprocessed source file attached.
* The same library version (latest commit on 4.x branch) can be built in
Release mode without issues.

[Bug target/111065] [RISCV] t-linux-multilib specifies incorrect multilib reuse patterns

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from Tommy Murphy  ---
Hi Kito/Palmer - should I maybe close this issue here and take it up in the
riscv-gnu-toolchain/riscv-gcc repos instead? 

* https://github.com/riscv-collab/riscv-gnu-toolchain
* https://github.com/riscv-collab/riscv-gcc

It sounds like the issue of RISC-V multilib specification and management needs
some work and has (at least in the case of the Linux toolchain) diverged from
what was previously intended and what is currently documented with regard to
the multilib-generator script etc.

*
https://github.com/riscv-collab/riscv-gnu-toolchain#installation-newliblinux-multilib

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[gasper.azman at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Gašper Ažman  ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that useful as a
type of an explicit object parameter, implicit conversions to pointer to
yourself are probably about as weird as overloading operator&().

Also, don't forget explicit object function bodies and their type behave a
lot more like static functions than member functions.

On Sat, Aug 19, 2023, 10:43 redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
>
> --- Comment #9 from Jonathan Wakely  ---
> If we're right about that, then I agree that a warning would be useful for
> classes that have no such implicit conversion from S to S*.
>
> I think the warning would give a false positive in the case below, so a
> way to
> disable it locally would be needed (e.g. via a diagnostic pragma).
>
> struct S {
>   int f(this S*); // warning: explicit object parameter of pointer type can
> only match if an implicit conversion to S* exists
> };
>
> struct T : S {
>   operator T*();
> };
>
> T t;
> int i = t.f(); // derived class has the required conversion
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Re: [PATCH][RFC] tree-optimization/92335 - Improve sinking heuristics for vectorization

[Prathamesh Kulkarni via Gcc-patches]

On Fri, 18 Aug 2023 at 17:11, Richard Biener  wrote:
>
> On Fri, 18 Aug 2023, Richard Biener wrote:
>
> > On Thu, 17 Aug 2023, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 15 Aug 2023 at 14:28, Richard Sandiford
> > >  wrote:
> > > >
> > > > Richard Biener  writes:
> > > > > On Mon, 14 Aug 2023, Prathamesh Kulkarni wrote:
> > > > >> On Mon, 7 Aug 2023 at 13:19, Richard Biener 
> > > > >>  wrote:
> > > > >> > It doesn't seem to make a difference for x86.  That said, the 
> > > > >> > "fix" is
> > > > >> > probably sticking the correct target on the dump-check, it seems
> > > > >> > that vect_fold_extract_last is no longer correct here.
> > > > >> Um sorry, I did go thru various checks in target-supports.exp, but 
> > > > >> not
> > > > >> sure which one will be appropriate for this case,
> > > > >> and am stuck here :/ Could you please suggest how to proceed ?
> > > > >
> > > > > Maybe Richard S. knows the magic thing to test, he originally
> > > > > implemented the direct conversion support.  I suggest to implement
> > > > > such dg-checks if they are not present (I can't find them),
> > > > > possibly quite specific to the modes involved (like we have
> > > > > other checks with _qi_to_hi suffixes, for float modes maybe
> > > > > just _float).
> > > >
> > > > Yeah, can't remember specific selectors for that feature.  TBH I think
> > > > most (all?) of the tests were AArch64-specific.
> > > Hi,
> > > As Richi mentioned above, the test now vectorizes on AArch64 because
> > > it has support for direct conversion
> > > between vectors while x86 doesn't. IIUC this is because
> > > supportable_convert_operation returns true
> > > for V4HI -> V4SI on Aarch64 since it can use extend_v4hiv4si2 for
> > > doing the conversion ?
> > >
> > > In the attached patch, I added a new target check vect_extend which
> > > (currently) returns 1 only for aarch64*-*-*,
> > > which makes the test PASS on both the targets, altho I am not sure if
> > > this is entirely correct.
> > > Does the patch look OK ?
> >
> > Can you make vect_extend more specific, say vect_extend_hi_si or
> > what is specifically needed here?  Note I'll have to investigate
> > why x86 cannot vectorize here since in fact it does have
> > the extend operation ... it might be also worth splitting the
> > sign/zero extend case, so - vect_sign_extend_hi_si or
> > vect_extend_short_int?
>
> And now having anaylzed _why_ x86 doesn't vectorize it's rather
> why we get this vectorized with NEON which is because
>
> static opt_machine_mode
> aarch64_vectorize_related_mode (machine_mode vector_mode,
> scalar_mode element_mode,
> poly_uint64 nunits)
> {
> ...
>   /* Prefer to use 1 128-bit vector instead of 2 64-bit vectors.  */
>   if (TARGET_SIMD
>   && (vec_flags & VEC_ADVSIMD)
>   && known_eq (nunits, 0U)
>   && known_eq (GET_MODE_BITSIZE (vector_mode), 64U)
>   && maybe_ge (GET_MODE_BITSIZE (element_mode)
>* GET_MODE_NUNITS (vector_mode), 128U))
> {
>   machine_mode res = aarch64_simd_container_mode (element_mode, 128);
>   if (VECTOR_MODE_P (res))
> return res;
>
> which makes us get a V4SImode vector for a V4HImode loop vector_mode.
Thanks for the explanation!
>
> So I think the appropriate effective dejagnu target is
> aarch64-*-* (there's none specifically to advsimd, not sure if one
> can disable that?)
The attached patch uses aarch64*-*-* target check, and additionally
for SVE (and other targets supporting vect_fold_extract_last) it
checks
if the condition reduction was carried out using FOLD_EXTRACT_LAST.
Does that look OK ?

Thanks,
Prathamesh
>

> Richard.
>
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Thanks,
> > > > Richard
> > >
> >
> >
>
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH,
> Frankenstrasse 146, 90461 Nuernberg, Germany;
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
diff --git a/gcc/testsuite/gcc.dg/vect/pr65947-7.c 
b/gcc/testsuite/gcc.dg/vect/pr65947-7.c
index 16cdcd1c6eb..58c46df5c54 100644
--- a/gcc/testsuite/gcc.dg/vect/pr65947-7.c
+++ b/gcc/testsuite/gcc.dg/vect/pr65947-7.c
@@ -52,5 +52,5 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target 
vect_fold_extract_last } } } */
-/* { dg-final { scan-tree-dump-not "LOOP VECTORIZED" "vect" { target { ! 
vect_fold_extract_last } } } } */
+/* { dg-final { scan-tree-dump "optimizing condition reduction with 
FOLD_EXTRACT_LAST" "vect" { target vect_fold_extract_last } } } */
+/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target aarch64*-*-* 
} } } */

Re: [PATCH] Loongarch: Fix plugin header missing install.

[Huacai Chen via Gcc-patches]

Thank you very much, I think this should also be backported to Gcc12/13.

Huacai

On Sat, Aug 19, 2023 at 11:59 AM Chenghua Xu  wrote:
>
> Pushed as r14-3331.
>
> Thanks.
> chenglulu writes:
>
> > LGTM!
> >
> > 在 2023/8/16 上午9:48, Guo Jie 写道:
> >> gcc/ChangeLog:
> >>
> >>  * config/loongarch/t-loongarch: Add loongarch-driver.h into
> >>  TM_H. Add loongarch-def.h and loongarch-tune.h into
> >>  OPTIONS_H_EXTRA.
> >>
> >> Co-authored-by: Lulu Cheng 
> >> ---
> >>   gcc/config/loongarch/t-loongarch | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/gcc/config/loongarch/t-loongarch 
> >> b/gcc/config/loongarch/t-loongarch
> >> index 6d6e3435d59..e73f4f437ef 100644
> >> --- a/gcc/config/loongarch/t-loongarch
> >> +++ b/gcc/config/loongarch/t-loongarch
> >> @@ -16,6 +16,10 @@
> >>   # along with GCC; see the file COPYING3.  If not see
> >>   # .
> >>   +TM_H += $(srcdir)/config/loongarch/loongarch-driver.h
> >> +OPTIONS_H_EXTRA += $(srcdir)/config/loongarch/loongarch-def.h \
> >> +   $(srcdir)/config/loongarch/loongarch-tune.h
> >> +
> >>   # Canonical target triplet from config.gcc
> >>   LA_MULTIARCH_TRIPLET = $(patsubst LA_MULTIARCH_TRIPLET=%,%,$\
> >>   $(filter LA_MULTIARCH_TRIPLET=%,$(tm_defines)))
>

[Bug c++/111075] ICE on g++.dg/torture/tail-padding1.C on darwin

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-19
  Build||x86_64-apple-darwin20
   Keywords||ice-on-valid-code
  Known to fail||14.0
   Host||x86_64-apple-darwin20

[Bug c++/111075] New: ICE on g++.dg/torture/tail-padding1.C on darwin

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 111075
   Summary: ICE on g++.dg/torture/tail-padding1.C on darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

ICE on valid C++ code, reduced from the test failure of
g++.dg/torture/tail-padding1.C observed on x86_64-apple-darwin20 (see for
example at
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html):

$ cat z.C
struct X { ~X() {} int n; char d; };
struct Y { Y(); char c[3]; };
struct Z : X, virtual Y { Z(); };

X f() { X nrvo; __builtin_memset(, 0, sizeof(X)); return nrvo; }
Z::Z() : Y(), X(f()) {}

$ /tmp/irun/bin/g++ -Os z.C   
z.C: In copy constructor ‘constexpr X::X(const X&)’:
z.C:1:8: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:2918
1 | struct X { ~X() {} int n; char d; };
  |^

[Bug tree-optimization/110932] [14 Regression] Dead Code Elimination Regression since r14-2230-g7e904d6c7f2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> So the general rule is:
> (simplify
>  (eq:c @0 (convert (cmp @1 @2)))
>  (if (bitwise_equal_p (@0, @1))
>  (with {
> bool zeroalwaystrue = ...
> bool zeroalwaysfalse = ...
> bool onealwaystrue = ...
> bool onealwaysfalse = ...
>   }
>   (switch
>(if (zeroalwaystrue && onealwaystrue)
> (le @0:unsigned { one(unsigned); } )) // @0 == 0 | @0 == 1
>(if (zeroalwaysfalse && onealwaysfalse )
> { false_bool; }) // false
>(if (zeroalwaystrue && onealwaysfalse)
> (eq @0 { zero(TREE_TYPE(@0)); })) // @0 == 0
>(if (onealwaystrue && onealwaysfalse)
> (eq @0 { one(TREE_TYPE(@0)); })) // @0 == 1

If we want to do this only in VRP, we could just use match to match the
sequence and then handle the comparison there ...

[Bug tree-optimization/110932] [14 Regression] Dead Code Elimination Regression since r14-2230-g7e904d6c7f2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-19

--- Comment #1 from Andrew Pinski  ---
  _41 = _43 <= 0;
  # RANGE [irange] unsigned short [0, 1] NONZERO 0x1
  _40 = (unsigned short) _41;
  # RANGE [irange] unsigned short [65534, +INF]
  _36 = ~_40;
  # RANGE [irange] short int [-2, -1]
  _19 = (short intD.17) _36;
  # RANGE [irange] unsigned int [4294967294, +INF]
  _17 = (unsigned intD.9) _19; // ~(unsigned)_41
   // rather _41 ? 4294967294 : 4294967295
  i.1_14 = (unsigned intD.9) pretmp_60;
  _13 = i.1_14 < _17;
  # RANGE [irange] int [0, 1] NONZERO 0x1
  _12 = (intD.6) _13;
  if (_12 == pretmp_60)


pretmp_60 == (((unsigned intD.9) pretmp_60) < _17)

Which is:
(pretmp_60  == 1 && ((unsigned intD.9) pretmp_60) < _17))
| (pretmp_60  == 0 && ((unsigned intD.9) pretmp_60) >= _17))
Though ((unsigned intD.9) pretmp_60) >= _17) is always false because _17's
range does not include 0.

So we are left with:
(pretmp_60  == 1 && 1 < _17)
But _17's range is always bigger than 0 so we are just left with:
pretmp_60 == 1


So the general rule is:
(simplify
 (eq:c @0 (convert (cmp @1 @2)))
 (if (bitwise_equal_p (@0, @1))
 (with {
bool zeroalwaystrue = ...
bool zeroalwaysfalse = ...
bool onealwaystrue = ...
bool onealwaysfalse = ...
  }
  (switch
   (if (zeroalwaystrue && onealwaystrue)
(le @0:unsigned { one(unsigned); } )) // @0 == 0 | @0 == 1
   (if (zeroalwaysfalse && onealwaysfalse )
{ false_bool; }) // false
   (if (zeroalwaystrue && onealwaysfalse)
(eq @0 { zero(TREE_TYPE(@0)); })) // @0 == 0
   (if (onealwaystrue && onealwaysfalse)
(eq @0 { one(TREE_TYPE(@0)); })) // @0 == 1

Later on instead of `if (_12 == _50)` we would have `if (_50 == 1)`
```
  if (_50 == 1)
goto ; [51.12%]
  else
goto ; [48.88%]
...
   [local count: 278223726]:
  if (_50 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]
```
Which is an obvious case where we know _50 is 1 in bb 4 and therefore !=0.
etc.

[Bug rtl-optimization/111074] New: RISC-V: segmentation fault during RTL pass: vsetvl

[maksim.shabunin at gmail dot com via Gcc-bugs]

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

Bug ID: 111074
   Summary: RISC-V: segmentation fault during RTL pass: vsetvl
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maksim.shabunin at gmail dot com
  Target Milestone: ---

Created attachment 55764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55764=edit
Preprocessed source file

We are experiencing issues when building the OpenCV library for RISC-V with RVV
support:

/work/chains/riscv-gcc-13.2.1/bin/riscv64-unknown-linux-gnu-g++
--sysroot=/work/chains/riscv-gcc-13.2.1/sysroot -D_USE_MATH_DEFINES
-D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -I/work/opencv/modules/imgproc/include
-I/work/build-opencv-rvv/modules/imgproc -I/work/opencv/modules/core/include
-isystem /work/build-opencv-rvv -march=rv64gc  -fmax-errors=1 -Wfatal-errors
-fsigned-char -W -Wall -Wreturn-type -Wnon-virtual-dtor -Waddress
-Wsequence-point -Wformat -Wformat-security -Wmissing-declarations -Wundef
-Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized
-Wsuggest-override -Wno-delete-non-virtual-dtor -Wno-comment
-Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option
-pthread -fomit-frame-pointer -ffunction-sections -fdata-sections 
-march=rv64gcv1p0 -DCV_RVV_SCALABLE -fvisibility=hidden
-fvisibility-inlines-hidden -O3 -DNDEBUG  -DNDEBUG -fPIC -std=c++11 -MD -MT
modules/imgproc/CMakeFiles/opencv_imgproc.dir/src/box_filter.dispatch.cpp.o -MF
modules/imgproc/CMakeFiles/opencv_imgproc.dir/src/box_filter.dispatch.cpp.o.d
-o modules/imgproc/CMakeFiles/opencv_imgproc.dir/src/box_filter.dispatch.cpp.o
-c /work/opencv/modules/imgproc/src/box_filter.dispatch.cpp -freport-bug
during RTL pass: vsetvl
In file included from
/work/opencv/modules/imgproc/src/box_filter.dispatch.cpp:53:
/work/opencv/modules/imgproc/src/box_filter.simd.hpp: In member function
'virtual void cv::cpu_baseline::{anonymous}::ColumnSum::operator()(const cv::hal_baseline::uchar**, cv::hal_baseline::uchar*,
int, int, int)':
/work/opencv/modules/imgproc/src/box_filter.simd.hpp:1162:5: internal
compiler error: Segmentation fault
 1162 | }
  | ^
0xe038c3 crash_signal
../.././gcc/gcc/toplev.cc:314
0x7fb2b9e4251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x6bdea2 hash_set >::iterator::operator*()
../.././gcc/gcc/hash-set.h:125
0x6bdea2 extract_single_source
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:1186
0x6bdea2 extract_single_source
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:1176
0x119ae7e pass_vsetvl::propagate_avl() const
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:4089
0x119cf8f pass_vsetvl::execute(function*)
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:4346
0x119cf8f pass_vsetvl::execute(function*)
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:4327
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.


* Compiler version is:
riscv64-unknown-linux-gnu-g++ (g91a5bdf2941) 13.2.1 20230818
* Issue does not reproduce with -fwrapv option.
* Preprocessed file is in the attachment (compressed), problematic loop starts
at line 86506.

We did not manage to make minimal reproducer, but we've been able to avoid it
by disabling one RVV-optimized block in our code (CV_SIMD_SCALABLE is enabled
for RVV), it does not look very different from other optimized blocks in this
or other files:
https://github.com/opencv/opencv/pull/24166/commits/8ab6c22e9a04f84cf1bf65e17c72f05e0b2b0825

[PING][PATCH] arm: Remove unsigned variant of vcaddq_m

[Stam Markianos-Wright via Gcc-patches]

(Pinging since I realised that this is required for my later Low Overhead Loop 
patch series to work)

Ok for trunk with the updated changelog that Christophe mentioned?

Thanks,
Stamatis/Stam Markianos-Wright


From: Stam Markianos-Wright
Sent: Tuesday, August 1, 2023 6:21 PM
To: gcc-patches@gcc.gnu.org 
Cc: Richard Earnshaw ; Kyrylo Tkachov 

Subject: arm: Remove unsigned variant of vcaddq_m

Hi all,

The unsigned variants of the vcaddq_m operation are not needed within the
compiler, as the assembly output of the signed and unsigned versions of the
ops is identical: with a `.i` suffix (as opposed to separate `.s` and `.u`
suffixes).

Tested with baremetal arm-none-eabi on Arm's fastmodels.

Ok for trunk?

Thanks,
Stamatis Markianos-Wright

gcc/ChangeLog:

 * config/arm/arm-mve-builtins-base.cc (vcaddq_rot90, vcaddq_rot270):
   Use common insn for signed and unsigned front-end definitions.
 * config/arm/arm_mve_builtins.def
   (vcaddq_rot90_m_u, vcaddq_rot270_m_u): Make common.
   (vcaddq_rot90_m_s, vcaddq_rot270_m_s): Remove.
 * config/arm/iterators.md (mve_insn): Merge signed and unsigned defs.
   (isu): Likewise.
   (rot): Likewise.
   (mve_rot): Likewise.
   (supf): Likewise.
   (VxCADDQ_M): Likewise.
 * config/arm/unspecs.md (unspec): Likewise.
---
  gcc/config/arm/arm-mve-builtins-base.cc |  4 ++--
  gcc/config/arm/arm_mve_builtins.def |  6 ++---
  gcc/config/arm/iterators.md | 30 +++--
  gcc/config/arm/mve.md   |  4 ++--
  gcc/config/arm/unspecs.md   |  6 ++---
  5 files changed, 21 insertions(+), 29 deletions(-)

diff --git a/gcc/config/arm/arm-mve-builtins-base.cc
b/gcc/config/arm/arm-mve-builtins-base.cc
index e31095ae112..426a87e9852 100644
--- a/gcc/config/arm/arm-mve-builtins-base.cc
+++ b/gcc/config/arm/arm-mve-builtins-base.cc
@@ -260,8 +260,8 @@ FUNCTION_PRED_P_S_U (vaddvq, VADDVQ)
  FUNCTION_PRED_P_S_U (vaddvaq, VADDVAQ)
  FUNCTION_WITH_RTX_M (vandq, AND, VANDQ)
  FUNCTION_ONLY_N (vbrsrq, VBRSRQ)
-FUNCTION (vcaddq_rot90, unspec_mve_function_exact_insn_rot,
(UNSPEC_VCADD90, UNSPEC_VCADD90, UNSPEC_VCADD90, VCADDQ_ROT90_M_S,
VCADDQ_ROT90_M_U, VCADDQ_ROT90_M_F))
-FUNCTION (vcaddq_rot270, unspec_mve_function_exact_insn_rot,
(UNSPEC_VCADD270, UNSPEC_VCADD270, UNSPEC_VCADD270, VCADDQ_ROT270_M_S,
VCADDQ_ROT270_M_U, VCADDQ_ROT270_M_F))
+FUNCTION (vcaddq_rot90, unspec_mve_function_exact_insn_rot,
(UNSPEC_VCADD90, UNSPEC_VCADD90, UNSPEC_VCADD90, VCADDQ_ROT90_M,
VCADDQ_ROT90_M, VCADDQ_ROT90_M_F))
+FUNCTION (vcaddq_rot270, unspec_mve_function_exact_insn_rot,
(UNSPEC_VCADD270, UNSPEC_VCADD270, UNSPEC_VCADD270, VCADDQ_ROT270_M,
VCADDQ_ROT270_M, VCADDQ_ROT270_M_F))
  FUNCTION (vcmlaq, unspec_mve_function_exact_insn_rot, (-1, -1,
UNSPEC_VCMLA, -1, -1, VCMLAQ_M_F))
  FUNCTION (vcmlaq_rot90, unspec_mve_function_exact_insn_rot, (-1, -1,
UNSPEC_VCMLA90, -1, -1, VCMLAQ_ROT90_M_F))
  FUNCTION (vcmlaq_rot180, unspec_mve_function_exact_insn_rot, (-1, -1,
UNSPEC_VCMLA180, -1, -1, VCMLAQ_ROT180_M_F))
diff --git a/gcc/config/arm/arm_mve_builtins.def
b/gcc/config/arm/arm_mve_builtins.def
index 43dacc3dda1..6ac1812c697 100644
--- a/gcc/config/arm/arm_mve_builtins.def
+++ b/gcc/config/arm/arm_mve_builtins.def
@@ -523,8 +523,8 @@ VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED,
vhsubq_m_n_u, v16qi, v8hi, v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vhaddq_m_u, v16qi, v8hi, v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vhaddq_m_n_u, v16qi, v8hi,
v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, veorq_m_u, v16qi, v8hi, v4si)
-VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vcaddq_rot90_m_u, v16qi,
v8hi, v4si)
-VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vcaddq_rot270_m_u, v16qi,
v8hi, v4si)
+VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vcaddq_rot90_m_, v16qi,
v8hi, v4si)
+VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vcaddq_rot270_m_, v16qi,
v8hi, v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vbicq_m_u, v16qi, v8hi, v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vandq_m_u, v16qi, v8hi, v4si)
  VAR3 (QUADOP_UNONE_UNONE_UNONE_UNONE_PRED, vaddq_m_u, v16qi, v8hi, v4si)
@@ -587,8 +587,6 @@ VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED,
vhcaddq_rot270_m_s, v16qi, v8hi, v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vhaddq_m_s, v16qi, v8hi, v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vhaddq_m_n_s, v16qi, v8hi, v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, veorq_m_s, v16qi, v8hi, v4si)
-VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vcaddq_rot90_m_s, v16qi, v8hi, v4si)
-VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vcaddq_rot270_m_s, v16qi, v8hi,
v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vbrsrq_m_n_s, v16qi, v8hi, v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vbicq_m_s, v16qi, v8hi, v4si)
  VAR3 (QUADOP_NONE_NONE_NONE_NONE_PRED, vandq_m_s, v16qi, v8hi, v4si)
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index b13ff53d36f..2edd0b06370 100644
--- 

Re: Testsuite issue and warning about floating-point conversion

[Jonathan Wakely via Gcc]

On Sat, 19 Aug 2023, 11:45 FX Coudert,  wrote:

> Hi,
>
> > That seems like a bug in the aarch64-darwin port.
> > 1.0q should definitely be __float128 rather than _Float128.
>
> Is there a simple way to test what type 1.0q is, in C? I tried using
> _Generic, but it says
>
> > a.c:7:52: error: ‘_Generic’ specifies two compatible types
> > 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
> >   |^
> > a.c:7:37: note: compatible type is here
> > 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
> >   | ^~
>
>
> Then:
>
> >  /* For C, let float128t_type_node (__float128 in some backends) be the
> > same type as float128_type_node (_Float128), for C++ let those
> > be distinct types that mangle and behave differently.  */
>
> OK so my mistake is in not defining float128t_type_node in the
> aarch64-darwin port. I will do that. Am I correct in reading that this
> “new” way of handling extended types in C++ was introduced in 2022-09-27?


Yes, this is a new C++23 feature first supported in gcc 13.


If so, my port to aarch64-darwin was done two years ago, and that explains
> why I missed that entirely…
>
> Thanks a lot Jakub for the help!
> FX

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi,

> That seems like a bug in the aarch64-darwin port.
> 1.0q should definitely be __float128 rather than _Float128.

Is there a simple way to test what type 1.0q is, in C? I tried using _Generic, 
but it says

> a.c:7:52: error: ‘_Generic’ specifies two compatible types
> 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
>   |^
> a.c:7:37: note: compatible type is here
> 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
>   | ^~


Then:

>  /* For C, let float128t_type_node (__float128 in some backends) be the
> same type as float128_type_node (_Float128), for C++ let those
> be distinct types that mangle and behave differently.  */

OK so my mistake is in not defining float128t_type_node in the aarch64-darwin 
port. I will do that. Am I correct in reading that this “new” way of handling 
extended types in C++ was introduced in 2022-09-27? If so, my port to 
aarch64-darwin was done two years ago, and that explains why I missed that 
entirely…

Thanks a lot Jakub for the help!
FX

Re: [PATCH] tree-optimization/111048 - avoid flawed logic in fold_vec_perm

[Prathamesh Kulkarni via Gcc-patches]

On Fri, 18 Aug 2023 at 14:52, Richard Biener  wrote:
>
> On Fri, 18 Aug 2023, Richard Sandiford wrote:
>
> > Richard Biener  writes:
> > > The following avoids running into somehow flawed logic in fold_vec_perm
> > > for non-VLA vectors.
> > >
> > > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> > >
> > > Richard.
> > >
> > > PR tree-optimization/111048
> > > * fold-const.cc (fold_vec_perm_cst): Check for non-VLA
> > > vectors first.
> > >
> > > * gcc.dg/torture/pr111048.c: New testcase.
> >
> > Please don't do this as a permanent thing.  It was a deliberate choice
> > to have the is_constant be the fallback, so that the "generic" (VLA+VLS)
> > logic gets more coverage.  Like you say, if something is wrong for VLS
> > then the chances are that it's also wrong for VLA.
>
> Sure, feel free to undo this change together with the fix for the
> VLA case.
Hi,
The attached patch reverts the workaround, and fixes the issue.
Bootstrapped+tested on aarch64-linux-gnu with and without SVE, and
x64_64-linux-gnu.
OK to commit ?

Thanks,
Prathamesh
>
> Richard.
>
> > Thanks,
> > Richard
> >
> >
> > > ---
> > >  gcc/fold-const.cc   | 12 ++--
> > >  gcc/testsuite/gcc.dg/torture/pr111048.c | 24 
> > >  2 files changed, 30 insertions(+), 6 deletions(-)
> > >  create mode 100644 gcc/testsuite/gcc.dg/torture/pr111048.c
> > >
> > > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > > index 5c51c9d91be..144fd7481b3 100644
> > > --- a/gcc/fold-const.cc
> > > +++ b/gcc/fold-const.cc
> > > @@ -10625,6 +10625,11 @@ fold_vec_perm_cst (tree type, tree arg0, tree 
> > > arg1, const vec_perm_indices ,
> > >unsigned res_npatterns, res_nelts_per_pattern;
> > >unsigned HOST_WIDE_INT res_nelts;
> > >
> > > +  if (TYPE_VECTOR_SUBPARTS (type).is_constant (_nelts))
> > > +{
> > > +  res_npatterns = res_nelts;
> > > +  res_nelts_per_pattern = 1;
> > > +}
> > >/* (1) If SEL is a suitable mask as determined by
> > >   valid_mask_for_fold_vec_perm_cst_p, then:
> > >   res_npatterns = max of npatterns between ARG0, ARG1, and SEL
> > > @@ -10634,7 +10639,7 @@ fold_vec_perm_cst (tree type, tree arg0, tree 
> > > arg1, const vec_perm_indices ,
> > >   res_npatterns = nelts in result vector.
> > >   res_nelts_per_pattern = 1.
> > >   This exception is made so that VLS ARG0, ARG1 and SEL work as 
> > > before.  */
> > > -  if (valid_mask_for_fold_vec_perm_cst_p (arg0, arg1, sel, reason))
> > > +  else if (valid_mask_for_fold_vec_perm_cst_p (arg0, arg1, sel, reason))
> > >  {
> > >res_npatterns
> > > = std::max (VECTOR_CST_NPATTERNS (arg0),
> > > @@ -10648,11 +10653,6 @@ fold_vec_perm_cst (tree type, tree arg0, tree 
> > > arg1, const vec_perm_indices ,
> > >
> > >res_nelts = res_npatterns * res_nelts_per_pattern;
> > >  }
> > > -  else if (TYPE_VECTOR_SUBPARTS (type).is_constant (_nelts))
> > > -{
> > > -  res_npatterns = res_nelts;
> > > -  res_nelts_per_pattern = 1;
> > > -}
> > >else
> > >  return NULL_TREE;
> > >
> > > diff --git a/gcc/testsuite/gcc.dg/torture/pr111048.c 
> > > b/gcc/testsuite/gcc.dg/torture/pr111048.c
> > > new file mode 100644
> > > index 000..475978aae2b
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.dg/torture/pr111048.c
> > > @@ -0,0 +1,24 @@
> > > +/* { dg-do run } */
> > > +/* { dg-additional-options "-mavx2" { target avx2_runtime } } */
> > > +
> > > +typedef unsigned char u8;
> > > +
> > > +__attribute__((noipa))
> > > +static void check(const u8 * v) {
> > > +if (*v != 15) __builtin_trap();
> > > +}
> > > +
> > > +__attribute__((noipa))
> > > +static void bug(void) {
> > > +u8 in_lanes[32];
> > > +for (unsigned i = 0; i < 32; i += 2) {
> > > +  in_lanes[i + 0] = 0;
> > > +  in_lanes[i + 1] = ((u8)0xff) >> (i & 7);
> > > +}
> > > +
> > > +check(_lanes[13]);
> > > +  }
> > > +
> > > +int main() {
> > > +bug();
> > > +}
> >
>
> --
> Richard Biener 
> SUSE Software Solutions Germany GmbH,
> Frankenstrasse 146, 90461 Nuernberg, Germany;
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
PR111048: Set arg_npatterns correctly.

In valid_mask_for_fold_vec_perm_cst we set arg_npatterns always
to VECTOR_CST_NPATTERNS (arg0) because of (q1 & 0) == 0 in
following condition:

 /* Ensure that the stepped sequence always selects from the same
 input pattern.  */
  unsigned arg_npatterns
= ((q1 & 0) == 0) ? VECTOR_CST_NPATTERNS (arg0)
  : VECTOR_CST_NPATTERNS (arg1);

resulting in wrong code-gen issues.
The patch fixes this by changing the condition to (q1 & 1) == 0.

gcc/ChangeLog:
PR tree-optimization/111048
* fold-const.cc (valid_mask_for_fold_vec_perm_cst_p): Set arg_npatterns
correctly.
(fold_vec_perm_cst): Remove workaround and again call
valid_mask_fold_vec_perm_cst_p for both VLS and VLA vectors.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Julian Waters  ---
(In reply to Tomas Kalibera from comment #17)
> (In reply to Tomas Kalibera from comment #16)
> > (In reply to Julian Waters from comment #15)
> > > It seems like the patch also doesn't fix the strftime case too, strangely
> > > enough. gcc with that patch applied still causes a compilation failure in
> > > the Windows JDK when encountering strftime with the %T specifier
> > 
> >
> > I don't easily see why the patch doesn't help with %T in strftime. In
> > MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> > the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> > attribute is present.
> 
> The older version of the patch I use with gcc 12 doesn't seem to be helping
> with %T, but the newer one (patch_master.diff) helps with %T on the current
> gcc master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with
> MinGW-W64 11.0.1.

If I may ask, could I have the link to patch_master.diff?

[Bug c++/111069] Mangling of static structured bindings

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 55763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55763=edit
gcc14-pr111069-wip.patch

WIP patch.  Seems to get the basics right, but mangling of guard vars (_ZGV*)
and life-extended vars (_ZGR*) needs work.  The latter will be hard, because
adding a full demangler to mangle.cc so that it handles arbitrary local names
would be undesirable.

Re: Testsuite issue and warning about floating-point conversion

[Jakub Jelinek via Gcc]

On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote:
> well.  So, if aarch64-darwin wants 64-bit long double, the question is if
> it should have __float128 support and q suffix support at all.  If it
> should, then it needs to initialize float128t_type_node to a distinct type
> if NULL like i386, ia64 and rs6000 backends do (i.e. for C++).

Oh, and as the comment say, one needs to decide how to mangle the types.
long_double_type_node, even when distinct from double_type_node, will
mangle unless overridden as e (double d), and float128_type_node as DF128_.
__float128 should mangle per Itanium ABI mangling as g (unless overridden)
but backend needs to do that.
Also, one needs to decide what _Float16 and __bf16 mangles as, whether
the Itanium ABI DF16_ and DF16b or something different (aarch64-linux
mangles the latter as u6__bf16 instead).
See what clang does as well...

Jakub

Re: [committed] libstdc++: Fix std::format("{:F}", inf) to use uppercase

[Jonathan Wakely via Gcc-patches]

On Thu, 17 Aug 2023 at 13:22, Jonathan Wakely via Libstdc++
 wrote:
>
> Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 will follow.

Re the backport, I forgot to say that this changes the order/values of
the enumerators for _Pres_type. In theory that could cause
incompatibilities between GCC 13.2 and 13.3, if one object uses the
old definition of std::formatter::parse and another object uses the
new definition of std::formatter::format, or vice versa. But given
that 99.999% of uses of std::formatter are via std::format (not using
the formatter class directly), I expect that the calls to parse and
format will always be instantiated together at the same time, and so
every object will contain both symbols. That will mean that the linker
will always pick a "matching pair" of symbols, i.e. both symbols will
use the new enumerator values, or both will use the old enumerator
values, and so in practice there won't be a mismatch.

I could have added the new _Pres_F enumerator at the end, so it would
not alter the values of the other enumerators. But that wouldn't
completely avoid the problem anyway, because a new object that uses
_Pres_F in formatter::parse would be incompatible with an old object
that didn't know about the new _Pres_F value in formatter::format. So
I would prefer to keep the _Pres_F enumerator adjacent to _Pres_f and
the other ones for floating-point presentation types.

There have been so many other fixes to std::format that I think it
will be reasonable to tell anybody using it that they should just use
GCC 13.3 consistently anyway, and not mix code built with 13.2 and
13.3 if they're using the experimental C++20 std::format
implementation.


>
> -- >8 --
>
> std::format was treating {:f} and {:F} identically on the basis that for
> the fixed 1.234567 format there are no alphabetical characters that need
> to be in uppercase. But that's wrong for infinities and NaNs, which
> should be formatted as "INF" and "NAN" for {:F}.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/format (__format::_Pres_type): Add _Pres_F.
> (__formatter_fp::parse): Use _Pres_F for 'F'.
> (__formatter_fp::format): Set __upper for _Pres_F.
> * testsuite/std/format/functions/format.cc: Check formatting of
> infinity and NaN for each presentation type.
> ---
>  libstdc++-v3/include/std/format  | 10 --
>  .../testsuite/std/format/functions/format.cc | 12 
>  2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
> index a8db10d6460..40c7d6128f6 100644
> --- a/libstdc++-v3/include/std/format
> +++ b/libstdc++-v3/include/std/format
> @@ -309,7 +309,7 @@ namespace __format
>  // Presentation types for integral types (including bool and charT).
>  _Pres_d = 1, _Pres_b, _Pres_B, _Pres_o, _Pres_x, _Pres_X, _Pres_c,
>  // Presentation types for floating-point types.
> -_Pres_a = 1, _Pres_A, _Pres_e, _Pres_E, _Pres_f, _Pres_g, _Pres_G,
> +_Pres_a = 1, _Pres_A, _Pres_e, _Pres_E, _Pres_f, _Pres_F, _Pres_g, 
> _Pres_G,
>  _Pres_p = 0, _Pres_P,   // For pointers.
>  _Pres_s = 0,// For strings and bool.
>  _Pres_esc = 0xf,// For strings and charT.
> @@ -1382,10 +1382,13 @@ namespace __format
> ++__first;
> break;
>   case 'f':
> - case 'F':
> __spec._M_type = _Pres_f;
> ++__first;
> break;
> + case 'F':
> +   __spec._M_type = _Pres_F;
> +   ++__first;
> +   break;
>   case 'g':
> __spec._M_type = _Pres_g;
> ++__first;
> @@ -1442,6 +1445,9 @@ namespace __format
>   __use_prec = true;
>   __fmt = chars_format::scientific;
>   break;
> +   case _Pres_F:
> + __upper = true;
> + [[fallthrough]];
> case _Pres_f:
>   __use_prec = true;
>   __fmt = chars_format::fixed;
> diff --git a/libstdc++-v3/testsuite/std/format/functions/format.cc 
> b/libstdc++-v3/testsuite/std/format/functions/format.cc
> index 4db5202815d..59ed3be8baa 100644
> --- a/libstdc++-v3/testsuite/std/format/functions/format.cc
> +++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
> @@ -159,6 +159,18 @@ test_alternate_forms()
>VERIFY( s == "1.e+01 1.e+01 1.e+01" );
>  }
>
> +void
> +test_infnan()
> +{
> +  double inf = std::numeric_limits::infinity();
> +  double nan = std::numeric_limits::quiet_NaN();
> +  std::string s;
> +  s = std::format("{0} {0:e} {0:E} {0:f} {0:F} {0:g} {0:G} {0:a} {0:A}", 
> inf);
> +  VERIFY( s == "inf inf INF inf INF inf INF inf INF" );
> +  s = std::format("{0} {0:e} {0:E} {0:f} {0:F} {0:g} {0:G} {0:a} {0:A}", 
> nan);
> +  VERIFY( s == "nan nan NAN nan NAN nan NAN nan NAN" );
> +}
> +
>  struct euro_punc : std::numpunct
>  {
>std::string do_grouping() const override { 

Re: Testsuite issue and warning about floating-point conversion

[Jakub Jelinek via Gcc]

On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc  wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC 
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> > failures which are due to the following:
> >
> > 1. The testsuite check_effective_target_has_q_floating_suffix check tries 
> > to compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> > allowed on floating-point types.
> >
> > 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> > because the q suffix matches the _Float128 type.
> >
> > 3. However, a warning is emitted which makes the test fail:
> >
> > a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> > conversion rank
> > 1 | float dummy = 1.0q;
> >   |   ^~~~
> >
> >
> > 4. Therefore, the expectations of the different tests fail.
> >
> >
> > Now, I am not sure why other targets are not affected in the same way, for 
> > example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> > warranted here? If so, we should adjust the check to silence warnings, or 
> > use a cast. Or is the warning emitted in error?
> 
> It's probably because 1.0q produces __float128 on those targets, not
> _Float128. In C++23 _Float128 (and _Float32 etc.) have special rules
> about implicit conversions to other floating-point types.
> 
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

That seems like a bug in the aarch64-darwin port.
1.0q should definitely be __float128 rather than _Float128.

The c-lex.cc code has:
/* For Q suffix, prefer float128t_type_node (__float128) type
   over float128_type_node (_Float128) type if they are distinct.  */
if (type == float128_type_node && float128t_type_node)
  type = float128t_type_node;
Now, the generic tree.cc initialization will initialize float128_type_node
(i.e. _Float128) to some floating point type if there is IEEE quad mode
backend support, and float128t_type_node (i.e. __float128) to 
float128_type_node,
and c-family/c-common.cc later on will:
  /* For C, let float128t_type_node (__float128 in some backends) be the
 same type as float128_type_node (_Float128), for C++ let those
 be distinct types that mangle and behave differently.  */
  if (c_dialect_cxx ())
float128t_type_node = NULL_TREE;
i.e. __float128 and _Float128 are the same type for C and for C++ distinct,
then i386, ia64 and rs6000 backends create their own float128t_type_node
as distinct types.
q/w suffixes aren't supported at all unless the backend overrides
c.mode_for_suffix target hook, and besides the above 3 arches only
aarch64 and pa do that. pa does that iff it it registers __float128
type as an alias to long double and aarch64 except for Darwin does that as
well.  So, if aarch64-darwin wants 64-bit long double, the question is if
it should have __float128 support and q suffix support at all.  If it
should, then it needs to initialize float128t_type_node to a distinct type
if NULL like i386, ia64 and rs6000 backends do (i.e. for C++).

Jakub

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi,

> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

That’s weird. I create it in this way:

+  /* Populate the float128 node if it is not already done so that the FEs
+ know it is available.  */
+  if (float128_type_node == NULL_TREE)
+{
+  float128_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (float128_type_node) = 128;
+  SET_TYPE_MODE (float128_type_node, TFmode);
+  layout_type (float128_type_node);
+}
+
+  lang_hooks.types.register_builtin_type (float128_type_node, "__float128");



> An explicit cast prevents the warning:
> float dummy = (float) 1.0q;

Yes, I think a cast does the job. It will still error out when q suffix is not 
supported, and will not have other messages.

FX

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jonathan Wakely  ---
If we're right about that, then I agree that a warning would be useful for
classes that have no such implicit conversion from S to S*.

I think the warning would give a false positive in the case below, so a way to
disable it locally would be needed (e.g. via a diagnostic pragma).

struct S {
  int f(this S*); // warning: explicit object parameter of pointer type can
only match if an implicit conversion to S* exists
};

struct T : S {
  operator T*();
};

T t;
int i = t.f(); // derived class has the required conversion

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jonathan Wakely  ---
I don't see anything forbidding that declaration, but I think it can only be
called if S& has an implicit conversion to S* because the object parameter is
an lvalue of type S, and so it can only match S* via an implicit conversion.

[Bug tree-optimization/107876] [13 Regression] ICE in verify_dominators, at dominance.cc:1184 (error: dominator of 4 should be 14, not 16) since r13-3749-g7314b98b1bcd382c

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert  ---
The test case (g++.dg/tree-ssa/pr107876.C) fails on aarch64-darwin.

FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++14  scan-tree-dump unswitch
"unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"
FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++17  scan-tree-dump unswitch
"unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"
FAIL: g++.dg/tree-ssa/pr107876.C  -std=gnu++20  scan-tree-dump unswitch
"unswitching loop 1 on .switch. with condition: i_[0-9]+\\(D\\) == 2"

The output says:

;; Function test17 (_Z6test17i, funcdef_no=0, decl_uid=4194, cgraph_uid=1,
symbol_order=0)

Estimating # of iterations of loop 1
g++.dg/tree-ssa/pr107876.C:21:7: optimized: unswitching loop 1 on 'if' with
condition: i_7(D) == 0
g++.dg/tree-ssa/pr107876.C:21:7: note: optimized sizes estimated to 0 (true)
and 0 (false) from original size 16

Re: Testsuite issue and warning about floating-point conversion

[Jonathan Wakely via Gcc]

On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc  wrote:
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC 
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> failures which are due to the following:
>
> 1. The testsuite check_effective_target_has_q_floating_suffix check tries to 
> compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> allowed on floating-point types.
>
> 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> because the q suffix matches the _Float128 type.
>
> 3. However, a warning is emitted which makes the test fail:
>
> a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> conversion rank
> 1 | float dummy = 1.0q;
>   |   ^~~~
>
>
> 4. Therefore, the expectations of the different tests fail.
>
>
> Now, I am not sure why other targets are not affected in the same way, for 
> example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> warranted here? If so, we should adjust the check to silence warnings, or use 
> a cast. Or is the warning emitted in error?

It's probably because 1.0q produces __float128 on those targets, not
_Float128. In C++23 _Float128 (and _Float32 etc.) have special rules
about implicit conversions to other floating-point types.

I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

I was going to suggest that using 'long double dummy = 1.0q' instead
of 'float' would help, but IIRC the Apple M1 ABI says that long double
is the same type as double, and so 'long double' would still have
lower conversion rank than _Float128.

An explicit cast prevents the warning:

float dummy = (float) 1.0q;

[Bug c++/105838] [11/12 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

[fxcoudert at gcc dot gnu.org via Gcc-bugs]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #25 from Francois-Xavier Coudert  ---
The new test (g++.dg/tree-ssa/initlist-opt5.C) fails on darwin. The gimple dump
is like this:

void f (const char * p)
{
  const struct basic_string * retval.0;
  const struct basic_string * D.24981;
  const struct basic_string * D.24982;
  long int D.24983;
  struct allocator D.24824;
  struct initializer_list lst;
  const struct basic_string D.24980[72];

  try
{
  lst = {};
  lst._M_len = 72;
  D.24981 = 
  D.24982 = D.24981;
  D.24983 = 71;
  try
{
  _4 = D.24982;
  try
{
  std::allocator::allocator ();
  try
{
  std::__cxx11::basic_string::basic_string (_4, "aahing",
);
  D.24982 = D.24982 + 32;
  D.24983 = D.24983 + -1;
  _5 = D.24982;
  std::__cxx11::basic_string::basic_string (_5, "aaliis",
);
  D.24982 = D.24982 + 32;
  D.24983 = D.24983 + -1;
  _6 = D.24982;
  std::__cxx11::basic_string::basic_string (_6, "aarrgh",
);
  D.24982 = D.24982 + 32;
  D.24983 = D.24983 + -1;
  _7 = D.24982;
[...]
  std::__cxx11::basic_string::basic_string (_75,
"absent", );
  D.24982 = D.24982 + 32;
  D.24983 = D.24983 + -1;
  retval.0 = D.24981;
  D.24983 = 71;
  lst._M_array = 
}
  finally
{
  std::allocator::~allocator ();
}
}
  finally
{
  D.24824 = {CLOBBER(eol)};
}
}
  catch
{
  {
const struct basic_string * D.24984;

if (D.24981 != 0B) goto ; else goto ;
:
_1 = 71 - D.24983;
_2 = (sizetype) _1;
_3 = _2 * 32;
D.24984 = D.24981 + _3;
:
if (D.24984 == D.24981) goto ; else goto ;
:
D.24984 = D.24984 + 18446744073709551584;
std::__cxx11::basic_string::~basic_string (D.24984);
goto ;
:
goto ;
:
:
  }
}
  try
{
  g ();
}
  finally
{
  {
const struct basic_string * D.24985;

D.24985 =  + 2304;
:
if ( == D.24985) goto ; else goto ;
:
D.24985 = D.24985 + 18446744073709551584;
std::__cxx11::basic_string::~basic_string (D.24985);
goto ;
:
  }
}
}
  finally
{
  lst = {CLOBBER(eol)};
  D.24980 = {CLOBBER(eol)};
}
}


__attribute__((always_inline))
void std::allocator::allocator (struct allocator * const this)
{
  try
{
  {
std::__new_allocator::__new_allocator (this);
try
  {

  }
catch
  {
std::__new_allocator::~__new_allocator (this);
  }
  }
}
  catch
{
  <<>>
}
}


__attribute__((always_inline))
void std::__new_allocator::__new_allocator (struct __new_allocator *
const this)
{
  try
{
  {

  }
}
  catch
{
  <<>>
}
}


__attribute__((always_inline))
void std::allocator::~allocator (struct allocator * const this)
{
  try
{
  {
try
  {

  }
finally
  {
std::__new_allocator::~__new_allocator (this);
  }
  }
}
  catch
{
  <<>>
}
}


void std::__new_allocator::~__new_allocator (struct __new_allocator *
const this)
{
  try
{
  {

  }
}
  catch
{
  <<>>
}
}

Re: gnu as

[Jonathan Wakely via Gcc]

On Sat, 19 Aug 2023 at 09:58, h3140067...@163.com 
wrote:

> Is it similar to the gnu as86 assembly compiler? Actually, I just hope to
> have a separate branch of the as86 assembly compiler
>


I don't know what GNU as86 is, but GCC does not have any assembler. GCC
uses your system's assembler, which will be the GNU Binutils 'as' on many
systems (proprietary UNIX systems tend to have their own 'as' that isn't
the one from Binutils).



>
>  Replied Message 
> From Jonathan Wakely 
> Date 08/19/2023 14:29
> To h3140067...@163.com 
> Cc gcc 
> Subject Re: gnu as
>
>
> On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc, 
> wrote:
>
>> Hi, I am an open-source enthusiast from China. I really like the cross
>> platform features of AS assembly compilers. I hope the community can
>> independently open source a branch of the backend assembly compiler of GCC
>> compiler in gcc.gnu.org, just like nasm, and continuously improve it
>> through open source
>>
>
> I'm not sure what you mean, but maybe the Binutils project is what you
> want.
>
>
>

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi Jakub,

I should have pinged you, I see you recently touched that code.

FX


> Le 18 août 2023 à 21:07, FX Coudert  a écrit :
> 
> Hello,
> 
> On the WIP aarch64-darwin port of GCC 
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> failures which are due to the following:
> 
> 1. The testsuite check_effective_target_has_q_floating_suffix check tries to 
> compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> allowed on floating-point types.
> 
> 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> because the q suffix matches the _Float128 type.
> 
> 3. However, a warning is emitted which makes the test fail:
> 
> a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> conversion rank
>1 | float dummy = 1.0q;
>  |   ^~~~
> 
> 
> 4. Therefore, the expectations of the different tests fail.
> 
> 
> Now, I am not sure why other targets are not affected in the same way, for 
> example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> warranted here? If so, we should adjust the check to silence warnings, or use 
> a cast. Or is the warning emitted in error?
> 
> Any help would be appreciated.
> 
> Thanks,
> FX

Re: gnu as

[h3140067568--- via Gcc]

Is it similar to the gnu as86 assembly compiler? Actually, I just hope to have 
a separate branch of the as86 assembly compiler



 Replied Message 
| From | Jonathan Wakely |
| Date | 08/19/2023 14:29 |
| To | h3140067...@163.com |
| Cc | gcc |
| Subject | Re: gnu as |



On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc,  wrote:

Hi, I am an open-source enthusiast from China. I really like the cross platform 
features of AS assembly compilers. I hope the community can independently open 
source a branch of the backend assembly compiler of GCC compiler in 
gcc.gnu.org, just like nasm, and continuously improve it through open source



I'm not sure what you mean, but maybe the Binutils project is what you want.

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #7 from waffl3x  ---
struct S {
int f(this S*) {
return 5;
}
};

int main()
{
S s{};
return s.f();
}

Here is my current progress, this code works. I have a good feeling that the
rest is going to be easy. Except for deduction maybe, but I have a minor hunch
that it might -just work- without any extra tinkering after everything else has
been implemented.
Also yes, I know that `int f(this S*)` is not a valid declaration, I just
didn't have to change any member function call code for it to work this way so
I made it my first goal to implement it this way.

Actually, I guess it's not explicitly invalid is it? I don't recall seeing it
in the pathological cases section of the paper, indeed, I just checked and
there doesn't seem to be mention of it. I believe it should probably be valid
though, not useful if you ask me. Even less so than the other pathological
cases (which I think might actually prove to be useful in some cases.) However,
regardless of my opinion, following the same direction as the original paper, I
imagine it should be allowed. The class would just need an implicit conversion
to pointer, maybe a warning would be in order though?

[Bug gcov-profile/111038] The function summary in gcov

[gejoed at rediffmail dot com via Gcc-bugs]

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

--- Comment #3 from Gejoe  ---
Not sure of that..Will have to check.

[PATCH][Ada] Fix syntax errors in expect.c

[Andris Pavēnis]

Noticed trivial syntax errors in gcc/ada/expect.c when tried to compile gcc 13.2 as cross-compiler 
for target i686-pc-msdosdjgpp.


Errors were there since

Tiedostossa, joka sisällytettiin kohdasta expect.c:54:
expect.c:Funktio ”__gnat_waitpid”:
expect.c:353:13:virhe: expected ”(” before numeric constant
 353 |   } else if WIFSTOPPED(status) {
 | ^~
expect.c:358:1:varoitus: ei-void-tyyppisen funktion loppu saavutettu 
[-Wreturn-type]
 358 | }
 | ^
make[5]: *** [../gcc-interface/Makefile:297: expect.o] Error 1

Errors were there since commit 9e6274e0a3b60e77a42784c3fb6ef2aa3cfc071a(Wed Dec 15 19:26:50 2021 
+0600)


Fixing these errors (attached patch for master branch) was not sufficient for building Ada 
cross-compiler, but it fixed compiler errors.


This would perhaps qualify for trivial change, but it seems that I no more have write access (I got 
it in 2015, but have not used it for a long time. Perhaps I do not really need it)



Andris




commit 64c48aa99656e06d5728bf5837da3bbc50ae4cc5
Author: Andris Pavēnis 
Date:   Sat Aug 19 10:40:22 2023 +0300

Fix syntax error

gcc/ada/expect.c(__gnat_waitpid):
fix syntax errors

diff --git a/gcc/ada/expect.c b/gcc/ada/expect.c
index e6899632bc9..7333c11d954 100644
--- a/gcc/ada/expect.c
+++ b/gcc/ada/expect.c
@@ -346,11 +346,11 @@ __gnat_waitpid (int pid)
  return -1;
   }
 
-  if WIFEXITED (status) {
+  if (WIFEXITED (status)) {
  status = WEXITSTATUS (status);
-  } else if WIFSIGNALED (status) {
+  } else if (WIFSIGNALED (status)) {
  status = WTERMSIG (status);
-  } else if WIFSTOPPED (status) {
+  } else if (WIFSTOPPED (status)) {
  status = WSTOPSIG (status);
   }
 

[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from David Binderman  ---
This seems to break sometime between g:93f803d53b5ccaab and g:68f7cb6cf9e8b9f2,
some 39 commits.

[Bug c++/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

Summary|[13/14 regression]  |[13/14 regression]
   |False-positive  |False-positive
   |-Wstringop-overflow when|-Wstringop-overflow when
   |building gdb from trunk |building gdb from trunk
   ||with -D_GLIBCXX_ASSERTIONS

--- Comment #2 from Sam James  ---
Oh, interesting. It needs -D_GLIBCXX_ASSERTIONS (which my gcc has on by
default) to trigger.

[Bug c++/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 Blocks||88443

--- Comment #1 from Sam James  ---
I can reproduce it with:
```
$ g++-14 -c infcall.ii -O2 -Werror=stringop-overflow
[...]
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:437:30:
error: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ writing
9 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
  437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
[...]
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug c++/111073] New: [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 111073
   Summary: [13/14 regression] False-positive -Wstringop-overflow
when building gdb from trunk
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org, tromey at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55762=edit
infcall.ii.xz

12.3.1 20230818 is OK, but 13.2.1 20230812 and 14.0.0 20230813 aren't.

I filed this over at gdb first:
https://sourceware.org/bugzilla/show_bug.cgi?id=30780.

```
$ g++-14 -x c++-I. -I. -I./config -DLOCALEDIR="\"/usr/local/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I../bfd -I./../bfd -I./../include
-I./../readline/readline/.. -I./../zlib  -I../libdecnumber -I./../libdecnumber 
-I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/
-I../libbacktrace/ -DTUI=1-I/usr/include/python3.12
-I/usr/include/python3.12   -I./.. -pthread-Wall -Wpointer-arith
-Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch
-Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
-Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized
-Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3
-Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor
-Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat
-Wformat-nonliteral -Werror -g -O2 -c -o infcall.o -MT infcall.o -MMD -MP
-MF ./.deps/infcall.Tpo infcall.c
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/hashtable_policy.h:36,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/hashtable.h:35,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/unordered_map.h:33,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/unordered_map:41,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/functional:63,
 from ./../gdbsupport/ptid.h:35,
 from ./../gdbsupport/common-defs.h:206,
 from defs.h:26,
 from infcall.c:20:
In static member function ‘static _Up* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
value*; _Up = value*; bool _IsMove = false]’,
inlined from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:506:30,
inlined from ‘_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:533:42,
inlined from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = value**; _OI = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:540:31,
inlined from ‘_OI std::copy(_II, _II, _OI) [with _II = value**; _OI =
value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_algobase.h:633:7,
inlined from ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = value**; _ForwardIterator = value**]’
at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:147:27,
inlined from ‘_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = value**;
_ForwardIterator = value**]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:185:15,
inlined from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
value**; _ForwardIterator = value**; _Tp = value*]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_uninitialized.h:373:37,
inlined from ‘void std::vector<_Tp, _Alloc>::_M_range_insert(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = value**; _Tp = value*; _Alloc = std::allocator]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/vector.tcc:884:38,
inlined from ‘std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = value**;  = void; _Tp = value*; _Alloc
= std::allocator]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/stl_vector.h:1486:19,
inlined from ‘value* call_function_by_hand_dummy(value*, type*,
gdb::array_view, void (*)(void*, int), void*)’ at infcall.c:1239:23:

Re: gnu as

[Jonathan Wakely via Gcc]

On Sat, 19 Aug 2023, 00:21 h3140067568--- via Gcc,  wrote:

> Hi, I am an open-source enthusiast from China. I really like the cross
> platform features of AS assembly compilers. I hope the community can
> independently open source a branch of the backend assembly compiler of GCC
> compiler in gcc.gnu.org, just like nasm, and continuously improve it
> through open source
>

I'm not sure what you mean, but maybe the Binutils project is what you want.