[Bug libstdc++/118209] New: ranges::sort doesn't use iter_move, cannot sort zip of move-only type

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 118209
   Summary: ranges::sort doesn't use iter_move, cannot sort zip of
move-only type
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Bug #105609 is related, i.e. it's about using std::move(*it) where ADL
iter_move(it) is required; but I think this new one differs enough to file it
separately. This one transitively affects make_heap and partial_sort.

This initially came from StackOverflow:
https://stackoverflow.com/questions/12227474/can-iter-swap-be-specialised/75535132?noredirect=1#comment139852610_75535132

// https://godbolt.org/z/jqYE9Tnqe

#include 
#include 
#include 
struct F {
  int a = -1;
  explicit F(int d) : a(d) { }
  F(const F&) = delete;
  F(F&& o) : a(o.a) { }
  void operator=(const F&) = delete;
  F& operator=(F&& o) {
a = o.a;
return *this;
  }
  auto operator<=>(const F&) const = default;
};
int main() {
  int a[] = {3,2,1};
  std::vector v(a, a+3);

  // sorting v is OK
  std::ranges::sort(v);

  // sorting zip(v) doesn't compile
  std::ranges::sort(std::views::zip(v));
}


include/c++/15.0.0/bits/stl_heap.h:355:15: error: no viable conversion from
'typename std::remove_reference>::type' (aka 'std::tuple') to
'_ValueType' (aka 'std::tuple')
  355 |   _ValueType __value = _GLIBCXX_MOVE(*(__first + __parent));
  |  ^ 

This happens inside __make_heap, called from __partial_sort.
The problem is that it's calling `std::move(*iter)` to get an xvalue
zip_view::reference, which then converts to an lvalue F, which can't be copied
because F is move-only. What we need instead is to call zip_view::iterator's
ADL `iter_move(iter)`, to give us an xvalue F directly.

libc++ and MS STL both handle this OK.

[Bug c/118191] missing option to read __float128 from command line argument or string

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

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

--- Comment #4 from Jonathan Wakely  ---
This bug database is still the wrong place for your questions. 

You probably need a newer glibc, strtof128 is relatively new.

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |15.0

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

--- Comment #1 from Andrew Pinski  ---
This is also a post december 3rd issue.

Reducing ...

[Bug middle-end/118050] [15 Regression] timevar.cc:163:18: error: 'CLOCK_MONOTONIC' was not declared in this scope

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:06867d9fa69ca6d4ded4602e6601c7153599cbff

commit r15-6443-g06867d9fa69ca6d4ded4602e6601c7153599cbff
Author: John David Anglin 
Date:   Thu Dec 26 11:27:36 2024 -0500

Fix timevar.cc build on systems that don't have CLOCK_MONOTONIC

2024-12-26  John David Anglin  

gcc/ChangeLog:

PR target/118050
* timevar.cc (get_time): Only use CLOCK_MONOTONIC if
'_POSIX_TIMERS > 0 && defined(_POSIX_MONOTONIC_CLOCK)'.
Otherise, use CLOCK_REALTIME.

[Bug middle-end/118050] [15 Regression] timevar.cc:163:18: error: 'CLOCK_MONOTONIC' was not declared in this scope

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed on trunk.

[Bug tree-optimization/118205] [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Blocks||59859


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
[Bug 59859] [meta-bug] GRAPHITE issues

[Bug ada/118208] sem_ch8 Program_Error.

[00120260a at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Saada Mehdi <00120260a at gmail dot com> ---
It's the "@" that causes problem.

[Bug c++/78216] Segfault when dealing with a parameter pack of member functions pointers

[gcc.gnu.org at ajryansolutions dot co.uk via Gcc-bugs]

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

--- Comment #4 from Adam Ryan  ---
Created attachment 59981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59981&action=edit
An example code change that will allow the code to compile.

[Bug c++/78216] Segfault when dealing with a parameter pack of member functions pointers

[gcc.gnu.org at ajryansolutions dot co.uk via Gcc-bugs]

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

--- Comment #5 from Adam Ryan  ---
I should the patch only allows the code snippet I posted to compile, the code
from the original poster has a different exception however I think the eventual
solution may be common to both.

[Bug tree-optimization/118206] New: [15 regression] libdeflate miscompiled by ifcombine

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

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

Bug ID: 118206
   Summary: [15 regression] libdeflate miscompiled by ifcombine
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

This first manifested as R failing to build (https://bugs.gentoo.org/946876),
then I found libdeflate failed its testsuite.

Here's a reduced version of its test_trailing_bytes test.
```
#include 
#include 

static inline __attribute__((always_inline)) uint16_t
load_uint16_t_unaligned(const void *p) {
  uint16_t v;
  __builtin_memcpy(&v, p, sizeof(v));
  return v;
}

__attribute__((noipa))
int libdeflate_zlib_decompress_ex(const void *in, size_t in_nbytes) {
  const uint8_t *in_next = in;
  uint16_t hdr;

  if (in_nbytes < (2 + 4))
return 1;

  hdr = __builtin_bswap16(load_uint16_t_unaligned(in_next));
  in_next += 2;

  if ((hdr % 31) != 0)
return 1;

  if (((hdr >> 8) & 0xF) != 8)
return 1;

  if ((hdr >> 12) > 7)
return 1;

  return 0;
}

int main() {
  uint8_t data[8] = {0x78, 0x9c, 0xc5, 0x96, 0x3, 0x93, 0x5d, 0x6b};
  int ret = libdeflate_zlib_decompress_ex(data, sizeof(data)/sizeof(data[0]));
  if (ret != 0) {
__builtin_abort();
  }
}
```

-O0 even fails, but -O0 -fdisable-tree-ifcombine works.

[Bug tree-optimization/118205] [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2

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

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

--- Comment #2 from Sam James  ---
(In reply to Andrew Pinski from comment #1)
> floop-parallelize does not use graphite.

In my defence...
```
$ gcc /tmp/a.c -O -floop-parallelize-all -ftree-parallelize-loops=2
/tmp/a.c: sorry, unimplemented: Graphite loop optimizations cannot be used (isl
is not available) ('-fgraphite', '-fgraphite-identity', '-floop-nest-optimize',
'-floop-parallelize-all')
```

[Bug tree-optimization/118205] [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks|59859   |

--- Comment #1 from Andrew Pinski  ---
floop-parallelize does not use graphite.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
[Bug 59859] [meta-bug] GRAPHITE issues

[Bug tree-optimization/118206] [15 regression] libdeflate miscompiled by ifcombine since r15-6360-g6d5df5133c5dd8

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] libdeflate  |[15 regression] libdeflate
   |miscompiled by ifcombine|miscompiled by ifcombine
   ||since
   ||r15-6360-g6d5df5133c5dd8
 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Sam James  ---
r15-6360-g6d5df5133c5dd8

[Bug tree-optimization/118207] New: [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

Bug ID: 118207
   Summary: [15 regression] ICE when building
dosbox-staging-0.82.0 (in fold_convert_loc, at
fold-const.cc:2779)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59980&action=edit
imfc.cpp.ii.xz

```
$ g++ -c ./src/hardware/libhardware.a.p/imfc.cpp.ii -std=c++20 -O3
during GIMPLE pass: fre
../dosbox-staging-0.82.0/src/hardware/imfc.cpp: In member function ‘void
MusicFeatureCard::initConfigurationMemory()’:
../dosbox-staging-0.82.0/src/hardware/imfc.cpp:5833:14: internal compiler
error: in fold_convert_loc, at fold-const.cc:2779
 5833 | void initConfigurationMemory()
  |  ^~~
0x5ab6729f940c internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x5ab6729f95a7 fancy_abort(char const*, int, char const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic.cc:1722
0x5ab670e925ba fold_convert_loc(unsigned long, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/fold-const.cc:2779
0x5ab67100c03e fold_stmt_1
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-fold.cc:6714
0x5ab672e9ef55 fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*),
bitmap_head*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-fold.cc:6815
0x5ab672e9ef55 eliminate_dom_walker::eliminate_stmt(basic_block_def*,
gimple_stmt_iterator*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-sccvn.cc:7240
0x5ab672e68ac5 process_bb
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-sccvn.cc:8322
0x5ab672e5ce00 do_rpo_vn_1
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-sccvn.cc:8774
0x5ab672e96d92 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-sccvn.cc:8935
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.
```

---

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
01d33f6be28d09edb2e9aaa66feab7a1b359aa60' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241222 (experimental)
cf59bf844037ae952f5058d0fd49e1f4f0cf907e (Gentoo Hardened 15.0. p, commit
01d33f6be28d09edb2e9aaa66feab7a1b359aa60)
```

[Bug tree-optimization/118205] New: [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 118205
   Summary: [15 Regression] ICE: in as_a, at is-a.h:255 with -O
-floop-parallelize-all -ftree-parallelize-loops=2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 59979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59979&action=edit
auto-reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -floop-parallelize-all -ftree-parallelize-loops=2
testcase.C 
during GIMPLE pass: parloops
testcase.C: In member function 'int Gfx10Lib::HwlComputeMaxMetaBaseAlignments()
const':
testcase.C:6:5: internal compiler error: in as_a, at is-a.h:255
6 | int Gfx10Lib::HwlComputeMaxMetaBaseAlignments() const {
  | ^~~~
0x3124421 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xfd8917 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1722
0x98d2e9 gimple_statement_with_memory_ops*
as_a(gimple*)
/repo/gcc-trunk/gcc/is-a.h:255
0x98d6bb gphi const* as_a(gimple const*)
/repo/gcc-trunk/gcc/tree-parloops.cc:964
0x98d6bb gimple_phi_result(gimple const*)
/repo/gcc-trunk/gcc/gimple.h:4617
0x98d6bb reduction_phi
/repo/gcc-trunk/gcc/tree-parloops.cc:958
0x1a636d7 try_create_reduction_list
/repo/gcc-trunk/gcc/tree-parloops.cc:3553
0x1a636d7 parallelize_loops
/repo/gcc-trunk/gcc/tree-parloops.cc:4118
0x1a64df1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4238
0x1a64df1 execute
/repo/gcc-trunk/gcc/tree-parloops.cc:4217
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20241226001859-r15-6441-g45b017b467bb91-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20241226001859-r15-6441-g45b017b467bb91-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241226 (experimental) (GCC)

[Bug tree-optimization/118205] [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from Lewis Hyatt  ---
Should be either r15-6016 (activated 64-bit location_t) or else r15-6001
(preparation for 64-bit location_t that touched this area). I'll take a look.

[Bug target/95095] Feature request: support -fno-unique-section-names

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

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

Sam James  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ada/118208] New: sem_ch8 Program_Error.

[00120260a at gmail dot com via Gcc-bugs]

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

Bug ID: 118208
   Summary: sem_ch8 Program_Error.
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 00120260a at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

I can't provide more than the code and bug report.

gcc -c -gnatX0 -gnatE -gnatd.n main2.adb
/home/drm/.local/share/alire/toolchains/gnat_native_14.2.1_06bb3def/lib/gcc/x86_64-pc-linux-gnu/14.2.0/adainclude/system.ads
main2.adb
main2.ads
+===GNAT BUG DETECTED==+
| 14.2.0 (x86_64-pc-linux-gnu) Program_Error sem_ch8.adb:5920 explicit raise|
| Error detected at main2.adb:10:22|
| Compiling main2.adb  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

package main2 is
 type Item (Degree : Natural := 0) is record
   Value: Float;
 end record;
 type ItemArray is array (Positive range 1..<>) of Item;
 type Poly is private;
 function Construct (N: ItemArray) return Poly;
private
 type ItemLink;
 type ItemAccess is access all ItemLink;
 type ItemLink is record
   Next: ItemAccess;
   I: Item;
 end record;
 type Poly is record
   MaxDegree: Natural := 0;
   Sentinel: aliased ItemLink;
 end record;
end main2;
_

package body main2 is
 function Construct (N: ItemArray) return Poly is
 begin
   return P: Poly do
 declare
   Current: not null ItemAccess := P.Sentinel'Unrestricted_Access;
 begin
   for A of N loop
 Current.Next := new ItemLink'(null, A);
 Current := @.Next;
   end loop;
 end;
   end return;
 end Construct;
end main2;

[Bug tree-optimization/118205] [15 Regression] ICE: in as_a, at is-a.h:255 with -O -floop-parallelize-all -ftree-parallelize-loops=2 since r15-6001

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[15 Regression] ICE: in |[15 Regression] ICE: in
   |as_a, at is-a.h:255 with -O |as_a, at is-a.h:255 with -O
   |-floop-parallelize-all  |-floop-parallelize-all
   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2
   ||since r15-6001
   Last reconfirmed||2024-12-27
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-Decembe
   ||r/672271.html
 Ever confirmed|0   |1

--- Comment #4 from Lewis Hyatt  ---
I think the issue is related to the undefined behavior with the zero-sized
array in this testcase. It leads to trying to call reduction_phi() to look up a
stmt that is not actually a phi. Prior to r15-6001, that was OK and just
returned NULL; in r15-6001 I did not consider that case that the PHI arg to
reduction_phi() may not be a gphi. One-line change to check for this case
submitted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672271.html.

[Bug preprocessor/118168] -Wmisleading-indentation causes 10x+ overhead or higher (visible on mypy-1.13.0)

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #11 from Andi Kleen  ---
Fix posted here:

https://inbox.sourceware.org/gcc-patches/20241227024559.2224623-1-a...@firstfloor.org/T/#t

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 59982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59982&action=edit
semi reduced

[Bug c++/118210] New: g++-14.2 fails to parse template lambda expression operator()<>() call inside the requires expression.

[piotr.rak at gmail dot com via Gcc-bugs]

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

Bug ID: 118210
   Summary: g++-14.2 fails to parse template lambda expression
operator()<>() call inside the requires expression.
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr.rak at gmail dot com
  Target Milestone: ---

Created attachment 59983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59983&action=edit
Test case

Hello,

g++-14.2 fails to parse template lambda expression template operator()<>() call
inside the requires expression.

Example:

requires{[]{}.template operator()();} //error: expected
nested-name-specifier before ‘T’
//error: expected ‘(’ before ‘T’
//error: expected ‘;’ before ‘.’ token

An expression:
[]{}.template operator()(); // compiles just fine
Outside the scope requires-expr.

I found this oddity trying to emulate clang __has_constexpr_builtin() invoking
such builtin wrapped in consteval template lambda expression.
As clang __has_constexpr_builtin works sparingly (trait builtin return false)
idea was to check abuse consteval context for both compilers.

As of 14.2 direct lambda calls with template type deduction do work (like
requires {[](T){}(char{});} ).

Please see attached or following example:

// compile -std=c++23 -DSHOW_BUG=1
#if SHOW_BUG
#define requires_expr requires
#else
#define requires_expr
#endif

using any_type_example = char;

void foo1() { requires_expr { [](){}.template
operator()(); }; }
void foo2() { requires_expr { []{}.template
operator()(); }; }
void foo3() { requires_expr { []{}.template operator()<1>(); }; }

Cheers,
/P

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #59982|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 59984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59984&action=edit
Reduced as much as I can do it today

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-12-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
Confirmed. I suspect it was r15-6339-g40f243e9179667 .

[Bug tree-optimization/118211] New: tree-vectorize: vectorize input.cc, find_end_of_line

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Bug ID: 118211
   Summary: tree-vectorize: vectorize input.cc, find_end_of_line
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org
  Target Milestone: ---

This is the hot loop of the line searching function in gcc input.cc.
It currently fails to vectorize on AVX512F. Would be nice if it could.

% gcc -O3 -mavx512f -fopt-info -fopt-info-all  eol.cc -S
Unit growth for small function inlining: 18->18 (0%)

Inlined 0 calls, eliminated 0 functions

BB 3 is always executed in loop 1
loop 1's coldest_outermost_loop is 1, hotter_than_inner_loop is NULL
eol.cc:6:36: missed: couldn't vectorize loop
eol.cc:8:11: missed: can't safely apply code motion to dependencies of _1 =
*s_12;
 to vectorize the early exit.
eol.cc:4:1: note: vectorized 0 loops in function.
eol.cc:23:36: note: * Analysis failed with vector mode V32QI
BB 3 is always executed in loop 1
loop 1's coldest_outermost_loop is 1, hotter_than_inner_loop is NULL
eol.cc:6:36: note: considering unrolling loop 1 at BB 5
considering unrolling loop with constant number of iterations
considering unrolling loop with runtime-computable number of iterations

#include 

const char *
find_end_of_line (const char *s, size_t len)
{
  for (const auto end = s + len; s != end; ++s)
{
  if (*s == '\n')
return s;
  if (*s == '\r')
{
  const auto next = s + 1;
  if (next == end)
{
  break;
}
  return (*next == '\n' ? next : s);
}
}
  return nullptr;
}

[Bug c/118212] New: False positive -Wstringop-truncation despite [[gnu::nonstring]]

[lukeshu at lukeshu dot com via Gcc-bugs]

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

Bug ID: 118212
   Summary: False positive -Wstringop-truncation despite
[[gnu::nonstring]]
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukeshu at lukeshu dot com
  Target Milestone: ---

System / GCC version / GCC options:

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20240910 (GCC)

Reproducer source code:

static struct {
  [[gnu::nonstring]] char name[16];
} table[1] = {0};

void set_name(unsigned int rownum, const char *name) {
  __builtin_strncpy(table[rownum].name, name, sizeof(table[0].name));
}

Reproducer command and output:

$ gcc -O2 -Wstringop-truncation -Werror -c f.c
f.c: In function ‘set_name’:
f.c:6:3: error: ‘__builtin_strncpy’ specified bound 16 equals destination
size [-Werror=stringop-truncation]
6 |   __builtin_strncpy(table[rownum].name, name,
sizeof(table[0].name));
  |  
^~
cc1: all warnings being treated as errors

Notes:

This goes away if the size of table is increased beyond `1`, but
comes back if rownum is set to the table size minus 1:

static struct {
  [[gnu::nonstring]] char name[16];
} table[3] = {0};

void set_name(const char *name) {
  unsigned int rownum = 3;
  __builtin_strncpy(table[rownum-1].name, name, sizeof(table[0].name));
}

[Bug tree-optimization/118206] [15 regression] libdeflate miscompiled by ifcombine since r15-6360-g6d5df5133c5dd8

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/118210] g++-14.2 fails to parse template lambda expression operator()<>() call inside the requires expression.

[piotr.rak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Piotr Rak  ---
Thanks, and sorry I did not found it.

[Bug c++/118214] [15 regression] OpenTTD test failure with C++ large initializer

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

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

--- Comment #2 from Sam James  ---
No, still fails

[Bug c++/118214] [15 regression] OpenTTD test failure with C++ large initializer

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/118214] New: [15 regression] OpenTTD test failure with C++ large initializer

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

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

Bug ID: 118214
   Summary: [15 regression] OpenTTD test failure with C++ large
initializer
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Originally reported downstream in Gentoo at https://bugs.gentoo.org/946984 with
OpenTTD tests failing, e.g. "PartialPixelTest - One corner up slopes -
SLOPE_N".

```
#include 
#include 

enum Slope {
SLOPE_N = 8U
};

static const unsigned int TILE_SIZE = 16U;

__attribute__((noipa))
bool CheckPartialPixelZ(Slope slope, std::array
expected)
{
int actual[TILE_SIZE * TILE_SIZE] = {8, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3,
2, 2, 1, 1, 0,
7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0,
7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0,
6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0,
6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0,
5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0,
5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0,
4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0,
4, 3};
for (unsigned int i = 0; i < expected.size(); i++) {
if (actual[i] != expected[i]) __builtin_trap();
}
return true;
}

int main() {
CheckPartialPixelZ(SLOPE_N, {
8, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0,
7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0,
7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0,
6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0,
6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0,
5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0,
5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0,
4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0,
4, 3, }
);
}
```

[Bug c++/118214] [15 regression] OpenTTD test failure with C++ large initializer

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

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

--- Comment #1 from Andrew Pinski  ---
Does removing the trailing comma fix the issue?

[Bug fortran/47928] Gfortran intrinsics documentation paragraph ordering illogical

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

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

--- Comment #4 from sandra at gcc dot gnu.org ---
The other GCC manuals I'm familiar with don't format things like man pages;
they use things like @deftypefn instead (e.g., see libgcc.texi).  I'm
definitely not volunteering to rewrite the whole intrinsics chapter that way,
but yes, I will move sections around en masse if there's consensus that's the
right thing to do.

FWIW I agree with the original comments that it's confusing to have references
to the arguments in the description before the syntax paragraph that tells you
what the arguments are, and that the standard info is relatively uninteresting.
 But I'll defer to the Fortran maintainers on how best to present this
language-specific information.

[Bug tree-optimization/118213] New: IVOPT causes superfluous IVs

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 118213
   Summary: IVOPT causes superfluous IVs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

See the case,

  int foo(char *a, char *b, int s, int n)
  {
 while (++s != n) {
   if (a[s] != b[s])
 break;
 }
 return s;
  }

Originally, memory accesses to "a[]" and "b[]" own a same IV, while after
IVOPT, two IVs are generated for each access respectively, difference between
the IVs is 1. This would cause some superfluous IV-related computation in both
loop prolog and body. On aarch64, we would get below suboptimal code-gen:

.LFB0:
.cfi_startproc
add w2, w2, 1
mov x6, x0
sub x1, x1, #1
sxtwx0, w2
b   .L2
.p2align 2,,3
.L3:
ldrbw5, [x6, x0]   #base: x6 = a, index: x0 
ldrbw4, [x1, x2]   #base: x1 = b - 1, index: x2 = x0 + 1 
cmp w5, w4
bne .L6
mov x0, x2
.L2:
add x2, x0, 1
cmp w3, w0
bne .L3
.L6:
ret

[Bug fortran/47928] Gfortran intrinsics documentation paragraph ordering illogical

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
What do the other gcc manuals do? Are you offering to do this for us?

[Bug fortran/47928] Gfortran intrinsics documentation paragraph ordering illogical

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
This sort of thing can easily be scripted using e.g. Emacs keyboard macros or a
bit of lisp code, and/or some sed magic.  The real question is, is there
consensus this a good idea?

[Bug tree-optimization/118207] [15 regression] ICE when building dosbox-staging-0.82.0 (in fold_convert_loc, at fold-const.cc:2779) since r15-6339-g40f243e9179667

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

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

Sam James  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[15 regression] ICE when|[15 regression] ICE when
   |building|building
   |dosbox-staging-0.82.0 (in   |dosbox-staging-0.82.0 (in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.cc:2779) |fold-const.cc:2779) since
   ||r15-6339-g40f243e9179667

--- Comment #5 from Sam James  ---
(In reply to Andrew Pinski from comment #4)
> Confirmed. I suspect it was r15-6339-g40f243e9179667 .

yes r15-6339-g40f243e9179667

[Bug c++/118210] g++-14.2 fails to parse template lambda expression operator()<>() call inside the requires expression.

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

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

--- Comment #1 from Andrew Pinski  ---
lambdas in a requires statement is known to be broken ...

[Bug middle-end/118007] ICE when building ruby-3.2.5 with -fstrub=all

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #6 from Sam James  ---
Fixed (unless you want to backport it, but I'm not fussed) (and thanks!)

[Bug c++/118214] [15 regression] OpenTTD test failure with C++ large initializer since r15-6339-g40f243e9179667

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] OpenTTD |[15 regression] OpenTTD
   |test failure with C++ large |test failure with C++ large
   |initializer |initializer since
   ||r15-6339-g40f243e9179667

--- Comment #3 from Sam James  ---
```
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
40f243e91796671701ded90919d1ca32ba9076ad
549af7288332d698d45bbbcf3c61aaeb193fb716
15dbb0a9ee8317c2a1983793d532c1f814ae1e33
e2f6ed54f75bbf8dd0292af90304890f06a9be17
17d8a3da25cd5262df1075b210cb4fa707c527df
We cannot bisect more!
error: bisect run cannot continue any more
```

so r15-6339-g40f243e9179667 as expected