[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 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 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 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 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 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 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)

[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 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 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

[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 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 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 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 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 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 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 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 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 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 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&action=edit
gcc15-pr115544.patch

So far lightly tested fix.

[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 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&action=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 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 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 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 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 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 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&action=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 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 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

[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 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 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 *)&a] = 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 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 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 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&action=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
G

[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 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 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 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/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/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 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 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 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(&u.p64[0]) and have load_64 defined to be:
```
static inline uint64_t load_64(void *a)
{
  uint64_t t;
  memcpy(&t, a, sizeof(t));
  return t;
}
```

[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 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 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 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 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.

[no subject]

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

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

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

[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...

[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 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 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 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 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 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 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 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 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

--- Comment #4 from Hu Lin  ---
Created attachment 58470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58470&action=edit
A short case

I tested the file with
1) -Ofast -flto -march=skylake-avx512 -mfpmath=sse -funroll-loops
2) -O2 -march=native （on an Icelake server)

Both generate redundant mov.

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

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 20 Jun 2024, pinskia at gcc dot gnu.org wrote:

> 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  8, 9, 10, 11 }>;
> 
> 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?

Maybe match \{_\[0-9\]\+, (0\|{ 0(, 0)+ })?  (with proper quoting)

[Bug tree-optimization/114413] BB SLP sub-graph merging fails to CSE nodes

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

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

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

https://gcc.gnu.org/g:46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452

commit r15-1467-g46bb4ce4d30ab749d40f6f4cef6f1fb7c7813452
Author: Richard Biener 
Date:   Wed Jun 19 12:57:27 2024 +0200

tree-optimization/114413 - SLP CSE after permute optimization

We currently fail to re-CSE SLP nodes after optimizing permutes
which results in off cost estimates.  For gcc.dg/vect/bb-slp-32.c
this shows in not re-using the SLP node with the load and arithmetic
for both the store and the reduction.  The following implements
CSE by re-bst-mapping nodes as finalization part of vect_optimize_slp.

I've tried to make the CSE part of permute materialization but it
isn't a very good fit there.  I've not bothered to implement something
more complete, also handling external defs or defs without
SLP_TREE_SCALAR_STMTS.

I realize this might result in more BB SLP which in turn might slow
down code given costing for BB SLP is difficult (even that we now
vectorize gcc.dg/vect/bb-slp-32.c on x86_64 might be not a good idea).
This is nevertheless feeding more accurate info to costing which is
good.

PR tree-optimization/114413
* tree-vect-slp.cc (release_scalar_stmts_to_slp_tree_map):
New function, split out from ...
(vect_analyze_slp): ... here.  Call it.
(vect_cse_slp_nodes): New function.
(vect_optimize_slp): Call it.

* gcc.dg/vect/bb-slp-32.c: Expect CSE and vectorization on x86.

[Bug middle-end/115551] [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

--- Comment #2 from Tobias Burnus  ---
> Thus we need some range info to do this optimization.

Good point.

It seems as if for c1 << (c2 * a + c3),  C requires a >= -c3/c2 (read as float
division; c2 ≠ 0)

And the suggested optimization requires c2*a >= 0 and c3 >= 0 to fulfill C
requirement of nonnegative shifts.

Thus, this is fulfilled for any value of 'a' if c3 >= 0 and abs(c2) > c3.


The optimization can also be done for any value of 'a', if the hardware
supports c1 << (negative value)  (as right shift, fillung with zeros) and
popcount(c1) == popcount(c1 << c3).


The first condition is fulfilled in this example.

I don't know about the second, but observed that Clang/LLVM optimizes the diff
mask1-mask2 to 0 on ARM but not x86_64 (not checked why nor whether ARM handles
negative shifts in a well-defined way or not).