[Bug c++/112715] Incorrect handling of template type aliases instantiated from decltype of lambdas

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

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

--- Comment #1 from David Mazières  ---
I should have mentioned, I hereby place the test case in the public domain.

[Bug c++/112715] New: Incorrect handling of template type aliases instantiated from decltype of lambdas

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

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

Bug ID: 112715
   Summary: Incorrect handling of template type aliases
instantiated from decltype of lambdas
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at nospam dot scs.stanford.edu
  Target Milestone: ---

Created attachment 56689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56689=edit
File that should compile but doesn't

I'm using g++ version 13.2.1 on arch linux, configured as follows:


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.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,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--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 13.2.1 20230801 (GCC) 


When defining template type aliases, I get bizarrely incorrect types in some
contexts but not others.  For example, the static assertion fails in this code
but should not:


#include 

template
using uintsz = decltype([](auto i){
  if constexpr (i <= 32)
return 0;
  else
return 0L;
 }(std::integral_constant{}));

template
constexpr uintsz<8*Nbytes>
f()
{
  return 0;
}

static_assert(std::is_same_v()), uintsz<56>>);


Specifically I get the following error:


$ g++ -std=c++20 -ggdb -O -Wall -c -o uintsz.o uintsz.cc
uintsz.cc:18:20: error: static assertion failed
   18 | static_assert(std::is_same_v()), uintsz<56>>);
  |   ~^~~


This feels like some sort of state corruption in the compiler, because there
are more complicated examples in which gcc rejects other things inside
functions (like rejecting a using type alias and accepting the corresponding
typedef).  I think this example suffices to show the problem, but I could try
to reduce another test case if necessary.  In all cases, clang++ -std=c++20
accepts the code.

[Bug testsuite/112714] New: gcc.dg/tree-ssa/predcom-2.c fails on aarch64-* with -march=armv9-a+sve

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

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

Bug ID: 112714
   Summary: gcc.dg/tree-ssa/predcom-2.c fails on aarch64-* with
-march=armv9-a+sve
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Similar to how gcc.dg/unroll-8.c is handled, gcc.dg/tree-ssa/predcom-2.c 
should be handled too.
Note right now we have:
/* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* riscv*-*-*
} } */

See also https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637835.html .

[Bug target/112531] [14] RISC-V: gcc.dg/unroll-8.c rtl-dump scan errors with --param=riscv-autovec-preference=scalable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv   |riscv aarch64-*-*
 CC||pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
I have the same failure on aarch64 with -march=armv9-a+sve:
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"


https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637835.html

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug testsuite/112691] [14 Regression] gcc.dg/vla-1.c fails

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

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

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-5850-gbd7f16b43e2afe5bd8429479485b5c70cedbdee6
Author: Andrew Pinski 
Date:   Sat Nov 25 20:24:56 2023 -0800

Fix gcc.dg/vla-1.c

r14-5628-g53ba8d669550d3 added noipa to f1 but `-fno-ipa-vrp` should have
been used
instead. The testcase is testing about the clone of f1 so turning off
IPA VRP is the correct approach here rather than turning off of IPA on the
function.

gcc/testsuite/ChangeLog:

PR testsuite/112691
* gcc.dg/vla-1.c: Add -fno-ipa-vrp.
Remove noipa from f1.

Signed-off-by: Andrew Pinski 

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-5849-ga9693bff396b28748464630e4c524776bce3ff4e
Author: Andrew Pinski 
Date:   Sat Nov 25 18:50:46 2023 -0800

Fix gcc.target/aarch64/simd/vmulxd_{f64,f32}_2.c after after IPA-VRP
improvement for return values

Just like the patch against gcc.target/aarch64/movk.c, the issue here
is the two functions, foo32 and foo64 needed to mark as noipa so that
IPA-VRP cannot propagate the return value.

gcc/testsuite/ChangeLog:

PR testsuite/112688
* gcc.target/aarch64/simd/vmulx.x (foo32): Mark as noipa rather
than noinline.
(foo4): Likewise.

Signed-off-by: Andrew Pinski 

[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed on the trunk.

[Bug c++/108321] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

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

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

--- Comment #8 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:6e15e4e1abed02443a27a69455f4bfa49457c99e

commit r14-5848-g6e15e4e1abed02443a27a69455f4bfa49457c99e
Author: Andrew Pinski 
Date:   Thu Nov 23 18:55:30 2023 -0800

Fix contracts-tmpl-spec2.C on targets where plain char is unsigned by
default

Since contracts-tmpl-spec2.C is just testing contracts, I thought it would
be better
to just add `-fsigned-char` to the options rather than change the testcase
to support
both cases.

Committed after testing on aarch64-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/108321
* g++.dg/contracts/contracts-tmpl-spec2.C: Add -fsigned-char
to options.

Signed-off-by: Andrew Pinski 

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #6 from Bruno Haible  ---
For comparison, what clang 17 with -fsanitize=address does in this situation,
is to not generate a stepping point at the function entry (xg-message.c:50).
The gdb 'step' command brings me directly to the first statement in the
function (xg-message.c:55). This may have some other drawbacks, but at least it
prevents the possibility of displaying wrong values for function parameters.

[Bug target/112443] [12/13/14 Regression] Misoptimization of _mm256_blendv_epi8 intrinsic on avx512bw+avx512vl

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |crazylht at gmail dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Sam James  ---
Fixed for 12.4/13.3/14.

[Bug c/112713] New: RISC-V: Trunk GCC regression on VSETVL PASS comparing with GCC-13

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 112713
   Summary: RISC-V: Trunk GCC regression on VSETVL PASS comparing
with GCC-13
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

https://godbolt.org/z/qePhcxd5z

#include "riscv_vector.h"

size_t
foo (char const *buf, size_t len)
{
size_t sum = 0;
size_t vl = __riscv_vsetvlmax_e8m8();
size_t step = vl * 4;
const char *it = buf, *end = buf + len;
for(; it + step <= end; ) {
it += vl;
vint8m8_t v3 = __riscv_vle8_v_i8m8((void*)it, vl); it += vl;
vbool1_t m3 = __riscv_vmsgt_vx_i8m8_b1(v3, -65, vl);
sum += __riscv_vcpop_m_b1(m3, vl);
}
return sum;
}

GCC-14 ASM:

foo:
vsetvli a4,zero,e8,m8,ta,ma
sllia5,a4,2
add a1,a0,a1
add a5,a0,a5
bltua1,a5,.L4
sllia6,a4,1
add a5,a0,a4
add t1,a6,a4
li  a0,0
li  a7,-65
vsetvli zero,zero,e8,m8,ta,ma   --> redundant
.L3:
vle8.v  v8,0(a5)
add a5,a5,a6
add a3,t1,a5
vmsgt.vxv8,v8,a7
vcpop.m a2,v8
add a0,a0,a2
bgeua1,a3,.L3
ret
.L4:
li  a0,0
ret

GCC-13 ASM:

foo:
vsetvli a4,zero,e8,m8,ta,ma
sllia5,a4,2
add a1,a0,a1
add a5,a0,a5
bltua1,a5,.L4
sllia6,a4,1
add a5,a0,a4
add t1,a6,a4
li  a0,0
li  a7,-65
.L3:
vle8.v  v8,0(a5)
add a5,a5,a6
add a3,t1,a5
vmsgt.vxv24,v8,a7
vcpop.m a2,v24
add a0,a0,a2
bgeua1,a3,.L3
ret
.L4:
li  a0,0
ret

Trunk GCC-14 has a regression that cause a redundant vsetvl.

Such regression need to be fixed and I will take a look at it.

[Bug c++/112712] New: Crash when compiling g++ -m68020-60 -O2

[miro.kropacek at gmail dot com via Gcc-bugs]

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

Bug ID: 112712
   Summary: Crash when compiling g++ -m68020-60 -O2
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miro.kropacek at gmail dot com
  Target Milestone: ---

Created attachment 56688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56688=edit
Preprocessed output

This is a crash which seems to be specific to the -m68020-60 option (or better
said to 060 code generation as the only other option where this bugs occurs is
-m68060). When changing to any other CPU (-m68000, -mcpu=5475, ...) and/or
changing to -O1, -O0, ... everything is fine.

See the attached preprocessed file which triggers the bug:

m68k-elf-g++ -c -g -O2 -m68020-60 -fomit-frame-pointer -funsigned-char
-std=gnu++20 -fvisibility=hidden -Wno-sign-compare crash.cpp

similar/main/multi.cpp:6167:1: internal compiler error: in push_reload, at
reload.cc:1124
 6167 | }
  | ^
0x15fee77 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x15ffd3c internal_error(char const*, ...)
???:0
0x5e9465 fancy_abort(char const*, int, char const*)
???:0
0x5c9a9d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class,
machine_mode, machine_mode, int, int, int, reload_type) [clone .cold]
???:0
0xca2ffb find_reloads(rtx_insn*, int, int, int, short*)
???:0
0xcb0dcb reload(rtx_insn*, int)
???:0
0xb4657a (anonymous namespace)::pass_reload::execute(function*)
???:0
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 target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Alex Henrie  ---
I should clarify that I was testing with GCC 12.2. It turns out that GCC 12.3
does not crash, and I have now confirmed that the patch from comment #5 applied
to GCC 12.3 fixes https://bugs.winehq.org/show_bug.cgi?id=55007

What will it take to get the patch accepted?

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

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

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

--- Comment #3 from Andrew Pinski  ---
movk.c is fixed, I will submit the change for vmulxd_*_2.c in a few.

[Bug testsuite/112688] [14 Regression] testcases: gcc.target/aarch64/movk.c and vmulxd_*_2.c need to updated after r14-5628-g53ba8d669550d3

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:8d559a9b85d9a6de4f358171178a74605f554082

commit r14-5845-g8d559a9b85d9a6de4f358171178a74605f554082
Author: Andrew Pinski 
Date:   Tue Nov 21 18:25:24 2023 -0800

Fix gcc.target/aarch64/movk.c testcase after IPA-VRP improvement for return
values

The problem here is dummy_number_generator returns a constant which IPA VRP
is now able
propagate that so we need to mark the funciton as noipa to stop that.

gcc/testsuite/ChangeLog:

PR testsuite/112688
* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

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

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

--- Comment #3 from Sergei Trofimovich  ---
I confirm bisect landed on r14-5831-gaae723d360ca26 as well.

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109849
 CC||mjambor at suse dot cz

--- Comment #2 from Andrew Pinski  ---
I am 90% sure it was introduced by r14-5831-gaae723d360ca26 .

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-25
   Target Milestone|--- |14.0
Summary|[14 Regression] possibly|[14 Regression] SRA seems
   |wrong code in bswap32(int)  |to ignore writes when using
   |on llvm-16.0.6 test suite   |__builtin_assume_aligned
  Component|target  |tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||alias

--- Comment #1 from Andrew Pinski  ---
It has nothing to do with __builtin_bswap32 really but rather
__builtin_assume_aligned and the memcpy.

SRA does not detect:
  _9 = __builtin_assume_aligned (, 1);
  MEM  [(char * {ref-all})_9] = 3451308718;
  _1 = data[0];


The store to _9 as touching data ...

[Bug sanitizer/112709] [13/14 Regression] address sanitize and returns_twice causes an ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|address sanitize and|[13/14 Regression] address
   |returns_twice causes an ICE |sanitize and returns_twice
   ||causes an ICE
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-25
   Target Milestone|--- |13.3

--- Comment #1 from Andrew Pinski  ---
Confirmed, the checking is new in GCC 13. Though it seems like GCC 5 produced
IR that was ok.

I am not 100% sure how we should handle this case either.

[Bug middle-end/112711] New: [14 Regression] possibly wrong code in bswap32(int) on llvm-16.0.6 test suite

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

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

Bug ID: 112711
   Summary: [14 Regression] possibly wrong code in bswap32(int) on
llvm-16.0.6 test suite
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially noticed possibly wrong code on llvm-16.0.6 test suite when building
with gcc-master from r14-5844-g9c26c91b94eb72:

  Failed Tests (2):
LLVM-Unit :: Support/./SupportTests/Endian/Write
LLVM-Unit :: Support/./SupportTests/Endian/WriteBitAligned

I extracted the following self-contained example:

// $ cat EndianTest.cpp
typedef  int i32;
typedef unsigned int u32;

static inline void write_i32(void *memory, i32 value) {
  // swap i32 bytes as if it was u32:
  u32 u_value = value;
  value = __builtin_bswap32(u_value);

  // llvm infers '1' alignment from destination type
  __builtin_memcpy(__builtin_assume_aligned(memory, 1), , sizeof(value));
}

__attribute__((noipa))
static void bug (void) {
  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()

  unsigned char data[5];
  write_i32(data, -1362446643);
  assert_eq(data[0], 0xAE);
  assert_eq(data[1], 0xCA);
  write_i32(data + 1, -1362446643);
  assert_eq(data[1], 0xAE);
}

int main() {
bug();
}

Fails as:

$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O0 && ./bug
$ gcc/xg++ -Bgcc EndianTest.cpp -o bug -O2 && ./bug
Illegal instruction (core dumped)

$ gcc/xg++ -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xg++
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231125 (experimental) (GCC)

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Alex Henrie  ---
Created attachment 56687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56687=edit
Minimal example to reproduce the crash

Here's a minimal example that crashes on MinGW 12 with -m32 -mavx512f
-mpreferred-stack-boundary=2. I tried it with MinGW 13 on Compiler Explorer
 and it does not crash, so it looks like that bug has
been fixed already.

[Bug fortran/106856] [12 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

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

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
*** Bug 96655 has been marked as a duplicate of this bug. ***

[Bug fortran/96655] [OOP] CLASS dummy arguments: Bogus "Duplicate OPTIONAL attribute specified"

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
This a variation of pr106856, fixed in 12.3, thus a duplicate.

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

[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #11 from anlauf at gcc dot gnu.org ---
Possibly related: pr93762 (see Steve's analysis).

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Alex Henrie  ---
Well, this is interesting: Unpatched MinGW 12 crashes in the same way if I set
both -march=native and -mpreferred-stack-boundary=2. So the problem is not the
patch itself, it's just that the patch revealed some other bug.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[gabrielopcode at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Gabriel Ivăncescu  ---
(In reply to Alexander Monakov from comment #9)
> -mpreferred-stack-boundary=n means that functions consume stack in
> increments of 2**n. This is sufficient to ensure that once stack is aligned
> to that boundary, it will keep it without the need for dynamic realignment.
> 
> -mincoming-stack-boundary specifies the guaranteed alignment on entry. If
> the function needs to place local variables with greater alignment
> requirement on the stack, it has perform dynamic realignment.

Yeah, but on 32-bit x86 Windows ABI, the stack is only guaranteed to be aligned
to 4 bytes (mincoming-stack-boundary=2). We don't control the callers, and apps
compiled with MSVC (i.e. the majority of them, including Windows' own
libraries) only adhere to this alignment, nothing more than that.

Therefore -mincoming-stack-boundary=2 should be the default on MinGW for this
target.

In general, setting -mpreferred-stack-boundary=2 is also preferable because the
vast majority of functions do *not* use SSE or AVX or whatever. If you set
-mpreferred-stack-boundary=4 it will *always* align the stack on entry, and
that's simply too much overhead. It's better only for functions that actually
need it to do it.

The point is, -mpreferred-stack-boundary=2 (and consequently
-mincoming-stack-boundary=2) is the default on MSVC and Windows 32-bit x86 ABI,
and that's for a reason. MinGW should follow that. By default, at least.

I've compiled Wine with those options for years now without trouble.

[Bug target/112443] [12/13/14 Regression] Misoptimization of _mm256_blendv_epi8 intrinsic on avx512bw+avx512vl

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Mikael Pettersson  ---
Can this be closed now?

[Bug preprocessor/112701] wrong type inference for ternary operator with `0/0u` in preprocessing context

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
gcc-2.95.3 generates neither, gcc-3.0.4 and up generate the bar: .long 0 (or
.zero 4) one.

[Bug tree-optimization/110062] missed vectorization in graphicsmagick

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

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

--- Comment #11 from Jan Hubicka  ---
trunk -O3 -flto -march=native -fopenmp
Operation: Sharpen:
257
256
256

Average: 256 Iterations Per Minute
GCC13 -O3 -flto -march=native -fopenmp
257
256
256

Average: 256 Iterations Per Minute
clang17 O3 -flto -march=native -fopenmp
   Operation: Sharpen:
257
256
256
Average: 256 Iterations Per Minute

So I guess I will need to try on zen3 to see if there is any difference.

the internal loop is:
  0.00 │460:┌─→movzbl  0x2(%rdx,%rax,4),%esi ▒
  0.02 ││  vmovss  (%r8,%rax,4),%xmm2▒
  0.95 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 20.22 ││  movzbl  0x1(%rdx,%rax,4),%esi ▒
  0.01 ││  vfmadd231ss %xmm1,%xmm2,%xmm3 ▒
 11.97 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 18.76 ││  movzbl  (%rdx,%rax,4),%esi▒
  0.00 ││  inc %rax  ▒
  0.72 ││  vfmadd231ss %xmm1,%xmm2,%xmm4 ▒
 12.55 ││  vcvtsi2ss   %esi,%xmm0,%xmm1  ▒
 14.95 ││  vfmadd231ss %xmm1,%xmm2,%xmm5 ▒
 15.93 │├──cmp %rax,%r13 ▒
  0.35 │└──jne 460  

so it still does not get

[Bug target/109811] libjxl 0.7 is a lot slower in GCC 13.1 vs Clang 16

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

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

--- Comment #18 from Jan Hubicka  ---
I made a typo:

Mainline with -O2 -flto  -march=native run manually since build machinery patch
is needed
23.03
22.85
23.04

Should be 
Mainline with -O3 -flto  -march=native run manually since build machinery patch
is needed
23.03
22.85
23.04

So with -O2 we still get slightly lower score than clang with -O3 we are
slightly better. push_back inlining does not seem to be a problem (as tested by
increasing limits) so perhaps more agressive unrolling/vectorization settings
clang has at -O2.

I think upstream jpegxl should use -O3 or -Ofast instead of -O2.  It is quite
typical kind of task that benefits from large optimization levels.

I filled in https://github.com/libjxl/libjxl/issues/2970

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

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

commit r14-5844-g9c26c91b94eb72397a4892b28022070a33636492
Author: Gerald Pfeifer 
Date:   Sat Nov 25 14:10:25 2023 +0100

doc: Complete and sort the list of front ends

gcc:

PR other/69374
* doc/install.texi (Downloading the source): Sort the list of
front ends and add D, Go, and Modula-2.

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

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

commit r14-5843-gf7df9d7aca6b7978ad4c08ee24267787a805a301
Author: Gerald Pfeifer 
Date:   Sat Nov 25 13:31:22 2023 +0100

doc: Remove obsolete notes on GCC 4.x on FreeBSD

FreeBSD 6 and 7 have been end of life for years as have been GCC 4.x
releases, so no point in detailing specifics of changes around those.

gcc:

PR target/69374
* doc/install.texi (Specific) <*-*-freebsd*>: Remove older
contents referencing GCC 4.x.

[Bug middle-end/112710] New: [13/14 Regression] ICE: in write_type, at cp/mangle.cc:2226 with -fdump-go-spec=filename -flto -fno-use-linker-plugin

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112710
   Summary: [13/14 Regression] ICE: in write_type, at
cp/mangle.cc:2226 with -fdump-go-spec=filename -flto
-fno-use-linker-plugin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  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 56686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56686=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fdump-go-spec=filename -flto -fno-use-linker-plugin
testcase.C -w
testcase.C:2:6: internal compiler error: in write_type, at cp/mangle.cc:2226
2 | void foo(const bool *);
  |  ^~~
0x761ff3 write_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2226
0xfcec7d write_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2398
0xfd087e write_method_parms
/repo/gcc-trunk/gcc/cp/mangle.cc:2880
0xfd0a97 write_bare_function_type
/repo/gcc-trunk/gcc/cp/mangle.cc:2816
0xfd0c2c write_mangled_name
/repo/gcc-trunk/gcc/cp/mangle.cc:810
0xfd1410 mangle_decl_string
/repo/gcc-trunk/gcc/cp/mangle.cc:4092
0xfd15fa get_mangled_id
/repo/gcc-trunk/gcc/cp/mangle.cc:4113
0xfd15fa mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4151
0x1acb60d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x14a2f8d go_output_fndecl
/repo/gcc-trunk/gcc/godump.cc:1109
0x14a2f8d go_finish
/repo/gcc-trunk/gcc/godump.cc:1408
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-r14-5841-20231125103155-g9866c98e101-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5841-20231125103155-g9866c98e101-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231125 (experimental) (GCC)

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

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

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

liuhongt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #21 from liuhongt at gcc dot gnu.org ---
The main gap is from openmp for hybrid machine.

[Bug fortran/100651] [11/12/13/14 Regression] Weird memory corruption with multiple triggers

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org
   Last reconfirmed|2021-07-29 00:00:00 |2023-11-25
 Target|x86_64-linux-gnu,   |
   |x86_64-apple-darwin |

--- Comment #10 from Francois-Xavier Coudert  ---
Further reduced to this:

meau /tmp $ cat a.f90
program main
  character(:), allocatable :: err_msg
  call to_int(err_msg)
  print *, 'allocated :', allocated(err_msg)
  print *, err_msg(1:7)
  print *, 'len :  ', len(err_msg)
  print *, 'err_msg :  ', err_msg
contains
  subroutine assert_code(err_msg)
character(:), optional, allocatable :: err_msg
err_msg = 'foo bar'
  end
  subroutine to_int(err_msg)
character(:), optional, allocatable :: err_msg
call assert_code(err_msg)
  end
end
meau /tmp $ gfortran a.f90 -O0 -g && ./a.out
 allocated : T
 foo bar
 len :  39026212
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc


The problem is in the code generated for the to_int subroutine, handling the
optional aspect. We can see above that the string is allocated and set
correctly. However, the length is not correctly set. You can see from the dump:

__attribute__((fn spec (". w ")))
void to_int (character(kind=1)[1:*_err_msg] * * err_msg, integer(kind=8) *
_err_msg)
{
  {
character(kind=1)[1:*_err_msg] * * D.3001;
integer(kind=8) D.3002;

D.3001 = err_msg != 0B ? err_msg : 0B;
D.3002 = err_msg != 0B ? *_err_msg : 0;
assert_code (D.3001, );
  }
}

The string length passed as second argument to assert_code is a pointer to a
local variable, and its value will not be propagated back into _err_msg (the
string length passed to to_int).

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #26 from Eric Gallager  ---
(In reply to Richard Biener from comment #20)
> Unfortunately there isn't a knob to diagnose late inlined always-inline
> functions.

Is there a separate bug for this?

[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed, eventhough backports are planned (but just for latent issue).

[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og since r14-215-g85279b0bddc1c5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9866c98e1015d98b8fc346d7cf73a0070cce5f69

commit r14-5841-g9866c98e1015d98b8fc346d7cf73a0070cce5f69
Author: Jakub Jelinek 
Date:   Sat Nov 25 10:31:55 2023 +0100

i386: Fix up *jcc_bt*_mask{,_1} [PR111408]

The following testcase is miscompiled in GCC 14 because the
*jcc_bt_mask and *jcc_bt_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.

I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).

I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.

2023-11-25  Jakub Jelinek  

PR target/111408
* config/i386/i386.md (*jcc_bt_mask,
*jcc_bt_mask_1): Add (const_int 0) as expected
second operand of bt_comparison_operator.

* gcc.c-torture/execute/pr111408.c: New test.

[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og since r14-215-g85279b0bddc1c5

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-5840-ga6a43a3b763816fec7c4eec6ae7be5b263dff340
Author: Jakub Jelinek 
Date:   Sat Nov 25 10:30:39 2023 +0100

aarch64: Fix up aarch64_simd_stp [PR109977]

The aarch64_simd_stp pattern uses w constraint in one alternative and
r in another, but for the latter incorrectly uses  iterator in %1
which
expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to
the pattern) and %w1 for others, so it ICEs if the alternative is selected
during final.  Compared to this,  macro has the same values for all
modes but uses w for V2DF and V2SF.

2023-11-24  Andrew Pinski  
Jakub Jelinek  

PR target/109977
* config/aarch64/aarch64-simd.md (aarch64_simd_stp): Use

rather than % for alternative with r constraint on input
operand.

* gcc.dg/pr109977.c: New test.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #9 from Alexander Monakov  ---
-mpreferred-stack-boundary=n means that functions consume stack in increments
of 2**n. This is sufficient to ensure that once stack is aligned to that
boundary, it will keep it without the need for dynamic realignment.

-mincoming-stack-boundary specifies the guaranteed alignment on entry. If the
function needs to place local variables with greater alignment requirement on
the stack, it has perform dynamic realignment.