[Bug c++/115314] New: Type of the `auto` template parameter in a concept is not decayed when called as dependent name

[mateusz.pusz at gmail dot com via Gcc-bugs]

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

Bug ID: 115314
   Summary: Type of the `auto` template parameter in a concept is
not decayed when called as dependent name
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mateusz.pusz at gmail dot com
  Target Milestone: ---

```
struct X {
  static constexpr int val = 42;
};

template
concept A = std::same_as;

template
concept B = A;

static_assert(A);
static_assert(B);
```

The first static assert passes while the other one fails. Both cases work on
clang and MSVC: https://godbolt.org/z/v5z6bee7c

Affects all gcc versions from 12 to 15.

[Bug analyzer/111536] -fanalyzer false positive with NRVO return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-01
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed.

Another reduced testcase, this time reduced from std::string:
```
struct g
{
  int t;
  g();
  g(const g&);
};

g foo1()
{
return g{};
}

```

[Bug analyzer/111536] -fanalyzer false positive with NRVO return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

--- Comment #1 from Andrew Pinski  ---
*** Bug 115313 has been marked as a duplicate of this bug. ***

[Bug analyzer/115313] False positive -fanalyzer use of uninitialized value due to not understand C++ front-end's NRVO

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 111536 ***

[Bug analyzer/115313] False positive -fanalyzer use of uninitialized value due to not understand C++ front-end's NRVO

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-01
Summary|False positive -fanalyzer   |False positive -fanalyzer
   |use of uninitialized value  |use of uninitialized value
   |due to std::string's|due to not understand C++
   |default constructor |front-end's NRVO

--- Comment #2 from Andrew Pinski  ---
Further reduced:
```
struct g
{
  int t;
  g();
  g(const g&);
};

g foo1()
{
return g{};
}
```

[Bug analyzer/115313] False positive -fanalyzer use of uninitialized value due to std::string's default constructor

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
Reduced:

#include 

std::string foo() {
std::string str;
return str;
}


: In function 'std::string foo()':
:4:17: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
4 | std::string str;
  | ^~~
  'std::string foo()': events 1-3
|
|3 | std::string foo() {
|  | ^~~
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 8 bytes
|4 | std::string str;
|  | ~~~
|  | |
|  | (3) use of uninitialized value '' here
|

[Bug c++/115313] New: False positive -fanalyzer use of uninitialized value due to std::string's default constructor

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 115313
   Summary: False positive -fanalyzer use of uninitialized value
due to std::string's default constructor
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

#include 
#include 

namespace foo {
namespace detail {
std::string format(const char*, const char*) {
std::string str;
return str;
}
}

std::string format(std::string_view fmt) {
return detail::format(fmt.begin(), fmt.end());
}

}

int main() {
foo::format("");
}


: In function 'std::string foo::detail::format(const char*, const
char*)':
:7:25: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
7 | std::string str;
  | ^~~
  'std::string foo::detail::format(const char*, const char*)': events 1-3
|
|6 | std::string format(const char*, const char*) {
|  | ^~~
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 8 bytes
|7 | std::string str;
|  | ~~~
|  | |
|  | (3) use of uninitialized value ''
here
|
: In function 'std::string foo::format(std::string_view)':
:13:53: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   13 | return detail::format(fmt.begin(), fmt.end());
  | ^
  'std::string foo::format(std::string_view)': events 1-3
|
|   12 | std::string format(std::string_view fmt) {
|  | ^~~
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 8 bytes
|   13 | return detail::format(fmt.begin(), fmt.end());
|  | ~
|  | |
|  | (3) use of
uninitialized value '' here
|
:13:53: warning: use of uninitialized value '' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   13 | return detail::format(fmt.begin(), fmt.end());
  | ^
  'int main()': events 1-4
|
|   18 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to 'main'
|   19 | foo::format("");
|  | ~~~
|  ||
|  |(2) calling
'std::basic_string_view::basic_string_view' from 'main'
|  |(3) returning to 'main' from
'std::basic_string_view::basic_string_view'
|  |(4) calling 'foo::format' from 'main'
|
+--> 'std::string foo::format(std::string_view)': events 5-8
   |
   |   12 | std::string format(std::string_view fmt) {
   |  | ~~~ ^~
   |  | |   |
   |  | |   (5) entry to 'foo::format'
   |  | (6) region created on stack here
   |  | (7) capacity: 8 bytes
   |   13 | return detail::format(fmt.begin(), fmt.end());
   |  | ~
   |  | |
   |  | (8) use
of uninitialized value '' here
   |


https://godbolt.org/z/enKzccqoK

[Bug middle-end/32911] Function __attribute__ ((idempotent))

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

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

--- Comment #8 from Eric Gallager  ---
It might also be worth comparing against the attributes [[unsequenced]] and
[[reproducible]] proposed for the C standard:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2956.htm

[Bug debug/78100] DWARF symbols for an array sometimes missing the array length

[puetzk at puetzk dot org via Gcc-bugs]

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

--- Comment #8 from Kevin Puetz  ---
Found it: this is a duplicate of bug 91507, thus fixed by
r276403/31632e2c4327146ea8d21cff33adaa505b17d2bd

[Bug debug/78100] DWARF symbols for an array sometimes missing the array length

[puetzk at puetzk dot org via Gcc-bugs]

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

--- Comment #7 from Kevin Puetz  ---
Nope, falsified that guess - I just realized compiler explorer can do
dwarfdump, which makes it easy to bisect among the releases they have (if not
actually commit-by-commit). This shows that 9.5.0 (which has r263660) still
produces bad DWARF, and 10.1 is fixed. So it can't be that commit...

https://godbolt.org/z/jj4safe6e

[Bug debug/78100] DWARF symbols for an array sometimes missing the array length

[puetzk at puetzk dot org via Gcc-bugs]

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

Kevin Puetz  changed:

   What|Removed |Added

 CC||puetzk at puetzk dot org

--- Comment #6 from Kevin Puetz  ---
Possibly r263660/ea379c9ec3776b9d4f72d5d8c8987e2e43c7baae? 
add_bound_info (subrange_die, DW_AT_upper_bound) eventually calls the
add_scalar_info() that was changed in that patch. And it at least seems
plausible that the changes around decl_die = lookup_decl_die(decl)` could be
relevant.

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/dwarf2out.c;h=b80c909e1fc6b05c35faa30a72e262a08cc7d65e;hp=236f199afcf050957639f1cce839f870a0d472c6;hb=ea379c9ec3776b9d4f72d5d8c8987e2e43c7baae;hpb=3fb558b154f795983ae6a9dd6478e18a2c846584

The new code requires that decl_die have  DW_AT_location or DW_AT_const_value
in order to take the early return, and the first decl (the `extern` with
DW_AT_external = yes) has neither. So that would help the function *not* just
reference the extern and return early, thus eventually writing the complete
DW_TAG_array_type too.

I don't know this code well, haven't actually bisected, and this isn't actually
an LTO case that patch's comment describes... but it seems to be in the right
timeframe and changing relevant parts of dwarf2out.c

[Bug pch/115312] New: [14/15 Regression] ICE when including a PCH via compiler option -include

[gcc at mailinator dot com via Gcc-bugs]

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

Bug ID: 115312
   Summary: [14/15 Regression] ICE when including a PCH via
compiler option -include
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

An internal compiler error is triggered in GCC 14.1.0 when including a
precompiled header via compiler option -include. A testcase is provided below:

```
touch test.cpp
touch test.h

g++ test.h
g++ -include test.h -c test.cpp -save-temps
test.cpp:1: internal compiler error: in c_init_preprocess, at cp/parser.cc:790
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

This issue shows up on (i686|x86_64)-w64-mingw32 platforms. GCC 14.1.0 releases
from MSYS2 and WinLibs projects are affected.

I have done some tests with prebuilt GCC 14 pre-releases from WinLibs project.

- Last working GCC 14 pre-release is from snapshot gcc-14-20231119.
- First GCC 14 pre-release with this issue is from snapshot gcc-14-20231217.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

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

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

--- Comment #12 from Hans-Peter Nilsson  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #11)
> > --- Comment #10 from Hans-Peter Nilsson  ---

> >> The failure is even earlier here: in a sparc64-unknown-linux-gnu
> >> bootstrap, building a libstdc++ .gch file in stage 2 breaks:
> >
> > Great, thanks!  That means that tricking my pc into believing it's a sparc 
> > by
> > means of using the binfmt machinery that Jeff mentioned in the thread where 
> > I
> > mentioned the revert on gcc-patches, would work.  (I don't have the details 
> > and
> > don't remember if I'd actually tried it, certainly not recently; I just know
> > about the concept.)
> 
> I can't help but wonder if this wouldn't be a total waste of your time:
> considering what the qemu wiki docments for SPARC support
> 
> https://wiki.qemu.org/Documentation/Platforms/SPARC
> 
> seems not too encouraging for 64-bit systems.

Thanks for the warning, but I'm confused as it doesn't look too bad to me; for
example the status field for SPARC64 says "working" at least for non-historic
qemu versions.  What am I missing?  Are you thinking of something specific
there?

> When I think about what
> it took myself to get recent macOS working on qemu-kvm (although the
> procedure is resonably well documented, with firmware and all
> available), I'd consider such an attempt a positive nightmare.

Also, I wouldn't be using qemu-system-sparc64 IIUC: with the binfmt trick I'd
be using qemu-user.

That "experience" (assuming success) would also lead to a template or identical
solution for other targets, which is the most interesting part.  The cfarm is
nice to have, but the machines are a bit crowded.

> When all it takes for you to either get your ssh client working to
> access a ready-made and not too slow SPARC system (or in the worst case,
> build OpenSSH from source), I know which route I'd take ;-)

A different nightmare, leading to a nightmare of chasing a bootstrap failure on
a system I'm not familiar with (referring to solaris on the cfarm machine).

> > What's not so great is that the described reproducer is a bootstrap, so the
> > debug situation is unpleasant.  The first step I'd do, would be to just do a
> > cross-build (or native --disable-bootstrap) and just run the testsuite
> > before/after the patch-set (or just 933ab59c59bdc1) and see if the problem
> > manifests there.

> I've tried that now on both
> 
> * sparc-sun-solaris2.11 (c and c++ only): no additional testsuite
>   failures are apparent there, which is not too astonishing given that
>   the bootstrap failure occurs in stage 3, suggesting a mis-compiled
>   stage 2 cc1plus, and

Oh, too bad.  Thanks for doing that!

> * sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite
>   failures all over the place, but I'd have to perform another bootstrap
>   with your patches removed to make an exact comparison.

Hm, the part where you compare results against a baseline is pretty central.

One the one hand, when it doesn't manifest for sparc64-solaris just through the
testsuite, the odds are against it manifesting that simple for sparc64-linux. 
On the other hand, an existing reproducer is so much easier to handle.  Thank
you and thanks in advance for the last step!

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||paalon1936 at gmail dot com

--- Comment #13 from Nathaniel Shead  ---
*** Bug 115257 has been marked as a duplicate of this bug. ***

[Bug c++/103524] [meta-bug] modules issue

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 115257, which changed state.

Bug 115257 Summary: Error when compiling a program with module and println and 
auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115257

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/115257] Error when compiling a program with module and println and auto

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Nathaniel Shead  ---
Looks to be the same issue as PR114275, fixed on trunk.

*** This bug has been marked as a duplicate of bug 114275 ***

[Bug c++/114867] [modules] name lookup issues when a function overload set is exported from GMF

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #4 from Nathaniel Shead  ---
Fixed for GCC 15.

[Bug c++/103524] [meta-bug] modules issue

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114867, which changed state.

Bug 114867 Summary: [modules] name lookup issues when a function overload set 
is exported from GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852
Bug 106852 depends on bug 114867, which changed state.

Bug 114867 Summary: [modules] name lookup issues when a function overload set 
is exported from GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114867

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/114867] [modules] name lookup issues when a function overload set is exported from GMF

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:85f15ea65a97686ad39af0c14b7dd9a9372e3a19

commit r15-964-g85f15ea65a97686ad39af0c14b7dd9a9372e3a19
Author: Nathaniel Shead 
Date:   Sat Jun 1 01:14:44 2024 +1000

c++/modules: Fix revealing with using-decls [PR114867]

This patch fixes a couple issues with the current handling of revealing
declarations with using-decls.

Firstly, doing 'remove_node' when handling function overload sets is not
safe, because it not only mutates the OVERLOAD we're walking over but
potentially any other references to this OVERLOAD that are cached from
phase-1 template lookup.  This causes the attached using-17 testcase to
fail because the overload set in 'X::test()' no longer contains the
'ns::f(T)' template once instantiated at the end of the file.

This patch works around this by simply not removing the old declaration.
This does make the overload list potentially longer than it otherwise
would have been, but only when re-exporting the same set of functions in
a using-decl.  Additionally, because 'ovl_insert' always prepends these
newly inserted overloads, repeated exported using-decls won't continue
to add declarations, as the first exported using-decl will be found
before the original (unexported) declaration.

Another, related, issue is that using-decls of GMF entities currently
doesn't mark them as reachable unless they are also exported, and thus
they may not be available in e.g. module implementation units.  We solve
this with a new flag on OVERLOADs set when they are declared within the
module purview.  This starts to run into the more general issue of
handling using-decls of non-functions (see e.g. PR114863) but by just
marking such GMF entities as purview we can work around this for now.

This also allows us to get rid of the special-casing of exported
using-decls in 'add_binding_entity', which was incorrect anyway: a
non-exported using-decl still needs to be emitted anyway if it lives in
the module purview, even if referring to a non-purview item.

PR c++/114867

gcc/cp/ChangeLog:

* cp-tree.h (OVL_PURVIEW_P): New.
(ovl_iterator::purview_p): New.
* module.cc (depset::hash::add_binding_entity): Only ignore
entities not within module purview. Set OVL_PURVIEW_P on new
OVERLOADs for emitted declarations.
(module_state::read_cluster): Imported using-decls are always
in purview, mark as OVL_PURVIEW_P.
* name-lookup.h (enum WMB_Flags): New WMB_Purview flag.
* name-lookup.cc (walk_module_binding): Set WMB_Purview as
needed.
(do_nonmember_using_decl): Don't remove from existing OVERLOADs.
Also reveal non-exported decls. Also reveal 'extern "C"' decls.
Add workaround to reveal non-function decls.
* tree.cc (ovl_insert): Adjust to also set OVL_PURVIEW_P when
needed.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-17_a.C: New test.
* g++.dg/modules/using-17_b.C: New test.
* g++.dg/modules/using-18_a.C: New test.
* g++.dg/modules/using-18_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

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

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

--- Comment #9 from Andrew Pinski  ---
```
float f(float a, float b, float x)
{
  x = a - b;
  float t = 0;
  t = t - x;
  return t/x;
}
```
! HONOR_NANS (type)  && ! HONOR_INFINITIES (type)



```
int f(int a, int b, int A)
{
  A = ~A;
  int t = 0;
  t = t - A;
  return A != 0 ? A : t;
}
```

Is not optimized at -O1 until phiopt3 .

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

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

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

--- Comment #8 from Andrew Pinski  ---
```
int f(int x)
{
x = ~x;
int t = (x >= 0 ? x : 0);
int t1 = (x <= 0 ? -x : 0);
return  t + t1;
}
```

abs(~x)

[Bug c/115311] -fno-builtin-xxx allowing anything for xxx

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

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

--- Comment #1 from Joseph S. Myers  ---
This definitely wouldn't work for glibc; we freely use -fno-builtin- when
e.g. aliasing double and long double functions when the formats are the same,
where GCC gives an error if it has the functions as built-in and so objects to
the incompatible types, and we don't limit this to the functions GCC has as
built-in in a particular version but also use those options for functions that
might be built-in in future (e.g. C23 functions). The number of functions
involved is large, needing configure tests for all of them would be a bad idea.
That is, it's useful to use -fno-builtin- for a valid function name that
might be built-in in future without needing configure tests for whether it's
built-in in a particular version.

[Bug target/115068] RISC-V: Illegal instruction of vfwadd

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:a2fd0812a54cf51520f15e900df4cfb5874b75ed

commit r15-951-ga2fd0812a54cf51520f15e900df4cfb5874b75ed
Author: Robin Dapp 
Date:   Mon May 13 13:49:57 2024 +0200

RISC-V: Do not allow v0 as dest when merging [PR115068].

This patch splits the vfw...wf pattern so we do not emit e.g. vfwadd.wf
v0,v8,fa5,v0.t anymore.

gcc/ChangeLog:

PR target/115068

* config/riscv/vector.md:  Split vfw.wf pattern.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr115068-run.c: New test.
* gcc.target/riscv/rvv/base/pr115068.c: New test.

[Bug analyzer/111567] RFE: support __attribute__((counted_by)) in -fanalyzer

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
Bug 111567 depends on bug 108896, which changed state.

Bug 108896 Summary: provide "element_count" attribute to give more context to 
__builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |15.0

--- Comment #51 from qinzhao at gcc dot gnu.org ---
the patches have been committed into GCC15 today:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-May/403596.html
https://gcc.gnu.org/pipermail/gcc-cvs/2024-May/403597.html
https://gcc.gnu.org/pipermail/gcc-cvs/2024-May/403598.html
https://gcc.gnu.org/pipermail/gcc-cvs/2024-May/403599.html
https://gcc.gnu.org/pipermail/gcc-cvs/2024-May/403600.html

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P4  |P3

[Bug rtl-optimization/114996] [15 Regression] [RISC-V] 2->2 combination no longer occurring

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

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

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

--- Comment #4 from Jeffrey A. Law  ---
Agh.  I was looking in the main config directory, not common/config.  So it all
makes sense now.

So if we go back to your original analysis, I think we can say things are
behaving correctly and we just need to adjust the testcase to either skip on
these targets or add the flag.

[Bug c/115311] New: -fno-builtin-xxx allowing anything for xxx

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

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

Bug ID: 115311
   Summary: -fno-builtin-xxx allowing anything for xxx
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Test case:

echo "" | gcc -xc - -S -fno-builtin-isinfff

This should rather complain that isinfff is not a valid built-in to disable.

Marked as a "c" flaw as the logic is in c-family.

[Bug c++/115296] CTAD fails

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2024-05-31
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Doesn't look like a regression.

#0  error_at (loc=74842051, gmsgid=0x38de910 "size %qE of array exceeds maximum
object size %qE")
at /home/mpolacek/src/gcc/gcc/diagnostic.cc:2137
#1  0x0129b72e in invalid_array_size_error (loc=74842051,
error=cst_size_too_big, 
size=, name=)
at /home/mpolacek/src/gcc/gcc/c-family/c-common.cc:9212
#2  0x0129b8e2 in valid_array_size_p (loc=74842051, t=, name=, 
complain=true) at /home/mpolacek/src/gcc/gcc/c-family/c-common.cc:9263
#3  0x00ee5c74 in compute_array_index_type_loc (name_loc=74842051,
name=, 
size=, complain=3) at
/home/mpolacek/src/gcc/gcc/cp/decl.cc:11653
#4  0x00ee61cd in compute_array_index_type (name=,
size=, 
complain=3) at /home/mpolacek/src/gcc/gcc/cp/decl.cc:11778
#5  0x0111fc4b in tsubst (t=,
args=, 
complain=3, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:16317
#6  0x011217bf in tsubst (t=, args=, complain=3, 
in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16742
#7  0x0111f4a7 in tsubst (t=,
args=, 
complain=3, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:16239
#8  0x0111d85f in tsubst_arg_types (arg_types=, 
args=, end=, complain=3, 
in_decl=) at
/home/mpolacek/src/gcc/gcc/cp/pt.cc:15749
#9  0x0111dc2d in tsubst_function_type (t=, 
args=, complain=3, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:15854
#10 0x011216de in tsubst (t=,
args=, 
complain=3, in_decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:16727
#11 0x01112526 in tsubst_function_decl (t=, 
args=, complain=3, lambda_fntype=,
use_spec_table=false)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:14560
#12 0x0111a255 in tsubst_decl (t=, 
args=, complain=3, use_spec_table=false)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:15131
#13 0x01165243 in alias_ctad_tweaks (tmpl=, 
uguides=) at
/home/mpolacek/src/gcc/gcc/cp/pt.cc:30380
#14 0x01166b4d in deduction_guides_for (tmpl=, 
any_dguides_p=@0x7fffb7ef: true, complain=3) at
/home/mpolacek/src/gcc/gcc/cp/pt.cc:30714
#15 0x01167a17 in do_class_deduction (ptype=, 
tmpl=, init=, 
outer_targs=, flags=1, complain=3) at
/home/mpolacek/src/gcc/gcc/cp/pt.cc:30878
#16 0x01168d77 in do_auto_deduction (type=, 
init=, auto_node=, complain=3, 
context=adc_variable_type, outer_targs=, flags=1, tmpl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:31089

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #14 from Alexandre Oliva  ---
Thanks.

The other problem the testcase in this PR evidenced was that simd_math.h and
simd_scalar.h seem to disregard _GLIBCXX_USE_C99_MATH_TR1, and on newlib-using
targets, that don't declare in math.h enough for this macro to be defined,
compiling the testcase complains about numerous such functions not being
declared in std::.

[Bug target/115289] PPC: Document the machine constraint 'Y' and make it non-internal

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

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

--- Comment #3 from Segher Boessenkool  ---
This needs backports all the way back to GCC 10 (well, as far back as we can
go, anyway :-) ).

[Bug target/115289] PPC: Document the machine constraint 'Y' and make it non-internal

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

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

--- Comment #2 from Segher Boessenkool  ---
Note that the testcase isn't valid C (you cannot validly access an array of
char as a long int), but the problem is there anyway.  I'll try to write a
better testcase.

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

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

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

--- Comment #3 from Florian Weimer  ---
This is just following the previous GCC behavior. For example, with GCC 11:

$ gcc -S -Werror=return-type -std=gnu89 t.c
t.c:1:1: error: return type defaults to ‘int’ [-Werror=return-type]
1 | main () { return 0; }
  | ^~~~

I'm not sure how this is a problem in practice.

Using -Werror=return-type at the distribution level is … problematic. It's why
we split -Werror=return-mismatch from it, and only enabled the latter by
default in GCC 14.

(In reply to Richard Biener from comment #1)
> It's really ugly to force old code to use -fpermissive instead of the
> much cleaner -std=gnu89 just because formerly, with the default of
> newer -std, we only had a warning for the implicit int while with
> -std=gnu89 we now get an error for it.  Did I say I dislike -fpermissive?
> (which also gets you diagnostics for older compilers, so packages building
> in multiple distributions get more difficult to maintain)

We added -fpermissive because we didn't want to change the meaning of
-std=gnu89. You can use it to get old sources to compile. But of course if you
use -Werror=… options at the same time, these old sources might not compile.
And that was true for previous GCC versions as well.

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
(In reply to Martin Jambor from comment #0)
> 
> This reduces the ability to use -std=gnu89 to avoid new errors which
> used to be warnings in environments where -Werror=return-type is the
> default.

In such environments, you don't need an explicit -Werror=return-type. So,
you're asking presumably about testing with < GCC 14 to emulate >= GCC 14
behaviour?

It works fine without the explicit -Werror=return-type on GCC 14.

[Bug c/115310] Option -Werror=return-type is too aggressive with -std=gnu89

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #1 from Richard Biener  ---
The logic that triggers is

  if (warn_about_return_type)
permerror_opt (loc, flag_isoc99 ? OPT_Wimplicit_int
   : (warn_return_type > 0 ? OPT_Wreturn_type
  : OPT_Wimplicit_int),
   "return type defaults to %");

and it's all documented this way.  We have -Werror=return-type to detect
the case "Also warn if execution may reach the end of the function
body, or if the function does not contain any return statement at all."

It would be nice if -std=gnu89 -Werror=return-type -Wno-implicit-int
would disable this particular instance about implicit int typed functions.

It's really ugly to force old code to use -fpermissive instead of the
much cleaner -std=gnu89 just because formerly, with the default of
newer -std, we only had a warning for the implicit int while with
-std=gnu89 we now get an error for it.  Did I say I dislike -fpermissive?
(which also gets you diagnostics for older compilers, so packages building
in multiple distributions get more difficult to maintain)

[Bug target/115307] [avr] Don't expand isinf() like a built-in

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

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

--- Comment #1 from Richard Biener  ---
The issue is that we probably fold isinff early.  On x86 I see already in
.original:

  return !(ABS_EXPR  u<= 3.4028234663852885981170418348451692544e+38);

I think your option is to provide optabs for isinf but make expansion
of them always FAIL; (which is of course a quite ugly way)

[Bug c/115310] New: Option -Werror=return-type is too aggressive with -std=gnu89

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

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

Bug ID: 115310
   Summary: Option -Werror=return-type is too aggressive with
-std=gnu89
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Consider:

 echo 'main () { return 0; }' > t.c

and then

  gcc -S -Werror=return-type t.c

works but

  gcc -S -Werror=return-type -std=gnu89 t.c

causes an error.

This reduces the ability to use -std=gnu89 to avoid new errors which
used to be warnings in environments where -Werror=return-type is the
default.

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 31 May 2024, law at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298
> 
> --- Comment #2 from Jeffrey A. Law  ---
> What still doesn't make sense is why nds32 would be special here.  It doesn't
> do anything special with flag_delete_null_pointer_checks and I don't think it
> uses any of the address space hooks.  So why does nds32 behave differently 
> than
> x86?

/* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */ 
static const struct default_options nds32_option_optimization_table[] =
{  
#if TARGET_LINUX_ABI == 0
  /* Disable -fdelete-null-pointer-checks by default in ELF toolchain.  */
  { OPT_LEVELS_ALL,   OPT_fdelete_null_pointer_checks,
   NULL, 0 },
#endif

that's in common/config/nds32/nds32-common.cc, a place to easily
overlook.  So it should be nds32-elf only.  And yeah, points-to
should use TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID but since it tracks
pointers across integer conversions we have to decide on integer
zero as well where we do not know what address-space is affected.
I guess we could use the default address space and try to be clever
with ADDR_SPACE_CONVERT.  So points-to only checks 
flag_delete_null_pointer_checks at the moment.

[Bug ipa/115309] Simple coroutine based generator is not optimized well

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |ipa

--- Comment #1 from Andrew Pinski  ---
Most of it is a missed inlining.

[Bug tree-optimization/113281] [11/12/13 Regression] Latent wrong code due to vectorization of shift reduction and missing promotions since r9-1590

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

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

--- Comment #30 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:2602b71103d5ef2ef86000cac832b31dad3dfe2b

commit r13-8813-g2602b71103d5ef2ef86000cac832b31dad3dfe2b
Author: Richard Sandiford 
Date:   Fri May 31 15:56:05 2024 +0100

vect: Tighten vect_determine_precisions_from_range [PR113281]

This was another PR caused by the way that
vect_determine_precisions_from_range handles shifts.  We tried to
narrow 32768 >> x to a 16-bit shift based on range information for
the inputs and outputs, with vect_recog_over_widening_pattern
(after PR110828) adjusting the shift amount.  But this doesn't
work for the case where x is in [16, 31], since then 32-bit
32768 >> x is a well-defined zero, whereas no well-defined
16-bit 32768 >> y will produce 0.

We could perhaps generate x < 16 ? 32768 >> x : 0 instead,
but since vect_determine_precisions_from_range was never really
supposed to rely on fix-ups, it seems better to fix that instead.

The patch also makes the code more selective about which codes
can be narrowed based on input and output ranges.  This showed
that vect_truncatable_operation_p was missing cases for
BIT_NOT_EXPR (equivalent to BIT_XOR_EXPR of -1) and NEGATE_EXPR
(equivalent to BIT_NOT_EXPR followed by a PLUS_EXPR of 1).

pr113281-1.c is the original testcase.  pr113281-[23].c failed
before the patch due to overly optimistic narrowing.  pr113281-[45].c
previously passed and are meant to protect against accidental
optimisation regressions.

gcc/
PR target/113281
* tree-vect-patterns.cc (vect_recog_over_widening_pattern): Remove
workaround for right shifts.
(vect_truncatable_operation_p): Handle NEGATE_EXPR and
BIT_NOT_EXPR.
(vect_determine_precisions_from_range): Be more selective about
which codes can be narrowed based on their input and output ranges.
For shifts, require at least one more bit of precision than the
maximum shift amount.

gcc/testsuite/
PR target/113281
* gcc.dg/vect/pr113281-1.c: New test.
* gcc.dg/vect/pr113281-2.c: Likewise.
* gcc.dg/vect/pr113281-3.c: Likewise.
* gcc.dg/vect/pr113281-4.c: Likewise.
* gcc.dg/vect/pr113281-5.c: Likewise.

(cherry picked from commit 1a8261e047f7a2c2b0afb95716f7615cba718cd1)

[Bug c++/115192] [11/12/13 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:0836216693749f3b0b383d015bd36c004754f1da

commit r13-8812-g0836216693749f3b0b383d015bd36c004754f1da
Author: Richard Sandiford 
Date:   Fri May 31 15:56:04 2024 +0100

vect: Fix access size alignment assumption [PR115192]

create_intersect_range_checks checks whether two access ranges
a and b are alias-free using something equivalent to:

  end_a <= start_b || end_b <= start_a

It has two ways of doing this: a "vanilla" way that calculates
the exact exclusive end pointers, and another way that uses the
last inclusive aligned pointers (and changes the comparisons
accordingly).  The comment for the latter is:

  /* Calculate the minimum alignment shared by all four pointers,
 then arrange for this alignment to be subtracted from the
 exclusive maximum values to get inclusive maximum values.
 This "- min_align" is cumulative with a "+ access_size"
 in the calculation of the maximum values.  In the best
 (and common) case, the two cancel each other out, leaving
 us with an inclusive bound based only on seg_len.  In the
 worst case we're simply adding a smaller number than before.

The problem is that the associated code implicitly assumed that the
access size was a multiple of the pointer alignment, and so the
alignment could be carried over to the exclusive end pointer.

The testcase started failing after g:9fa5b473b5b8e289b6542
because that commit improved the alignment information for
the accesses.

gcc/
PR tree-optimization/115192
* tree-data-ref.cc (create_intersect_range_checks): Take the
alignment of the access sizes into account.

gcc/testsuite/
PR tree-optimization/115192
* gcc.dg/vect/pr115192.c: New test.

(cherry picked from commit a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba)

[Bug d/115295] [15 regression] Various gdc testsuite regressions

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-31
   Assignee|ibuclaw at gdcproject dot org  |aoliva at gcc dot 
gnu.org

--- Comment #1 from Rainer Orth  ---
I've now run a reghunt, which again found this patch as the culprit:

commit bdc264a16e327c63d133131a695a202fbbc0a6a0
Author: Alexandre Oliva 
Date:   Thu May 30 02:06:48 2024 -0300

[testsuite] conditionalize dg-additional-sources on target and type

Taking gdc.dg/attr_module.d, which I've use as test for the reghunt, I see

-PASS: gdc.dg/attr_module.d(test for warnings, line 12)
-PASS: gdc.dg/attr_module.d(test for warnings, line 18)
-PASS: gdc.dg/attr_module.d(test for warnings, line 24)
-PASS: gdc.dg/attr_module.d(test for warnings, line 36)
-PASS: gdc.dg/attr_module.d   (test for excess errors)
+UNSUPPORTED: imports/attributes.d: additional-source will not be used to build
attr_module.s
+FAIL: gdc.dg/attr_module.d(test for warnings, line 12)
+FAIL: gdc.dg/attr_module.d(test for warnings, line 18)
+FAIL: gdc.dg/attr_module.d(test for warnings, line 24)
+FAIL: gdc.dg/attr_module.d(test for warnings, line 36)
+FAIL: gdc.dg/attr_module.d   (test for excess errors)

when comparing the gdc.sum files.

Please fix.  This patch should really have gotten way more testing before
committing!

[Bug middle-end/115309] New: Simple coroutine based generator is not optimized well

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 115309
   Summary: Simple coroutine based generator is not optimized well
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following minimal C++ coroutine based generator: 

#include 

namespace {
struct generator {
  struct promise_type {
using handle = std::coroutine_handle;
unsigned value{};

generator get_return_object() noexcept {
  return generator{handle::from_promise(*this)};
}

std::suspend_never initial_suspend() noexcept { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }  
void return_void() noexcept {}
void unhandled_exception() { __builtin_abort(); }

std::suspend_always yield_value(unsigned v) noexcept {
  value = v;
  return {};
}
  };

  ~generator() noexcept { m_coro.destroy(); }
  unsigned operator*() { return m_coro.promise().value; }
private:
  promise_type::handle m_coro;
  explicit generator(promise_type::handle coro) noexcept: m_coro{coro} {}
};

generator generate_1() { co_yield 1; }
}

unsigned test() {
auto gen = generate_1();
return *gen;
}



The expected assembly is:
test():
mov eax, 1
ret

However, trunk GCC with `-O2 -std=c++23` flags generates 60+ instructions with
dynamic merory allocations and function calls.

Godbolt playground: https://godbolt.org/z/6PvfTfx9n


Looks that the main part of the problem is the missing allocation elision for
coroutine.

Note that the same problem arises with the Standard C++ std::generator:
https://godbolt.org/z/EvEPT7d1T

[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:ec92744de552303a1424085203e1311bd9146f21

commit r14-10264-gec92744de552303a1424085203e1311bd9146f21
Author: Uros Bizjak 
Date:   Fri May 31 15:52:03 2024 +0200

alpha: Fix invalid RTX in divmodsi insn patterns [PR115297]

any_divmod instructions are modelled with invalid RTX:

  [(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
 (match_operand:DI 2 "register_operand" "b")])))
   (clobber (reg:DI 23))
   (clobber (reg:DI 28))]

where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.

Wrap input operand with truncate:SI to make machine modes consistent.

PR target/115297

gcc/ChangeLog:

* config/alpha/alpha.md (si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.

gcc/testsuite/ChangeLog:

* gcc.target/alpha/pr115297.c: New test.

(cherry picked from commit 0ac802064c2a018cf166c37841697e867de65a95)

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||martin at martin dot st

--- Comment #11 from Jonathan Wakely  ---
CC Martin Storsjo to see if changing Clang would be possible, or if he has a
better idea for the preprocessor check suggested in comment 9.

It might be that Clang can't pre-define this macro because it has different
values for different mingw/mingw-w64/w64devkit toolchains, and clang wouldn't
know which one to be compatible with a priori.

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #13 from Matthias Kretz (Vir)  ---
I opened PR115308 for the __clang__ issue.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> I would argue that the root cause is that Clang does not conform to the
> platform ABI for mingw-w64, which requires __GXX_TYPEINFO_EQUALITY_INLINE=0
> to be defined.

I stand by this comment though. If Clang wants to be able to use libstdc++
headers on Windows, it should be compatible (i.e. define the same ABI-impacting
macros) with g++ on Windows.

[Bug libstdc++/115308] std::experimental::simd is not convertible to NEON intrinsic type with Clang

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

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

Matthias Kretz (Vir)  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-31

[Bug libstdc++/115308] New: std::experimental::simd is not convertible to NEON intrinsic type with Clang

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

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

Bug ID: 115308
   Summary: std::experimental::simd is not convertible to
NEON intrinsic type with Clang
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: mkretz at gcc dot gnu.org
  Reporter: mkretz at gcc dot gnu.org
  Target Milestone: ---
Target: arm-*-*, aarch64-*-*

std::experimental::parallelism_v2::__int_for_sizeof<1>() returns 'char' instead
of 'signed char' if __clang__ is defined. With -fno-signed-char that's an
observable bug.

https://github.com/VcDevel/std-simd/commit/2f99e2813fc751d2493ad79bc1aec3ce64c7c49e
is the commit that introduced it (before the merge to libstdc++). "Use char for
1
byte and long long for 8 bytes. This is necessary to match the return vector
type of vector compares."
I'm taking a guess here that this is due to GCC applying
-flax-vector-conversions on vector compare results and Clang probably doesn't
do it. But that still doesn't really justify returning 'char' unconditionally
for trait that is supposed to return a signed integer type.

The mask type issue must be solved differently, so that __int_for_sizeof can
return the right type again.

All releases of GCC are affected.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

--- Comment #9 from Jonathan Wakely  ---
Right, for Clang we need:

--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -73,7 +73,7 @@ namespace __cxxabiv1

 // By default follow the old inline rules to avoid ABI changes.
 #ifndef __GXX_TYPEINFO_EQUALITY_INLINE
-#  if !__GXX_WEAK__
+#  if !__GXX_WEAK__ || defined(_WIN32)
 #define __GXX_TYPEINFO_EQUALITY_INLINE 0
 #  else
 #define __GXX_TYPEINFO_EQUALITY_INLINE 1
@@ -188,6 +188,9 @@ namespace std
 #endif

 #if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus > 202002L
+#if ! __GXX_TYPEINFO_EQUALITY_INLINE
+  [[__gnu__::__always_inline__]]
+# endif
   _GLIBCXX23_CONSTEXPR inline bool
   type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
   {


Because otherwise the macro gets defined to 1 and so the always_inline
attribute isn't used.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

[peter0x44 at disroot dot org via Gcc-bugs]

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

--- Comment #8 from Peter Damianov  ---
The suggested fix works for g++, but not clang++.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #9 from Rama Malladi  ---
I wanted us to review this feature implementation given GCC 15 Stage 1
development has started. Thank you.

[Bug middle-end/115307] [avr] Don't expand isinf() like a built-in

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:0ac802064c2a018cf166c37841697e867de65a95

commit r15-943-g0ac802064c2a018cf166c37841697e867de65a95
Author: Uros Bizjak 
Date:   Fri May 31 15:52:03 2024 +0200

alpha: Fix invalid RTX in divmodsi insn patterns [PR115297]

any_divmod instructions are modelled with invalid RTX:

  [(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
 (match_operand:DI 2 "register_operand" "b")])))
   (clobber (reg:DI 23))
   (clobber (reg:DI 28))]

where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.

Wrap input operand with truncate:SI to make machine modes consistent.

PR target/115297

gcc/ChangeLog:

* config/alpha/alpha.md (si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.

gcc/testsuite/ChangeLog:

* gcc.target/alpha/pr115297.c: New test.

[Bug middle-end/115307] New: [avr] Don't expand isinf() like a built-in

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

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

Bug ID: 115307
   Summary: [avr] Don't expand isinf() like a built-in
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

avr-gcc compiles

int isinff (float);

int call_isinff (float f)
{
return isinff (f);
}

like:
call_isinff:
push r12 ;  63  [c=4 l=1]  pushqi1/0
push r13 ;  64  [c=4 l=1]  pushqi1/0
push r14 ;  65  [c=4 l=1]  pushqi1/0
push r15 ;  66  [c=4 l=1]  pushqi1/0
push r28 ;  67  [c=4 l=1]  pushqi1/0
/* prologue: function */
/* frame size = 0 */
/* stack size = 5 */
.L__stack_usage = 5
movw r12,r22 ;  56  [c=4 l=2]  *movsf/0
movw r14,r24
clt  ;  57  [c=4 l=2]  *abssf2/1
bld r15,7
ldi r28,lo8(1)   ;  58  [c=4 l=1]  movqi_insn/1
ldi r18,lo8(-1)  ;  59  [c=4 l=4]  *movsf/4
ldi r19,lo8(-1)
ldi r20,lo8(127)
ldi r21,lo8(127)
movw r24,r14 ;  60  [c=4 l=2]  *movsf/0
movw r22,r12
call __unordsf2  ;  10  [c=12 l=2]  call_value_insn/1
cpse r24,__zero_reg__;  61  [c=0 l=1]  enable_interrupt-3
rjmp .L2
ldi r18,lo8(-1)  ;  52  [c=4 l=4]  *movsf/4
ldi r19,lo8(-1)
ldi r20,lo8(127)
ldi r21,lo8(127)
movw r24,r14 ;  53  [c=4 l=2]  *movsf/0
movw r22,r12
call __lesf2 ;  15  [c=12 l=2]  call_value_insn/1
cp __zero_reg__,r24  ;  77  [c=16 l=1]  *swapped_tstqi
brge .L2 ;  78  [c=4 l=1]  branch
ldi r28,0;  51  [c=4 l=1]  movqi_insn/0
.L2:
ldi r24,lo8(1)   ;  45  [c=4 l=1]  movqi_insn/1
eor r24,r28  ;  46  [c=4 l=1]  *xorqi3
ldi r25,0;  50  [c=4 l=1]  movqi_insn/0
/* epilogue start */
pop r28  ;  70  [c=4 l=1]  popqi
pop r15  ;  71  [c=4 l=1]  popqi
pop r14  ;  72  [c=4 l=1]  popqi
pop r13  ;  73  [c=4 l=1]  popqi
pop r12  ;  74  [c=4 l=1]  popqi
ret  ;  75  [c=0 l=1]  return_from_epilogue

where a simple call to isinff would be mush better.

[Bug tree-optimization/115298] [15 Regression] Various targets failing DSE tests after recent changes

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

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

--- Comment #2 from Jeffrey A. Law  ---
What still doesn't make sense is why nds32 would be special here.  It doesn't
do anything special with flag_delete_null_pointer_checks and I don't think it
uses any of the address space hooks.  So why does nds32 behave differently than
x86?

[Bug tree-optimization/115306] (X + 1) > Y ? -X : 1 pattern does not handle X=~X nor X = -X;

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-31
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Mine, filing as I will get back to this in a few but want to finish up a
different patch.

[Bug tree-optimization/115306] New: (X + 1) > Y ? -X : 1 pattern does not handle X=~X nor X = -X;

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

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

Bug ID: 115306
   Summary: (X + 1) > Y ? -X : 1 pattern does not handle X=~X nor
X = -X;
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

The new pattern:
/* (1 - X) > Y ? X : 1 simplifies to (-X) >= Y ? X : 1 when
   X is unsigned for the same logic as above, just replace X with -X.  */
(simplify
 (cond (gt (minus integer_onep @0) @1) @0 integer_onep@2)
 (if (TYPE_UNSIGNED (type))
  (cond (ge (negate @0) @1) @0 @2)))

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

--- Comment #7 from Jonathan Wakely  ---
This is the fix I'm suggesting:

--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -188,6 +188,9 @@ namespace std
 #endif

 #if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus > 202002L
+# if ! __GXX_TYPEINFO_EQUALITY_INLINE
+  [[__gnu__::__always_inline__]]
+# endif
   _GLIBCXX23_CONSTEXPR inline bool
   type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
   {

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #12 from Matthias Kretz (Vir)  ---
I noticed that weird special case for __clang__ and don't recall why it was
needed. I should dig up the reason or remove it, I guess.

[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Peter Damianov from comment #5)
> #include 
> int main() { return typeid(0) == typeid(0); }
> 
> The following reproduces for me, although strangely only with -std=c++23 and
> -static-libstdc++.

Because it's constexpr (and so always inline) in C++23, and not in C++20.

I think I probably meant to type c++23 in comment 3.

[Bug target/115282] [15 regression] gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c fails after r15-812-gc71886f2ca2e46

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Target|powerpc64-linux-gnu |powerpc64*-linux-gnu
 Status|NEW |ASSIGNED

--- Comment #3 from Richard Biener  ---
Ah, this is probably a case where we need to split because CSE causes us to
associate operations differently so SLP build for the whole thing fails.

The three-vector permute issue will go away when I manage to finish the load
part of the full SLP enablement.

It also fails on LE.  It's the

node 0x39913f0 (max_nunits=4, refcnt=2) vector(4) unsigned int
op template: _14 = in[_13];
stmt 0 _14 = in[_13];
load permutation { 6 }

note.  We split the 8-group into 6 and two times 1 element.  This needs
an intermediate (interleaving) permute and indeed the load part will fix it.

I suggest to leave this failing until then.  The loop is still vectorized
but using non-SLP full interleaving until then.

[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Hans-Peter Nilsson  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #9)
>> > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > > Uni-Bielefeld.DE> ---
>> >> --- Comment #6 from Hans-Peter Nilsson  ---
>> [...]
>> >> versions.)  BTW, it'd be nice to know it it reproduces for sparc-linux
>> >> as well.
>> >
>> > I happen to have a Linux/sparc64 LDom around: I'll give it a whirl.
>> 
>> The failure is even earlier here: in a sparc64-unknown-linux-gnu
>> bootstrap, building a libstdc++ .gch file in stage 2 breaks:
>
> Great, thanks!  That means that tricking my pc into believing it's a sparc by
> means of using the binfmt machinery that Jeff mentioned in the thread where I
> mentioned the revert on gcc-patches, would work.  (I don't have the details 
> and
> don't remember if I'd actually tried it, certainly not recently; I just know
> about the concept.)

I can't help but wonder if this wouldn't be a total waste of your time:
considering what the qemu wiki docments for SPARC support

https://wiki.qemu.org/Documentation/Platforms/SPARC

seems not too encouraging for 64-bit systems.  When I think about what
it took myself to get recent macOS working on qemu-kvm (although the
procedure is resonably well documented, with firmware and all
available), I'd consider such an attempt a positive nightmare.

When all it takes for you to either get your ssh client working to
access a ready-made and not too slow SPARC system (or in the worst case,
build OpenSSH from source), I know which route I'd take ;-)

> What's not so great is that the described reproducer is a bootstrap, so the
> debug situation is unpleasant.  The first step I'd do, would be to just do a
> cross-build (or native --disable-bootstrap) and just run the testsuite
> before/after the patch-set (or just 933ab59c59bdc1) and see if the problem
> manifests there.
>
> It's also not great (from the view of gcc targeting architectures with
> delay-slots) that this isn't at the top of my queue anymore, since the
> immediate situation was resolved; as mentioned I committed the revert.  I'll
> get to it eventually, but if someone is intrigued enough by the prospect of a
> 0.36%-ish performance improvement (see commit log for the culprit commit) to 
> do
> such a --disable-bootstrap regtest, that'd help. :)

I've tried that now on both

* sparc-sun-solaris2.11 (c and c++ only): no additional testsuite
  failures are apparent there, which is not too astonishing given that
  the bootstrap failure occurs in stage 3, suggesting a mis-compiled
  stage 2 cc1plus, and

* sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite
  failures all over the place, but I'd have to perform another bootstrap
  with your patches removed to make an exact comparison.

[Bug tree-optimization/115303] gcc.dg/vect/pr112325.c FAILs

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

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

--- Comment #2 from Richard Biener  ---
Yeah, if requiring vect_shift works for you that's pre-approved.

[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail

--- Comment #2 from Richard Biener  ---
It should only need vect32 - basically I assumed the target can compose the
64bit vector from two 32bit elements.  But it might be that for this to work
the loads would need to be aligned.

What is needed is char-to-short unpacking and vector composition.  Either
composing V2SImode or V8QImode from two V4QImode vectors.

Does the following help?

diff --git a/gcc/testsuite/gcc.dg/vect/slp-gap-1.c
b/gcc/testsuite/gcc.dg/vect/slp-gap-1.c
index 36463ca22c5..08942380caa 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-gap-1.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-gap-1.c
@@ -4,6 +4,9 @@
 typedef unsigned char uint8_t;
 typedef short int16_t;
 void pixel_sub_wxh(int16_t * __restrict diff, uint8_t *pix1, uint8_t *pix2) {
+  diff = __builtin_assume_aligned (diff, __BIGGEST_ALIGNMENT__);
+  pix1 = __builtin_assume_aligned (pix1, 4);
+  pix2 = __builtin_assume_aligned (pix2, 4);
   for (int y = 0; y < 4; y++) {
 for (int x = 0; x < 4; x++)
   diff[x + y * 4] = pix1[x] - pix2[x];

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||i686-darwin9
   Target Milestone|--- |15.0

[Bug tree-optimization/115278] [13/14 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[13/14/15 Regression]   |[13/14 Regression]
   |-ftree-vectorize optimizes  |-ftree-vectorize optimizes
   |away volatile write on  |away volatile write on
   |x86_64 since r13-3219   |x86_64 since r13-3219
  Known to work||15.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:65dbe0ab7cdaf2aa84b09a74e594f0faacf1945c

commit r15-941-g65dbe0ab7cdaf2aa84b09a74e594f0faacf1945c
Author: Richard Biener 
Date:   Fri May 31 10:14:25 2024 +0200

tree-optimization/115278 - fix DSE in if-conversion wrt volatiles

The following adds the missing guard for volatile stores to the
embedded DSE in the loop if-conversion pass.

PR tree-optimization/115278
* tree-if-conv.cc (ifcvt_local_dce): Do not DSE volatile stores.

* g++.dg/vect/pr115278.cc: New testcase.

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #11 from Alexandre Oliva  ---
it's the first test for __clang__ in __int_for_sizeof(), that ends up returning
char() rather than _Schar().

I guess that places the problem entirely on our need for defining __clang__ :-(

Sorry about the noise.

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Eric Botcazou from comment #7)
> They might come from https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r15-615
> and, in particular, the change made to libgnarl/s-osinte__darwin.ads, in
> which case the way out would be to duplicate libgnat/s-oslock__posix.ads
> into libgnat/s-oslock__darwin.ads, add back the sig field and remove the
> alignment clause there, and then do the substitution on line 2749 of
> Makefile.rtl.

thanks for the pointer - if I have a chance, will take a look over the weekend.

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #10 from Alexandre Oliva  ---
FWIW, I can trigger the problem on arm-eabi (and presumably also on
aarch64-elf, but I haven't tried that) with -D__clang__.

(our vxworks toolchains have to define that macro, for complicated reasons)

here's a reduced testcase:

arm-eabi-g++ ~/pr114803.cc -mfpu=neon -mfloat-abi=hard -O0 -std=gnu++17
-D__clang__ [-funsigned-char]

include 

template 
void
test()
{
  using V = std::experimental::simd >;
  if constexpr (std::is_signed_v)
static_cast(V{});
  else
static_cast(V{});
}

int main()
{
  test();
}

pr114803.cc: In instantiation of ‘void test() [with T = char]’:
pr114803.cc:16:   required from here
pr114803.cc:11: error: invalid ‘static_cast’ from type
‘std::experimental::parallelism_v2::simd >’ to type
‘uint8x16_t’

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

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

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

--- Comment #7 from Eric Botcazou  ---
They might come from https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r15-615 and,
in particular, the change made to libgnarl/s-osinte__darwin.ads, in which case
the way out would be to duplicate libgnat/s-oslock__posix.ads into
libgnat/s-oslock__darwin.ads, add back the sig field and remove the alignment
clause there, and then do the substitution on line 2749 of Makefile.rtl.

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

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

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

--- Comment #6 from Iain Sandoe  ---
a quick look at current results for other platform versions suggests that:

 * x86_64-darwin10 [64b runtimes, but 32b kernel] is also affected but
 * from darwin11+ [64 kernel] the main fail is FAIL:   cxa4001 which is a known
issue.

my darwin10 box is v. slow (and I lost a bunch of runs on Weds from a power
outage) but will post the 889 results for Darwin10 when it's done.

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9

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

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

Eric Botcazou  changed:

   What|Removed |Added

Version|14.0|15.0
 Status|UNCONFIRMED |NEW
Summary|[15 Regression] many (162)  |[15 Regression] many (162)
   |acats regressions on|acats regressions on
   |i686-darwin9.   |i686-darwin9
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-31
 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou  ---
Thanks for creating the PR.

[Bug ada/115292] [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Iain Sandoe  ---
(In reply to Eric Botcazou from comment #1)
> Can you post the list of ACATS regressions on the 32-bit host?

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

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.

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

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

--- Comment #4 from Iain Sandoe  ---
Created attachment 58322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58322&action=edit
between 856 and 889

likewise.

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.

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

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

--- Comment #3 from Iain Sandoe  ---
Created attachment 58321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58321&action=edit
between 792 and 856

likewise

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.

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

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

--- Comment #2 from Iain Sandoe  ---
Created attachment 58320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58320&action=edit
between 644 and 792

[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.

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

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

--- Comment #1 from Iain Sandoe  ---
Created attachment 58319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58319&action=edit
between 386 and 644

the results have been somewhat turbulent - so posting the ranges I have in case
it helps

[Bug ada/115305] New: [15 Regression] many (162) acats regressions on i686-darwin9.

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

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

Bug ID: 115305
   Summary: [15 Regression] many (162) acats regressions on
i686-darwin9.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58318&action=edit
totals between r15-386-889

firstly, this is not a high priority target (even for me) - but I guess these
regressions do indicate some underlying omission or similar.

up to r15-386 darwin has clean acats results (both 32b and 64b hosts).

Unfortunately between r15-386 and 644 there was a bootstrap break for Ada on
i686-darwin, so the revision history is fragmented

I will attach diffs for the revision ranges I have; listing 162 fails here can
be done - but not sure it would be helpful.

Where we are testing an unpatched trunk/branch we are now pushing the results
to GCC's bunsen project:
https://builder.sourceware.org/testruns/?commitishes=&has_expfile_glob=&has_trsfile_glob=&has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=iains%2F*&has_keyvalue2_k=omnitest.results&has_keyvalue2_op=glob&has_keyvalue2_v=*&order_by=testrun.authored.time&order=desc&limit=1000&offset=0&offset=0

the tag is :

 iains ///-

so you can also poke at the detailed logs there if it's helpful.

===

There are regressions also on other earlier platform versions; I will also try
to identify them.

[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())

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

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

--- Comment #7 from Jonathan Wakely  ---
The patch needs a little refactoring to share code with std::stacktrace, but it
will be fixed soon.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

--- Comment #8 from avieira at gcc dot gnu.org ---
Thanks! Missed that Andrew.

> It's a low-level worker, it relies on the caller to have performed sanity
> checking on the stmt itself.  I'm testing a patch doing that.

OK, no strong opinion here, but do you reckon we should somehow make that
clearer in terms of comments for this function? I was trying to think of
whether there's a data-flow based reason to ever consider a write of a volatile
ok for elimination, which is how I'd first interpret the meaning of the
classification of this function. But I can't.

[Bug target/115282] [15 regression] gcc.dg/vect/costmodel/ppc/costmodel-slp-12.c fails after r15-812-gc71886f2ca2e46

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-31
 Status|UNCONFIRMED |NEW
 CC||linkw at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Kewen Lin  ---
(In reply to Richard Biener from comment #1)
> I don't see a good reason why, but I don't have a BE cross around to check
> myself.  Does BE vect maybe not have unsigned integer vector multiplication
> support?

BE should have int vector mult too, I noticed it's guarded with TARGET_ALTIVEC.

The first loop (line 17) causes the difference, previously it did the splitting
like: 

test.c:16:17: note:   Splitting SLP group at stmt 6
test.c:16:17: note:   Split group into 6 and 2

but now it won't and then seems to fail due to that:

test.c:16:17: note:   ==> examining statement: _14 = in[_13];
test.c:16:17: missed:   permutation requires at least three vectors _2 =
in[_1];
test.c:16:17: missed:   unsupported load permutation
test.c:25:14: missed:   not vectorized: relevant stmt not supported: _14 =
in[_13];
test.c:16:17: note:   Cannot vectorize all-constant op node 0x140dd450
test.c:16:17: note:   removing SLP instance operations starting from: out[_1] =
_17;
test.c:16:17: missed:  unsupported SLP instances
test.c:16:17: note:  re-trying with SLP disabled
test.c:16:17: note:  vectorization_factor = 4, niters = 8

I can't figure out why it can pass on LE, so I did a test on LE and found it
fails on LE too!?

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

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

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

--- Comment #9 from Matthias Kretz (Vir)  ---
(In reply to Alexandre Oliva from comment #7)
> FWIW, since the backport, this test started failing in gcc-13 on arm and
> aarch64 targets.  Presumably this affects earlier branches as well.
> 
> .../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: In
> instantiation of 'void maybe_test() [with T = char]':
> .../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc:87: 
> required from here
> .../libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc:68:
> error: invalid 'static_cast' from type 'V' {aka
> 'std::experimental::parallelism_v2::simd std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16> >'} to type
> 'uint8x16_t'

I tested on aarch64-linux-gnu and arm-linux-gnueabi before and after the
backport and there were no regressions. What target do I need to add to my
list?

The specific error you report is rather puzzling. Basically an integral, sizeof
1, not signed char, when packed into a simd is not explicitly convertible
to uint8x16_t. The simd is defined to be convertible to its underlying
intrinsic type which is determined in
libstdc++-v3/include/experimental/bits/simd.h and goes like this:

'char' has no full specialization for '__intrinsic_type' (unless
'char' is the *same* type as 'signed char' or 'unsigned char') and thus picks
the partial specialization of __intrinsic_type. This in turn determines the
corresponding signed integer type to be 'signed char'. Depending on whether
'is_unsigned_v' is true, it subsequently applies 'make_unsigned_t'. It
then uses the __intrinsic_type_t of that, which is either int8x16_t or
uint8x16_t depending on 'is_unsigned_v'.

This

[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 58317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58317&action=edit
32-bit sparc-sun-solaris2.11 slp-gap-1.c.179t.vect

[Bug tree-optimization/115304] New: gcc.dg/vect/slp-gap-1.c FAILs

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

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

Bug ID: 115304
   Summary: gcc.dg/vect/slp-gap-1.c FAILs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

The new gcc.dg/vect/slp-gap-1.c test FAILs on 32 and 64-bit Solaris/SPARC:

+FAIL: gcc.dg/vect/slp-gap-1.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "{_[0-9]+, 0" 6
+FAIL: gcc.dg/vect/slp-gap-1.c scan-tree-dump-times vect "{_[0-9]+, 0" 6

The dump has

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21: note: 
 ==> examining statement: _34 = *pix1_72;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   unsupported vect permute { 0 1 2 3 8 9 10 11 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:9:29:
missed:   not vectorized: relevant stmt not supported: _34 = *pix1_72;

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21: note: 
 ==> examining statement: _34 = *pix1_72;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   no array mode for V8QI[16]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   no array mode for V8QI[16] 
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   extract even/odd not supported by target
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:7:21:
missed:   not falling back to elementwise accesses
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-gap-1.c:9:29:
missed:   not vectorized: relevant stmt not supported: _34 = *pix1_72;

IIUC the test needs both vect_perm and vect_extract_even_odd.

[Bug tree-optimization/115303] gcc.dg/vect/pr112325.c FAILs

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 58316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58316&action=edit
32-bit sparc-sun-solaris2.11 pr112325.c.179t.vect

[Bug tree-optimization/115303] gcc.dg/vect/pr112325.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/115303] New: gcc.dg/vect/pr112325.c FAILs

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

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

Bug ID: 115303
   Summary: gcc.dg/vect/pr112325.c FAILs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-sun-solaris2.11

The new gcc.dg/vect/pr112325.c test FAILs on 32 and 64-bit Solaris/SPARC:

+FAIL: gcc.dg/vect/pr112325.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/pr112325.c scan-tree-dump-times vect "vectorized 1 loops" 1

The dump has

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr112325.c:43:27:
missed:   op not supported by target.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr112325.c:44:45:
missed:   not vectorized: relevant stmt not supported: _6 = qh.1_5 >> j_68;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr112325.c:43:27:
missed:  bad operation or unsupported loop bound.
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr112325.c:43:27: note: 
* Analysis  failed with vector mode SI

IIUC the test needs vect_shift.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to avieira from comment #5)
> > I think we fixed similar bug on the read side.
> 
> I don't have the best memory, but the one I can remember is PR 111882, where
> we had the SAVE_EXPR. And the the fix was to not lower bitfields with
> non-constant offsets.

The one which Richard was thinking of was PR 114197 which I linked in the see
also.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

--- Comment #6 from Richard Biener  ---
(In reply to avieira from comment #5)
> > I think we fixed similar bug on the read side.
> 
> I don't have the best memory, but the one I can remember is PR 111882, where
> we had the SAVE_EXPR. And the the fix was to not lower bitfields with
> non-constant offsets.
> 
> Should dse_classify_store not return *_DEAD for volatiles?

It's a low-level worker, it relies on the caller to have performed sanity
checking on the stmt itself.  I'm testing a patch doing that.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org

--- Comment #5 from avieira at gcc dot gnu.org ---
> I think we fixed similar bug on the read side.

I don't have the best memory, but the one I can remember is PR 111882, where we
had the SAVE_EXPR. And the the fix was to not lower bitfields with non-constant
offsets.

Should dse_classify_store not return *_DEAD for volatiles?

[Bug lto/115300] gcc 14 cannot compile itself on Windows when bootstrap-lto is specified

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

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

--- Comment #3 from Richard Biener  ---
Can you try --disable-plugin?  It might be the mingw equivalent of exporting
all dynamic symbols from the cc1 binary runs into target limitations?  It looks
like the default on *-*-mingw* is disabled though ...

[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
Created attachment 58315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58315&action=edit
Proposed patch

any_divmod instructions are modelled with invalid RTX:

  [(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
 (match_operand:DI 2 "register_operand" "b")])))
   (clobber (reg:DI 23))
   (clobber (reg:DI 28))]

SImode divmod_operator (div,mod,udiv,umod) has DImode operands.

The patch adds truncate:SI to the input operand to make machine modes
consistent.

[Bug tree-optimization/113281] [11/12/13 Regression] Latent wrong code due to vectorization of shift reduction and missing promotions since r9-1590

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

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

--- Comment #29 from Robin Dapp  ---
Just to document again:  The test case should not be vectorized and at some
point we will adjust the cost model so it is not going to be.  I'd prefer to
base that decision on real uarchs rather than adjust the generic cost model
right away though.

[Bug tree-optimization/115278] [13/14/15 Regression] -ftree-vectorize optimizes away volatile write on x86_64 since r13-3219

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
It's actually a latent issue, unrelated to bitfields?  We elide the store via

  tree lhs = gimple_get_lhs (stmt);
  ao_ref write;
  ao_ref_init (&write, lhs);

  if (dse_classify_store (&write, stmt, false, NULL, NULL, latch_vdef)
  == DSE_STORE_DEAD)
delete_dead_or_redundant_assignment (&gsi, "dead");

but that fails to guard against volatiles.