[Bug target/115661] [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r15-1599-g63512c72df09b4

[Evgeny.Karpov at microsoft dot com via Gcc-bugs]

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

--- Comment #8 from Evgeny Karpov  ---
Thank you for reporting the issues and discussing the root causes. 
It helped in preparing the patch.

The patch is under review.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655807.html

[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ()))) since r15-159

[Evgeny.Karpov at microsoft dot com via Gcc-bugs]

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

--- Comment #11 from Evgeny Karpov  ---
Thank you for reporting the issues and discussing the root causes. 
It helped in preparing the patch.

The patch is under review.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655807.html

[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31

[Evgeny.Karpov at microsoft dot com via Gcc-bugs]

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

--- Comment #12 from Evgeny Karpov  ---
Thank you for reporting the issues and discussing the root causes. 
It helped in preparing the patch.

The patch is under review.
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655807.html

[Bug c++/79424] dtor synthesized before abstractness correctly determined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79393

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, looks like only clang gets this right.

In that MSVC, GCC and EDG all reject this. Maybe there is a defect report since
only 1 out of 4 compilers have the behavior that is reported here ...

[Bug rtl-optimization/90343] ICE: in verify_dominators, at dominance.c:1184 (error: dominator of 7 status unknown)

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

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

--- Comment #3 from Andrew Pinski  ---
Note changing the definition of initializer_list to:
```
template
class initializer_list
{
public:
  const int *i2 () { return uk; }
  const int *w2 () { return uk + in; }

private:
  const E *uk;
  unsigned long int in;
};
```

Allows clang to accept the code. I will file a bug about (maybe) accepting an
invalid version of initializer_list later today.

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

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

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

commit r15-1677-gc320a7efcd35ba6c6be70dc9b2fe562a9673e363
Author: Hu, Lin1 
Date:   Thu Feb 1 15:15:01 2024 +0800

vect: generate suitable convert insn for int -> int, float -> float and int
<-> float.

gcc/ChangeLog:

PR target/107432
* tree-vect-generic.cc
(expand_vector_conversion): Support convert for int -> int,
float -> float and int <-> float.
* tree-vect-stmts.cc (vectorizable_conversion): Wrap the
indirect convert part.
(supportable_indirect_convert_operation): New function.
* tree-vectorizer.h (supportable_indirect_convert_operation):
Define the new function.

gcc/testsuite/ChangeLog:

PR target/107432
* gcc.target/i386/pr107432-1.c: New test.
* gcc.target/i386/pr107432-2.c: Ditto.
* gcc.target/i386/pr107432-3.c: Ditto.
* gcc.target/i386/pr107432-4.c: Ditto.
* gcc.target/i386/pr107432-5.c: Ditto.
* gcc.target/i386/pr107432-6.c: Ditto.
* gcc.target/i386/pr107432-7.c: Ditto.

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Hu :

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

commit r15-1678-ge5f8a39941f6f0f25dac88bd71fd368fb284a10f
Author: Hu, Lin1 
Date:   Wed Feb 28 18:11:55 2024 +0800

vect: Support v4hi -> v4qi.

gcc/ChangeLog:

PR target/107432
* config/i386/mmx.md
(VI2_32_64): New mode iterator.
(mmxhalfmode): New mode atter.
(mmxhalfmodelower): Ditto.
(truncv2hiv2qi2): Extend mode v4hi and change name from
truncv2hiv2qi to trunc2.

gcc/testsuite/ChangeLog:

PR target/107432
* gcc.target/i386/pr107432-1.c: Modify test.
* gcc.target/i386/pr107432-6.c: Add test.
* gcc.target/i386/pr108938-3.c: This patch supports
truncv4hiv4qi affect bswap optimization, so I added
the -mno-avx option for now, and open a bugzilla.

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

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

https://gcc.gnu.org/g:4385dc97b0d28e54541eb2418d6e68fc672441d7

commit r15-1679-g4385dc97b0d28e54541eb2418d6e68fc672441d7
Author: Hu, Lin1 
Date:   Wed Mar 6 19:58:48 2024 +0800

vect: support direct conversion under x86-64-v3.

gcc/ChangeLog:

PR target/107432
* config/i386/i386-expand.cc
(ix86_expand_trunc_with_avx2_noavx512f):
New function for generate a series of suitable insn.
* config/i386/i386-protos.h
(ix86_expand_trunc_with_avx2_noavx512f):
Define new function.
* config/i386/sse.md: Extend trunc2 for x86-64-v3.
(ssebytemode) Add V8HI.
(PMOV_DST_MODE_2_AVX2): New mode iterator.
(PMOV_SRC_MODE_3_AVX2): Ditto.
* config/i386/mmx.md
(trunc2): Ditto.
(avx512vl_trunc2): Ditto.
(truncv2si2): Ditto.
(avx512vl_truncv2si2): Ditto.
(mmxbytemode): New mode attr.

gcc/testsuite/ChangeLog:

PR target/107432
* gcc.target/i386/pr107432-8.c: New test.
* gcc.target/i386/pr107432-9.c: Ditto.
* gcc.target/i386/pr92645-4.c: Modify test.

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

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

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

commit r15-1677-gc320a7efcd35ba6c6be70dc9b2fe562a9673e363
Author: Hu, Lin1 
Date:   Thu Feb 1 15:15:01 2024 +0800

vect: generate suitable convert insn for int -> int, float -> float and int
<-> float.

gcc/ChangeLog:

PR target/107432
* tree-vect-generic.cc
(expand_vector_conversion): Support convert for int -> int,
float -> float and int <-> float.
* tree-vect-stmts.cc (vectorizable_conversion): Wrap the
indirect convert part.
(supportable_indirect_convert_operation): New function.
* tree-vectorizer.h (supportable_indirect_convert_operation):
Define the new function.

gcc/testsuite/ChangeLog:

PR target/107432
* gcc.target/i386/pr107432-1.c: New test.
* gcc.target/i386/pr107432-2.c: Ditto.
* gcc.target/i386/pr107432-3.c: Ditto.
* gcc.target/i386/pr107432-4.c: Ditto.
* gcc.target/i386/pr107432-5.c: Ditto.
* gcc.target/i386/pr107432-6.c: Ditto.
* gcc.target/i386/pr107432-7.c: Ditto.

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Hu :

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

commit r15-1678-ge5f8a39941f6f0f25dac88bd71fd368fb284a10f
Author: Hu, Lin1 
Date:   Wed Feb 28 18:11:55 2024 +0800

vect: Support v4hi -> v4qi.

gcc/ChangeLog:

PR target/107432
* config/i386/mmx.md
(VI2_32_64): New mode iterator.
(mmxhalfmode): New mode atter.
(mmxhalfmodelower): Ditto.
(truncv2hiv2qi2): Extend mode v4hi and change name from
truncv2hiv2qi to trunc2.

gcc/testsuite/ChangeLog:

PR target/107432
* gcc.target/i386/pr107432-1.c: Modify test.
* gcc.target/i386/pr107432-6.c: Add test.
* gcc.target/i386/pr108938-3.c: This patch supports
truncv4hiv4qi affect bswap optimization, so I added
the -mno-avx option for now, and open a bugzilla.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

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

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

--- Comment #5 from Richard Biener  ---
I think we use a wrong ELSE value:

  vect_b.19_54 = VIEW_CONVERT_EXPR(vect_b_lsm.18_53);
  vect__15.20_56 = .COND_ADD (loop_mask_55, { -1, ... }, vect_b.19_54, { -1,
... });
^^^
  vect__8.21_57 = .COND_SUB (loop_mask_55, vect__15.20_56, vect__5.17_51,
vect__15.20_56);
  vect__9.22_58 = VIEW_CONVERT_EXPR(vect__8.21_57);

I'll see how that happens.  Possibly an operand order issue.

[Bug middle-end/115675] New: truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.

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

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

Bug ID: 115675
   Summary: truncv4hiv4qi affect r14-1402-gd8545fb2c71683's
optimization.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lin1.hu at intel dot com
  Target Milestone: ---

After r15-1678-ge5f8a39941f6f0, truncv4hiv4qi affects dump and interferes with
r14-1402-gd8545fb2c71683's optimization.

When I compile pr108938-3.c with -mavx or -mavx512bw -mavx512vl, GCC doesn't
generate bswap r32. I've discussed this with Hongtao and haven't found an
easier way to do it yet. I think it might be possible to target match the
current form to re-support bswap optimization with option -mavx.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

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

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

--- Comment #6 from Richard Biener  ---
OK, so the issue is the SLP child order is different than the scalar stmt
operand order and inconsistent with what we have recorded in reduc_idx.
Likely because we do

t.c:6:23: note:   pre-sorted chains of plus_expr
plus_expr -1 plus_expr b.2_7 minus_expr _5 

and that requires -fwrapv.  I think this is a latent issue possibly triggerable
with a masked SLP reduction.

[Bug libstdc++/103191] vector doesn't have any checks enabled by _GLIBCXX_ASSERTIONS

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-1689-g8fd84bc009b3073666a24047c78a04c19eeab752
Author: Jonathan Wakely 
Date:   Tue Jun 18 10:57:45 2024 +0100

libstdc++: Add debug assertions to std::vector [PR103191]

This adds debug assertions for std::vector element access.

libstdc++-v3/ChangeLog:

PR libstdc++/103191
* include/bits/stl_bvector.h (vector::operator[])
(vector::front, vector::back): Add debug assertions.
* testsuite/23_containers/vector/bool/element_access/constexpr.cc:
Remove dg-error that no longer triggers.

[Bug libstdc++/111250] __glibcxx_requires_subscript assertions are not checked during constant evaluation

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-1688-gcfc9fa3bdddc1af59b7854937b99516067fd8c63
Author: Jonathan Wakely 
Date:   Tue Jun 18 20:57:13 2024 +0100

libstdc++: Enable more debug assertions during constant evaluation
[PR111250]

Some of our debug assertions expand to nothing unless
_GLIBCXX_ASSERTIONS is defined, which means they are not checked during
constant evaluation. By making them unconditionally expand to a
__glibcxx_assert expression they will be checked during constant
evaluation. This allows us to diagnose more instances of undefined
behaviour at compile-time, such as accessing a vector past-the-end.

libstdc++-v3/ChangeLog:

PR libstdc++/111250
* include/debug/assertions.h (__glibcxx_requires_non_empty_range)
(__glibcxx_requires_nonempty, __glibcxx_requires_subscript):
Define to __glibcxx_assert expressions or to debug mode
__glibcxx_check_xxx expressions.
* testsuite/23_containers/array/element_access/constexpr_c++17.cc:
Add checks for out-of-bounds accesses in constant expressions.
* testsuite/23_containers/vector/element_access/constexpr.cc:
Likewise.

[Bug libstdc++/115668] Cannot format chrono::duration

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-1690-gdafa750c8a6f0a088677871bfaad054881737ab1
Author: Jonathan Wakely 
Date:   Wed Jun 26 20:22:54 2024 +0100

libstdc++: Fix std::format for chrono::duration with unsigned rep
[PR115668]

Using std::chrono::abs is only valid if numeric_limits::is_signed
is true, so using it unconditionally made it ill-formed to format a
duration with an unsigned rep.

The duration formatter might as negate the duration itself instead of
using chrono::abs, because it already needs to check for a negative
value.

libstdc++-v3/ChangeLog:

PR libstdc++/115668
* include/bits/chrono_io.h (formatter::format):
Do not use chrono::abs.
* testsuite/20_util/duration/io.cc: Check formatting a duration
with unsigned rep.

[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #7 from Kewen Lin  ---
> > > (simplify
> > >  (vec_cond @0 @1 integer_all_ones_p)
> > >  (bit_ior (view_convert @0) @1))
> > > ```
> > 
> > Missing negate for the vector one?
> 
> No because vector true is already -1 :).

I could be wrong, but this vector transformation seems wrong, like @0 is -1,
originally wants @1 but this simplification returns -1, while @0 is 0,
originally wants -1 but this simplification returns @1, the results get
switched?

[Bug libstdc++/111250] __glibcxx_requires_subscript assertions are not checked during constant evaluation

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

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk. I think this would be good to backport so that we diagnose more
errors during constant evaluation.

[Bug libstdc++/103191] vector doesn't have any checks enabled by _GLIBCXX_ASSERTIONS

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk.

[Bug c++/115676] New: gcc allows invalid calling to implicitly-deleted default constructor of a template derived class in template function

[rush102333 at gmail dot com via Gcc-bugs]

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

Bug ID: 115676
   Summary: gcc allows invalid calling to implicitly-deleted
default constructor of a template derived class in
template function
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rush102333 at gmail dot com
  Target Milestone: ---

The following invalid code is accepted by gcc-13.2.0 and gcc-trunk:

~~
struct empty{

};
template 
struct A
: public empty
{
const int is_valid;
};

template 
void check_a()
{
  const A<0> a {};
}
~~

It can be seen that the template class "A" is non-trivial because it has an
empty base class. Thus, the default constructor of "A" should be implicitly
deleted, and the initialization statement "const A<0> a{}" should be invalid. 

But when the initialization happens in a template function, GCC seems to ignore
the error. Changing "check_a" to a non-template function can make the compiler
reject the code by giving the following error message:


~~
: In function 'void check_a()':
:14:17: error: use of deleted function 'A<0>::A()'
   14 |   const A<0> a {};
  | ^
:5:8: note: 'A<0>::A()' is implicitly deleted because the default
definition would be ill-formed:
5 | struct A
  |^
: At global scope:
:5:8: error: uninitialized const member in 'struct A<0>'
:8:15: note: 'const int A<0>::is_valid' should be initialized
8 | const int is_valid;
  |   ^~~~
: In function 'void check_a()':
:14:17: note: use '-fdiagnostics-all-candidates' to display considered
candidates
   14 |   const A<0> a {};

~~

Please check https://godbolt.org/z/nGxPdn9jf

[Bug rtl-optimization/115677] New: ICE when building argon2 with -flate-combine-instructions on amd64

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

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

Bug ID: 115677
   Summary: ICE when building argon2 with
-flate-combine-instructions on amd64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

```
$ gcc -c src/core.c -flate-combine-instructions
during RTL pass: late_combine
In file included from src/core.c:38:
src/blake2/blake2-impl.h: In function ‘load64’:
src/blake2/blake2-impl.h:80:1: internal compiler error: Segmentation fault
   80 | }
  | ^
0x5575346c43e6 internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:491
0x557533f82365 crash_signal
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:319
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

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

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

--- Comment #1 from Sam James  ---
Created attachment 58529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58529&action=edit
core.i.xz

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

--- Comment #2 from Sam James  ---
```
==240== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/15/cc1 -fpreprocessed
core.i -quiet -dumpbase core.i -dumpbase-ext .i -mtune=generic -march=x86-64
-flate-combine-instructions -o /tmp/ccLQtrdV.s
==240==
==240== Jump to the invalid address stated on the next line
==240==at 0x0: ???
==240==by 0x1B9AF68: UnknownInlinedFun (obstack.c:94)
==240==by 0x1B9AF68: _obstack_newchunk (obstack.c:206)
==240==by 0x209EA2E: UnknownInlinedFun (bitmap.cc:792)
==240==by 0x209EA2E: df_analyze() (df-core.cc:1258)
==240==by 0x1A29D65: UnknownInlinedFun (late-combine.cc:700)
==240==by 0x1A29D65: (anonymous
namespace)::pass_late_combine::execute(function*) [clone .lto_priv.0]
(late-combine.cc:754)
==240==by 0x3D5100: execute_one_pass(opt_pass*) [clone .cold]
(passes.cc:2647)
==240==by 0x1CCA33B: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==240==by 0x1CCA358: execute_pass_list_1(opt_pass*) (passes.cc:2757)
==240==by 0x1CCA248: execute_pass_list(function*, opt_pass*)
(passes.cc:2767)
==240==by 0x1C4A8D3: cgraph_node::expand() (cgraphunit.cc:1845)
==240==by 0x1BFB025: UnknownInlinedFun (cgraphunit.cc:2195)
==240==by 0x1BFB025: symbol_table::compile() (cgraphunit.cc:2401)
==240==by 0x2411308: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2589)
==240==by 0x23C90F0: compile_file() [clone .lto_priv.0] (toplev.cc:476)
==240==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==240==
during RTL pass: late_combine
In file included from src/core.c:38:
src/blake2/blake2-impl.h: In function ‘load64’:
src/blake2/blake2-impl.h:80:1: internal compiler error: Segmentation fault
```

[Bug target/115678] New: MIPS: Condition trap can optimize

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

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

Bug ID: 115678
   Summary: MIPS: Condition trap can optimize
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

void teq5 (int i) {
if (i == 5)
__builtin_trap();
}
void tne5 (int i) {
if (i != 5)
__builtin_trap();
}
void tge5 (int i) {
if (i >= 5)
__builtin_trap();
}
/* We have TGEI.  */


void tgeu5 (unsigned int i) {
if (i >= 5)
__builtin_trap();
}
/* We have TGEIU.  */

void tlt5 (int i) {
if (i < 5)
__builtin_trap();
}
/* We have TLTI.  */

void tle0 (int i) {
if (i <= 0)
__builtin_trap();
}
move$2,$0   # <--- not needed.
tge $2,$4

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

--- Comment #3 from Sam James  ---
Reduced:
```
void initialize() {}
```

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Sandiford  ---
Guess we need the usual optimize > 0 guard too.

[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #8 from Kewen Lin  ---
Inspired by Andrew's comments, it looks we can have:

   c = x CMP y
   r = c ?  0 :  z   =>  r =  ~c & z  (1)
   r = c ?  z :  0   =>  r =   c & z  (2)
   r = c ? -1 :  z   =>  r =   c | z  (3)
   r = c ?  z : -1   =>  r =  ~c | z  (4)

so if target supports vector "or" and "and", (2)(3) is clearly an improvement
(basic logical operation should not be slower than vector select), (1)(4) may
need further cost comparison (or if target supports the compound operation then
query with optab support).

[Bug c++/115664] -Wnonnull-compare breaks templated methods

[ossman at cendio dot se via Gcc-bugs]

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

--- Comment #6 from Pierre Ossman  ---
Is there a cleaner way to can work around this than duplicating the affected
methods? I tried adding a #pragma, but that breaks older versions of gcc that
don't have -Wnonnull-compare.

[Bug libstdc++/115454] std::experimental::find_last_set is buggy on x86-64-v4

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b

commit r15-1692-g95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b
Author: Alexandre Oliva 
Date:   Thu Jun 27 07:22:48 2024 -0300

[libstdc++] [testsuite] defer to check_vect_support* [PR115454]

The newly-added testcase overrides the default dg-do action set by
check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so
it attempts to run the test even if runtime vector support is not
available.

Remove the explicit dg-do directive, so that the default is honored,
and the test is run if vector support is found, and only compiled
otherwise.


for  libstdc++-v3/ChangeLog

PR libstdc++/115454
* testsuite/experimental/simd/pr115454_find_last_set.cc: Defer
to check_vect_support_and_set_flags's default dg-do action.

[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns

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

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

--- Comment #9 from Richard Biener  ---
I think the inversion code wants to check invert_tree_comparison and see if
the inverted compare is supported and only if not fall back to inverting the
comparison result (there is of course the multi-use case to consider).

I also think that incrementally improving the /* Try to fold x CMP y ? -1 : 0
to x CMP y.  */ is fine we don't have to handle everything in one patch.

Thanks for working on this.  The x86 folks seem to be able to handle most
things within the backend which is also fine, handling common problems in
the middle-end is of course better.

[Bug ada/115666] Cloaking access to subprogram in a record allows storing anonymous access-to-subprogram value

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Confirmed, but nobody should write this sort of things.

[Bug tree-optimization/115679] New: inlining failed in call to 'foo': function not considered for inlining

[Changqing.Li at windriver dot com via Gcc-bugs]

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

Bug ID: 115679
   Summary: inlining failed in call to 'foo': function not
considered for inlining
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Changqing.Li at windriver dot com
  Target Milestone: ---

The issue I met is similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965.

Reproduce steps:
1. wget https://cairographics.org/releases/pixman-0.43.4.tar.gz
2. Untar source
3. cd pixman-0.43.4; mkdir build; 
4. add options -Og and -save-temps in meson.build
5. meson setup ./build
6. ninja -C ./build/

gcc version: both 14.0.1 and 14.1.0 can reproduce
system type: linux (eg: fedora 40)
Success option:
 ARGS = -Ipixman/libpixman-1.so.0.43.4.p -Ipixman -I../pixman
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=gnu99 -O2 -g -Wdeclaration-after-statement -fno-strict-aliasing
-fvisibility=hidden -Wundef -ftrapping-math -Wno-unused-local-typedefs
-DHAVE_CONFIG_H -fPIC -pthread

Fail option:
 ARGS = -Ipixman/libpixman-1.so.0.43.4.p -Ipixman -I../pixman
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=gnu99 -O2 -g -Wdeclaration-after-statement -fno-strict-aliasing
-fvisibility=hidden -Wundef -ftrapping-math -Og -Wno-unused-local-typedefs
-DHAVE_CONFIG_H -fPIC -pthread


Difference of success/fail option:  -Og,  once -Og is used, compile will fail.

Fail message:
../pixman/pixman-combine-float.c:370:5: error: inlining failed in call to
‘always_inline’ ‘combine_soft_light_c’: function not considered for inlining
  370 | combine_ ## name ## _c (float sa, float s, float da, float d)  
\
  | ^~~~
../pixman/pixman-combine-float.c:655:1: note: in expansion of macro
‘MAKE_SEPARABLE_PDF_COMBINERS’
  655 | MAKE_SEPARABLE_PDF_COMBINERS (soft_light)
  | ^~~~

See the attached *.i*

[Bug ada/115666] Cloaking access to subprogram in a record allows storing anonymous access-to-subprogram value

[saulius.grazulis at bti dot vu.lt via Gcc-bugs]

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

--- Comment #3 from Saulius Gražulis  ---
Hi, Eric,

thank you for updating the bug #115666 status!

I am bit puzzled by your comment "nobody should write this sort of 
things". Could you please let me know in somewhat more detail what was 
wrong with my bug report? I am relatively new to GCC/GNAT Bugzilla, so I 
would like to avoid mistakes in the future :)

Cheers,
Saulius


On 2024-06-27 13:45, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115666
>
> Eric Botcazou  changed:
>
> What|Removed |Added
> 
>   Ever confirmed|0   |1
>   Status|UNCONFIRMED |NEW
>   CC||ebotcazou at gcc dot gnu.org
> Last reconfirmed||2024-06-27
>
> --- Comment #2 from Eric Botcazou  ---
> Confirmed, but nobody should write this sort of things.
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.

[Bug c++/115664] -Wnonnull-compare breaks templated methods

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

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

--- Comment #7 from Jonathan Wakely  ---
if constexpr (not is_same_v)
  if (dynamic_cast(this) == nullptr)
throw Exception("Bad callback");

[Bug c/115680] New: ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

Bug ID: 115680
   Summary: ICE in on_ranges, at
analyzer/constraint-manager.cc:3166
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.hall at gmail dot com
  Target Milestone: ---

Created attachment 58530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58530&action=edit
.s containing machine details

[Bug ada/115630] Bounded queue does not finalize controlled components

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-27
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Eric Botcazou  ---
Please try with newer versions, 14.x at least or else mainline.

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jeremy  ---
Created attachment 58531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58531&action=edit
.i file from save-temps containing pre-processed source

[Bug ada/115666] Cloaking access to subprogram in a record allows storing anonymous access-to-subprogram value

[saulius.grazulis at bti dot vu.lt via Gcc-bugs]

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

--- Comment #4 from Saulius Gražulis  ---
Hi, Eric,

thank you for updating the bug #115666 status!

I am bit puzzled by your comment "nobody should write this sort of 
things". Could you please let me know in somewhat more detail what was 
wrong with my bug report? I am relatively new to GCC/GNAT Bugzilla, so I 
would like to avoid mistakes in the future :)

Cheers,
Saulius


On 2024-06-27 13:45, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115666
>
> Eric Botcazou  changed:
>
> What|Removed |Added
> 
>   Ever confirmed|0   |1
>   Status|UNCONFIRMED |NEW
>   CC||ebotcazou at gcc dot gnu.org
> Last reconfirmed||2024-06-27
>
> --- Comment #2 from Eric Botcazou  ---
> Confirmed, but nobody should write this sort of things.
>
> --
> You are receiving this mail because:
> You reported the bug.
> You are on the CC list for the bug.

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jeremy  ---
gcc -std=gnu23 g.c -DEDITOR=0 -O3 -Wall -Wextra -Wconversion -Wunused
-Wuninitialized -Wcast-qual -Wcast-align -Werror -march=native -mcpu=native
-mtune=native -pipe -funsigned-char -fwrapv -ffinite-math-only -mcmodel=tiny
-mlittle-endian -momit-leaf-frame-pointer -frename-registers
-mno-low-precision-recip-sqrt -mno-low-precision-sqrt -mno-low-precision-div
-mno-track-speculation -mpc-relative-literal-loads -mbranch-protection=none
-mno-fix-cortex-a53-835769 -mno-fix-cortex-a53-843419 -fcf-protection=none
-mearly-ra=all -mearly-ldp-fusion -mlate-ldp-fusion
--param=aarch64-ldp-policy=always --param=aarch64-stp-policy=always --param
case-values-threshold=6 -fwhole-program -fdelete-null-pointer-checks
-fallow-store-data-races -fno-math-errno -fno-reciprocal-math
-fno-trapping-math -fno-rounding-math -falign-jumps -ffp-contract=fast
-fmerge-all-constants -fomit-frame-pointer -freg-struct-return
-foptimize-strlen -fno-exceptions -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-stack-protector -Wno-clobbered
-Wno-char-subscripts -Wno-implicit-fallthrough -ftree-vrp -Wduplicated-branches
-Wduplicated-cond -Wpointer-arith -Wnested-externs -Wundef -Wfloat-conversion
-Wsign-conversion -Warith-conversion -Wnarrowing -Wsign-compare -Winline
-Woverflow -Wmissing-include-dirs -Wredundant-decls -Wunused-macros
-Wformat-truncation=2 -Woverlength-strings -Wdisabled-optimization -Wnormalized
-Wformat=2 -Wformat-overflow=2 -Wrestrict -Wshift-overflow=2 -Wpacked
-Wnull-dereference -Wmain -Wstringop-truncation -Wstringop-overflow=4
-Wstringop-overread -Winit-self -Wmultichar -Wstrict-prototypes
-Wreturn-local-addr -Wlogical-op -Wwrite-strings -Warray-bounds=2
-Wformat-signedness -Wstrict-overflow=5 -Walloc-zero -Wdiscarded-qualifiers
-fanalyzer -fstrict-aliasing -Wstrict-aliasing=3 -Wdouble-promotion
-Wunsafe-loop-optimizations -Wtrampolines -Wbad-function-cast
-Wcast-align=strict -Waddress-of-packed-member -Wsuggest-attribute=malloc
-Wsuggest-attribute=const -Wsuggest-attribute=noreturn -fstrict-flex-arrays=3
-Wxor-used-as-pow -Wdiscarded-array-qualifiers -Wenum-int-mismatch
-Wmissing-noreturn -Wflex-array-member-not-at-end -Wno-format-nonliteral
-freport-bug -save-temps -o /dev/null -lm -lreadline
gcc: warning: ‘-pipe’ ignored because ‘-save-temps’ specified
during IPA pass: analyzer
g.c:5629:10: internal compiler error: in on_ranges, at
analyzer/constraint-manager.cc:3166
 5629 |   return c1;
  |  ^~
0x1ab264b ana::merger_fact_visitor::on_ranges(ana::svalue const*,
ana::bounded_ranges const*)
../../gcc/analyzer/constraint-manager.cc:3166
0x1ab264b ana::merger_fact_visitor::on_ranges(ana::svalue const*,
ana::bounded_ranges const*)
../../gcc/analyzer/constraint-manager.cc:3146
0x1aadc33 ana::constraint_manager::for_each_fact(ana::fact_visitor*) const
../../gcc/analyzer/constraint-manager.cc:3252
0x1aadd43 ana::constraint_manager::merge(ana::constraint_manager const&,
ana::constraint_manager const&, ana::constraint_manager*)
../../gcc/analyzer/constraint-manager.cc:3193
0x111c62b ana::region_model::can_merge_with_p(ana::region_model const&,
ana::program_point const&, ana::region_model*, ana::extrinsic_state const*,
ana::program_state const*, ana::program_state const*) const
../../gcc/analyzer/region-model.cc:6222
0x1109dcb ana::program_state::can_merge_with_p(ana::program_state const&,
ana::extrinsic_state const&, ana::program_point const&, ana::program_state*)
const
../../gcc/analyzer/program-state.cc:1468
0x10ea973
ana::exploded_graph::maybe_process_run_of_before_supernode_enodes(ana::exploded_node*)
../../gcc/analyzer/engine.cc:3683
0x10ec2d7 ana::exploded_graph::process_worklist()
../../gcc/analyzer/engine.cc:3385
0x10ee377 ana::impl_run_checkers(ana::logger*)
../../gcc/analyzer/engine.cc:6210
0x10ef2bb ana::run_checkers()
../../gcc/analyzer/engine.cc:6308
0x10dfdef execute
../../gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccsQUmhZ.out file, please attach this to
your bugreport.
make: *** [makefile:269: lint] Error 1

[Bug c++/115664] -Wnonnull-compare breaks templated methods

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

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

--- Comment #8 from Jonathan Wakely  ---
Even if you can't use C++17, it still works like this:

  if (not std::is_same::value)
if (dynamic_cast(this) == nullptr)

[Bug ada/115666] Cloaking access to subprogram in a record allows storing anonymous access-to-subprogram value

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

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

--- Comment #5 from Eric Botcazou  ---
I probably should have said "but nobody should write this sort of code."

[Bug libstdc++/104395] ext/bitmap_allocator.h is not C++98 friendly when using with -faligned-new

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

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

Jonathan Wakely  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-June/65
   ||5842.html
   Last reconfirmed||2024-06-27
   Keywords||patch
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

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

[Bug c/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jeremy  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-unknown-linux-gnu/14.1.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../configure --with-cpu=cortex-a76
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.1.0 (GCC)

[Bug analyzer/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

Jeremy  changed:

   What|Removed |Added

  Attachment #58530|a-g.i   |a-g.s
   filename||

--- Comment #4 from Jeremy  ---
Comment on attachment 58530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58530
.s containing machine details

.arch armv8.2-a+dotprod+crc+crypto+fp16+rcpc
.file   "g.c"

[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:73ad57c244c283bf6da0c16630212f11b945eda5

commit r15-1693-g73ad57c244c283bf6da0c16630212f11b945eda5
Author: Jonathan Wakely 
Date:   Tue Jun 11 16:45:43 2024 +0100

libstdc++: Fix std::codecvt for empty dest
[PR37475]

For the GNU locale model, codecvt::do_out and codecvt::do_in incorrectly
return 'ok' when the destination range is empty. That happens because
detecting incomplete output is done in the loop body, and the loop is
never even entered if to == to_end.

By restructuring the loop condition so that we check the output range
separately, we can ensure that for a non-empty source range, we always
enter the loop at least once, and detect if the destination range is too
small.

The loops also seem easier to reason about if we return immediately on
any error, instead of checking the result twice on every iteration. We
can use an RAII type to restore the locale before returning, which also
simplifies all the other member functions.

libstdc++-v3/ChangeLog:

PR libstdc++/37475
* config/locale/gnu/codecvt_members.cc (Guard): New RAII type.
(do_out, do_in): Return partial if the destination is empty but
the source is not. Use Guard to restore locale on scope exit.
Return immediately on any conversion error.
(do_encoding, do_max_length, do_length): Use Guard.
* testsuite/22_locale/codecvt/in/char/37475.cc: New test.
* testsuite/22_locale/codecvt/in/wchar_t/37475.cc: New test.
* testsuite/22_locale/codecvt/out/char/37475.cc: New test.
* testsuite/22_locale/codecvt/out/wchar_t/37475.cc: New test.

[Bug analyzer/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

[gcc.hall at gmail dot com via Gcc-bugs]

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

Jeremy  changed:

   What|Removed |Added

  Attachment #58530|0   |1
is obsolete||

--- Comment #5 from Jeremy  ---
Created attachment 58532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58532&action=edit
Correct .s file with machine details

[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
Fixed on trunk (with the typo fixed).

[Bug ada/115666] Cloaking access to subprogram in a record allows storing anonymous access-to-subprogram value

[saulius.grazulis at bti dot vu.lt via Gcc-bugs]

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

--- Comment #6 from Saulius Gražulis  ---
On 2024-06-27 13:58, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115666
> 
> --- Comment #5 from Eric Botcazou  ---
> I probably should have said "but nobody should write this sort of code."
> 

:D

Thanks for the clarification!

True enough, the code t is deliberately broken. I had to push hard to 
get MEMORY_ERROR out of the provided example. But if would be great of 
Ada compilers would warn us about the problems with the code. :)

Regards,
Saulius

PS. Actually, I stumbled into the issue when applying in Ada program 
patterns which we regularly use in C (store a function pointer into a 
structure and call it later). For C, this is not a problem IMHO since C 
does not have nested functions. For Ada, this is clearly incorrect and 
bad design, but you only learn this after reading "Rationale for Ada 
2005. 3.4". It would be great if GNAT informed it users about the buggy 
code, as it does now for the simpler case of 'access to procedure' 
variables.

[Bug libstdc++/115454] std::experimental::find_last_set is buggy on x86-64-v4

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Alexandre Oliva
:

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

commit r14-10352-gb70af0bd2e33e9cc20dae45c131429a402fc8845
Author: Alexandre Oliva 
Date:   Thu Jun 27 08:14:34 2024 -0300

[libstdc++] [testsuite] defer to check_vect_support* [PR115454]

The newly-added testcase overrides the default dg-do action set by
check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so
it attempts to run the test even if runtime vector support is not
available.

Remove the explicit dg-do directive, so that the default is honored,
and the test is run if vector support is found, and only compiled
otherwise.


for  libstdc++-v3/ChangeLog

PR libstdc++/115454
* testsuite/experimental/simd/pr115454_find_last_set.cc: Defer
to check_vect_support_and_set_flags's default dg-do action.

(cherry picked from commit 95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b)

[Bug ada/115630] Bounded queue does not finalize controlled components

[saulius.grazulis at bti dot vu.lt via Gcc-bugs]

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

--- Comment #2 from Saulius Gražulis  ---
OK, I can confirm that GNAT 15.0 from the git://gcc.gnu.org/git/gcc.git master
no longer gas the bug, the finalization behaves as expected:

saulius@pterodaktilis queue-finlisation/ $
PATH=$HOME/install/gnat-alire/gnat-13.2.1/bin:$PATH

saulius@pterodaktilis queue-finlisation/ $ gnatclean check_queue_finalisation
"./check_queue_finalisation.ali" has been deleted
"./check_queue_finalisation.o" has been deleted
"check_queue_finalisation" has been deleted

saulius@pterodaktilis queue-finlisation/ $ gnatmake check_queue_finalisation
gcc -c check_queue_finalisation.adb
gnatbind -x check_queue_finalisation.ali
gnatlink check_queue_finalisation.ali

saulius@pterodaktilis queue-finlisation/ $ ./check_queue_finalisation | grep
'Disposing' 
>>> Disposing 'Thing'  Address:  140729416360224 Name: 'T' Some_Stuff: Count:  
>>> 0 Name: 't'
saulius@pterodaktilis queue-finlisation/ $ 
saulius@pterodaktilis queue-finlisation/ $
PATH=$HOME/install/gcc/gcc-gnu-commit-7fada36c778/bin:$PATH

# Too few 'Dispose' procedures called...

saulius@pterodaktilis queue-finlisation/ $ gnat --version
GNAT 15.0.0 20240626 (experimental)
Copyright (C) 1996-2024, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

saulius@pterodaktilis queue-finlisation/ $ gnatclean check_queue_finalisation
"./check_queue_finalisation.ali" has been deleted
"./check_queue_finalisation.o" has been deleted
"check_queue_finalisation" has been deleted

saulius@pterodaktilis queue-finlisation/ $ gnatmake check_queue_finalisation
gcc -c check_queue_finalisation.adb
gnatbind -x check_queue_finalisation.ali
gnatlink check_queue_finalisation.ali

saulius@pterodaktilis queue-finlisation/ $ ./check_queue_finalisation | grep
'Disposing' 
>>> Disposing 'Thing'  Address:  140735380336864 Name: 'T' Some_Stuff: Count:  
>>> 0 Name: 't'
>>> Disposing 'Thing'  Address:  140735380334504 Name: 'Y' Some_Stuff: Count:  
>>> 0 Name: 'y'
>>> Disposing 'Thing'  Address:  140735380334472 Name: 'X' Some_Stuff: Count:  
>>> 0 Name: 'x'
>>> Disposing 'Thing'  Address:  140735380336768 Name: 'U' Some_Stuff: Count:  
>>> 0 Name: 'u'
>>> Disposing 'Thing'  Address:  140735380336864 Name: 'W' Some_Stuff: Count:  
>>> 0 Name: 'w'

# All objects Dispose'd as intended :)

Sorry for the false alarm, and thanks for the rapid fixes! (Did not expect the
15.0 o have the issue fixed already :)

[Bug ada/115630] Bounded queue does not finalize controlled components

[saulius.grazulis at bti dot vu.lt via Gcc-bugs]

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

--- Comment #3 from Saulius Gražulis  ---
PS All other queues also behave as expected when compiled with GNAT 15.0.

[Bug ada/115630] Bounded queue does not finalize controlled components

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Thanks for confirming.  This also works with 14.x for me.

[Bug libstdc++/115454] std::experimental::find_last_set is buggy on x86-64-v4

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Alexandre Oliva
:

https://gcc.gnu.org/g:3de1c4985bebd1882b6643789daba24f2d11bafe

commit r13-8872-g3de1c4985bebd1882b6643789daba24f2d11bafe
Author: Alexandre Oliva 
Date:   Thu Jun 27 08:32:15 2024 -0300

[libstdc++] [testsuite] defer to check_vect_support* [PR115454]

The newly-added testcase overrides the default dg-do action set by
check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so
it attempts to run the test even if runtime vector support is not
available.

Remove the explicit dg-do directive, so that the default is honored,
and the test is run if vector support is found, and only compiled
otherwise.


for  libstdc++-v3/ChangeLog

PR libstdc++/115454
* testsuite/experimental/simd/pr115454_find_last_set.cc: Defer
to check_vect_support_and_set_flags's default dg-do action.

(cherry picked from commit 95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b)

[Bug libstdc++/115454] std::experimental::find_last_set is buggy on x86-64-v4

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Alexandre Oliva
:

https://gcc.gnu.org/g:95ca5f458251e21123e45ec52c38d629d39cd0e4

commit r12-10585-g95ca5f458251e21123e45ec52c38d629d39cd0e4
Author: Alexandre Oliva 
Date:   Thu Jun 27 08:44:54 2024 -0300

[libstdc++] [testsuite] defer to check_vect_support* [PR115454]

The newly-added testcase overrides the default dg-do action set by
check_vect_support_and_set_flags (in libstdc++-dg/conformance.exp), so
it attempts to run the test even if runtime vector support is not
available.

Remove the explicit dg-do directive, so that the default is honored,
and the test is run if vector support is found, and only compiled
otherwise.


for  libstdc++-v3/ChangeLog

PR libstdc++/115454
* testsuite/experimental/simd/pr115454_find_last_set.cc: Defer
to check_vect_support_and_set_flags's default dg-do action.

(cherry picked from commit 95faa1bea7bdc7f92fcccb3543bfcbc8184c5e5b)

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #19 from Rama Malladi  ---
Thank you Hubicka@ for the inputs. I see your intent and that we have to
revisit the inline parameter tuning. As I and Richard S mentioned, the intent
of this feature request or PR is to expose such an option to the user for
getting aggressive inline optimizations enabled by the compiler.

Coming to some equivalent flags such as `-fvect-cost-model`, those flags allow
for choosing one of the multiple models such as 'dynamic', 'cheap'... In case
of inline parameter choice, we have only 2 choices: 'default', 'aggressive'.
Hence, adding an option such as `-finline-functions-aggressive` would be fine
to toggle between default and aggressive settings.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

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

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

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

https://gcc.gnu.org/g:7886830bb45c4f5dca0496d4deae9a45204d78f5

commit r15-1694-g7886830bb45c4f5dca0496d4deae9a45204d78f5
Author: Richard Biener 
Date:   Thu Jun 27 11:26:08 2024 +0200

tree-optimization/115669 - fix SLP reduction association

The following avoids associating a reduction path as that might
get STMT_VINFO_REDUC_IDX out-of-sync with the SLP operand order.
This is a latent issue with SLP reductions but now easily exposed
as we're doing single-lane SLP reductions.

When we achieved SLP only we can move and update this meta-data.

PR tree-optimization/115669
* tree-vect-slp.cc (vect_build_slp_tree_2): Do not reassociate
chains that participate in a reduction.

* gcc.dg/vect/pr115669.c: New testcase.

[Bug tree-optimization/115669] [15 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed (verified on aarch64).

[Bug libstdc++/115444] std::copy_n generates more code than needed

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #0)
> But if you compile with `-std=c++20 -ULESS`, you get more verbose codegen:
> first a call to `It::operator+(int)`, then a call to `It::operator-(It)`,
> and then the same loop as before. That is, it appears that libstdc++ is
> "lowering" `std::copy_n(first, n, dest)` into `std::copy(first, first+n,
> dest)`

Yes, so that std::copy_n benefits from the same memmove optimization as
std::copy.

> and then "lowering" that back into `std::copy_n(first, first+n -
> first, dest)` before finally getting to the loop.

No, we just do last - first in std::copy if we have random access iterators:

  for(_Distance __n = __last - __first; __n > 0; --__n)
{
  *__result = *__first;
  ++__first;
  ++__result;
}

We could just use while (__first != __last) instead, but that would remove a
very intentional "optimization" that's explicitly mentioned in a comment:

  // All of these auxiliary structs serve two purposes.  (1) Replace
  // calls to copy with memmove whenever possible.  (Memmove, not memcpy,
  // because the input and output ranges are permitted to overlap.)
  // (2) If we're using random access iterators, then write the loop as
  // a for loop with an explicit count.

If we stopped using a loop with an explicit count then we could get rid of the
partial specializations for random access iterators, as they'd now be
equivalent to the default loop for input iterators.

That wouldn't change the fact that copy_n dispatches to copy though, so
wouldn't do anything about the s+1000 case.

[Bug libffi/115681] New: libffi.closures/single_entry_structs2.c FAILs on 32-bit SPARC

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

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

Bug ID: 115681
   Summary: libffi.closures/single_entry_structs2.c FAILs on
32-bit SPARC
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, sparc-unknown-linux-gnu

Since the libffi 3.4.2 import on 20211020, the
libffi.closures/single_entry_structs2.c
test FAILs on 32-bit SPARC (both Linux and Solaris):

FAIL: libffi.closures/single_entry_structs2.c -W -Wall -Wno-psabi -O0 execution
test

In current upstream libffi, the failure persists, and there are quite a number
of additional ones.  I've reported them as
https://github.com/libffi/libffi/issues/841
and finally posted a proposed patch there.

When/if that's accepted upstream, it should be cherry-picked into the gcc tree,
I believe.

[Bug libffi/115681] libffi.closures/single_entry_structs2.c FAILs on 32-bit SPARC

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/115669] [12/13/14 Regression] rv64gcv/aarch64+sve -fwrapv miscompile since r15-1006-gd93353e6423

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||15.0
 Status|RESOLVED|ASSIGNED
   Priority|P3  |P2
   Target Milestone|15.0|12.5
 Resolution|FIXED   |---
Summary|[15 Regression] |[12/13/14 Regression]
   |rv64gcv/aarch64+sve -fwrapv |rv64gcv/aarch64+sve -fwrapv
   |miscompile since|miscompile since
   |r15-1006-gd93353e6423   |r15-1006-gd93353e6423

--- Comment #9 from Richard Biener  ---
Let me re-open for backports, the issue is latent with a true SLP reduction.
Unfortunately getting a SLP reduction like the following to work seems
difficult.

int a = 10;
unsigned b, f;
long long c[100];
int main() {
  long long *d = c;
  for (short e = 0; e < a; e++)
{
  b += ~(d ? d[2*e] : 0);
  f += ~(d ? d[2*e+1] : 0);
}
  __builtin_printf("%d %d\n", b, f);
}

[Bug middle-end/115675] [15 Regression] truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
Version|unknown |15.0
   Target Milestone|--- |15.0
 Target||x86_64-*-*
Summary|truncv4hiv4qi affect|[15 Regression]
   |r14-1402-gd8545fb2c71683's  |truncv4hiv4qi affect
   |optimization.   |r14-1402-gd8545fb2c71683's
   ||optimization.

--- Comment #1 from Richard Biener  ---
so it's now SLP vectorized?

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0

--- Comment #5 from Richard Biener  ---
looks like memory corruption to me

[Bug libstdc++/115444] std::copy_n generates more code than needed

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> We could just use while (__first != __last) instead, but that would remove a
> very intentional "optimization" that's explicitly mentioned in a comment:
> 
>   // All of these auxiliary structs serve two purposes.  (1) Replace
>   // calls to copy with memmove whenever possible.  (Memmove, not memcpy,
>   // because the input and output ranges are permitted to overlap.)
>   // (2) If we're using random access iterators, then write the loop as
>   // a for loop with an explicit count.

Although that comment came directly from the SGI STL, so the "optimization" is
more than 25 years old and might be irrelevant now.

[Bug tree-optimization/115679] inlining failed in call to 'foo': function not considered for inlining

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
With -Og it's usually that the always-inline function is called indirectly -
that's an unsupported case.

[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array

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

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

Andre Vehreschild  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
 CC||vehre at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #4 from Andre Vehreschild  ---
The line

 print*, errornous_ver(spcs, fuel)

blocks for me. In the I/O classes and does not print anything.

Changing that line to 

   integer :: r
...
   r = errornous_ver(spcs, fuel)
   print*, r

works with gfortran 13.3.1. Therefore I think the initial error resolved. Ok to
close?

[Bug target/115682] New: nvptx vs. "fwprop: invoke change_is_worthwhile to judge if a replacement is worthwhile"

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

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

Bug ID: 115682
   Summary: nvptx vs. "fwprop: invoke change_is_worthwhile to
judge if a replacement is worthwhile"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: sayle at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

I've observed/bisected that "fwprop: invoke change_is_worthwhile to judge if a
replacement is worthwhile" (a) slightly improves and in a some cases also (b)
slightly regresses nvptx target code generation (supposedly; not actually
benchmarked).  That is, in a few cases, it introduces additional register usage
together with (a) different choice of PTX instructions (presumably beneficial),
or (b) redundant computations (presumably bad).  It's possible that the PTX JIT
later is able to re-optimize this, but we can't be sure -- and would like good
PTX code emitted by GCC if only for our own reading pleasure.

I've only looked at PTX code generated for GCC target libraries, and only
looked at those where the 'diff' was less than one screenful, roughly.

A few examples of category (a):

'nvptx-none/libgfortran/generated/_dim_i16.o:_gfortran_specific__dim_i16':

[...]
+.reg .u64 %r42;
[...]
-mov.u64 %r54,%r32;
-sub.u64 %r55,%r39,%r35;
-setp.ge.s64 %r45,%r55,0;
-@ %r45 bra $L2;
-mov.u64 %r54,0;
-mov.u64 %r55,%r54;
-$L2:
+sub.u64 %r42,%r39,%r35;
+setp.ge.s64 %r45,%r42,0;
+selp.u64 %r54,%r32,0,%r45;
+selp.u64 %r55,%r42,0,%r45;
[...]

That is, replace conditional 'bra' by two 'selp's.

Similar, 'nvptx-none/newlib/libc/stdio/libc_a-makebuf.o:__swhatbuf_r':

[...]
 setp.ne.u16 %r41,%r39,0;
-@ %r41 bra $L22;
 mov.u32 %r23,0;
-mov.u64 %r31,1024;
+selp.u64 %r31,64,1024,%r41;
 mov.u32 %r32,%r23;
 bra $L20;
 $L19:
@@ -325,11 +324,6 @@
 .loc 2 123 10
 mov.u64 %r31,1024;
 mov.u32 %r32,2048;
-bra $L20;
-$L22:
-mov.u32 %r23,0;
-mov.u64 %r31,64;
-mov.u32 %r32,%r23;
 $L20:
[...]

Differently, 'nvptx-none/newlib/libc/search/libc_a-hash_page.o:__addel':

[...]
-add.u64 %r38,%r37,%r37;
+shl.b64 %r38,%r37,1;
[...]

A few examples of category (b):

'nvptx-none/newlib/libc/stdlib/libc_a-gdtoa-gdtoa.o:__gdtoa':

[...]
+.reg .u64 %r263;
[...]
-add.u64 %r337,%r391,24;
+add.u64 %r263,%r391,24;
+mov.u64 %r337,%r263;
[...]

New unnecessary intermediate 'u64 %r263'.

Similarly, 'nvptx-none/newlib/libc/stdlib/libc_a-mprec.o:__d2b':

[...]
+.reg .u32 %r89;
[...]
-cvt.u64.u32 %r90,%r39;
+mov.u32 %r89,%r39;
+cvt.u64.u32 %r90,%r89;
[...]

'nvptx-none/libgfortran/generated/cshift0_c4.o:_gfortrani_cshift0_c4' (full
diff with a bit of unchanged context added):

[...]
 .reg .u64 %r131;
[...]
 .reg .u32 %r177;
[...]
+.reg .u32 %r266;
 .reg .u64 %r267;
[...]
 mov.u32 %r177,%ar3;
[...]
 cvt.s64.s32 %r131,%r177;
[...]
-cvt.u64.u32 %r267,%r177;
+cvt.u32.u64 %r266,%r131;
+cvt.u64.u32 %r267,%r266;
[...]

In the new code, the 'u32' '%r177' is interpreted as 's32', converted into
's64', and stored into 'u64' '%r131' (which is present also in the old code for
other reasons; I didn't try to understand that in more detail).  The 'u64'
'%r131' is then converted into 'u32' and stored in the new 'u32 %r266', and
then again converted into 'u64', and stored in '%r267'.

In the old code, the 'u32' '%r177' was converted into 'u64', and stored into
the 'u64' '%r267' directly.

A lot more instances of this in other files.

'nvptx-none/libgfortran/generated/matmul_i1.o:_gfortran_matmul_i1' (full diff
with a bit of unchanged context added):

[...]
 .reg .u64 %r299;
[...]
 .reg .u64 %r347;
 .reg .u64 %r349;
[...]
 .reg .u64 %r432;
[...]
 .reg .u64 %r1004;
[...]
 ['%r299' initialized via different code paths]
[...]
 ld.u64 %r347,[%r733];
[...]
 add.u64 %r1004,%r299,1;
[...]
 sub.u64 %r349,%r347,%r1004;
[...]
-mov.u64 %r432,%r347;
+add.u64 %r432,%r349,%r1004;
[...]

That is, instead of just using '%r347' ('mov') for '%r432', we now prefer
re-computing it ('add').

Similarly in 'nvptx-none/libgfortran/io/transfer.o:bswap_array' -- even more
concisely:

[...]
 add.u64 %r68,%r92,%r65;
-mov.u64 %r53,%r92;
+sub.u64 %r53,%r68,%r65;
[...]

..., and both these items in combination (?) in
'nvptx-none/newlib/libc/search/libc_a-hash.o:__expand_table', for example,
where we now use two additional registers, plus additional 'sub' plus
additional 'cvt'.

Now, I suppose, we'll quickly conclude this is due to instruction costing (...,
and, in pa

[Bug libstdc++/115444] std::copy_n generates more code than needed

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

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

--- Comment #5 from Arthur O'Dwyer  ---
> Yes, so that std::copy_n benefits from the same memmove optimization as 
> std::copy.

Right, I'm not objecting to the memmove optimization, just to the current
codebase's approach of "slightly pessimize by going halfway down that alley,
then find out memmove isn't possible and turn around and go back to the
non-memmove path but now we've got a few extra instructions we can't go back
and get rid of." The current approach is *not buggy*, but it would be *better*
if copy_n could figure out the applicability of the memmove optimization on its
own.

I hadn't considered that there might [have] be[en] platforms on which a
for-loop over integers might be faster than a while-loop over pointer
comparisons. I'm pretty sure that's not true of any *mainstream* platform. But
that could certainly have contributed to historical justification for the
current approach.

[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:57482cadeb12af2dd52b381b0766776d1e8ec59b

commit r11-11541-g57482cadeb12af2dd52b381b0766776d1e8ec59b
Author: Iain Sandoe 
Date:   Sat Oct 2 14:43:39 2021 +0100

coroutines: Await expressions are not allowed in handlers [PR 99710].

C++20 [expr.await] / 2
An await-expression shall appear only in a potentially-evaluated expression
within the compound-statement of a function-body outside of a handler.

Signed-off-by: Iain Sandoe 

PR c++/99710

gcc/cp/ChangeLog:

* coroutines.cc (await_statement_walker): Report an error if
an await expression is found in a handler body.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr99710.C: New test.

(cherry picked from commit 650beb110538097b9c3e8600149b333a83e7e836)

[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

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

commit r11-11542-gf647906ef227bc22af224d955a408d776cfddb04
Author: Iain Sandoe 
Date:   Sun Oct 3 19:46:09 2021 +0100

coroutines: Pass lvalues to user-defined operator new [PR 100772].

The wording of the standard has been clarified to be explicit that
the the parameters to any user-defined operator-new in the promise
class should be lvalues.

Signed-off-by: Iain Sandoe 

PR c++/100772

gcc/cp/ChangeLog:

* coroutines.cc (morph_fn_to_coro): Convert function parms
from reference before constructing any operator-new args
list.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr100772-a.C: New test.
* g++.dg/coroutines/pr100772-b.C: New test.

(cherry picked from commit 921942a8a106cb53994c21162922e4934eb3a3e0)

[Bug c++/101765] ICE when using a VLA inside of a coroutine

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:1d5779274ce9807358f9e04f1112b65c6ed6c284

commit r11-11543-g1d5779274ce9807358f9e04f1112b65c6ed6c284
Author: Iain Sandoe 
Date:   Sat Oct 2 16:15:38 2021 +0100

coroutines: Fail with a sorry when presented with a VLA [PR 101765].

We do not support this yet.

Signed-off-by: Iain Sandoe 

PR c++/101765

gcc/cp/ChangeLog:

* coroutines.cc (register_local_var_uses): Emit a sorry if
we encounter a VLA in the coroutine local variables.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr101765.C: New test.

(cherry picked from commit fdf0b6ce6c1cfa1c328c0c40473c71ca11fd8303)

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

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

commit r11-11544-gf4cdbf1f757fa9525d70780546d7daa43dfb129f
Author: Iain Sandoe 
Date:   Mon Apr 18 16:23:30 2022 +0100

c++, coroutines: Improve check for throwing final await [PR104051].

We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case.  If the use returns some nonsensical type from the
method, we need to handle that in the checking for noexcept.

Signed-off-by: Iain Sandoe 

PR c++/104051

gcc/cp/ChangeLog:

* coroutines.cc (coro_diagnose_throwing_final_aw_expr): Handle
non-target expression inputs.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr104051.C: New test.

(cherry picked from commit 7b96274a340bc0e9bcaef9baff3a44ec2f12c3df)

[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed on open branches

[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed on open branches

[Bug c++/101765] ICE when using a VLA inside of a coroutine

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #8 from Iain Sandoe  ---
fixed on open branches

[Bug c++/16994] [meta-bug] VLA and C++

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

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

Bug 101765 Summary: ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765

   What|Removed |Added

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

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed on open branches

[Bug target/115618] [11/12/13 only] should define __ARM_FEATURE_CRYPTO with +aes+sha2

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Kyrylo Tkachov
:

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

commit r13-8873-gc93a9bba743ac236f6045ba7aafbc12a83726c48
Author: Andrew Carlotti 
Date:   Fri Nov 24 17:06:07 2023 +

aarch64: Fix +nocrypto handling

Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with
checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead.  The value of the
AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is
retained because removing it would make processing the data in
option-extensions.def significantly more complex.

This bug should have been picked up by an existing test, but a missing
newline meant that the pattern incorrectly allowed "+crypto+nocrypto".

gcc/ChangeLog:

PR target/115618
* common/config/aarch64/aarch64-common.cc
(aarch64_get_extension_string_for_isa_flags): Fix generation of
the "+nocrypto" extension.
* config/aarch64/aarch64.h (AARCH64_ISA_CRYPTO): Remove.
(TARGET_CRYPTO): Remove.
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins):
Don't use TARGET_CRYPTO.

gcc/testsuite/ChangeLog:

PR target/115618
* gcc.target/aarch64/options_set_4.c: Add terminating newline.
* gcc.target/aarch64/options_set_27.c: New test.

(cherry picked from commit 8d30107455f2309854ced3d65fb07dc1f2c357c0)

[Bug target/115683] New: SSE2 regressions after obselete of vcond{,u,eq}.

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

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

Bug ID: 115683
   Summary: SSE2 regressions after obselete of vcond{,u,eq}.
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

Whole failure list.
g++: g++.target/i386/pr100637-1b.C  -std=gnu++14  scan-assembler-times pcmpeqb
2
g++: g++.target/i386/pr100637-1b.C  -std=gnu++17  scan-assembler-times pcmpeqb
2
g++: g++.target/i386/pr100637-1b.C  -std=gnu++20  scan-assembler-times pcmpeqb
2
g++: g++.target/i386/pr100637-1b.C  -std=gnu++98  scan-assembler-times pcmpeqb
2
g++: g++.target/i386/pr100637-1w.C  -std=gnu++14  scan-assembler-times pcmpeqw
2
g++: g++.target/i386/pr100637-1w.C  -std=gnu++17  scan-assembler-times pcmpeqw
2
g++: g++.target/i386/pr100637-1w.C  -std=gnu++20  scan-assembler-times pcmpeqw
2
g++: g++.target/i386/pr100637-1w.C  -std=gnu++98  scan-assembler-times pcmpeqw
2
g++: g++.target/i386/pr103861-1.C  -std=gnu++14  scan-assembler-times pcmpeqb 2
g++: g++.target/i386/pr103861-1.C  -std=gnu++17  scan-assembler-times pcmpeqb 2
g++: g++.target/i386/pr103861-1.C  -std=gnu++20  scan-assembler-times pcmpeqb 2
g++: g++.target/i386/pr103861-1.C  -std=gnu++98  scan-assembler-times pcmpeqb 2
gcc: gcc.target/i386/pr88540.c scan-assembler minpd



There're extra 1 pcmpeq instruction generated in below 3 testcase for
comparison of GTU, x86 doesn't support native GTU comparison, but use psubusw +
pcmpeq + pcmpeq, the second pcmpeq is used to negate the mask, and the negate
can be
 eliminated in vcond{,u,eq} expander by just swapping if_true and if_else.

g++: g++.target/i386/pr100637-1b.C 
g++.target/i386/pr100637-1w.C
g++: g++.target/i386/pr103861-1.C


This one maybe a little bit difficult, it's x86 specific floating point
min/max{ps,pd} which is an exact match of a > b ? a : b, and not
ieee-conformant.

gcc: gcc.target/i386/pr88540.c scan-assembler minpd

[Bug middle-end/115675] [15 Regression] truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #2 from Hongtao Liu  ---
(In reply to Richard Biener from comment #1)
> so it's now SLP vectorized?

Yes, the vectorization looks not reasonable. it used to be vectorized as v4qi
vector CTOR +  v4qi vector store. Now it's vectorized as v4hi vector CTOR +
truncv4hiv4qi + v4qi vector store.

[Bug libstdc++/104259] libstdc++ fails for epiphany-elf

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-11545-g6e33ffd543257a1a599b51201e9db95b070dbf84
Author: Martin Liska 
Date:   Thu Jan 27 14:47:23 2022 +0100

libstdc++: fix typo in acinclude.m4.

PR libstdc++/104259

libstdc++-v3/ChangeLog:

* acinclude.m4: Fix typo.
* configure: Regenerate.

(cherry picked from commit 14f339894db6ca7fe4772d5528c726694d2517c4)

[Bug libstdc++/104259] libstdc++ fails for epiphany-elf

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.5

[Bug tree-optimization/108860] [12/13/14/15 regression] New (since gcc 12) false positive null-dereference in vector.resize

[adl at gnu dot org via Gcc-bugs]

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

Alexandre Duret-Lutz  changed:

   What|Removed |Added

 CC||adl at gnu dot org

--- Comment #3 from Alexandre Duret-Lutz  ---
Arrived here because I have the same issue, but with an even simpler input.


% cat foo.c 
#include 

void test(std::vector& v)
{
  v.insert(v.begin(), 12);
}
% g++ -O -std=c++20 -Werror=null-dereference -c  foo.cc
In file included from /usr/include/c++/13/bits/stl_iterator.h:85,
 from /usr/include/c++/13/bits/stl_algobase.h:67,
 from /usr/include/c++/13/vector:62,
 from foo.cc:1:
In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*,
_Args&& ...) [with _Tp = int; _Args = {int}]’,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = int; _Args = {int}; _Tp = int]’ at
/usr/include/c++/13/bits/alloc_traits.h:540:21,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_realloc_insert(iterator, _Args&& ...) [with _Args = {int}; _Tp =
int; _Alloc = std::allocator]’ at
/usr/include/c++/13/bits/vector.tcc:468:28,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::_M_insert_rval(const_iterator, value_type&&) [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/13/bits/vector.tcc:372:19,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, value_type&&) [with _Tp = int; _Alloc =
std::allocator]’ at /usr/include/c++/13/bits/stl_vector.h:1394:30,
inlined from ‘void test(std::vector&)’ at foo.cc:5:11:
/usr/include/c++/13/bits/stl_construct.h:97:14: error: potential null pointer
dereference [-Werror=null-dereference]
   97 | { return ::new((void*)__location)
_Tp(std::forward<_Args>(__args)...); }
  | 
^~~~
cc1plus: some warnings being treated as errors


Reproduced with 
- g++-13 (Debian 13.2.0-25) 13.2.0
- g++-12 (Debian 12.3.0-17) 12.3.0

[Bug analyzer/115680] ICE in on_ranges, at analyzer/constraint-manager.cc:3166

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-27
 Status|UNCONFIRMED |NEW

--- Comment #6 from David Malcolm  ---
Thanks for filing this bug report.

Minimal args to reproduce the ICE with attachment 58531 seem to be:
  -fanalyzer -ftree-vrp -std=gnu23 -O1
(https://godbolt.org/z/P6T91PzWf)

[Bug tree-optimization/115679] inlining failed in call to 'foo': function not considered for inlining

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #2 from Jan Hubicka  ---
> With -Og it's usually that the always-inline function is called indirectly -
> that's an unsupported case.
We can probably add CIF code for functions that were called indirectly
but are no more, so this is reported better.  I will cook up patch.

[Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang

[djordje.baljozovic at ac dot rwth-aachen.de via Gcc-bugs]

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

Djordje Baljozovic  changed:

   What|Removed |Added

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

[Bug target/115634] [15 regression] s390 bootstrap failure since r15-1579-g792f97b44ffc5e

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:187eeb99ec5289538923668de9d61a3138376817

commit r15-1695-g187eeb99ec5289538923668de9d61a3138376817
Author: Stefan Schulze Frielinghaus 
Date:   Thu Jun 27 15:46:24 2024 +0200

s390: Check for ADDR_REGS in s390_decompose_addrstyle_without_index

An explicit check for address registers was not required so far since
during register allocation the processing of address constraints was
sufficient.  However, address constraints themself do not check for
REGNO_OK_FOR_{BASE,INDEX}_P.  Thus, with the newly introduced
late-combine pass in r15-1579-g792f97b44ffc5e we generate new insns with
invalid address registers which aren't fixed up afterwards.

Fixed by explicitly checking for address registers in
s390_decompose_addrstyle_without_index such that those new insns are
rejected.

gcc/ChangeLog:

PR target/115634
* config/s390/s390.cc (s390_decompose_addrstyle_without_index):
Check for ADDR_REGS in s390_decompose_addrstyle_without_index.

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r15-1696-gf6081ee665fd5e4e7d37e02c69d16df0d3eead10
Author: Richard Sandiford 
Date:   Thu Jun 27 14:51:37 2024 +0100

Disable late-combine for -O0 [PR115677]

late-combine relies on df, which for -O0 is only initialised late
(pass_df_initialize_no_opt, after split1).  Other df-based passes
cope with this by requiring optimize > 0, so this patch does the
same for late-combine.

gcc/
PR rtl-optimization/115677
* late-combine.cc (pass_late_combine::gate): New function.

[Bug rtl-optimization/115677] ICE when building argon2 with -flate-combine-instructions on amd64

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Sandiford  ---
Fixed.

[Bug target/115457] AArch64 should define __ARM_FEATURE_BF16

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Mine.

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

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug c++/115364] [11/12/13/14/15 Regression] ICE-on-invalid when calling non-const template member on const object

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #2 from Simon Martin  ---
Working on it.

[Bug c/115684] New: No warning for pointer and enum field comparison

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

Bug ID: 115684
   Summary: No warning for pointer and enum field comparison
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
  Target Milestone: ---

Comparing an enum field with a pointer produces no warnings (while comparing an
int to a pointer produces them). We just had a regression due to this missing
check, such code clearly shouldn't have been compiled in the first place (well,
with Wfatal of course).

# Steps to reproduce (in terms of terminal commands)

λ cat test.c
#include 

int main() {
enum { myEnumField };
int a = 0;
int *b = &a;
if (b == myEnumField)
puts("hey");
}
λ gcc test.c -o a -g3 -O0 -Wall -Wextra -Wsign-conversion


## Expected

A warning, something like:

test.c:16:11: warning: comparison between pointer and enum field
   16 | if (b == myEnumField)


## Actual

No warnings being produced

[Bug fortran/115685] New: [OpenMP][5.1][OpenACC] Permit named constants ("PARAMETER") in firstprivate, shared and copyin clauses

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

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

Bug ID: 115685
   Summary: [OpenMP][5.1][OpenACC] Permit named constants
("PARAMETER") in firstprivate, shared and copyin
clauses
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openacc, openmp, rejects-valid
  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, tschwinge at gcc dot gnu.org
  Target Milestone: ---

OpenMP 5.1 permits now named constants ("PARAMETER") in 'shared' and in
'firstprivate' clauses.

OpenACC 3.4 will permit it explicitly in 'firstprivate' and 'copyin' clauses (→
OpenACC, Issue 505), user code already used it for both arrays and scalars.

* * *

3 | !$omp parallel firstprivate(p) shared(q)
6 | !$omp target firstprivate(p)
Error: Object 'p' is not a variable at (1)
Error: Object 'q' is not a variable at (1)
Error: Object 'p' is not a variable at (1)

 for: 

integer, parameter :: p = 5, q= 7

!$omp parallel firstprivate(p) shared(q)
!$omp end parallel

!$omp target firstprivate(p)
!$omp end target
end

* * *

OpenACC (real-world use in the ICON code,
https://gitlab.dkrz.de/icon/icon-model/ ):

  REAL(wp), PARAMETER ::  zwdmin = 0.05_wp
  !$ACC DECLARE COPYIN(zwdmin)

  REAL(KIND=jprb), PARAMETER :: beta(2)= [0.7_jprb , 0.45_jprb ]  
  !$ACC DECLARE COPYIN(beta)

* * *

Wording in OpenMP (here TR12, but it was added in 5.1):

In "4.2.1 OpenMP Argument Lists":

[104:8]  A variable list item is one of the following: […]
[104:11] * a named constant; […]

[104:18] A named constant as a list item can appear only in clauses where it is
explicitly allowed.

And in "6.1 Data-Sharing Attribute Rules" → "6.1.1 Variables Referenced in a
Construct":

[148:3–4]   Certain variables and objects have predetermined data-sharing
attributes for the construct in which they are referenced […]

[150:16–17] * […] named constants are shared in constructs that are not
  data-mapping constructs.
[150:18]* Named constants are firstprivate in target constructs.

[150:23–24] Variables with predetermined data-sharing attributes may not be
listed in data-sharing attribute clauses, except for the cases
listed below […]

[151:11]Named constants may be listed in a shared or firstprivate clause.


In 6.4.4 firstprivate Clause:

The list items that appear in a firstprivate clause may include named
constants.


(Same in 'shared' clauses, once the omission has been fixed; OpenMP, Issue
3995.)

[Bug c/115684] No warning for pointer and enum field comparison

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #1 from Konstantin Kharlamov  ---
FWIW, IRL these cases happen during refactoring, when you factor out a code to
a smaller function, and some variables from the original function become
pointers. I honestly never even check the parameter types in these cases
because I sincerely think it's the duty of the compiler to warn about the
pointer/non-pointer usage mismatch. I am kind of shocked to see this isn't
handled.

[Bug c/115684] No warning for pointer and enum field comparison

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
I modified it slightly and got it it to warn:

$ cat 115684.c
#include 

int main(void) {
enum { myEnumField0, myEnumField1 };
int a = 0;
int *b = &a;
if (b == myEnumField0)
return puts("hey");
else if (b == myEnumField1)
return puts("yeh");
return a;
}
$ /usr/local/bin/gcc -c -g3 -O3 -Wall -Wextra -Wconversion -pedantic
-Wc++-compat -Wunused 115684.c
115684.c: In function 'main':
115684.c:9:16: warning: comparison between pointer and integer
9 | else if (b == myEnumField1)
  |^~
$

So, it depends on the value of the enumerator, it seems. Also it's a problem
that the existing warning doesn't seem to be linked to a flag; see bug 44209

[Bug libstdc++/115444] std::copy_n generates more code than needed

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

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

--- Comment #6 from Jonathan Wakely  ---
If the compile wants to vectorize the loop, knowing there are N iterations
helps. Using first != last as the condition isn't necessarily just a pointer
comparison for arbitrary random access iterators, so the number of iterations
might be harder for the compiler to determine. Although it probably is
tractable for any case where the loop is going to be vectorizable.

[Bug tree-optimization/110498] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve

[rogerio.souza at gmail dot com via Gcc-bugs]

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

Rogério de Souza Moraes  changed:

   What|Removed |Added

Version|13.1.0  |12.4.0

--- Comment #4 from Rogério de Souza Moraes  ---
This issue now is affecting the GCC 12.4.0 as you can see at
https://godbolt.org/z/8xr6eMeha.

[Bug c++/115686] New: gcc cannot generate weak link function for thread_local variable `TLS init function`

[MacroModel at trajectronix dot onmicrosoft.com via Gcc-bugs]

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

Bug ID: 115686
   Summary: gcc cannot generate weak link function for
thread_local variable `TLS init function`
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: MacroModel at trajectronix dot onmicrosoft.com
  Target Milestone: ---

gcc cannot generate weak link function for thread_local variable `TLS init
function`

```cpp

// h1.h

#include 
inline thread_local ::std::vector v{};

// c1.cpp

#include "h1.h"
int main()
{
v.push_back(1);
}

// c2.cpp

#include "h1.h"
void foo()
{
v.push_back(2);
}

```

compile:

```bash
g++ -o test c1.cpp c2.cpp -std=c++2c
G:/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/15.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\User\AppData\Local\Temp\ccQoDAAa.o:c2.cpp:(.text+0x2a): multiple
definition of `TLS init function for v';
C:\Users\User\AppData\Local\Temp\ccjOPJhU.o:c1.cpp:(.text+0x33): first defined
here
```

gcc version:

```bash
Using built-in specs.
COLLECT_GCC=G:\x86_64-w64-mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=G:/x86_64-w64-mingw32/bin/../libexec/gcc/x86_64-w64-mingw32/15.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/cqwrteur/toolchains_build/gcc/configure
--with-gxx-libcxx-include-dir=/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/v1
--prefix=/home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-w64-mingw32
--build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --disable-werror
--enable-languages=c,c++ --enable-multilib --disable-bootstrap
--disable-libstdcxx-verbose --enable-libstdcxx-static-eh-pool
--with-libstdcxx-eh-pool-obj-count=0 --disable-sjlj-exceptions
--enable-libstdcxx-threads --enable-libstdcxx-backtrace
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240622 (experimental) (GCC)
```

[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align

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

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

--- Comment #27 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Wilco Dijkstra
:

https://gcc.gnu.org/g:5aa9ed0f353f835005c3df8932c7bc6e26f53904

commit r13-8874-g5aa9ed0f353f835005c3df8932c7bc6e26f53904
Author: Wilco Dijkstra 
Date:   Wed Oct 25 16:28:04 2023 +0100

AArch64: Fix strict-align cpymem/setmem [PR103100]

The cpymemdi/setmemdi implementation doesn't fully support strict
alignment.
Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT.
Clean up the condition when to use MOPS.

gcc/ChangeLog/
PR target/103100
* config/aarch64/aarch64.md (cpymemdi): Remove pattern condition.
(setmemdi): Likewise.
* config/aarch64/aarch64.cc (aarch64_expand_cpymem): Support
strict-align.  Cleanup condition for using MOPS.
(aarch64_expand_setmem): Likewise.

(cherry picked from commit 318f5232cfb3e0c9694889565e1f5424d0354463)

[Bug c++/115670] auto placeholder for return type should change the linkage of the function if the type becomes local linkage too

[federico at kircheis dot it via Gcc-bugs]

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

--- Comment #3 from Federico Kircheis  ---
I've collected the example mentioned here and in my original report

https://godbolt.org/z/o4893zhPs



struct {
int i = 42;
} const a;


auto foo0(){
return a;
}

int foo1(decltype(a)&){
return 1;
}


decltype(a) foo2(){
return a;
}

namespace {
struct s{};
s foo3(){
return {};
}
}

s foo4(){
return {};
}

auto foo5(){
struct {} t;
return t;
}


Except for foo0 and foo5, `-Wunused-function` emits a diagnostic (should I make
a separate issue for the warning?)


> GCC is able to change the linkage of bar. it is just auto which is not 
> handled.

As you can se in the emitted code, even if GCC changes the linkage (I'm sorry,
I did not verify that), it still generates the corresponding code.
I suppose that that code can be discarded later by the linker.

In the case of MSVC, as far as I've understood, as the function is never used,
no code is emitted (less work for the linker).

I guess that a more generic approach would be that all unused code (all code
that triggers a diagnostic with -Wunused-function could be avoided...

[Bug c++/115670] auto placeholder for return type should change the linkage of the function if the type becomes local linkage too

[federico at kircheis dot it via Gcc-bugs]

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

--- Comment #4 from Federico Kircheis  ---
Sorry, I've posted the wrong link in the previous reply, this is the correct
one

https://godbolt.org/z/nhrM46ajs

Also 



struct s2{
s i; //s is in anonymous namespace
};

s2 foo6(){
return {};
}


does not warn with `-Wunused-function`