[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #13 from Jürgen Reuter  ---
The daily bump in the morning of Friday, June 14, 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=028cd77db322d21312680c9a0a7c30565854f577
shows the segmentation fault, so the culprit comment must have happened on
Thursday, June 13, my guess would be that it's one of these two:
6 days ago  Richard Biener  tree-optimization/115385 - handle more gaps
with peelin...  commit | commitdiff | tree
6 days ago  Richard Biener  tree-optimization/114107 - avoid peeling for
gaps in... commit | commitdiff | tree

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

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

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

--- Comment #14 from Andi Kleen  ---
Latest patchkit is here, but stalled due to lack of reviewers:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653319.html

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #12 from Andrew Pinski  ---
Note when I am adding V4QI support to the aarch64 backend (emulating it via
V8QI), I am getting a failure in slp-gap-1.c but it is different from the
others.

Without V4QI, the pattern matched `\{_\[0-9\]\+, 0` was able to match 6 times.

we got in the IR:
```
  unsigned int _50;
  vector(2) unsigned int _49;
...
  _50 = MEM  [(uint8_t *)vectp_pix1.5_58];
  _49 = {_50, 0};
```


But afterwards we now get:
```
  vector(4) unsigned char _50;
  vector(8) unsigned char vect__34.9;
...
  _50 = MEM  [(uint8_t *)vectp_pix1.5_58];
  vect__34.9_49 = {_50, { 0, 0, 0, 0 }};
```

Which produces the exact same code. I am trying to figure out the best way to
change the testcase pattern to make sure we don't match:
  vect__37.23_6 = VEC_PERM_EXPR ;

too.

`\{_\[0-9\]\+, { 0, 0` I think that will work but should I just do an
alternative for the scan-tree-dump-times or should I put it as a seperate one
with some target selection here?

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

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

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan  ---
Matthias - are you looking to go further back than GCC 13 for this ?

[Bug target/115342] [14/15 Regression] AArch64: Function multiversioning initialization incorrect

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

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-06-20

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed ?

[Bug target/115475] AArch64 should define __ARM_FEATURE_SVE_BF16 when appropriate

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

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Patrick O'Neill  ---
This failure also appears when compiling glibc 2.39 with rv64gcv_zvl512b and
rv64gcv_zvl1024b.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by YunQiang Su :

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

commit r15-1466-gbea447a2982f3094aa3423b5045cea929f4f4700
Author: Collin Funk 
Date:   Wed Jun 19 16:36:50 2024 -0700

build: Fix missing variable quotes and typo

When dlopen and pthread_create are in libc the variable is
set to "none required", therefore running configure will show
the following errors:

./configure: line 8997: test: too many arguments
./configure: line 8999: test: too many arguments
./configure: line 9003: test: too many arguments
./configure: line 9005: test: =: unary operator expected

ChangeLog:

PR bootstrap/115453
* configure.ac: Quote variable result of AC_SEARCH_LIBS.  Fix
typo ac_cv_search_pthread_crate.
* configure: Regenerate.

Signed-off-by: Collin Funk 

[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #7 from Jiang An  ---
(In reply to Jonathan Wakely from comment #5)
> Ah, it looks like is_trivial is just wrong for types with a deleted default
> constructor, that's PR 85723
> 
> The std::to_array code _should_ work correctly for this case :-\

I guess we still need to check is_default_constructible_v even after
__is_trivial gets fixed because the default construct may be protected or
private...

[no subject]

[บริษัทเพิ่มทรัพย์ เครดิต via Gcc-bugs]

วงเงินสินเชื่อพร้อมใช้เสริมสภาพคล่องสำหรับบริษัท
ทุกขนาดและโรงงานอุตสาหกรรม
อนุมัติสูงสุด 10,000,000 บาท
เอกสารไม่ยุ่งยาก
ไม่ต้องมีคนค้ำหรือหลักทรัพย์ ผ่านการอนุมัติ รับเงินทันที

#สอบถามข้อมูลเพิ่มเติมได้ที่
▫️โทร  : 0908863804 (คุณ สรวิชญ์)
▫️ ไอดีไลน์ : ptery9992
** การอนุมัติขึ้นอยู่กับระเบียบบริษัทและคุณสมบัติของผู้กู้ **
❗️เตือนบริษัทเราไม่มีเรียกเก็บมัดจำหรือให้ท่านโอนก่อนทุกกรณีค่ะ

[Bug target/115462] [15 regression] 416.gamess regressed 4-6% on x86_64 since r15-882-g1d6199e5f8c1c0

[lin1.hu at intel dot com via Gcc-bugs]

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

Hu Lin  changed:

   What|Removed |Added

 CC||lin1.hu at intel dot com

--- Comment #3 from Hu Lin  ---
I looked up the hotspot for this test. 

At int2a.F:570 (we output its .f file int2a.fppized.f.), its source code is 

 566   DO 200 K = 1,MAX
 567   MX = NX+KLX(K)
 568   MY = NY+KLY(K)
 569   MZ = NZ+KLZ(K)
 570   N = N1+KLGT(K)
 571   200 GHONDO(N) = ( XIN(MX )*YIN(MY )*ZIN(MZ ) +XIN(MX+625)*YIN(MY+625)*
 572  + ZIN(MZ+625) +XIN(MX+1250)*YIN(MY+1250)*ZIN(MZ+1250) )*D1*
 573  + DKL(K)+GHONDO(N)
.

At this loop's beginning, the original ASM code is  
mov 0x271e3c98(,%rdx,4),%edi
mov 0x271e401c(,%rdx,4),%esi
mov 0x271e43a0(,%rdx,4),%ecx
mov 0x271e3914(,%rdx,4),%r8d
.
But after r15-882-g1d6199e5f8c1c0, the ASM code is
mov $0x27bf6c98, %r10d
mov $0x27bf701c, %r9d
mov $0x27bf73a0, %esi
movl  (%rbx,%rdx,4), %ecx
movl  (%r10,%rdx,4), %edi
movl  (%r9,%rdx,4), %r8d
movl  (%rsi,%rdx,4), %esi
.
In addition to this loop other places also have some similar extra
instructions. These instructions increase the instruction retired by about the
similar percentage as the regression.

[Bug middle-end/115551] [missed optimization] "c1 << (a + c2)" not optimized into "(c1 << c2) << a"

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
"c1 << (-5 + 5)" is fine but "(c1 << -5) << 5" invokes undefined behavior. 
Thus we need some range info to do this optimization.

[Bug c/115549] ICE: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in common_handle_aligned_attribute, at c-family/c-attribs.cc:2665 with invalid aligned attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
   Severity|normal  |trivial

--- Comment #1 from Andrew Pinski  ---
I suspect r8-5161-g5d9ae53d70c729 might have introduced this.

Confirmed.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

[collin.funk1 at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Collin Funk  ---
(In reply to Mark Wielaard from comment #15)
> -Copyright (C)  Free Software Foundation, Inc.
> +Copyright (C) 2012 Free Software Foundation, Inc.

I thought I used the correct Autoconf version, but I guess not. I think this
should go away if you regenerate with Autoconf 2.69 (released in 2012).

> -if test "x$gcc_cv_as_mips_explicit_relocs_pcrel" = "xyes"; then
> +if test $gcc_cv_as_mips_explicit_relocs_pcrel = yes; then

I think my commit was amended to include this. Therefore the configure script
must be generated again.

Sorry for the confusion.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #15 from Mark Wielaard  ---
Something seems to have gone slightly wrong when regenerating the configure
files.
The gcc-autoregen bot is unhappy:
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen

https://builder.sourceware.org/buildbot/#/builders/269/builds/5952

Sourceware

Buildersgcc-autoregen5952git diffstdio

Anonymous

git diff --exit-code
 in dir /home/builder/shared/bb2-2/worker/gcc-autoregen/build (timeout 1200
secs)
 watching logfiles {}
 argv: [b'git', b'diff', b'--exit-code']
 environment:
  BUILDMASTER=builder.sourceware.org
  BUILDMASTER_PORT=9989
  CCACHE_DIR=/home/builder/shared/autotools/ccache
  CCACHE_LIBDIR=/usr/lib/ccache
  HOME=/home/builder
  HOSTNAME=cf526139a6b4
  IMAGE_NAME=autotools
  LC_CTYPE=C.UTF-8
 
PATH=/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  PWD=/home/builder/shared/bb2-2/worker/gcc-autoregen/build
  WORKERNAME=bb2-2
 using PTY: False
diff --git a/configure b/configure
index 6e95b27d9df..03dad4d362d 100755
--- a/configure
+++ b/configure
@@ -19746,7 +19746,7 @@ config.status
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"

-Copyright (C)  Free Software Foundation, Inc.
+Copyright (C) 2012 Free Software Foundation, Inc.
 This config.status script is free software; the Free Software Foundation
 gives unlimited permission to copy, distribute and modify it."

diff --git a/gcc/configure b/gcc/configure
index b536af664d3..a8fc4bb34aa 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30239,7 +30239,7 @@ else
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result:
$gcc_cv_as_mips_explicit_relocs_pcrel" >&5
 $as_echo "$gcc_cv_as_mips_explicit_relocs_pcrel" >&6; }
-if test "x$gcc_cv_as_mips_explicit_relocs_pcrel" = "xyes"; then
+if test $gcc_cv_as_mips_explicit_relocs_pcrel = yes; then

 $as_echo "#define MIPS_EXPLICIT_RELOCS MIPS_EXPLICIT_RELOCS_PCREL"
>>confdefs.h

@@ -30498,7 +30498,7 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler and linker for
explicit JALR relocation" >&5
 $as_echo_n "checking assembler and linker for explicit JALR relocation... "
>&6; }
 gcc_cv_as_ld_jalr_reloc=no
-if test $gcc_cv_as_mips_explicit_relocs = yes; then
+if test "x$gcc_cv_as_mips_explicit_relocs" = "xyes"; then
   if test $in_tree_ld = yes ; then
 if test "$gcc_cv_gld_major_version" -eq 2 -a
"$gcc_cv_gld_minor_version" -ge 20 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
program finished with exit code 1
elapsedTime=0.410978

I am not sure what exactly could have caused this difference.

[Bug c/115552] wrong code at -O2 and above when strict-aliasing with uint128 and double

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

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

--- Comment #2 from Andrew Pinski  ---
So basically since main writes via a double type but then spookyhash_short
reads via a uint64_t type there is an alias violation.

Using an union to change the pointer type does not change there is an alias
violation happening. You need to use memcpy for copying from one type to
another in this case. 

Instead of doing:
c += u.p64[0];

You could do load_64([0]) and have load_64 defined to be:
```
static inline uint64_t load_64(void *a)
{
  uint64_t t;
  memcpy(, a, sizeof(t));
  return t;
}
```

[Bug target/114759] Power: multiple issues with -mrop-protect

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

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

--- Comment #7 from Peter Bergner  ---
Patch for item 3. submitted.

  https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655164.html

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

[collin.funk1 at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Collin Funk  ---
(In reply to Sam James from comment #11)
> But the crate vs create needs fixing still.

Oops. Sorry, I thought a correct patch here was being used not mine. If I had
known I would have submitted a fixed patch.

(In reply to YunQiang Su from comment #13)
> It has been fixed.

Thanks!

[Bug fortran/115553] New: Memory leak in openmp.cc's gfc_free_expr_list - gfc_expr not freed

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

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

Bug ID: 115553
   Summary: Memory leak in openmp.cc's gfc_free_expr_list -
gfc_expr not freed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

It looks as if a 'gfc_free_expr (list->expr)' is missing before the 'free' call
in:

However, I have not checked whether there are cases where only the list needs
to be removed and the gfc_expr is used (and later freed elsewhere).

* * *

/* Free expression list. */
void
gfc_free_expr_list (gfc_expr_list *list)
{
  gfc_expr_list *n;

  for (; list; list = n)
{
  n = list->next;
  free (list);
}
}

[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |13.4
 Status|NEW |RESOLVED

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0530884fbf49cc81119d66de7e4a48b47172ed4c

commit r13-8857-g0530884fbf49cc81119d66de7e4a48b47172ed4c
Author: Harald Anlauf 
Date:   Mon Jun 3 22:02:06 2024 +0200

Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]

gcc/fortran/ChangeLog:

PR fortran/83865
* trans-stmt.cc (gfc_trans_allocate): Restrict special case for
source-expression with zero-length character to rank 0, so that
the array shape is not discarded.

gcc/testsuite/ChangeLog:

PR fortran/83865
* gfortran.dg/allocate_with_source_32.f90: New test.

(cherry picked from commit 7f21aee0d4ef95eee7d9f7f42e9a056715836648)

[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 115390 Summary: Bogus -Wuninitialized warning when using CHARACTER(*) 
argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390

   What|Removed |Added

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

[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()

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

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

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

https://gcc.gnu.org/g:25860fd2a674373a6476af5ff0bd92354fc53d06

commit r15-1455-g25860fd2a674373a6476af5ff0bd92354fc53d06
Author: Jakub Jelinek 
Date:   Wed Jun 19 21:10:39 2024 +0200

bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

We don't really support _Complex _BitInt(N), the only place we use
bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function
results and COMPLEX_EXPR in the usual case should be either not present
yet because the ifns weren't folded and will be lowered, or optimized
into something simpler, because normally the complex bitint should be
used just for extracting the 2 subparts from it.
Still, with disabled optimizations it can occassionally happen that it
appears in the IL and that is why there is support for lowering those,
but it doesn't handle optimizing those too much, so if it uses SSA_NAME,
it relies on them having a backing VAR_DECL during the lowering.
This is normally achieves through the
  && ((is_gimple_assign (use_stmt)
   && (gimple_assign_rhs_code (use_stmt)
   != COMPLEX_EXPR))
  || gimple_code (use_stmt) == GIMPLE_COND)
hunk in gimple_lower_bitint, but as the following testcase shows, there
is one thing I've missed, the load optimization isn't guarded by the
above stuff.  So, either we'd need to add support for loads to
lower_complexexpr_stmt, or because they should be really rare, this
patch just disables the load optimization if at least one load use is
a COMPLEX_EXPR (like we do already for PHIs, calls, asm).

2024-06-19  Jakub Jelinek  

PR tree-optimization/115544
* gimple-lower-bitint.cc (gimple_lower_bitint): Disable optimizing
loads used by COMPLEX_EXPR operands.

* gcc.dg/bitint-107.c: New test.

[Bug c/115552] wrong code at -O2 and above when strict-aliasing with uint128 and double

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---

union {
const uint8_t *p8;
uint32_t *p32;
uint64_t *p64;
size_t i;
} u;


Does not get around aliasing rules of C/C++.

[Bug c/115552] New: wrong code at -O2 and above when strict-aliasing with uint128 and double

[davidhu0903ex3 at gmail dot com via Gcc-bugs]

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

Bug ID: 115552
   Summary: wrong code at -O2 and above when strict-aliasing with
uint128 and double
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Keywords: alias, wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidhu0903ex3 at gmail dot com
  Target Milestone: ---

Created attachment 58469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58469=edit
preproccessed file

=== Summary ===

When turning on -O2 optimization or above, the produced hash output is
different when without -O2, unless adding `-fno-strict-aliasing`. To my
investigation, the issue arise only when either:
  1. output to a uint128_t*
  2. input with a double*

=== Detail Explanation ===

The program produced the following output when compiled with -O1

  60d8f0889f4b7d88
  3bcf47a7eecabc5d
  1b153029d058b5115490463dd8be0468
  1b153029d058b5115490463dd8be0468

However, it produced different output with -O2

  e09546989572a77c
  95fe807a3fab3ad5
  b8b1ef1e717bc0d4818be1e9343867f6
  

The first two lines are the case where the inputs are double* pointers. The
third line is the case where the output are written to a uint128_t* pointer.
The last line is the case of passing a uint128_t by value to `foo` before dump.

The warning didn't complain about strict-aliasing, but rather an ambiguous
message:

  'd1' may be used uninitialized [-Wmaybe-uninitialized]

However, those variables are already initialized in `main`:

  double d1 = 1;
  double d2 = 2;

>From the generated assembly, the initialization of the inputs seems missing, so
perhaps that's the reason of the warning message. However, in production our
code didn't emit "-Wmaybe-uninitialized" at all, so that's what surprises us.

With Compiler Explorer (godbolt.org), I can roughly locate that this behavior
appear after version 10.5.0 and until 14.1.0.

=== Environment ===

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wall' '-Wextra' '-o' 'poc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
poc.c -mtune=generic -march=x86-64 -Wall -Wextra -O2 -fpch-preprocess
-fasynchronous-unwind-tables -o poc.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/12/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wall' '-Wextra' '-o' 'poc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -fpreprocessed poc.i -quiet -dumpbase
poc.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O2 -Wall -Wextra -version
-fasynchronous-unwind-tables -o poc.s
GNU C17 (Debian 12.2.0-14) version 12.2.0 (x86_64-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.1-p1, MPC version 1.3.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.1-p1 differs from library version 4.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 

[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||5146.html
   Keywords||patch

--- Comment #6 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655146.html

[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:954f9011c4923b72f42cc6ca8460333e7c7aad98

commit r15-1449-g954f9011c4923b72f42cc6ca8460333e7c7aad98
Author: Harald Anlauf 
Date:   Tue Jun 18 21:57:19 2024 +0200

Fortran: fix for CHARACTER(len=*) dummies with bind(C) [PR115390]

gcc/fortran/ChangeLog:

PR fortran/115390
* trans-decl.cc (gfc_conv_cfi_to_gfc): Move derivation of type
sizes
for character via gfc_trans_vla_type_sizes to after character
length
has been set.

gcc/testsuite/ChangeLog:

PR fortran/115390
* gfortran.dg/bind_c_char_11.f90: New test.

[Bug rtl-optimization/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3

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

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

--- Comment #3 from Robin Dapp  ---
At first it looked very weird that we need 50 (or so) instructions to expand

;; MEM  [(short int *)] = vect_cst__21;

but then I realized that all the hoops we jump through are due to possible
misalignment.  Otherwise we could of course just emit a vector store.

So we don't ICE with -mno-vector-strict-align.

Going to look into the actual issue in the next days.

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #4)
> The if-condition will have trouble *for now* with `Leopard`-like types

What trouble? I don't care if there's some confusing deleted assignment, I care
that the assignment *first = tmp is equivalent to *first = val, where tmp is a
const lvalue of the same type as val.

*first = tmp and *first = val do the same thing for your Leopard type, and that
assignment is trivial, which is all that matters.

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

--- Comment #5 from Jonathan Wakely  ---
I don't think we're on the same page at all.

I'm intending to use the trait to mean that the assignment is known to call no
operation that is not trivial, as defined in the standard today.

[Bug debug/115272] [debug] complex type is hard to related back to base type

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

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> With this patch:

So, would this approach be acceptable?

If so, I can put effort into doing a proper submission.

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #4 from Arthur O'Dwyer  ---
@jwakely #3: FWIW, I agree with that logic and that if-condition... as long as
we're all on the same page that we ought to act as if
`__is_trivially_assignable(T, U)` means "take the bit-pattern from the U (or
the thing referenced by U, if U is a reference type) and put it into the T (or
the thing referenced by T, if T is a reference type)." This isn't what the
trait means today (see P3279,
https://quuxplusone.github.io/blog/2024/05/15/false-advertising/ etc), but I'm
thrilled that everyone's going along with the idea, because I really think
that's where we need to get to as a language.

The if-condition will have trouble *for now* with `Leopard`-like types, but
such types are pathological and I am thrilled for library authors to act as if
the trait's going to get fixed soon. :)

[Bug middle-end/115551] New: [missed optimization] "c1 << (a + c2)" not optimized into "(c1 << c2) << a"

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

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

Bug ID: 115551
   Summary: [missed optimization] "c1 << (a + c2)" not optimized
into "(c1 << c2) << a"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58468=edit
patch to show how to get a nice output – but doesn't actually use it. Not to be
used..

"c1 << (a + c2)" not optimized into "(c1 << c2) << a"

Example:

int f(int ch) {
  unsigned long mask1 = 1UL))) << (1 + 4 * ((1) - 1))) << (ch * 4); 
  unsigned long mask2 = 1UL))) << (1 + 4 * ((ch + 1) - 1)));
  return mask1-mask2;
}

GCC converts this currently to:

mask1 = 2 << (ch * 4)
mask2 = 1 << (ch * 4 + 1)

* * *

Related to
https://lore.kernel.org/lkml/d7ef7a6158df4ba6687233b0e00d37796b069fb3.1718791090.git.u.kleine-koe...@baylibre.com/

Result: 
* With the 2nd form the resulting binary gets ~25% smaller
* Saving nearly 500 bytes!

* * *

On ARM, the generated code for mask1 is:

lslsr0, r0, #2
movsr3, #2
lsl.w   r0, r3, r0

and for mask2:

lslsr0, r0, #2
addsr0, #1  // additional 'adds' instruction
movsr3, #1
lsl.w   r0, r3, r0

[Bug rtl-optimization/84101] [8 Regression] -O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure

[gcc at gmch dot uk via Gcc-bugs]

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

--- Comment #30 from Chris Hall  ---
godbolt shows that gcc v9.1 -O3 generates:

   : 8d 04 3f   lea(%rdi,%rdi,1),%eax
   0003: d1 ff  sar$1,%edi
   0005: 48 98  cltq
   0007: 48 63 d7   movslq %edi,%rdx
   000A: c3 ret
   000B:

The last earlier version available on godbolt is v8.5, which generates 47 bytes
of code shuffling stuff to and from %xmm0.

gcc v13.3 generates the same code as v9.1.  I haven't tried all the intervening
versions, but all the ones I did try also gave the same.

BUT, v14.1 generates:

   : 8d 14 3f   lea(%rdi,%rdi,1),%edx
   0003: d1 ff  sar$1,%edi
   0005: 48 63 c7   movslq %edi,%rax
   0008: 48 63 d2   movslq %edx,%rdx
   000B: 48 92  xchg   %rax,%rdx
   000D: c3 ret
   000E:

The difference is clearly trivial (1 extra instruction and 3 extra bytes)...
but I don't see why it would choose %edx instead of %eax for the first
operation ?

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

--- Comment #3 from Jonathan Wakely  ---
I think we can use this condition:

  const bool __load_outside_loop =
#if __has_builtin(__is_trivially_constructible) \
  && __has_builtin(__is_trivially_assignable)
__is_trivially_constructible(_Tp, const _Tp&)
&& __is_trivially_assignable(__decltype(*__first), const _Tp&)
#else
__is_trivially_copyable(_Tp)
&& __is_same(_Tp, __typeof__(*__first))
#endif
&& sizeof(_Tp) <= sizeof(long long);

We need to know that making a copy of the object has no side effects, i.e. is
trivial.
We need to know that assigning the object to *__first is a trivial assignment.
And we probably don't want to make a local copy if it's very large.

This will disable the optimization when it's not correct to use it, as in
comment 1 and comment 2, and will enable it for other scalar types like enums,
and for sufficiently small structs where the assignment is trivial.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

YunQiang Su  changed:

   What|Removed |Added

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

--- Comment #13 from YunQiang Su  ---
It has been fixed.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by YunQiang Su :

https://gcc.gnu.org/g:8088374a868aacab4dff208ec3e3fde790a1d9a3

commit r15-1446-g8088374a868aacab4dff208ec3e3fde790a1d9a3
Author: YunQiang Su 
Date:   Wed Jun 19 22:30:22 2024 +0800

Build: Fix typo ac_cv_search_pthread_crate

The correct variable name is
  ac_cv_search_pthread_create

ChangeLog:
PR bootstrap/115453
* configure.ac: Fix typo ac_cv_search_pthread_crate.
* configure: Regnerate.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

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

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

--- Comment #18 from YunQiang Su  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654956.html

[Bug c++/115550] New: [coroutines] Reference to reference in promise constructor template argument corresponding to coroutine *this

[henri.vettenranta at bitwise dot fi via Gcc-bugs]

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

Bug ID: 115550
   Summary: [coroutines] Reference to reference in promise
constructor template argument corresponding to
coroutine *this
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: henri.vettenranta at bitwise dot fi
  Target Milestone: ---

Created attachment 58467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58467=edit
Preprocessed source that triggers the bug

The attached preprocessed file is from GCC 11.4.0, but the bug can also be
reproduced with GCC 14.1.0 on godbolt.org.

When the coroutine promise type constructor is a template using a forwarding
reference for the first parameter and the coroutine in question is a non-static
member function, GCC seems to deduce the promise constructor template type
argument to be a reference to a reference. In the attached code, it can be seen
that removing one reference results in one reference being left, and removing
two references results in a different type.

This may have the same underlying cause as bug 104981. It would not be
surprising if some internal compiler code removed the outer reference and
expected to be left with a type that is not a reference. I can't preclude this
being just a coincidence, however.

Relevant parts of the code (full preprocessed source in the attachment):

struct coroutine
{
struct promise_type
{
template 
explicit promise_type(Arg&&)
{
static_assert(same_as<
remove_reference_t>,
remove_reference_t
>);
}

// ...
};
};

struct x
{
coroutine f()
{
co_return;
}
};

===

$ g++ -v -Wall -Wextra -Wpedantic -std=c++20 -c -o /dev/null gcccoroctorbug.i
Using built-in specs.
COLLECT_GCC=g++
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-Wpedantic' '-std=c++20' '-c' '-o'
'/dev/null' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed gcccoroctorbug.i
-quiet -dumpbase gcccoroctorbug.i -dumpbase-ext .i -mtune=generic -march=x86-64
-Wall -Wextra -Wpedantic -std=c++20 -version -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat-security -fstack-clash-protection
-fcf-protection -o /tmp/ccWWTO55.s
GNU C++20 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d591828bb4d392ae8b7b160e5bb0b95f
gcccoroctorbug.cpp: In instantiation of
‘coroutine::promise_type::promise_type(Arg&&) [with Arg = x&&]’:
gcccoroctorbug.cpp:44:5:   required from here
gcccoroctorbug.cpp:23:27: error: static assertion failed
   23 | static_assert(same_as<
  |   ^~~~
   24 | remove_reference_t>,
  | 

[Bug libstdc++/109150] std::fill should use __gnu_cxx::__is_scalar overloads for all scalars

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

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

--- Comment #2 from Jonathan Wakely  ---
Another example of how the optimization is non-conforming, as I just
rediscovered:

#include 
#include 

struct X {
  int i = 0;

  X& operator=(int ii)
  {
i = ii + 1;
return *this;
  }
};

int main()
{
  X x[2];
  std::fill_n(x, 2, x[0].i);
  assert(x[1].i == 2);
}

[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 58466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58466=edit
gcc15-pr115544.patch

So far lightly tested fix.

[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655124.html

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code

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

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

--- Comment #12 from Sam James  ---
I would just git bisect instead.

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #11 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #10)
> (In reply to Jürgen Reuter from comment #9)
> > Also at the daily bump shortly after midnight morning of June 11,
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> > h=097bc0aebaed58c11c738ea61da723cca950e5b1
> > the reproducer still runs fine.
> 
> Next landmark:
> also the daily bump after Tuesday June 11 in the morning of June 12,
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=7fa4b335b1ae6824893528eae56fb01ec15b6bc5
> is still fine.

Also the daily bump shortly after midnight of June 13 including all changes
from Wednesday, June 12,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=158ce8ade0a98443b8fc05cbdbed5c49ee8a13b7
is still fine.

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

Sam James  changed:

   What|Removed |Added

 CC||collin.funk1 at gmail dot com

--- Comment #11 from Sam James  ---
commit r15-1436-gc6a9ab8c920f29
Author: Collin Funk 
Date:   Thu Jun 13 17:53:55 2024 -0700

build: Fix missing variable quotes

When dlopen and pthread_create are in libc the variable is
set to "none required", therefore running configure will show
the following errors:

./configure: line 8997: test: too many arguments
./configure: line 8999: test: too many arguments
./configure: line 9003: test: too many arguments
./configure: line 9005: test: =: unary operator expected

gcc/configure also has a similar problem on
gcc_cv_as_mips_explicit_relocs:

./gcc/configure: line 30242: test: =: unary operator expected

ChangeLog:

* configure.ac: Quote variable result of AC_SEARCH_LIBS.
* configure: Regenerate.

gcc/ChangeLog:

* configure.ac: Add missing quotation of variable
gcc_cv_as_mips_explicit_relocs.
* configure: Regenerate.

Signed-off-by: Collin Funk 

But the crate vs create needs fixing still.

[Bug debug/115543] DWARF call_site_parameter entries are not generated for stack-passed parameters

[spevnev16 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sergey  ---
(In reply to Jakub Jelinek from comment #1)
> That is not a bug, DW_TAG_call_site_parameter is emitted only when it has
> something relevant to say (like, what value has been passed).  If it isn't
> known how to reconstruct the value or if the compiler is unable to track the
> value passed to it, it can omit it.

I do not see how it is any different from register-passed parameters in its
"relevance", being able to reconstruct or track it. Could you please explain?

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #10 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #9)
> Also at the daily bump shortly after midnight morning of June 11,
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=097bc0aebaed58c11c738ea61da723cca950e5b1
> the reproducer still runs fine.

Next landmark:
also the daily bump after Tuesday June 11 in the morning of June 12,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7fa4b335b1ae6824893528eae56fb01ec15b6bc5
is still fine.

[Bug c/115549] New: ICE: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in common_handle_aligned_attribute, at c-family/c-attribs.cc:2665 with invalid aligned attri

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115549
   Summary: ICE: tree check: expected tree that contains ‘decl
common’ structure, have ‘error_mark’ in
common_handle_aligned_attribute, at
c-family/c-attribs.cc:2665 with invalid aligned
attribute
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

ICE on trunk.
Compiler Explorer: https://godbolt.org/z/zcab6cfWj

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/root/gcc_set/trunk-48a320a/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/trunk-48a320a/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/trunk-48a320a
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak --enable-coverage
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240426 (experimental) (GCC) 

***
Program:
$ cat mutant.c
__attribute__((aligned, optimize(s),)0) s()

***
Command Lines:
$ gcc mutant.c
mutant.c:1:34: error: ‘s’ undeclared here (not in a function)
1 | __attribute__((aligned, optimize(s),)0) s()
  |  ^
mutant.c:1:38: error: expected ‘)’ before numeric constant
1 | __attribute__((aligned, optimize(s),)0) s()
  |  ^
  |  )
mutant.c:1:1: internal compiler error: tree check: expected tree that contains
‘decl common’ structure, have ‘error_mark’ in common_handle_aligned_attribute,
at c-family/c-attribs.cc:2665
1 | __attribute__((aligned, optimize(s),)0) s()
  | ^
0x25433e9 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.cc:9130
0xd34731 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3770
0x10360bf common_handle_aligned_attribute
../../gcc/gcc/c-family/c-attribs.cc:2665
0x103692a handle_aligned_attribute
../../gcc/gcc/c-family/c-attribs.cc:2750
0xd2acd9 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/gcc/attribs.cc:900
0xd598f1 c_decl_attributes
../../gcc/gcc/c/c-decl.cc:5497
0xd795ab start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/gcc/c/c-decl.cc:10483
0xe40891 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:2912
0xe3c6ed c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2046
0xe3bbd7 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:1900
0xeccd02 c_parse_file()
../../gcc/gcc/c/c-parser.cc:26889
0xfe8faa c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1311
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 tree-optimization/114413] BB SLP sub-graph merging fails to CSE nodes

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2024-06-19

[Bug fortran/86754] [meta-bug] Memory leaks at run time

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

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

Bug 90076 Summary: Polymorphic Allocate on Assignment Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90076

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/90076] Polymorphic Allocate on Assignment Memory Leak

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #9 from Jürgen Reuter  ---
Also at the daily bump shortly after midnight morning of June 11,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=097bc0aebaed58c11c738ea61da723cca950e5b1
the reproducer still runs fine.

[Bug fortran/90076] Polymorphic Allocate on Assignment Memory Leak

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

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

commit r15-1434-gdbb718175d7df89b957b316ba2f5fbea5d21b2b1
Author: Andre Vehreschild 
Date:   Thu Jun 6 14:01:13 2024 +0200

Fortran: Set the vptr of a class typed result.

PR fortran/90076

gcc/fortran/ChangeLog:

* trans-decl.cc (gfc_generate_function_code): Set vptr for
results to declared class type.
* trans-expr.cc (gfc_reset_vptr): Allow to provide the typespec
instead of the expression.
* trans.h (gfc_reset_vptr): Same.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_76.f90: Add declared vtab occurrence.
* gfortran.dg/class_78.f90: New test.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

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

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

--- Comment #11 from Jakub Jelinek  ---
It is always good if you're testing on x86_64 to test such tests with
make check-gcc
RUNTESTFLAGS="--target_board=unix\{-m32/-mno-mmx/-mno-sse,-m32/-msse2,-m64\}
dg.exp='pr105109.c c23-tag-enum-*.c'"
or similar, that allows testing both 64-bit and 32-bit compilation and for the
latter both the variants with vector support and without (e.g. in case test
needs -Wno-psabi).
I certainly see
+FAIL: gcc.dg/c23-tag-enum-6.c  (test for errors, line 10)
+FAIL: gcc.dg/c23-tag-enum-6.c  (test for errors, line 13)
+FAIL: gcc.dg/c23-tag-enum-7.c (test for excess errors)
+FAIL: gcc.dg/pr115109.c (test for excess errors)
on i686-linux and not on x86_64-linux and the above make check would show it
immediately, even before trying to bootstrap/regtest the patch.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

--- Comment #13 from Jonathan Wakely  ---
std::random_shuffle was removed from the C++ standard years ago, precisely
because it uses low quality randomness. So it's not a high priority to fix
something that is no longer even in the standard, because it's known to have
unfixable problems. We also don't waste time on std::auto_ptr and
std::strstream.

I do intend to revisit Giovanni's patch for GCC 15, but it's not a high
priority.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

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

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

--- Comment #10 from uecker at gcc dot gnu.org ---

Yeah, I looked at the CI before submitting and saw  the three passing tests,
not realizing that the fourth was stilling running.  I will fix this soon.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #9 from Christophe Lyon  ---
Linaro CI and Intel CI have reported failures of the new tests:
https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080080.html
https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080078.html

(Linaro precommit CI also reported the problem before the patch was committed
BTW)

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #11 from avieira at gcc dot gnu.org ---
I realized this ticket hadn't been updated in a while. Late in development for
gcc-14 I realized sve simdclone usage was leading to a regression on a
benchmark, I couldn't get to the bottom of the regression in time so I decided
to punt this to gcc-15.

Someone in our team has picked up this work and we are planning to get this
done in gcc-15.

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
I'll have a closer look.

[Bug ada/115507] bogus Constraint_Error for Wide_Wide_Value with wide enumeration literal

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
I'll have a closer look.

[Bug fortran/96992] Class arrays of different ranks are rejected as storage association argument

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

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

--- Comment #3 from Andre Vehreschild  ---
Second version of patch. Now also working for negative strides:
https://gcc.gnu.org/pipermail/fortran/2024-June/060592.html
Waiting for review.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

[agriff at tin dot it via Gcc-bugs]

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

Andrea Griffini  changed:

   What|Removed |Added

 CC||agriff at tin dot it

--- Comment #12 from Andrea Griffini  ---
Even assuming rand() were generating hardware random numbers (not allowed by
the standard because of srand, obviously), gcc would still be broken and
performing a terrible random_shuffle with ranges larger than 64k elements
(indeed non-uniformity becomes evident even at much smaller ranges).

Mingw's rand() numbers are decent enough (and the period is not just 2**16, for
example) but they're only 16 bit. This is allowed.

The gcc bug is that it uses rand() (that can be just 16) bit to pick a random
number between 0 and the size of the range even when the range is much bigger
than 65536. Using rand() to feed data into a xorshift64 or something similar
only for large ranges would fix, and would also keep shuffle of small ranges
backward compatible (shuffling elements in small ranges exactly as current
implementation does if starting from the same random seed).

I've somewhere an half backed patch for doing that but quite frankly I don't
know if I should polish it and submit here as, in all honesty, seems that in
this case the maintainers simply don't want to have this bug fixed, for reasons
that I really cannot understand.

[Bug debug/115543] DWARF call_site_parameter entries are not generated for stack-passed parameters

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
not a bug

[Bug c/115548] New: ICE: verify_cgraph_node failed with attribute malloc and simd enabled

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 115548
   Summary: ICE: verify_cgraph_node failed with attribute malloc
and simd enabled
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

Also ICE on trunk.
Compiler Explorer: https://godbolt.org/z/1q9nc3acK

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/root/gcc_set/trunk-48a320a/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/trunk-48a320a/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/trunk-48a320a
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak --enable-coverage
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240426 (experimental) (GCC) 

***
Program:
$ cat mutant.c
__attribute__((malloc, simd)) int *a() {}

***
Command Lines:
$ gcc mutant.c
mutant.c:1:1: error: malloc attribute should be used for a function that
returns a pointer
1 | __attribute__((malloc, simd)) int *a() {}
  | ^
_ZGVeM8_a/8 (a.simdclone.7)
  Type: function definition analyzed
  Visibility: externally_visible semantic_interposition no_reorder asm_written
public artificial
  References: 
  Referring: 
  Availability: available
  Function flags: decl_is_malloc
  Called by: 
  Calls: 
mutant.c:1:1: internal compiler error: verify_cgraph_node failed
0x11fec4c cgraph_node::verify_node()
../../gcc/gcc/cgraph.cc:3956
0x11d1c0a symtab_node::verify()
../../gcc/gcc/symtab.cc:1362
0x11d22bd symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.cc:1482
0x1219e99 symbol_table::compile()
../../gcc/gcc/cgraphunit.cc:2420
0x121a6f3 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.cc:2589
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 middle-end/115528] [15 regression] segmentation fault in legacy F77 code

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #8 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #6)
> (In reply to kargls from comment #5)
> > (In reply to Jürgen Reuter from comment #4)
> > > Created attachment 58462 [details]
> > > Input file that triggers the test case with segmentation fault
> > > 
> > > This test case needs Whizard 3.1.4 to be downloaded here,
> > > http://whizard.hepforge.org/whizard-3.1.4.tar.gz
> > > I avoided the need for OCaml being present, just do ./configure, make, 
> > > make
> > > install. This will create a binary whizard, and then execute
> > > whizard tauola_1.sin as attached.
> > 
> > ./configure
> > ...
> > checking for OCaml version 408000... test: -ge: unexpected operator
> > < 4.08.0
> > configure: error: *
> > configure: error: found version , too old!
> > configure: error: *
> 
> Just do configure with --disable-ocaml.

Out of curiosity, what OCaml version is on your system?

[Bug tree-optimization/115547] `(a ^ c) & (a | c)` -> `a ^ c` not done on the gimple/tree level

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/95946

--- Comment #1 from Andrew Pinski  ---
Note sometimes it can get complex for bool case:
```
bool fn1(bool a, bool b, bool c) {
return a != c && (b || (c || a));
}

bool fn2(bool a, bool b, bool c) {
return a != c && (b || c || a);
}
bool fn3(bool a, bool b, bool c) {
return a != c && (a || b || c);
}
bool fn4(bool a, bool b, bool c) {
return a != c && (a || c || b);
}
```

The above is from https://github.com/llvm/llvm-project/issues/95946 .

For those we have:
```
   [local count: 1073741824]:
  if (a_3(D) != c_4(D))
goto ; [66.00%]
  else
goto ; [34.00%]

   [local count: 708669600]:
  _8 = c_4(D) | b_5(D);
  _7 = a_3(D) | _8;

   [local count: 1073741824]:
  # iftmp.0_2 = PHI <_7(3), 0(2)>
  return iftmp.0_2;
```

Which really we know that (a|c) will be 1. But maybe that is a different issue
all together.