[Bug libstdc++/115209] New: The implementation of concat_view refers to p2542r7 rather than the p2542r8

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 115209
   Summary: The implementation of concat_view refers to p2542r7
rather than the p2542r8
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

It seems that R8 is the final version. Not sure why libstdc++ refers to R7,
which makes some updates of R8 not integrated, such as the new relaxed
constraints of operator-(const iterator& x, default_sentinel_t).

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|--- |15.0

[Bug testsuite/115140] [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Host|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu,  |
   |*-*-solaris2.11 |
  Build|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu,  |
   |*-*-solaris2.11 |
 CC||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Target|powerpc64-linux-gnu,|
   |powerpc64le-linux-gnu,  |
   |*-*-solaris2.11 |
   Last reconfirmed||2024-05-24
 Ever confirmed|0   |1

--- Comment #3 from Thomas Schwinge  ---
So the PASS -> FAIL regressions are due to parloops (for '-O2') no longer
parallelizing the simple OpenACC 'kernels' construct at line 185 (and two
more):

int x[N];
#pragma acc kernels
{
  for (int i = 0; i < N; ++i)
x[i] = i * i;
}

(In reply to Richard Biener from comment #1)
> Looks like a testsuite artifact?
> 
> volatile // TODO PR90488
> static int state = -1;
> 
> I've not looked as to why/how we are getting that to influence points-to
> solutions (note as we track also integers volatile on non-pointers can
> matter).

Yeah, it's not obvious to me how that 'state' variable would have such an
effect -- but I've not yet 'diff'ed the dumps.

On the other hand, it's highly likely that there is some relation, as no other
OpenACC 'kernels' test cases did regress.

[Bug middle-end/115208] [15 Regression] Memory consumption get extremely high after r15-809

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #1 from Haochen Jiang  ---
Forgot to mention, the memory consumption collection is collected on x86_64
target in order to get the test finished. Therefore, we could debug on x86_64.

[Bug middle-end/115208] New: [15 Regression] Memory consumption get extremely high after r15-809

[haochen.jiang at intel dot com via Gcc-bugs]

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

Bug ID: 115208
   Summary: [15 Regression] Memory consumption get extremely high
after r15-809
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

I currently got some testcase fail on i686 target.

New failures:
FAIL: gcc.target/i386/avx-1.c (test for excess errors)
FAIL: gcc.target/i386/sse-13.c (test for excess errors)
FAIL: gcc.target/i386/sse-23.c (test for excess errors)
FAIL: gcc.target/i386/sse-24.c (test for excess errors)
FAIL: gcc.target/i386/sse-25.c (test for excess errors)
FAIL: gcc.target/i386/sse-26.c (test for excess errors)

>From my investigation, it happened after the commit series r15-797 to r15-809.

After those commits, the memory consumption got very high.

I ran with:
make check-gcc RUNTESTFLAGS="i386.exp=avx-1.c --target_board='unix{-m32}'"

Before those commits, the memory usage:

Memory usage summary: heap total: 245591, heap peak: 205651, stack peak: 13824
 total calls   total memory   failed calls
 malloc|402 238998  0
realloc| 14   5416  0  (nomove:7, dec:0, free:0)
 calloc|  6   1177  0
   free|224  57705

After those commits, the memory usage:

Memory usage summary: heap total: 17691252434, heap peak: 7691866921, stack
peak: 51056
 total calls   total memory   failed calls
 malloc|   6961407515426859093  0
realloc| 260731   17538362  0  (nomove:88951, dec:19349,
free:0)
 calloc|   11132073 2246854979  0
   free|   81105599 9997315310


Since i686 target gets very limited memory, it crashed those targets.

[Bug c++/115207] New: [constexpr] constexpr assignment rejected as non const on self-assignment test

[nov.ondrej at gmail dot com via Gcc-bugs]

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

Bug ID: 115207
   Summary: [constexpr] constexpr assignment rejected as non const
on self-assignment test
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nov.ondrej at gmail dot com
  Target Milestone: ---

Hello

Following code fails to compile
//--
#include 
#include 

class value {
public:
int v;
constexpr value():v(0) {}
constexpr value(int v):v(v) {}

constexpr value &operator=(const value &other) {
if (this != &other) {
std::destroy_at(this);
std::construct_at(this, other.v);
}
return *this;
}
};

template
class array {
public:

constexpr array(const std::initializer_list &items) {
std::copy(items.begin(), items.end(), std::begin(_items));
}

protected:
value _items[N] = {};
};

template
array(const value (&)[N]) -> array;

constexpr array test ({1,2,3,4});
//--

:37:32:   in 'constexpr' expansion of 'array<4>(const
std::initializer_list{((const value*)(& const value [4]{value{1},
value{2}, value{3}, value{4}})), 4})'
:25:18:   in 'constexpr' expansion of 'std::copy((& items)->std::initializer_list::begin(), (&
items)->std::initializer_list::end(), std::begin(((array<4>*)this)->array<4>::_items))'
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_algobase.h:651:7:
  in 'constexpr' expansion of 'std::__copy_move_a(std::__miter_base(__first), std::__miter_base(__last), __result)'
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_algobase.h:556:31:
  in 'constexpr' expansion of 'std::__copy_move_a1(std::__niter_base(__first), std::__niter_base(__last), std::__niter_base(__result))'
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_algobase.h:548:42:
  in 'constexpr' expansion of 'std::__copy_move_a2(__first, __last, __result)'
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_algobase.h:518:12:
  in 'constexpr' expansion of 'std::__copy_move::__copy_m(__first,
__last, __result)'
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/stl_algobase.h:403:18:
  in 'constexpr' expansion of '__result->value::operator=((* __first))'
:11:18: error: '(((const value*)(&)) != ((const value*)(&
test.array<4>::_items)))' is not a constant expression
   11 | if (this != &other) {
  | ~^
Compiler returned: 1

//--


Godbolt link: https://godbolt.org/z/zzKs58qzv

The above code is compiled correctly in both clang and msvc.

Thank you

[Bug c++/115206] New: ICE: segfault in code involving C++ modules, std::format and std::println

[sentabel at gmail dot com via Gcc-bugs]

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

Bug ID: 115206
   Summary: ICE: segfault in code involving C++ modules,
std::format and std::println
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sentabel at gmail dot com
  Target Milestone: ---

Created attachment 58279
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58279&action=edit
produced with -freport-bug

This is a segfault I encountered when working through some code exercises from
Marc Gregoire's 6th edition Professional C++ book. I have attached the output
of -freport-bug as a text file.

The offending compile command from my CMake invocation seems to be as follows:
/opt/homebrew/bin/g++-14   -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG
-save-temps -freport-bug -O3 -DNDEBUG -std=gnu++23 -arch arm64 -isysroot
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk -MD -MT
Chapter2/CMakeFiles/KeyValue.dir/KeyValueClass.cxx.o -MF
Chapter2/CMakeFiles/KeyValue.dir/KeyValueClass.cxx.o.d -fmodules-ts
-fmodule-mapper=Chapter2/CMakeFiles/KeyValue.dir/KeyValueClass.cxx.o.modmap -MD
-fdeps-format=p1689r5 -x c++ -o
Chapter2/CMakeFiles/KeyValue.dir/KeyValueClass.cxx.o -c
/Users/abelsen/Documents/Professional_CPP_Sixth_Edition_Exercises_Solutions/Chapter2/KeyValueClass.cxx

The output of g++-14 -v on my Mac is as follows:
Using built-in specs.
COLLECT_GCC=g++-14
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/14.1.0/bin/../libexec/gcc/aarch64-apple-darwin23/14/lto-wrapper
Target: aarch64-apple-darwin23
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-14
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 14.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin23
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.0 (Homebrew GCC 14.1.0)

Please let me know if there's any additional information I could provide to
make debugging this issue simpler.

[Bug c++/104678] pointer to member cannot be passed as template argument after derived/base cast

[3y3p4tch at protonmail dot com via Gcc-bugs]

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

--- Comment #4 from Saurav Yadav <3y3p4tch at protonmail dot com> ---
@jason can you please have this checked? I can reproduce the issue on current
trunk

[Bug sanitizer/115205] ICE when using -fsanitize=hwaddress

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I think this will fix it:
```
diff --git a/gcc/asan.cc b/gcc/asan.cc
index 9e0f51b1477..c684ca6d366 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -4276,6 +4276,7 @@ asan_instrument (void)
 {
   if (hwasan_sanitize_p ())
 {
+  initialize_sanitizer_builtins ();
   transform_statements ();
   return 0;
 }

```

Let me test that.

[Bug sanitizer/115205] ICE when using -fsanitize=hwaddress

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|fortran |sanitizer

--- Comment #3 from Andrew Pinski  ---
Someone is missing calling initialize_sanitizer_builtins . Maybe it is in the
sanitizers.

[Bug fortran/115205] ICE when using -fsanitize=hwaddress

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|sanitizer   |fortran
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-24

--- Comment #2 from Andrew Pinski  ---
BUILT_IN_HWASAN_STORE8 is not being built.

This is a fortran front-end issue after all.
gfc_init_builtin_functions should be handling the sanitizers.

[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs

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

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

--- Comment #4 from Hongtao Liu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> To investigate further, I've added comparison functions to a reduced
> version of pr106010-7b.c, with
> 
> void
> cmp_epi8 (_Complex unsigned char* a, _Complex unsigned char* b)
> {
>   for (int i = 0; i != N; i++)
> if (a[i] != b[i])
>   {
>   printf ("cmp_epi8: i = %d: a[i].r = %x a[i].i = %x b[i].r = %x b[i].i =
> %x\n",
>   i, __real__ a[i], __imag__ a[i], __real__ b[i], __imag__ b[i]);
>   }
> }
> 
> This shows (when using _Complex unsigned char since on Solaris, char is
> signed by default)
> 
> cmp_epi8: i = 76: a[i].r = 0 a[i].i = 0 b[i].r = 88 b[i].i = 33
> cmp_epi8: i = 77: a[i].r = 0 a[i].i = 0 b[i].r = 6 b[i].i = 8
> cmp_epi8: i = 80: a[i].r = 0 a[i].i = 0 b[i].r = 3 b[i].i = 0
> 
> I've also noticed that the test result depends on the implementation of
> malloc used:
> 
> * With Solaris libc malloc, libmalloc, and watchmalloc, the test aborts.
> 
> * However, when using one of libbsdmalloc, libmapmalloc, libmtmalloc, or
>   libumem, the test works.
> 
> However, ISTM that the test is simply bogus: in avx_test
> 
> * epi8_src, epi8_dst are allocated with malloc, buffer contents undefined
> 
> * epi8_dst is cleared
> 
> * epi8_dst is initialized from p_init
> 
> * in foo_epi8, epi8_src[0] (an undefined value) is copied into first N
>   elements of epi8_dst
> 
> * epi8_dst is compared to epi8_src (with the remaining members of epi8_src
>   still undefined)
uoops, does below patch fix the testcase on Solaris/x86?

   memcpy (pd_src, p_init, 2 * N * sizeof (double));
-  memcpy (ps_dst, p_init, 2 * N * sizeof (float));
-  memcpy (epi64_dst, p_init, 2 * N * sizeof (long long));
-  memcpy (epi32_dst, p_init, 2 * N * sizeof (int));
-  memcpy (epi16_dst, p_init, 2 * N * sizeof (short));
-  memcpy (epi8_dst, p_init, 2 * N * sizeof (char));
+  memcpy (ps_src, p_init, 2 * N * sizeof (float));
+  memcpy (epi64_src, p_init, 2 * N * sizeof (long long));
+  memcpy (epi32_src, p_init, 2 * N * sizeof (int));
+  memcpy (epi16_src, p_init, 2 * N * sizeof (short));
+  memcpy (epi8_src, p_init, 2 * N * sizeof (char));

> 
> Why on earth would the rest of epi8_dst and epi8_src be identical if
> epi8_src was never initialized?
Guess, epi8_src is all zero, and epi8_dst if set as epi8_src[0] by foo_epi8.

[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/109561] -Wmaybe-uninitialized false positive with std::optional

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to Richard Biener from comment #1)
> Confirmed with GCC 13.  Almost always a missed optimization in the end ...

Pff, maybe I should report more of them then. I often end up forgetting and not
bothering to come back to it...

[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure

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

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

--- Comment #5 from David Malcolm  ---
Created attachment 58278
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58278&action=edit
WIP patch to split out the classes into the c-family

I tried the attached patch, to move the pertinent code to the c-family
subdirectory and its objects.

I tried bootstrapping with this on cfarm119.  It seemed to get further, but is
now failing here:

[...snip...]
ar  -X64 x ../pthread/ppc64/libgcc/libgcc_s.a shr.o
ar: 0707-100 ../pthread/ppc64/libgcc/libgcc_s.a does not exist.
make[3]: *** [../../../src/libgcc/config/rs6000/t-slibgcc-aix:101: all] Error 1
make[3]: Leaving directory
'/scratch/dmalcolm/gcc-bugfixing/build/powerpc-ibm-aix7.3.1.0/libgcc'
make[2]: *** [Makefile:18469: all-stage2-target-libgcc] Error 2
make[2]: Leaving directory '/scratch/dmalcolm/gcc-bugfixing/build'
make[1]: *** [Makefile:23365: stage2-bubble] Error 2
make[1]: Leaving directory '/scratch/dmalcolm/gcc-bugfixing/build'
make: *** [Makefile:1103: all] Error 2


That said, I forgot to do this within a "screen" and lost my ssh connection a
few times, and had to rerun make each time, so maybe I messed something up
there?

[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 114947, which changed state.

Bug 114947 Summary: [modules] ICE when processing class-scope constrained 
partial specialisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114947

   What|Removed |Added

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

[Bug c++/114947] [modules] ICE when processing class-scope constrained partial specialisations

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

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

[Bug c++/114947] [modules] ICE when processing class-scope constrained partial specialisations

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

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

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

https://gcc.gnu.org/g:7fa0ffa4f789683ba80e93cd10546cb7bd2c3d8a

commit r15-810-g7fa0ffa4f789683ba80e93cd10546cb7bd2c3d8a
Author: Nathaniel Shead 
Date:   Sun May 12 22:31:01 2024 +1000

c++/modules: Ensure all partial specialisations are tracked [PR114947]

Constrained partial specialisations aren't all necessarily tracked on
the instantiation table.  The modules code uses a separate
'partial_specializations' table to track them instead to ensure that
they get walked and emitted when emitting a module, but currently this
does not always happen.

The attached testcase fails in two ways.  First, because the partial
specialisation is just a declaration (and not a definition),
'set_defining_module' never ends up getting called on it and so it never
gets added to the partial specialisation table.  We fix this by ensuring
that when partial specializations are created they always get added, and
so we never miss one. To prevent adding partial specialisations multiple
times we split this out as a new function.

The second way it fails is that when exporting the primary interface for
a module with partitions, we also re-walk the specializations of all
imported partitions to merge them into a single BMI.  So this patch
ensures that after calling 'match_mergeable_specialization' we also
ensure that if the name came from a partition it gets added to the
specialization table so that a dependency is correctly created for it.

PR c++/114947

gcc/cp/ChangeLog:

* cp-tree.h (set_defining_module_for_partial_spec): Declare.
* module.cc (trees_in::decl_value): Track partial specs coming
from partitions.
(set_defining_module): Don't track partial specialisations here
anymore.
(set_defining_module_for_partial_spec): New function.
* pt.cc (process_partial_specialization): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/modules/partial-4_a.C: New test.
* g++.dg/modules/partial-4_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug fortran/115205] ICE when using -fsanitize=hwaddress

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #1 from kargls at comcast dot net ---
Clearly, this is not a Fortran bug.  Please change the component to sanitizer. 
I would change it, but I've lost the ability to edit bug reports.

[Bug fortran/115205] New: ICE when using -fsanitize=hwaddress

[ashermancinelli at gmail dot com via Gcc-bugs]

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

Bug ID: 115205
   Summary: ICE when using -fsanitize=hwaddress
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashermancinelli at gmail dot com
  Target Milestone: ---

Any use of -fsanitize=hwaddress causes an ICE:

$ cat test.f
   program main
   print *, 'running'
   end
$ gfortran -fsanitize=hwaddress test.f
during GIMPLE pass: sanopt
test.f:1:72:

1 |program main
  |   
^
internal compiler error: Segmentation fault
0xd2e843 crash_signal
../../gcc-13.2.0/gcc/toplev.cc:314
0xa5f5b0 gimple_build_call(tree_node*, unsigned int, ...)
../../gcc-13.2.0/gcc/gimple.cc:268
0xa6d73f gimple_build(gimple_stmt_iterator*, bool, gsi_iterator_update,
unsigned int, combined_fn, tree_node*, tree_node*)
../../gcc-13.2.0/gcc/gimple-fold.cc:8908
0xd46ae7 tree_node* gimple_build(gimple**, unsigned int,
combined_fn, tree_node*, tree_node*)
../../gcc-13.2.0/gcc/gimple-fold.h:122
0xd46ae7 hwasan_expand_check_ifn(gimple_stmt_iterator*, bool)
../../gcc-13.2.0/gcc/asan.cc:4793
0xd5730f execute
../../gcc-13.2.0/gcc/sanopt.cc:1375
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #8 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

I simply copied all the associated functions in trans-expr.cc from mainline
and plonked them in 13-branch. That's why I said that I hadn't done any
weeding. There is also a commit from Jakub in there as well. I'll check to
see if the associated PRs are fixed.

I got into regression fixing before the 14.1 release and this was one of
the low hanging fruit. To be honest, I am not especially bothered about
fixing it or not. Up until the ICE of the PR it was giving an error on
valid code. I would prefer though that the ICE went away!

Cheers

Paul





On Thu, 23 May 2024 at 19:18, anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>  CC||anlauf at gcc dot gnu.org
>
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #6)
> > Created attachment 58277 [details]
> > Fix for this PR
> >
> > This was substantially fixed on 14-branch by the patch for PR49213.
> However,
> > there have been many subsequent changes to gfc_trans_structure_assign and
> > its subsidiary functions as the attachment demonstrates.
> >
> > I haven't attempted to do any weeding of the changes to separate those
> > responsible for fixing this PR. However, 13-branch regtests successfuly
> with
> > the patch applied.
> >
> > Should I commit this with a testcase or just close the PR?
> >
> > Paul
>
> Paul,
>
> can you summarize where you gathered the pieces of this patch from?
>
> From a quick glance, r14-870 and r14-2160 (both yours) seem to be involved.
>
> Does it also fix any of the issues addressed by the respective PRs?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug tree-optimization/113879] missed optimization - not exploiting known range of integers

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r15-802-gefc4255d4393cba3d2232a7152799e1b161c3062
Author: Andrew MacLeod 
Date:   Thu May 2 12:23:18 2024 -0400

Add inferred ranges for range-ops based statements.

Gimple_range_fold contains some shorthand fold_range routines for
easy user consumption of that range-ops interface, but there is no
equivalent
routines for op1_range and op2_range.  This patch provides basic versions.

Any range-op entry which has an op1_range or op2_range implemented can
potentially also provide inferred ranges.  This is a step towards
PR 113879.  Default is currently OFF for performance reasons as it
dramtically increases the number of inferred ranges.

PR tree-optimization/113879
* gimple-range-fold.cc (op1_range): New.
(op2_range): New.
* gimple-range-fold.h (op1_range): New prototypes.
(op2_range): New prototypes.
* gimple-range-infer.cc (gimple_infer_range::add_range): Do not
add an inferred range if it is VARYING.
(gimple_infer_range::gimple_infer_range): Add inferred ranges
for any range-op statements if requested.
* gimple-range-infer.h (gimple_infer_range): Add parameter.

[Bug c++/115187] [14/15 Regression] ICE when deleting temporary array

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r15-796-ged63cd2aa5b114565fe5499c3a6bf8da5e8e48ba
Author: Jason Merrill 
Date:   Wed May 22 18:41:27 2024 -0400

c++: deleting array temporary [PR115187]

Decaying the array temporary to a pointer and then deleting that crashes in
verify_gimple_stmt, because the TARGET_EXPR is first evaluated inside the
TRY_FINALLY_EXPR, but the cleanup point is outside.  Fixed by using
get_target_expr instead of save_expr.

I also adjust the stabilize_expr comment to prevent me from again thinking
it's a suitable replacement.

PR c++/115187

gcc/cp/ChangeLog:

* init.cc (build_delete): Use get_target_expr instead of save_expr.
* tree.cc (stabilize_expr): Update comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/array-prvalue3.C: New test.

[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt

[crrodriguez at opensuse dot org via Gcc-bugs]

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

--- Comment #8 from Cristian Rodríguez  ---
SO shall I flile a bug report to the linker instead? if -znow is used I would
expect no plt used in the whole executable..

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||reiter.christoph at gmail dot 
com

--- Comment #7 from Christoph Reiter  ---
If the problem is indeed in read_tuple_file(), then I see one potential cause
there:

The file is opened in text mode and it checks if the read count matches the
size of the actual data read. But in text mode where newline normalization
happens the read part can be smaller if there are CRLF in there that got
converted to LF:

https://github.com/gcc-mirror/gcc/blob/0b3b6a8df77b0ae15078402ea5fb933d6fccd585/c%2B%2Btools/resolver.cc#L129-L130

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #6)
> Created attachment 58277 [details]
> Fix for this PR
> 
> This was substantially fixed on 14-branch by the patch for PR49213. However,
> there have been many subsequent changes to gfc_trans_structure_assign and
> its subsidiary functions as the attachment demonstrates.
> 
> I haven't attempted to do any weeding of the changes to separate those
> responsible for fixing this PR. However, 13-branch regtests successfuly with
> the patch applied.
> 
> Should I commit this with a testcase or just close the PR?
> 
> Paul

Paul,

can you summarize where you gathered the pieces of this patch from?

>From a quick glance, r14-870 and r14-2160 (both yours) seem to be involved.

Does it also fix any of the issues addressed by the respective PRs?

[Bug other/115189] libiberty introduces UNC paths waking up binutils bug

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

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

--- Comment #3 from Tomas Kalibera  ---
I hope there is a more elegant solution, but I could think of a best-effort
one. Check if the result of the normalization is a UNC path, if yes, check if
the original path started with a drive letter, if yes, modify the UNC path
replacing the \\server\share by that drive, normalize the modified path again
and if it normalizes to the same UNC path, use the version with the drive;
otherwise, use the original UNC result of normalization.

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
Created attachment 58277
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58277&action=edit
Fix for this PR

This was substantially fixed on 14-branch by the patch for PR49213. However,
there have been many subsequent changes to gfc_trans_structure_assign and its
subsidiary functions as the attachment demonstrates.

I haven't attempted to do any weeding of the changes to separate those
responsible for fixing this PR. However, 13-branch regtests successfuly with
the patch applied.

Should I commit this with a testcase or just close the PR?

Paul

[Bug c++/115198] Class template argument deduction fails for copy ctor when used with an alias template if the aliased class template has explicitly defaulted copy ctor

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |14.2

[Bug target/115188] [14/15 regression] invalid Thumb assembly for atomic store in loop on ARMv6

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #2 from Wilco  ---
(In reply to Andrew Pinski from comment #1)
> At first I thought it was the same failure as PR 115153 but it is different.

It's similar in that 'm' apparently allows LDMIA/STMIA with writeback in
Thumb-1. The correct constraint is 'Uw'.

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

--- Comment #3 from David Malcolm  ---
(In reply to Tobias Burnus from comment #2)
> Thus, one way would be to have LANG=C set somewhere (e.g. via the Makefile -
> assuming it can be done portable). 

I'd prefer not to do that as we may want to have selftests of i18n (though
libintl seems to have a lot of global state, which is a pain for selftests).

> Alternative would be your suggestion to disable it in simple_diagnostic_path.

I have a patch for that; it seems to work.

> Looking at gcc/intl.cc's gcc_init_libintl, you also need to watch out for
> open_quote/close_quote and other fun changes as they might come before you
> switch to to LANG=C.

FWIW we already have class auto_fix_quotes for that (see selftest.h)

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

--- Comment #2 from Tobias Burnus  ---
Indeed, the suggestion was not to disable the translations in general. A
similar issue shows up when running the testsuite. There is it solved by
"setenv LANG C" and "setenv LANG C.ASCII" – while various scripts also use
LANG=C.

Thus, one way would be to have LANG=C set somewhere (e.g. via the Makefile -
assuming it can be done portable).

Alternative would be your suggestion to disable it in simple_diagnostic_path.
Looking at gcc/intl.cc's gcc_init_libintl, you also need to watch out for
open_quote/close_quote and other fun changes as they might come before you
switch to to LANG=C.

[Bug tree-optimization/115197] [13/14/15 Regression] ICE on valid code at -O{1,2} with "-fno-tree-scev-cprop -ftree-pre -ftree-loop-distribute-patterns" on x86_64-linux-gnu: Segmentation fault

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

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

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

https://gcc.gnu.org/g:2b2476d4d18c92b8aba3567ebccd2100c2f7c258

commit r15-793-g2b2476d4d18c92b8aba3567ebccd2100c2f7c258
Author: Richard Biener 
Date:   Thu May 23 14:36:39 2024 +0200

tree-optimization/115197 - fix ICE w/ constant in LC PHI and loop
distribution

Forgot a check for an SSA name before trying to replace a PHI arg with
its current definition.

PR tree-optimization/115197
* tree-loop-distribution.cc (copy_loop_before): Constant PHI
args remain the same.

* gcc.dg/pr115197.c: New testcase.

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Sorry about this; thanks for reporting it.

The translation happens here in simple_diagnostic_path::add_event:

2583  text_info ti (_(fmt), &ap, 0, nullptr, &rich_loc);
^^

There's a chance that simple_diagnostic_path might get used for real purposes,
rather than just selftests, so maybe we want a flag on the
simple_diagnostic_path to suppress translation for events within it (and set it
for test_diagnostic_path).

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #44 from rguenther at suse dot de  ---
On Thu, 23 May 2024, mkretz at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
> 
> --- Comment #43 from Matthias Kretz (Vir)  ---
> I see this issue in SIMD programming. Example (on x86_64 with only '-O2', i.e.
> without AVX512) https://compiler-explorer.com/z/K64djP356:
> 
> typedef int V __attribute__((vector_size(64)));
> 
> V gen();
> 
> void g0(V const&, V const&);
> void g1(V, V);
> 
> void constref()
> {
>   g0(gen(), gen());
> }
> 
> void byvalue()
> {
>   g1(gen(), gen());
> }
> 
> Both the 'constref' and 'byvalue' cases copy every V argument before calling
> g0/g1.

The copy on GIMPLE is due to IL constraints:

  _10 = gen ();

   :
  D.2805 = _10;
  g0 (&D.2805, &D.2806);

when the call has a register type return value the LHS of the call
statement has to be a register (SSA name).  But the argument to
g0 has to be memory, so we get the extra copy.  Now, w/o AVX512
that "register" doesn't work out and we allocate it to memory
causing a memory-to-memory copy.

That's also because in vector lowering we do not lower those
register-to-memory stores (doing that would possibly help a bit,
as would more clever expansion of the copy or more clever
expanding of _10)

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

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

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

--- Comment #43 from Matthias Kretz (Vir)  ---
I see this issue in SIMD programming. Example (on x86_64 with only '-O2', i.e.
without AVX512) https://compiler-explorer.com/z/K64djP356:

typedef int V __attribute__((vector_size(64)));

V gen();

void g0(V const&, V const&);
void g1(V, V);

void constref()
{
  g0(gen(), gen());
}

void byvalue()
{
  g1(gen(), gen());
}

Both the 'constref' and 'byvalue' cases copy every V argument before calling
g0/g1.

[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/115199] [15 regression] gettext (libtextstyle) testsuite miscompiled since r15-579

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #24 from Richard Biener  ---
Fixed.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

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

https://gcc.gnu.org/g:61f5b3c59ed20438d7d9918d7a83d29a21097d4e

commit r15-791-g61f5b3c59ed20438d7d9918d7a83d29a21097d4e
Author: Richard Biener 
Date:   Thu May 23 11:26:14 2024 +0200

tree-optimization/115138 - ptr-vs-ptr and FUNCTION_DECLs

I failed to realize we do not represent FUNCTION_DECLs or LABEL_DECLs
in vars explicitly and thus have to compare pt.vars_contains_nonlocal.

PR tree-optimization/115138
* tree-ssa-alias.cc (ptrs_compare_unequal): Make sure
pt.vars_contains_nonlocal differs since we do not represent
FUNCTION_DECLs or LABEL_DECLs in vars explicitly.

* gcc.dg/torture/pr115138.c: New testcase.

[Bug tree-optimization/115199] [15 regression] gettext (libtextstyle) testsuite miscompiled since r15-579

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

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

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

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

commit r15-792-gf0a02467bbc35a478eb82f5a8a7e8870827b51fc
Author: Richard Biener 
Date:   Thu May 23 13:33:15 2024 +0200

tree-optimization/115199 - fix PTA constraint processing for &ANYTHING LHS

When processing a &ANYTHING = X constraint we treat it as *ANYTHING = X
during constraint processing but then end up recording it as
&ANYTHING = X anyway, breaking constraint graph building.  This is
because we only update the local copy of the LHS and not the constraint
itself.

PR tree-optimization/115199
* tree-ssa-structalias.cc (process_constraint): Also
record &ANYTHING = X as *ANYTING = X in the end.

* gcc.dg/torture/pr115199.c: New testcase.

[Bug tree-optimization/115197] [13/14/15 Regression] ICE on valid code at -O{1,2} with "-fno-tree-scev-cprop -ftree-pre -ftree-loop-distribute-patterns" on x86_64-linux-gnu: Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|needs-bisection |

--- Comment #2 from Richard Biener  ---
Caused by r13-1728-gce92603fbe3b48, testing trivial fix.

[Bug tree-optimization/114273] `PHI(a, MIN(b, c)) < c` is not optimized to just `PHI(a,b) < c`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-23
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed via the dup.

[Bug middle-end/28831] [11/12/13/14/15 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mkretz at gcc dot gnu.org

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

[Bug target/115204] unnecessary stack usage and copies (of temporaries)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/114148] gcc.target/i386/pr106010-7b.c FAILs

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

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
To investigate further, I've added comparison functions to a reduced
version of pr106010-7b.c, with

void
cmp_epi8 (_Complex unsigned char* a, _Complex unsigned char* b)
{
  for (int i = 0; i != N; i++)
if (a[i] != b[i])
  {
printf ("cmp_epi8: i = %d: a[i].r = %x a[i].i = %x b[i].r = %x b[i].i =
%x\n",
i, __real__ a[i], __imag__ a[i], __real__ b[i], __imag__ b[i]);
  }
}

This shows (when using _Complex unsigned char since on Solaris, char is
signed by default)

cmp_epi8: i = 76: a[i].r = 0 a[i].i = 0 b[i].r = 88 b[i].i = 33
cmp_epi8: i = 77: a[i].r = 0 a[i].i = 0 b[i].r = 6 b[i].i = 8
cmp_epi8: i = 80: a[i].r = 0 a[i].i = 0 b[i].r = 3 b[i].i = 0

I've also noticed that the test result depends on the implementation of
malloc used:

* With Solaris libc malloc, libmalloc, and watchmalloc, the test aborts.

* However, when using one of libbsdmalloc, libmapmalloc, libmtmalloc, or
  libumem, the test works.

However, ISTM that the test is simply bogus: in avx_test

* epi8_src, epi8_dst are allocated with malloc, buffer contents undefined

* epi8_dst is cleared

* epi8_dst is initialized from p_init

* in foo_epi8, epi8_src[0] (an undefined value) is copied into first N
  elements of epi8_dst

* epi8_dst is compared to epi8_src (with the remaining members of epi8_src
  still undefined)

Why on earth would the rest of epi8_dst and epi8_src be identical if
epi8_src was never initialized?

[Bug target/115204] unnecessary stack usage and copies (of temporaries)

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

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

--- Comment #2 from Andrew Pinski  ---
I am 99% sure there is a dup of this bug already.

[Bug target/115204] unnecessary stack usage and copies (of temporaries)

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

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

--- Comment #1 from Matthias Kretz (Vir)  ---
That's why I tagged is as 'target'. I'd be happy to learn that it can be
resolved target-independently.

[Bug tree-optimization/115035] Missed optimization: fold min/max in phi

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/114273] `PHI(a, MIN(b, c)) < c` is not optimized to just `PHI(a,b) < c`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||xxs_chy at outlook dot com

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

[Bug target/115204] New: unnecessary stack usage and copies (of temporaries)

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

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

Bug ID: 115204
   Summary: unnecessary stack usage and copies (of temporaries)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkretz at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Test case (https://compiler-explorer.com/z/P7s75EhMr):

struct A {
  int data[8];
};

struct A gen();

void g(struct A);

void f()
{
  g(gen());
}

This places the returned A object from 'gen()' on the stack, copies it and then
calls 'g'. Why? So instead of

f:
sub rsp, 40
xor eax, eax
mov rdi, rsp
callgen
sub rsp, 32
movdqa  xmm0, XMMWORD PTR [rsp+32]
movups  XMMWORD PTR [rsp], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+48]
movups  XMMWORD PTR [rsp+16], xmm0
callg
add rsp, 72
ret

can GCC just elide the copy? Like this:

f:
sub rsp, 40
xor eax, eax
mov rdi, rsp
callgen
callg
add rsp, 40
ret


I understand that this optimization requires the caller to never read from the
object anymore. So a second call to 'g' with the same object returned from
'gen' (like in https://compiler-explorer.com/z/6rMYdnb34) requires that the
first call to 'g' gets a copy. But the second call does not require the copy.
I.e.

int f()
{
  struct A a = gen();
  g(a);
  g(a);
  return 1;
}

compiles to

f:
sub rsp, 40
xor eax, eax
mov rdi, rsp
callgen
sub rsp, 32
movdqa  xmm0, XMMWORD PTR [rsp+32]
movups  XMMWORD PTR [rsp], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+48]
movups  XMMWORD PTR [rsp+16], xmm0
callg
movdqa  xmm0, XMMWORD PTR [rsp+32]
movups  XMMWORD PTR [rsp], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+48]
movups  XMMWORD PTR [rsp+16], xmm0
callg
mov eax, 1
add rsp, 72
ret

but could be

f:
sub rsp, 40
xor eax, eax
mov rdi, rsp
callgen
sub rsp, 32
movdqa  xmm0, XMMWORD PTR [rsp+32]
movups  XMMWORD PTR [rsp], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+48]
movups  XMMWORD PTR [rsp+16], xmm0
callg
add rsp, 32
callg
mov eax, 1
add rsp, 40
ret

IIUC, the second change would be significantly harder to implement because it
needs to shrink the stack. However, I don't believe this second case is as
important. The first one should be sufficiently common because of temporaries
passed into function arguments. So the following variation

void f()
{
  g(gen(), gen());
}

is something I see often, leading to many unnecessary stack copies. Instead of

f:
sub rsp, 72
xor eax, eax
mov rdi, rsp
callgen
lea rdi, [rsp+32]
xor eax, eax
callgen
sub rsp, 64
movdqa  xmm0, XMMWORD PTR [rsp+64]
movups  XMMWORD PTR [rsp+32], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+80]
movups  XMMWORD PTR [rsp+48], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+96]
movups  XMMWORD PTR [rsp], xmm0
movdqa  xmm0, XMMWORD PTR [rsp+112]
movups  XMMWORD PTR [rsp+16], xmm0
callg
add rsp, 136
ret

I think it should be:

f:
sub rsp, 72
xor eax, eax
mov rdi, rsp
callgen
lea rdi, [rsp+32]
xor eax, eax
callgen
callg
add rsp, 72
ret

IIUC, this depends on the psABI and I don't know how target-dependent such an
optimization is. That's why I

[Bug tree-optimization/115202] [11/12/13/14/15 Regression] Missed optimization: std::min(f ? (unsigned short)m : a, ~0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|14.2|11.5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-23
Summary|[14/15 Regression] Missed   |[11/12/13/14/15 Regression]
   |optimization: std::min(f ?  |Missed optimization:
   |(unsigned short)m : a, ~0)  |std::min(f ?  (unsigned
   ||short)m : a, ~0)
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Here is a reduced testcase:
```
unsigned short m;
template
const T min(const T a, const T b)
{
if (a < b)
  return a;
return b;
}
unsigned short func(int a, int f) {
return min(f ? m : a, ~0);
}
```

The above is a regression from GCC 8 where in GCC 9 adds an early phiopt.


And here is a version which is not a regression:
```
unsigned short m;
template
inline const T min(const T a, const T b)
{
  return a < b ? a : b;
}
unsigned short func(int a, int f) {
return min(f ? m : a, ~0);
}
```


The real issue is we don't optimize MIN, -1>.
>From the IR:
```
  # RANGE [irange] int [0, 65535] MASK 0x VALUE 0x0
  iftmp.0_6 = (intD.9) m.1_1;
;;succ:   4 [always]  count:536870912 (estimated locally, freq 0.5000)
(FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 1073741824 (estimated locally, freq
1.), maybe hot
;;prev block 3, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   3 [always]  count:536870912 (estimated locally, freq 0.5000)
(FALLTHRU,EXECUTABLE)
;;2 [50.0% (guessed)]  count:536870912 (estimated locally, freq
0.5000) (FALSE_VALUE,EXECUTABLE)
  # iftmp.0_2 = PHI 
  # RANGE [irange] int [-INF, -1]
  _7 = MIN_EXPR ;
```

Obviously here `MIN_EXPR ` for the iftmp.0_6 part of the PHI, it will be
-1.

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[bugzilla.gcc at me dot benboeckel.net via Gcc-bugs]

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

--- Comment #6 from Ben Boeckel  ---
> The line ending of last line is also required. Personally feel strange.

This is explicitly handled (as a "no, not supported" case):
https://github.com/gcc-mirror/gcc/blob/4efa7ec85a85c6024d0907a0e735ad5df7fca952/c%2B%2Btools/resolver.cc#L143

[Bug analyzer/115203] New: [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_S

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

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

Bug ID: 115203
   Summary: [15 Regression] Build fail with non LANG=C in analyzer
self test: ICE in fail_formatted at selftest.cc:63 /
tree-diagnostic-path.cc:2158: test_control_flow_5:
FAIL: ASSERT_STREQ
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

For some testing, I happened to build with LANG=de_DE.UTF-8
and that was also set when building GCC itself.

That works fine until the analyzer self test - as the strings don't match:

.../build-gcc-trunk-fast/./gcc/xgcc
-B/home/tob/projects/build-gcc-trunk-fast/./gcc/  -xc++ -nostdinc /dev/null -S
-o /dev/null -fself-test=.../gcc/testsuite/selftests
.../gcc/tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ
("  events 1-5\n" "FILENAME:1:6:\n" "1 |   if ((arr = (struct foo **)malloc
[...]
5 ||if ((arr[i] = (struct foo *)malloc(sizeof(struct foo))) == NULL) {
  ||~   ~~
  |||   |
  |+--->(4) ...to here  (5) wurde hier deklariert



cc1plus: interner Compiler-Fehler: in fail_formatted, bei selftest.cc:63

0x22af256 selftest::fail_formatted(selftest::location const&, char const*, ...)
../../../repos/gcc/gcc/selftest.cc:63
0x22af301 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../../repos/gcc/gcc/selftest.cc:92
0x25b6cd6 selftest::fail_formatted(selftest::location const&, char const*, ...)
../../../repos/gcc/gcc/selftest.cc:63
0x25b6d81 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../../repos/gcc/gcc/selftest.cc:92
0x10a7b42 test_control_flow_5
../../../repos/gcc/gcc/tree-diagnostic-path.cc:2158
0x10aabe6 control_flow_tests
../../../repos/gcc/gcc/tree-diagnostic-path.cc:2292
0x13a5512 test_control_flow_5
../../../repos/gcc/gcc/tree-diagnostic-path.cc:2158
0x13a85b6 control_flow_tests
../../../repos/gcc/gcc/tree-diagnostic-path.cc:2292

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

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

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

--- Comment #11 from Jonathan Wakely  ---
The fix is in 13.1

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #5 from huangqinjin at gmail dot com ---
(In reply to huangqinjin from comment #3)
> (In reply to Peter Damianov from comment #2)
> > I could only reproduce this on MSYS2's gcc packages. On w64devkit, I
> > couldn't reproduce it. Nor with a gcc 15 I built myself.
> > 
> Oh yes, I made another test, but the error message is different.
> 
> $ printf 'test test.gcm\r\n' > a.modmap
> $ echo 'export module test;' > test.cpp
> $ g++ -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -c test.cpp
> test.cpp:1:8: error: unknown Compiled Module Interface: no such module
> 1 | export module test;
>   |^~
> test.cpp:1:8: warning: not writing module 'test' due to errors

The line ending of last line is also required. Personally feel strange.

$ printf 'test test.gcm' > a.modmap
$ echo 'export module test;' > test.cpp
$ g++ -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -c test.cpp
test.cpp:1:8: error: unknown Compiled Module Interface: no such module
1 | export module test;
  |^~
test.cpp:1:8: warning: not writing module 'test' due to errors

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

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

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

--- Comment #21 from Sergei Trofimovich  ---
Shrunk the example down to a single simpler function while preserving the
original masking intent:

```c
cat bug.cc
#include 
#include 
#include 

__attribute__((noipa))
static void assert_eq_p(void * l, void * r) {
char lb[16];
char rb[16];

__builtin_memcpy(lb, l, 16);
__builtin_memcpy(rb, r, 16);

if (__builtin_memcmp(lb, rb, 16) != 0) __builtin_trap();
}

__attribute__((noipa))
static void assert_eq(__m128i l, __m128i r) { assert_eq_p(&l, &r); }

int main() {
  const __m128i su = _mm_set1_epi32(0x4f80);
  const __m128  sf = _mm_castsi128_ps(su);

  const __m128  overflow_mask_f32 = _mm_cmpge_ps(sf,
_mm_set1_ps(2147483648.0f));
  const __m128i overflow_mask = _mm_castps_si128(overflow_mask_f32);

  const __m128i conv = _mm_cvttps_epi32(sf); // overflows
  const __m128i yes = _mm_set1_epi32(INT32_MAX);

  const __m128i a = _mm_and_si128(overflow_mask, yes);
  const __m128i na = _mm_andnot_si128(overflow_mask, conv);

  const __m128i conv_masked = _mm_or_si128(a, na);

  const __m128i actual = _mm_cmpeq_epi32(conv_masked,
_mm_set1_epi32(INT32_MAX));
  const __m128i expected = _mm_set1_epi32(-1);

  assert_eq(expected, actual);
}
```

The discrepancy:

Ok:
$ /tmp/gb/gcc/xg++ -Wall -B/tmp/gb/gcc bug.cc -o bug -O0 && ./bug
Bad:
$ /tmp/gb/gcc/xg++ -Wall -B/tmp/gb/gcc bug.cc -o bug -O2 && ./bug
Illegal instruction (core dumped)

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #4 from huangqinjin at gmail dot com ---
The repro in description shows that MSYS2 gcc read the module mapper early even
it is not used, seems to me it doesn't match the document
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html

> The mapper is connected to or loaded lazily,
> when the first module mapping is required.

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[huangqinjin at gmail dot com via Gcc-bugs]

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

--- Comment #3 from huangqinjin at gmail dot com ---
(In reply to Peter Damianov from comment #2)
> I could only reproduce this on MSYS2's gcc packages. On w64devkit, I
> couldn't reproduce it. Nor with a gcc 15 I built myself.
> 
Oh yes, I made another test, but the error message is different.

$ printf 'test test.gcm\r\n' > a.modmap
$ echo 'export module test;' > test.cpp
$ g++ -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -c test.cpp
test.cpp:1:8: error: unknown Compiled Module Interface: no such module
1 | export module test;
  |^~
test.cpp:1:8: warning: not writing module 'test' due to errors

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

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

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

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

--- Comment #7 from Rainer Orth  ---
Created attachment 58276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58276&action=edit
Minimal patch

Minimal patch as described: just build src/libbacktrace with -funwind-tables,
same for 19_diagnostics/stacktrace tests.

Ran just the stacktrace tests on i386-pc-solaris2.11 and sparc-sun-solaris2.11
(32 and 64-bit each), all PASS now.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

--- Comment #22 from Richard Biener  ---
Yes!  Testing a fix for

int foo (int) {}
int bar (int) {}

typedef int (*pred)(int);

int x, y;
pred A () { if (x) return foo; else return bar; }
pred B () { if (y) return foo; else return bar; }
int __attribute__((noipa)) baz()
{
  pred a = A();
  pred b = B();
  if (a != b)
return 42;
  return 0;
}

int main()
{
  if (baz () != 0)
__builtin_abort ();
  y = 1;
  if (baz () != 42)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/115202] [14/15 Regression] Missed optimization: std::min(f ? (unsigned short)m : a, ~0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.2

[Bug tree-optimization/115199] [15 regression] gettext (libtextstyle) testsuite miscompiled since r15-579

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Mine.

[Bug tree-optimization/115197] [13/14/15 Regression] ICE on valid code at -O{1,2} with "-fno-tree-scev-cprop -ftree-pre -ftree-loop-distribute-patterns" on x86_64-linux-gnu: Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.3.0
Version|unknown |13.3.1
  Known to fail||13.3.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
Summary|ICE on valid code at|[13/14/15 Regression] ICE
   |-O{1,2} with|on valid code at -O{1,2}
   |"-fno-tree-scev-cprop   |with "-fno-tree-scev-cprop
   |-ftree-pre  |-ftree-pre
   |-ftree-loop-distribute-patt |-ftree-loop-distribute-patt
   |erns" on x86_64-linux-gnu:  |erns" on x86_64-linux-gnu:
   |Segmentation fault  |Segmentation fault
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code,
   ||needs-bisection
   Last reconfirmed||2024-05-23
   Target Milestone|--- |13.4

--- Comment #1 from Richard Biener  ---
I'll have a look.

[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test

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

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #4 from Jonathan Wakely  ---
>
>> It's possible that all the lambda frames are inlined, or skip+2 in
>> stacktrace.cc causes us to skip real frames that we should keep, or maybe
>> libbacktrace just doesn't work on this target.
[...]
> The stacktrace failures only happen on 32-bit x86; 64-bit x86 is fine.
>
> I'm now trying a debug build and plan to compare i386 and amd64 side by
> side to find differences.

While that didn't produce anything useful, I noticed that both
libbacktrace and its testcases are built with -funwind-tables.

Checking what gcc does for that option, here's what I found:

* 64-bit x86 defaults to -fasynchronous-unwind-tables, thus implicitly
  -funwind-tables, too.  For that reason, the stacktrace tests PASS on
  both Linux/x86_64 and Solaris/amd64.

* 32-bit x86 defaults to -fasynchronous-unwind-tables *if*
  -fomit-frame-pointer is enabled.  This is the case on Linux/i686, thus
  the PASSes, while Solaris/i386 defaults to -fno-omit-frame-pointer,
  thus the FAILs observed.

* Solaris never enables -funwind-tables by default, thus the FAILs on
  both Solaris/SPARC and Linux/SPARC.

When I manually rebuild libstdc++-v3/src/libbacktrace with -g3 -O0
-funwind-tables and a testcase, too, it PASSes.

The question is how to proceed, though: while one could enable
-funwind-tables unconditionally in src/libbacktrace/Makefile.am (it's
done this way in other runtimes libs) and add -funwind-tables to the
affected testcases using dg-additional-options, I wonder if that
produces a satisfying user experience in the end.  Maybe it's better to
just default to -funwind-tables in g++ instead?

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> I'm looking into the first issue.  Interesting fact:
> 
> > /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec 
> > -fno-tree-slp-vectorize --param vect-epilogues-nomask=0
> t.C:7:21: optimized: loop vectorized using 16 byte vectors
> t.C:7:21: optimized:  loop versioned for vectorization because of possible
> aliasing
> rguenther@localhost:/tmp> ./a.out
> > /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec 
> > -fno-tree-slp-vectorize --param vect-epilogues-nomask=1
> t.C:7:21: optimized: loop vectorized using 16 byte vectors
> t.C:7:21: optimized:  loop versioned for vectorization because of possible
> aliasing
> t.C:7:21: optimized: loop vectorized using 8 byte vectors
> rguenther@localhost:/tmp> ./a.out 
> Aborted (core dumped)
> 
> so avoiding the vectorized epilog fixes this (I've also placed #pragma GCC
> novector on the loop in main and noipa on foo).

Actually with -fno-vect-cost-model even --param vect-epilogues-nomask=0 fails.
Since we are vectorizing

  for (int y = 1; y < n; y++)
{
  a[y * n][0] = d[y * n] + a[(y - 1) * n][0];
  a[y * n][1] = d[y * n] + a[(y - 1) * n][1];
}

with a VF of two this is a failure to identify the dependence between
the iterations, so possibly related to r11-6380 as well.

(compute_affine_dependence
  ref_a: BIT_FIELD_REF <*_37, 32, 0>, stmt_a: _38 = BIT_FIELD_REF <*_37, 32,
0>;  ref_b: BIT_FIELD_REF <*_40, 32, 0>, stmt_b: BIT_FIELD_REF <*_40, 32, 0> =
_41;
) -> dependence analysis failed

Creating dr for BIT_FIELD_REF <*_37, 32, 0>
analyze_innermost: success.
base_address: a_23(D)
offset from base address: 0
constant offset from base address: 0
step: (ssizetype) ((long unsigned int) n_20(D) * 16)
base alignment: 16
base misalignment: 0
offset alignment: 128
step alignment: 16
base_object: BIT_FIELD_REF <*_37, 32, 0>

Creating dr for BIT_FIELD_REF <*_40, 32, 0>
analyze_innermost: success.
base_address: (float4_t *) a_23(D) + (sizetype) n_20(D) * 16
offset from base address: 0
constant offset from base address: 0
step: (ssizetype) ((long unsigned int) n_20(D) * 16)
base alignment: 16
base misalignment: 0
offset alignment: 128
step alignment: 16
base_object: BIT_FIELD_REF <*_40, 32, 0>

and for reference

Creating dr for BIT_FIELD_REF <*_37, 32, 32>
analyze_innermost: success.
base_address: a_23(D)
offset from base address: 0
constant offset from base address: 4
step: (ssizetype) ((long unsigned int) n_20(D) * 16)
base alignment: 16
base misalignment: 0
offset alignment: 128
step alignment: 16
base_object: BIT_FIELD_REF <*_37, 32, 32>

that looks sensible.  And 'a' is indeed properly aligned.

t.c:6:21: note:   recording new base alignment for d_22(D) + (sizetype) n_20(D)
* 4
  alignment:4
  misalignment: 0
  based on: _32 = *_31;
t.c:6:21: note:   recording new base alignment for a_23(D)
  alignment:16
  misalignment: 0
  based on: _38 = BIT_FIELD_REF <*_37, 32, 0>;
t.c:6:21: note:   recording new base alignment for (float4_t *) a_23(D) +
(sizetype) n_20(D) * 16
  alignment:16
  misalignment: 0
  based on: BIT_FIELD_REF <*_40, 32, 0> = _41;
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   step doesn't divide the vector alignment.
t.c:6:21: missed:   Unknown alignment for access: *_31
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   Unknown alignment for access: BIT_FIELD_REF <*_37, 32, 0>
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   Unknown alignment for access: BIT_FIELD_REF <*_40, 32, 0>

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #8 from Rainer Orth  ---
Fixed for GCC 15.0.

[Bug tree-optimization/114072] gcc.dg/vect/vect-pr111779.c FAILs

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r15-789-gfc5e109272977f0242a2ceee3a85765cdbed1993
Author: Rainer Orth 
Date:   Thu May 23 09:53:45 2024 +0200

testsuite: vect: Fix gcc.dg/vect/vect-pr111779.c on SPARC [PR114072]

gcc.dg/vect/vect-pr111779.c FAILs on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/vect-pr111779.c -flto -ffat-lto-objects  scan-tree-dump
vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-pr111779.c scan-tree-dump vect "LOOP VECTORIZED"

This patch implements Richard's analysis from the PR, skipping the
scan-tree-dump part for big-endian targets without vect_shift_char
support.

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11 (32 and 64-bit
each).

2024-05-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114072
* gcc.dg/vect/vect-pr111779.c (scan-tree-dump): Require
vect_shift_char on big-endian targets.

[Bug tree-optimization/115202] New: [14/15 Regression] Missed optimization: std::min(f ? (unsigned short)m : a, ~0)

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 115202
   Summary: [14/15 Regression] Missed optimization: std::min(f ?
(unsigned short)m : a, ~0)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that the code below can be optimized to be independent of
'm', but gcc -O3 seems to have missed it.

https://godbolt.org/z/a6MoofoYK

unsigned short m;
#include 
unsigned short func(int a, int f) {
return std::min(f ? m : a, ~0);
}

GCC-trunk -O3:
func(int, int):
movzx   eax, WORD PTR m[rip]
testesi, esi
mov edx, -1
cmove   eax, edi
testeax, eax
cmovns  eax, edx
ret


Expected code (gcc-13.2):
func(int, int):
mov eax, edi
testedi, edi
jns .L4
testesi, esi
jne .L4
ret
.L4:
mov eax, 65535
ret

If we did it correctly, it's caused by
https://github.com/gcc-mirror/gcc/commit/7b34cacc5735385e7e2855d7c0a6fad60ef4a99b

Thank you very much for your time and effort! We look forward to hearing from
you.

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

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #7)
> int main()
> { 
>   const int n = 3;
>   float d[n*n];
>   float4_t a[n*n];

I'd recommend using #define n 3 or enum { n = 3 }; instead of const int n = 3;
so that the arrays aren't unnecessary VLAs.

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

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I'm looking into the first issue.  Interesting fact:

> /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec 
> -fno-tree-slp-vectorize --param vect-epilogues-nomask=0
t.C:7:21: optimized: loop vectorized using 16 byte vectors
t.C:7:21: optimized:  loop versioned for vectorization because of possible
aliasing
rguenther@localhost:/tmp> ./a.out
> /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec 
> -fno-tree-slp-vectorize --param vect-epilogues-nomask=1
t.C:7:21: optimized: loop vectorized using 16 byte vectors
t.C:7:21: optimized:  loop versioned for vectorization because of possible
aliasing
t.C:7:21: optimized: loop vectorized using 8 byte vectors
rguenther@localhost:/tmp> ./a.out 
Aborted (core dumped)

so avoiding the vectorized epilog fixes this (I've also placed #pragma GCC
novector on the loop in main and noipa on foo).

C testcase:

typedef float float4_t __attribute__((vector_size(4 * sizeof(float;

void __attribute__((noipa))
foo(int n, const float *d, float4_t * __restrict a)
{
  for (int y = 1; y < n; y++)
for (int c = 0; c < 2; c++)
  a[y * n][c] = d[y * n] + a[(y - 1) * n][c];
}

int main()
{ 
  const int n = 3;
  float d[n*n];
  float4_t a[n*n];
#pragma GCC novector
  for (int i = 0; i < n * n; ++i)
d[i] = i;
  foo(n, d, a);
  if (a[6][1] != 9)
__builtin_abort();
}

[Bug fortran/103312] [11/12/13/14/15 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:2ce90517ed75c4af9fc0616f2670cf6dfcfa8a91

commit r15-788-g2ce90517ed75c4af9fc0616f2670cf6dfcfa8a91
Author: Paul Thomas 
Date:   Thu May 23 07:59:46 2024 +0100

Fortran: Fix ICEs due to comp calls in initialization exprs [PR103312]

2024-05-23  Paul Thomas  

gcc/fortran
PR fortran/103312
* dependency.cc (gfc_dep_compare_expr): Handle component call
expressions. Return -2 as default and return 0 if compared with
a function expression that is from an interface body and has
the same name.
* expr.cc (gfc_reduce_init_expr): If the expression is a comp
call do not attempt to reduce, defer to resolution and return
false.
* trans-types.cc (gfc_get_dtype_rank_type,
gfc_get_nodesc_array_type): Fix whitespace.

gcc/testsuite/
PR fortran/103312
* gfortran.dg/pr103312.f90: New test.