[Bug target/115058] on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

[yanxiaoyong5 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from xiaoyong yan  ---
(In reply to Andrew Pinski from comment #3)
> This looks like a binutils issue rather a gcc one. It might be already fixed
> in binutils too.

I am using binutils 2.39.0, GNU assembler version 2.39.0

arm-none-eabi-as -v
GNU assembler version 2.39.0 (arm-none-eabi) using BFD version (Arm GNU
Toolchain 12.2.Rel1 (Build arm-12.24)) 2.39.0.20221210

Could you tell which version fixed it?

[Bug rtl-optimization/115081] find thie PR will cause ICE: Modify cost calculation for dealingf with equivalaennces

[andyzhenyu.zhao at mail dot utoronto.ca via Gcc-bugs]

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

--- Comment #2 from Zhenyu Zhao  ---
Created attachment 58198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58198=edit
Detail info about ICE

Sorry for that, I reattach the image.

[Bug rtl-optimization/115081] find thie PR will cause ICE: Modify cost calculation for dealingf with equivalaennces

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-14
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug rtl-optimization/115081] find thie PR will cause ICE: Modify cost calculation for dealingf with equivalaennces

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
Lthe attachment was most likely too big so it didn't attach. Can you attach it
again maybe compress?

[Bug c/115081] New: find thie PR will cause ICE: Modify cost calculation for dealingf with equivalaennces

[andyzhenyu.zhao at mail dot utoronto.ca via Gcc-bugs]

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

Bug ID: 115081
   Summary: find thie PR will cause ICE: Modify cost calculation
for dealingf with equivalaennces
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andyzhenyu.zhao at mail dot utoronto.ca
  Target Milestone: ---

Here is the website for this patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f55cdce3f8dd8503e080e35be59c5f5390f6d95e

And I also find a patch to sovled some problems caused by this patch.
Here is the website:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4d3d2cdb574488223d023b590c3a34ddd93f4dae.

detail info in the attachment.

[Bug c++/114303] [11/12/13 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:47cac09307874ff1d640392e3d986453f34f7bcb

commit r13-8767-g47cac09307874ff1d640392e3d986453f34f7bcb
Author: Patrick Palka 
Date:   Thu Apr 11 10:16:41 2024 -0400

c++: build_extra_args recapturing local specs [PR114303]

r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization in an evaluated
context even if its first use is in an unevaluated context.  But this
means we need to avoid walking a tree that already has extra args/specs
saved because the list of saved specs appears to be an evaluated
context which we'll now walk first.  It seems then that we should be
calculating the saved specs from scratch each time, rather than
potentially walking the saved specs list from an earlier partial
instantiation when calling build_extra_args a second time around.

PR c++/114303

gcc/cp/ChangeLog:

* constraint.cc (tsubst_requires_expr): Clear
REQUIRES_EXPR_EXTRA_ARGS before calling build_extra_args.
* pt.cc (tree_extra_args): Define.
(extract_locals_r): Assert *_EXTRA_ARGS is empty.
(tsubst_stmt) : Clear IF_SCOPE on the new
IF_STMT.  Call build_extra_args on the new IF_STMT instead
of t which might already have IF_STMT_EXTRA_ARGS.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if-lambda6.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit b262b17636e47ae969a74f16e86ccb00678d5e88)

[Bug debug/115080] New: ICE when generating debug information for lambda in requires expression

[cmingyi01 at gmail dot com via Gcc-bugs]

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

Bug ID: 115080
   Summary: ICE when generating debug information for lambda in
requires expression
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cmingyi01 at gmail dot com
  Target Milestone: ---

The following C++20 code triggers an ICE on gcc-12 onwards, including trunk.

struct Foo {
template 
requires requires { [] {}; }
struct Bar {
T data;
};
Bar b;
};
int main() {}


(See Compiler Explorer: https://godbolt.org/z/E911brobo)

Required command line flags: -std=c++20 -g

Compiler output:
: In substitution of 'template  requires requires{;}
struct Foo::Bar [with T = int]':
:7:12:   required from here
7 | Bar b;
  |^
:3:25: internal compiler error: in gen_type_die_with_usage, at
dwarf2out.cc:26507
3 | requires requires { [] {}; }
  | ^
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0xe3581e rest_of_type_compilation(tree_node*, int)
???:0
0x7b9d56 finish_struct_1(tree_node*)
???:0
0x7bb0b4 finish_struct(tree_node*, tree_node*)
???:0
0x943ec2 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dc716 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dde08 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x937c61 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x95f671 finish_template_type(tree_node*, tree_node*, int)
???:0
0x90e414 c_parse_file()
???:0
0xa0c4d9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

[Bug target/115058] on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

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

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

--- Comment #3 from Andrew Pinski  ---
This looks like a binutils issue rather a gcc one. It might be already fixed in
binutils too.

[Bug target/115058] on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

[yanxiaoyong5 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from xiaoyong yan  ---
(In reply to Richard Earnshaw from comment #1)
> It looks like those messages are coming from the assembler, not the
> compiler, but without a testcase it's difficult to be exactly sure what your
> problem is.
> 
> Please attach a small program that demonstrates your problem and state the 
> /exact/ command line you used.

Hi Richard:
   thanks for reply.
   here is the test file for pauth, named as test.S:
   align 8
   .global test
   .type test,%function
   test:
mrs x9, apiakeyhi_el1  
mrs x10, apiakeylo_el1
mov x11, lr
mov x12, sp

   when I use "aarch64-none-linux-gnu-gcc -mcpu=cortex-a78ae test.S -o test.o",
gcc generates errors as follows:
   test.S: Assembler messages:
test.S:5: Error: selected processor does not support system register name
'apiakeyhi_el1'
test.S:6: Error: selected processor does not support system register name
'apiakeylo_el1'

   when I use "aarch64-none-linux-gnu-gcc -march=armv8.2-a+pauth -c test.S -o
test.o", gcc generates errors as follows:
   test.S: Assembler messages:
test.S:5: Error: selected processor does not support system register name
'apiakeyhi_el1'
test.S:6: Error: selected processor does not support system register name
'apiakeylo_el1'

   when I use "aarch64-none-linux-gnu-gcc -march=armv8.3-a -c test.S -o
test.o", there is no error generated.

[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled

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

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

--- Comment #7 from sandra at gcc dot gnu.org ---
My most recent metadirectives/dynamic selector patch set does include partial
support for dynamic selectors.  For C/C++ it handles expressions that reference
variables/functions that are globally visible, and for C++ also class
fields/methods, references to the "this" pointer, etc, but it gives a "sorry"
for references to parameters on the base function declaration.  For Fortran it
still permits only constant expressions in selectors.

https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html

I agree with Tobias's comment 3 that the right solution is to wrap these
expressions in a function that has the same parameters as the associated base
decl, and that these generated functions can be internal and inline.  But, it
might be more efficient to bypass actually creating functions and instead just
stash a parameter map (e.g. to match parameter positions to decls) along with
the expression so that the gimplifier can effectively do the inlining at the
point where it synthesizes both the replacement call and the code to match
dynamic selectors (in posted patch set above).

[Bug target/112109] Missing riscv vectorized strcmp (and other) expanders

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-439-gdf15eb15b5f820321c81efc75f0af13ff8c0dd5b
Author: Sergei Lewis 
Date:   Mon May 13 17:32:24 2024 -0600

[PATCH v2 1/3] RISC-V: movmem for RISCV with V extension

This patchset permits generation of inlined vectorised code for movmem,
setmem and cmpmem, if and only if the operation size is
at least one and at most eight vector registers' worth of data.

Further vectorisation rapidly becomes debatable due to code size concerns;
however, for these simple cases we do have an unambiguous performance win
without sacrificing too much code size compared to a libc call.

Changes in v2:

* run clang-format over the code in addition to the
  contrib/check_GNU_style.sh that was used for v1

* remove string.h include and refer to __builtin_* memory functions
  in multilib tests

* respect stringop_strategy (don't vectorise if it doesn't include VECTOR)

* use an integer constraint for movmem length parameter

* use TARGET_MAX_LMUL unless riscv-autovec-lmul=dynamic
  to ensure we respect the user's wishes if they request specific lmul

* add new unit tests to check that riscv-autovec-lmul is respected

* PR target/112109 added to changelog for patch 1/3 as requested

Sergei Lewis (3):
  RISC-V: movmem for RISCV with V extension
  RISC-V: setmem for RISCV with V extension
  RISC-V: cmpmem for RISCV with V extension

gcc/ChangeLog

* config/riscv/riscv.md (movmem): Use
riscv_vector::expand_block_move,
if and only if we know the entire operation can be performed using
one vector
load followed by one vector store

gcc/testsuite/ChangeLog

PR target/112109
* gcc.target/riscv/rvv/base/movmem-1.c: New test

[Bug target/113578] Incorrect sign printed for -nan on RISC-V

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Waterman  ---
For my M1 running Ventura 13.6, NaN payloads _are_ propagated, sign bit
included. This test prints fffc0080:

int main()
{
  volatile long long ll = 0x8010;
  volatile double d;
  memcpy((char*), (char*), sizeof(ll));

  volatile float f = d;
  volatile int i;
  memcpy((char*), (char*), sizeof(i));

  printf("%x\n", i);

  return 0;
}

So perhaps Apple has switched from default-NaN mode to NaN-propagating mode in
the time since that R blog post was written.

[Bug c++/115079] New: unexpected error with partial specialization of template

[420 at zerberste dot es via Gcc-bugs]

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

Bug ID: 115079
   Summary: unexpected error with partial specialization of
template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 420 at zerberste dot es
  Target Milestone: ---

Consider the following code snippet
```cpp
template 
struct TypeList {};

template 
struct Proxy;

template 
struct Proxy {
using alternatives = TypeList;
};

struct Bare {
int alt_0;
};
template struct Proxy<::alt_0>;
```
https://gcc.godbolt.org/z/41T89b64a

Clang accepts this, GCC does not. Up until GCC 8 it did provide a slightly more
helpful error message, but I do not think it should error to begin with.

[Bug c++/115078] New: ICE with invalid partial specialization of template

[420 at zerberste dot es via Gcc-bugs]

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

Bug ID: 115078
   Summary: ICE with invalid partial specialization of
template
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 420 at zerberste dot es
  Target Milestone: ---

Consider the following code snippet:
```cpp
template 
struct Proxy;// 1

template 
struct Proxy {}; // 2

struct Bare {
int alt_0;
};
template struct Proxy<::alt_0>;
```
https://gcc.godbolt.org/z/46GEhfYGc

The partial specialization 2) is not more specialized than the primary template
1). Instead of emitting a helpful error, current versions of GCC crash with
>:5:8: internal compiler error: in unify, at cp/pt.cc:24728
>5 | struct Proxy {};
>  |^
>0x26861cc internal_error(char const*, ...)
>   ???:0
>0xa5aaaf fancy_abort(char const*, int, char const*)
>   ???:0
>0xcbc865 maybe_process_partial_specialization(tree_node*)
>   ???:0
>0xc634da c_parse_file()
>   ???:0
>0xdb8d09 c_common_parse_file()
>   ???:0
>Please submit a full bug report, with preprocessed source (by using 
>-freport-bug).
>Please include the complete backtrace with any bug report.
>See  for instructions.
>Compiler returned: 1


The earliest version of GCC I was able to get to crash with this is GCC 7.2 in
C++17 mode.


This might be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84822

[Bug bootstrap/115077] bootstrap fails with in-tree isl-0.25/6

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #0)
> The isl configure checks for this support using AX_CXX_COMPILE_STDCXX_17
> which updates CXX to include the addition of -std=c++17, if that is required
> to enable it.

LMK if you open a bug with the autoconf-archive about that macro

[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Keywords||wrong-code

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060512.html

[Bug bootstrap/115077] New: bootstrap fails with in-tree isl-0.25/6

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

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

Bug ID: 115077
   Summary: bootstrap fails with in-tree isl-0.25/6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

see also this thread: https://gcc.gnu.org/pipermail/gcc/2024-May/243949.htm
version 0.25 and 0.26 have test cases that require c++17 support.

Essentially we have a stage1 bootstrap fail with errors of the form
"
/src-local/gcc-master/isl/isl_test_cpp17-generic.cc: In function ‘isl::id
construct_id(isl::ctx, bool*)’:
/src-local/gcc-master/isl/isl_test_cpp17-generic.cc:25:24: error: no matching
function for call to ‘isl::id::id(isl::ctx&, const char [2],
std::shared_ptr&)’
   25 |  isl::id id(ctx, "S", s);
"

because we are somehow mismatching the build flags and the configure ones.

=

The isl configure checks for this support using AX_CXX_COMPILE_STDCXX_17 which
updates CXX to include the addition of -std=c++17, if that is required to
enable it.

The test cases are then added on HAVE_CXX17

The isl (stage1) Makefile contains (for an example on Darwin)

CXX = x86_64-apple-darwin21-g++ -std=c++11 -std=gnu++17
CXXCPP = x86_64-apple-darwin21-g++ -std=c++11 -std=gnu++17 -E

Which is correct.

However somehow we are overriding this in the actual build:

x86_64-apple-darwin21-g++ -std=c++11 -DHAVE_CONFIG_H   -I.
-I/src-local/gcc-master/isl -I/src-local/gcc-master/isl/include -Iinclude/
-I/src-local/gcc-master/gmp -I/scratch/12-mon-rosetta/gcc-master/./gmp   -O
-pipe -MT isl_test_cpp17.o -MD -MP -MF $depbase.Tpo -c -o isl_test_cpp17.o
/src-local/gcc-master/isl/isl_test_cpp17.cc &&\
mv -f $depbase.Tpo $depbase.Po

[Bug gcov-profile/115047] Inconsistent MC/DC reported by GCC and LLVM

[j at lambda dot is via Gcc-bugs]

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

--- Comment #2 from Jørgen Kvalsvik  ---
> f(1, 0, 0) = false, while f(1, 0, 1) = true

Sorry, I meant:

f(0, 0, 1) = true
f(0, 0, 0) = false
and
f(1, 0, 1) = true
f(1, 0, 0) = false

It does not take away from the conclusion when doing masking MC/DC.

[Bug c++/115061] Compiling gcc failed when using clang 16.0.6

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||ppalka at gcc dot gnu.org

[Bug gcov-profile/115047] Inconsistent MC/DC reported by GCC and LLVM

[j at lambda dot is via Gcc-bugs]

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

--- Comment #1 from Jørgen Kvalsvik  ---
gcc is not wrong here - f(1, 0, 0) = false, while f(1, 0, 1) = true so clearly
c has an independent effect on the outcome here, and both its values has been
observed.

I think clang measures unique-cause and not masking MC/DC which probably
explains the difference (at least clang's documentation [1] does not specify
which form it measures. Since more than one variable change between the two
test vectors I assume that would be it. I don't have clang 19 available right
now, does f(0, 0, 1); f(0, 0, 0); cover c?

[1]
https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#mc-dc-instrumentation

[Bug other/115076] [OpenMP] "declare variant" scoping rules and visibility

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Created attachment 58197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58197=edit
second test case

[Bug other/115076] New: [OpenMP] "declare variant" scoping rules and visibility

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

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

Bug ID: 115076
   Summary: [OpenMP] "declare variant" scoping rules and
visibility
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58196=edit
test case

The OpenMP 5.0 spec says:  "If the context selector that is associated with a
declared function variant is compatible with the OpenMP context of a call to a
base function according to the matching rules defined in Section 2.3.3 then a
call to the variant is a candidate to replace the base function call."

The 5.1 spec (and later versions) add the requirement that the declare variant
be "visible" at the call site (it uses this term generally to refer to visible
according to the scoping rules of the base language):

"If a declare variant directive for the base function is visible at the call
site and the static part of the context selector that is associated with the
declared function variant is compatible with the OpenMP context of the call
according to the matching rules defined in Section 2.3.3 then the variant is a
replacement candidate to be called instead of the base function."

GCC's present implementation of "declare variant" dates back to the initial 5.0
spec for this feature.  The front ends store "declare variant" info on
attributes on the base function, and the list of candidates for each call site
isn't produced until gimplification, based on "declare variant" directives
collected everywhere in the compilation unit and recorded on the associated
decl.  This leads to surprising behavior; in each of the attached test cases,
both calls to foo() are resolved to baz() even though the "declare variant"
directive isn't in scope at the first call.

It seems to me that the list of visible variants needs to be collected by the
front ends at each call site and inserted into the tree structure produced,
instead of relying on global attributes.  Perhaps the existing
OMP_METADIRECTIVE tree node type could be adapted/re-used here, similar to how
the patch set for adding dynamic selector support

https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html

re-uses the gimple metadirective data structures for late resolution of
"declare variant" as well.

[Bug c++/115053] gcc crashed without back trace

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can't reproduce:

$ time ./cc1plus -quiet 115053.C -std=c++20

real0m0.016s
user0m0.010s
sys 0m0.006s

same with gcc 14 and 13.

[Bug c++/115074] incorrect stringop-overflow warning

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101361
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-13
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed, I think.  Doesn't look like a dup of bug 101361.

In file included from 115074.C:2:
In constructor ‘constexpr std::__detail::__variant::_Variant_storage::_Variant_storage(std::in_place_index_t<_Np>, _Args&& ...) [with
long unsigned int _Np = 0; _Args = {}; _Types = {int}]’,
inlined from ‘constexpr std::__detail::__variant::_Copy_ctor_base::_Copy_ctor_base(std::in_place_index_t<_Idx>, _Args&& ...) [with long
unsigned int _Np = 0; _Args = {}][inherited from
std::__detail::__variant::_Variant_storage]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:611:20,
inlined from ‘constexpr std::__detail::__variant::_Move_ctor_base::_Move_ctor_base(std::in_place_index_t<_Idx>, _Args&& ...) [with long
unsigned int _Np = 0; _Args = {}][inherited from
std::__detail::__variant::_Variant_storage]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:649:20,
inlined from ‘constexpr std::__detail::__variant::_Copy_assign_base::_Copy_assign_base(std::in_place_index_t<_Idx>, _Args&& ...) [with long
unsigned int _Np = 0; _Args = {}][inherited from
std::__detail::__variant::_Variant_storage]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:701:20,
inlined from ‘constexpr std::__detail::__variant::_Move_assign_base::_Move_assign_base(std::in_place_index_t<_Idx>, _Args&& ...) [with long
unsigned int _Np = 0; _Args = {}][inherited from
std::__detail::__variant::_Variant_storage]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:755:20,
inlined from ‘constexpr
std::__detail::__variant::_Variant_base<_Types>::_Variant_base(std::in_place_index_t<_Np>,
_Args&& ...) [with long unsigned int _Np = 0; _Args = {}; _Types = {int}]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:774:45,
inlined from ‘constexpr
std::__detail::__variant::_Variant_base<_Types>::_Variant_base() [with _Types =
{int}]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:769:40,
inlined from ‘constexpr std::variant<_Types>::variant() requires 
is_default_constructible_v::type>
[with _Types = {int}]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:1431:7,
inlined from ‘constexpr decltype (::new(void*(0)) _Tp)
std::construct_at(_Tp*, _Args&& ...) [with _Tp = variant; _Args = {}]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_construct.h:97:14,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = std::variant; _Args = {}; _Tp =
std::variant]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:536:21,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::reference
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {}; _Tp =
std::variant; _Alloc = std::allocator >]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:117:30,
inlined from ‘VariantVector::VariantVector()’ at 115074.C:14:26:
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/variant:534:9:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  534 | _M_index{_Np}
  | ^
In file included from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:46,
 from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:63,
 from 115074.C:1:
In member function ‘_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = std::variant]’,
inlined from ‘constexpr _Tp* std::allocator< 
>::allocate(std::size_t) [with _Tp = std::variant]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocator.h:196:40,
inlined from ‘static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = std::variant]’ at
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:478:28,
inlined from ‘constexpr std::_Vector_base<_Tp, _Alloc>::pointer
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp =
std::variant; _Alloc = 

[Bug c++/105644] ICE in a fold expression with a requires expression: in iterative_hash_template_arg, at cp/pt.cc:1805

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hlewin at gmx dot de

--- Comment #4 from Marek Polacek  ---
*** Bug 115075 has been marked as a duplicate of this bug. ***

[Bug c++/115075] internal_compiler_error during compilation

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Marek Polacek  ---
Reproduced with latest trunk, but I think it's a dup.

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

[Bug c++/115075] internal_compiler_error during compilation

[hlewin at gmx dot de via Gcc-bugs]

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

--- Comment #1 from Heiko Lewin  ---
Created attachment 58195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58195=edit
gzipped output file of -freport-bug

[Bug c++/115075] New: internal_compiler_error during compilation

[hlewin at gmx dot de via Gcc-bugs]

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

Bug ID: 115075
   Summary: internal_compiler_error during compilation
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hlewin at gmx dot de
  Target Milestone: ---

Hello!

I ran across a crash due to an internal compiler error. This happened while
working on  some source - the program likely is not correct: clang 17.0.6 also
crashes during compilation seemingly while printing error messages.

I have attached the gzipped output of `-freport-bug`. Let me know if you need
further information.

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

--- Comment #6 from Dimitar Dimitrov  ---
Created attachment 58194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58194=edit
tentative fix for PRU

The PRU requires a further target adjustment to fix SMALL_REGISTER_CLASS_P. The
attached patch fixes the dg.exp=pr71478.c regression.

I'm doing full regression tests now, and will commit if there are no
objections.

[Bug c++/115074] New: incorrect stringop-overflow warning

[ryanpiwowarski at gmail dot com via Gcc-bugs]

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

Bug ID: 115074
   Summary: incorrect stringop-overflow warning
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryanpiwowarski at gmail dot com
  Target Milestone: ---

#include 
#include 

class VariantVector
{
std::vector> vars;

public:
VariantVector()
{
// need at least three
vars.emplace_back();
vars.emplace_back();
vars.emplace_back();
}
};

int main()
{
// need at least two
VariantVector c0;
VariantVector c1;
return 0;
}

//--

above compiled with -std=c++20 -O2 -Wall -Wextra -Werror -Wfatal-errors
will generate a stringop-overflow warning, presumably incorrectly.
Present at least on gcc 13.1 and 13.2
You can see code and error output on godbolt: https://godbolt.org/z/h9M9cKzTs

[Bug middle-end/111009] [12 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andrew Macleod
:

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

commit r12-10439-gc5c3a4a265256535a66f1656d44e143f05d77f66
Author: Andrew MacLeod 
Date:   Fri May 10 13:56:01 2024 -0400

Fix range-ops operator_addr.

Lack of symbolic information prevents op1_range from being able to draw
the same conclusions as fold_range can.

PR tree-optimization/111009
gcc/
* range-op.cc (operator_addr_expr::op1_range): Be more restrictive.
* value-range.h (contains_zero_p): New.

gcc/testsuite/
* gcc.dg/pr111009.c: New.

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #8 from sandra at gcc dot gnu.org ---
This bug is addressed in the metadirective/dynamic selector patch set I posted
here:

https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650725.html

[Bug c++/115061] Compiling gcc failed when using clang 16.0.6

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

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

Ken Matsui  changed:

   What|Removed |Added

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

--- Comment #2 from Ken Matsui  ---
Thank you for reporting this, Demin.  I fixed this problem in
https://gcc.gnu.org/g:30ff6c55ba0f2262cf292c90d7b9d771005305f0.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing the scalar argument 'obs' by something with rank > 0 avoids the ICE,
but then assumed-rank is not accepted with intent(out).  Another bug...

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

--- Comment #5 from Jeffrey A. Law  ---
So this seems to have fixed the RISC-V port.  Thanks!

I'm still seeing some problems on the PRU port though:

Tests that now fail, but worked before (1 tests):

pru-sim: gcc: gcc.dg/pr71478.c (test for excess errors)

New tests that FAIL (1 tests):

pru-sim: gcc: gcc.dg/pr71478.c (internal compiler error: in
lra_split_hard_reg_for, at lra-assigns.cc:1868)

New tests that PASS (1 tests):

pru-sim: gcc: gcc.dg/pr113982.c (test for excess errors)

[Bug c++/115061] Compiling gcc failed when using clang 16.0.6

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Ken Matsui :

https://gcc.gnu.org/g:30ff6c55ba0f2262cf292c90d7b9d771005305f0

commit r15-437-g30ff6c55ba0f2262cf292c90d7b9d771005305f0
Author: Ken Matsui 
Date:   Sun May 12 23:43:55 2024 -0700

c++: Avoid using __array_rank as a variable name [PR115061]

This patch fixes a compilation error when building GCC using Clang.
Since __array_rank is used as a built-in trait name, use rank instead.

PR c++/115061

gcc/cp/ChangeLog:

* semantics.cc (finish_trait_expr): Use rank instead of
__array_rank.

Signed-off-by: Ken Matsui 

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||12.3.1
 Ever confirmed|0   |1
   Target Milestone|--- |13.3
   Priority|P3  |P4
   Last reconfirmed||2024-05-13
  Known to fail||13.2.1, 14.1.0, 15.0
Summary|ICE using IEEE_ARITHMETIC   |[13/14/15 Regression] ICE
   |in a derived type method|using IEEE_ARITHMETIC in a
   |with intent(out) statement  |derived type method with
   ||class, intent(out)
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed as a regression.  12-branch works here, current 13-branch fails.

Replacing class by type also avoids the ICE.

[Bug fortran/115072] Memory leak with unlimited polymorphic function result

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Memory link with unlimited  |Memory leak with unlimited
   |polymorphic function result |polymorphic function result
   Priority|P3  |P4
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2024-05-13

--- Comment #1 from anlauf at gcc dot gnu.org ---
Runtime memleak confirmed, also seen with -fsanitize=address .

Affects all versions up to 15-mainline.

[Bug c++/114709] [12/13 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

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

commit r13-8765-gd3659e2dfcc6db83391cd2c6d70097cba35eb4b9
Author: Patrick Palka 
Date:   Wed Apr 24 17:49:56 2024 -0400

c++: constexpr union member access folding [PR114709]

The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses information
about the member being accessed which we may later need to diagnose an
inactive-member access.  So this patch restricts the canonicalization
accordingly.

PR c++/114709

gcc/cp/ChangeLog:

* constexpr.cc (cxx_fold_indirect_ref): Restrict object/offset
canonicalization to RECORD_TYPE member accesses.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-union8.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 0844170e9ef60a8b2f6fba6786672f30ce1c2749)

[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
It doesn't seem worth backporitng this relatively risky patch just to fix a
checking-only assertion failure that we otherwise gracefully handle.

[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Not backporting any of these fixes since this never properly worked -- it was
either wrong-code, rejects-valid or (most recently) ice-on-valid -- and so not
really a regression.

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.2
 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 14.2

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 14.2

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.2, thanks for the reports.

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

--- Comment #4 from Andrew Pinski  ---
Note -fsanitize=undefined does detect this undefinedness at runtime already
too.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

--- Comment #3 from Jakub Jelinek  ---
Or another option is to use C23 , that is well defined for all
values.
But you need recent glibc (2.39 snapshots or 2.40) & gcc (14) for that.

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:44e7855e4e817a7f5a1e332cd95e780e57052dba

commit r15-436-g44e7855e4e817a7f5a1e332cd95e780e57052dba
Author: Vladimir N. Makarov 
Date:   Mon May 13 10:12:11 2024 -0400

[PR115013][LRA]: Modify register starvation recognition

  My recent patch to recognize reg starvation resulted in few GCC test
failures.  The following patch fixes this by using more accurate
starvation calculation and ignoring small reg classes.

gcc/ChangeLog:

PR rtl-optimization/115013
* lra-constraints.cc (process_alt_operands): Update all_used_nregs
only for winreg.  Ignore reg starvation for small reg classes.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Invalid as explained.  The builtin has undefined behavior no matter what the
backend says is the value at 0.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is misunderstanding of what C[LT]Z_DEFINED_VALUE_AT_ZERO is.
The builtin has always UB on zero.
If you want to define it for zero, use x ? __builtin_clz (x) : 32 (and the
like) or
__builtin_clzg (x, 32) in the source.
C[LT]Z_DEFINED_VALUE_AT_ZERO returning 2 then makes sure the compiler can fold
those conditionals or builtins into .CLZ internal calls with 2 arguments which
makes it well defined for all inputs.

[Bug tree-optimization/115073] New: RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Bug ID: 115073
   Summary: RISC-V: Gimple fold not honor
C[LT]Z_DEFINED_VALUE_AT_ZERO
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kito at gcc dot gnu.org
  Target Milestone: ---
Target: riscv64-unknown-linux-gnu

# What's up?

A loop induction variable initialized from __builtin_ctz (x), and the loop
bound is 32, and increment is one, and GCC turn it into infinite loops when x
is 0.

However RISC-V has defined CTZ_DEFINED_VALUE_AT_ZERO as 32 for SImode, so it's
not UB IMO, but seems like gimple-range-op.cc and match.pd are not handle that.

# Command to reproduce
```
$ riscv64-unknown-elf-gcc -O3 -march=rv64gc_zba_zbb_zbc
```

# Testcase
```c
void f();
void foo(unsigned int id, unsigned int x)
{
for (unsigned int idx = __builtin_ctz(x); idx < 32; idx++) {
f();
}
}
```

# Asm output with comment:

```
foo:
addisp,sp,-32
sd  s0,16(sp)
sd  s1,8(sp)
sd  ra,24(sp)
ctzws0,a1 # s0 is 32 if a1 is 0
li  s1,32
.L2:
addiw   s0,s0,1   # thne s0 become 33 here
callf
bne s0,s1,.L2 # compare with 32, which never terminate
ld  ra,24(sp)
ld  s0,16(sp)
ld  s1,8(sp)
addisp,sp,32
jr  ra
```


# What I tried?

I try to call CTZ_DEFINED_VALUE_AT_ZERO gimple-range-op.cc but it seems not
help for this test case, and then I found it was screw up at match.pd when ccp
pass.

It applied a CTZ simplifications at match.pd:

```
 (for op (eq ne)
  (simplify
   /* __builtin_ctz (x) == C -> (x & ((1 << (C + 1)) - 1)) == (1 << C).  */
   (op (ctz:s @0) INTEGER_CST@1)
(with { tree type0 = TREE_TYPE (@0); 
int prec = TYPE_PRECISION (type0);
  } 
 (if (prec <= MAX_FIXED_MODE_SIZE)
  (if (tree_int_cst_sgn (@1) < 0 || wi::to_widest (@1) >= prec) 
   { constant_boolean_node (op == EQ_EXPR ? false : true, type); }
   (op (bit_and @0 { wide_int_to_tree (type0,
   wi::mask (tree_to_uhwi (@1) + 1,
 false, prec)); })
   { wide_int_to_tree (type0,
   wi::shifted_mask (tree_to_uhwi (@1), 1,
 false, prec)); })))
```

Then I found it has checked with CTZ_DEFINED_VALUE_AT_ZERO
(g:75f8900159133ce069ef1d2edf3b67c7bc82e305) untill
g:7383cb56e1170789929201b0dadc156888928fdd, but I realized it because is not
really work well here CLZ_DEFINED_VALUE_AT_ZERO.

So I did some aggressive experiment here: convert __builtin_ctz to IFN_CTZ with
second operand (from C[LT]Z_DEFINED_VALUE_AT_ZERO, ideally), it can work *IF*
backend provide patterns for ctz, but NOT work when backend is not provided, it
could be a problem to RISC-V since ctz is not included in baseline ISA for
RISC-V.

It might be arguable if target didn't have ctz/clz pattern but
C[LT]Z_DEFINED_VALUE_AT_ZERO is provided to backend, so I think middle-end
optimization should still honor with that?

Or another thought is convert that into target macro to resolve the issue
describe in g:75f8900159133ce069ef1d2edf3b67c7bc82e305?


# Aggressive experiment:
```
diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index 494da49791d..d84469a6dca 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -858,7 +858,16 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p
ATTRIBUTE_UNUSED,
  c, CALL_EXPR_ARG (*expr_p, 1));
return GS_OK;
  }
-   break;
+  if (fndecl && fndecl_built_in_p(fndecl, BUILT_IN_CTZ) &&
+  call_expr_nargs(*expr_p) == 1) {
+tree a = save_expr(CALL_EXPR_ARG(*expr_p, 0));
+*expr_p = build_call_expr_internal_loc(
+EXPR_LOCATION(*expr_p), IFN_CTZ, TREE_TYPE(a), 2, a,
+build_int_cst(TREE_TYPE(a), 32));
+return GS_OK;
+  }
+
+break;
   }

 default:;
```

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:41b3cf262e61aee9d26380f1c820e0eaae740f50

commit r15-435-g41b3cf262e61aee9d26380f1c820e0eaae740f50
Author: Pan Li 
Date:   Sat May 11 15:25:28 2024 +0800

RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16 scalar

For the vfw vx format RVV intrinsic, the scalar type _Float16 also
requires the zvfh extension.  Unfortunately,  we only check the
vector tree type and miss the scalar _Float16 type checking.  For
example:

vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1, size_t
vl)
{
  return __riscv_vfwsub_wf_f32mf2(vs2, rs1, vl);
}

It should report some error message like zvfh extension is required
instead of ICE for unreg insn.

This patch would like to make up such kind of validation for _Float16
in the RVV intrinsic API.  It will report some error like below when
there is no zvfh enabled.

error: built-in function '__riscv_vfwsub_wf_f32mf2(vs2,  rs1,  vl)'
  requires the zvfhmin or zvfh ISA extension

Passed the rv64gcv fully regression tests, included c/c++/fortran.

PR target/114988

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.cc
(validate_instance_type_required_extensions): New func impl to
validate the intrinisc func type ops.
(expand_builtin): Validate instance type before expand.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr114988-1.c: New test.
* gcc.target/riscv/rvv/base/pr114988-2.c: New test.

Signed-off-by: Pan Li 

[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I think I've found what's going on:  really has

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#ifndef NC_TPI_CLTS
#define NC_TPI_CLTS 1   /* must agree with netconfig.h */
#define NC_TPI_COTS 2   /* must agree with netconfig.h */
[...]
#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#define SOCK_STREAM NC_TPI_COTS /* stream socket */
#define SOCK_DGRAM  NC_TPI_CLTS /* datagram socket */
[...]
#else
#define SOCK_STREAM 2   /* stream socket */
#define SOCK_DGRAM  1   /* datagram socket */

The problem seems to be the indirection: when SOCK_DGRAM etc. are
defined as numeric constants, things work, while the indirection via
NC_TPI_* does not.

[Bug fortran/115072] New: Memory link with unlimited polymorphic function result

[rnhmjoj at eurofusion dot eu via Gcc-bugs]

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

Bug ID: 115072
   Summary: Memory link with unlimited polymorphic function result
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rnhmjoj at eurofusion dot eu
  Target Milestone: ---

The following program works as expected, but the result of the id(x) function
does not appear to be ever deallocated creating a memory leak:

program test

  print *, transfer(id(7), 1)

contains

  pure function id(x) result(y)
class(*), intent(in)  :: x
class(*), allocatable :: y
y = x
  end function

end program test

Specifically, running the program in valgrind memcheck with --leak-check=full
reveals this:

4 bytes in 1 blocks are definitely lost in loss record 1 of 1
   at 0x484276B: malloc (in vgpreload_memcheck-amd64-linux.so)
   by 0x401338: id.1 (test.f90:10)
   by 0x401243: MAIN__ (test.f90:3)
   by 0x401432: main (test.f90:3)

Replacing the `class(*)` with some other type does not produce a leak.

[Bug target/115071] performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #2 from Colin Ian King  ---
Created attachment 58193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58193=edit
gcc-14 disassembly

[Bug target/115071] performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #1 from Colin Ian King  ---
Created attachment 58192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58192=edit
gcc-13 disassembly

[Bug target/115071] New: performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

Bug ID: 115071
   Summary: performance regression, x86, between gcc-14 and gcc-13
using -O3 and _Pragma("GCC unroll 4") on skylake
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colin.king at intel dot com
  Target Milestone: ---

Created attachment 58191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58191=edit
reproducer source code

I'm seeing a ~15% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

cking@skylake:~$ gcc-13 reproducer-bitonicsort.c -O2
cking@skylake:~$ ./a.out 
duration: 5.71 seconds, count = 1119566602

cking@skylake:~$ gcc-14 reproducer-bitonicsort.c -O2
cking@skylake:~$ ./a.out 
duration: 6.56 seconds, count = 1119566602

The original issue appeared when regression testing stress-ng bitonic sorting
stressor [1]. I've managed to extract the attached reproducer from the original
code (see attached).

Salient point to focus on:

1. The issue is also dependant on the use of _Pragma("GCC unroll 4")
2. The issue is also dependant on the use of __attribute__((optimize("-O3")))
by use of the OPTIMIZE3 macro in the example.

Attached are the reproducer C source and disassembled object code. 

References:
[1] https://github.com/ColinIanKing/stress-ng/blob/master/stress-bitonicsort.c

[Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement

[bardeau at iram dot fr via Gcc-bugs]

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

Bug ID: 115070
   Summary: ICE using IEEE_ARITHMETIC in a derived type method
with intent(out) statement
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bardeau at iram dot fr
  Target Milestone: ---

Hi,

gfortran 14.0.1 raises an ICE in the following context:

~> uname -a
Linux bardeau-lap 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27
17:53:31 UTC 2024 x86_64 GNU/Linux

~> cat /etc/redhat-release 
Fedora release 40 (Forty)

~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240411/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240411 (Red Hat 14.0.1-0) (GCC)

~> cat bug-gfortran.f90
module my_mod
  type my_type
integer :: a
  end type my_type
contains
  subroutine my_sub(obs)
use ieee_arithmetic
class(my_type), intent(out) :: obs
  end subroutine my_sub
end module my_mod

~> gfortran -c bug-gfortran.f90 
bug-gfortran.f90:10:17:

   10 | end module my_mod
  | ^
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3307
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

It seems that the combination of "use ieee_arithmetic" and the "intent(out)"
statement is important (for example using intent(inout) fixes the ICE). I let
you rephrase the summary to a better description.

[Bug tree-optimization/109071] -Warray-bounds false positive warnings due to code duplication from jump threading

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

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
with the following added heuristic in array-bound checker:

+  /* If the stmt is duplicated and splitted, the warning level is not 2,
+ and the current block is not dominating the exit block, not report
+ the warning.  */
+  if (is_splitted && warn_array_bounds < 2
+  && !is_dominate_exit)
+return false;
+

such false positive warnings are moved from -Warray-bound=1 to -Warray-bound=2.
[opc@qinzhao-ol8u3-x86 109071]$ /home/opc/Install/latest-d/bin/gcc -O2
-Warray-bounds=2 -c -o t.o t.c
t.c: In function ‘sparx5_set’:
t.c:12:29: warning: array subscript 4 is above array bounds of ‘int[4]’
[-Warray-bounds=]
   12 | int *val = >vals[index];
  | ^~~
t.c:8:18: note: while referencing ‘vals’
8 | struct nums {int vals[4];};
  |  ^~~~
[opc@qinzhao-ol8u3-x86 109071]$ /home/opc/Install/latest-d/bin/gcc -O2
-Warray-bounds=1 -c -o t.o t.c
[opc@qinzhao-ol8u3-x86 109071]$

[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> +  using _ValT = typename iterator_traits<_InputIterator>::value_type;
> +  if constexpr (is_same_v<_ValT, _Tp>)
> +   if constexpr (__is_byte<_ValT>::__value)

We can do better than this.

We can use memchr to find a char in a range of signed char, or even to find an
int in a range of signed char, as long as we're careful about values.

For example, given s = "abc"sv, std::find(s.begin(). s.end(), 'a'+0) should
find a match, but std::find(s.begin(), s.end(), 'a'+256) should not (even
though memchr would match in that case, because it does (unsigned
char)('a'+256)).

We should also ensure that std::ranges::find gets the same optimizations.

[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.

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

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

--- Comment #18 from Robin Dapp  ---
A bit of a follow-up:  I'm working on a patch for reassociation that can handle
the mentioned cases and some more but it will still require a bit of time to
get everything regression free and correct.  What it does is allow reassoc to
look through constant multiplications and negates to provide more freedom in
the optimization process.

Regarding the mentioned element-wise costing how should we proceed here?  I'm
going to remove the hunk in question, run SPEC2017 on x86 and post a patch in
order to get some data and basis for discussion.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

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

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

--- Comment #19 from Martin Jambor  ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:


void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT };
enum c_omp_region_type { C_ORT_OMP };
void c_finish_omp_clauses(int *, c_omp_region_type);
int *c_parser_omp_all_clauses_prev;
int *c_parser_omp_all_clauses(bool finish_p) {
  if (finish_p)
c_finish_omp_clauses(c_parser_omp_all_clauses_prev, C_ORT_OMP);
  return c_parser_omp_all_clauses_prev;
}
int c_parser_omp_teams___trans_tmp_104;
static void c_parser_omp_teams(int **cclauses) {
  c_parser_omp_all_clauses(cclauses);
  omp_clause_elt_check(_parser_omp_teams___trans_tmp_104, "", __FUNCTION__);
}
void c_parser_omp_target() {
  int *cclauses[C_OMP_CLAUSE_SPLIT_COUNT];
  c_parser_omp_teams(cclauses);
}

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #4)
> Then this is partly a dup of bug 88545

Yes, that would manually transform the find_epi8 case into a memchr call, but
Clang doesn't need a manual transform in the library, it does it in the
compiler.

Tamar's plan to remove the manual loop unrolling in our std::find_if might help
here, but I'm not sure.

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #2 from Colin Ian King  ---
Created attachment 58190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58190=edit
gcc-14 disassembly

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #1 from Colin Ian King  ---
Created attachment 58189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58189=edit
gcc-13 disassembly

[Bug target/115069] New: 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

Bug ID: 115069
   Summary: 8 bit integer vector performance regression, x86,
between gcc-14 and gcc-13 using avx2 target clones on
skylake platform
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colin.king at intel dot com
  Target Milestone: ---

Created attachment 58188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58188=edit
reproducer source code

I'm seeing a ~12-14% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

cking@skylake:~$ gcc-13 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
13540.16 vec8 ops per sec, duration = 14.77 secs

cking@skylake:~$ gcc-14 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
11720.25 vec8 ops per sec, duration = 17.06 secs

The original issue appeared when regression testing stress-ng vecmath stressor
[1]. I've managed to extract the attached reproducer from the original code
(see attached).

Salient point to focus on:

1. The issue is also dependant on the TARGET_CLONES macro being defined as
__attribute__((target_clones("mmx,avx,avx2,default")))  - the avx2 target
clones seems to be an issue in reproducing this problem, remove it for gcc-14
and the performance regression is reduced.

Attached are the reproducer C source and disassembled object code. 

References: [1]
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vecmath.c

[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Jonathan Wakely  ---
(In reply to Georg Sauthoff from comment #0)
> Created attachment 45259 [details]
> specialize std::find to memchr for character searches in continous memory
> 
> If std::find() is called with continuous random access iterators and a
> trivial char sized value, then calling memchr() is much more efficient than
> calling into the generic __find_if().
> 
> The attached patch implements this optimization.
> 
> That means it specializes a std::find helper on the iterator category and
> the value and calls __builtin_memchr() if possible.

Why specialize on the iterator category, when the __is_simple boolean already
checks if the iterator is a pointer?

The condition of a trivial byte-sized type seem insufficient, because you could
have:

struct B {
  char c;
  bool operator==(const B& b) const { return true; }
};



I would prefer to do simply:

--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -3846,6 +3846,32 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   __glibcxx_function_requires(_EqualOpConcept<
typename iterator_traits<_InputIterator>::value_type, _Tp>)
   __glibcxx_requires_valid_range(__first, __last);
+
+#if __cpp_if_constexpr
+  using _ValT = typename iterator_traits<_InputIterator>::value_type;
+  if constexpr (is_same_v<_ValT, _Tp>)
+   if constexpr (__is_byte<_ValT>::__value)
+#if __cpp_lib_concepts
+ if constexpr (contiguous_iterator<_InputIterator>)
+   {
+ if (const size_t __n = __last - __first)
+   {
+ auto __p0 = std::to_address(__first);
+ if (auto __p1 = __builtin_memchr(__p0, __val, __n))
+   return __first + (__p1 - __p0);
+   }
+ return __last;
+   }
+#else
+ if constexpr (is_pointer_v<_InputIterator>)
+   {
+ if (const size_t __n = __last - __first)
+   if (auto __p = __builtin_memchr(__first, __val, __n))
+ return __p;
+ return __last;
+   }
+#endif
+#endif
   return std::__find_if(__first, __last,
__gnu_cxx::__ops::__iter_equals_val(__val));
 }


I think we're going to remove the manual loop unrolling in __find_if for GCC
15, which should allow the compiler to optimize it better, potentially
auto-vectorizing. That might make memchr less advantageous, but I think it's
worth doing anyway.

[Bug target/115058] on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-05-13

--- Comment #1 from Richard Earnshaw  ---
It looks like those messages are coming from the assembler, not the compiler,
but without a testcase it's difficult to be exactly sure what your problem is.

Please attach a small program that demonstrates your problem and state the 
/exact/ command line you used.

[Bug tree-optimization/60276] [4.7 Regression] -O3 autovectorizer breaks on a particular loop

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

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

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

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

commit r15-431-g8a9b159a86081053289be0c44339623ff59717a2
Author: Richard Biener 
Date:   Thu Nov 9 11:30:22 2023 +0100

PR60276 fix for single-lane SLP

When enabling single-lane SLP and not splitting groups the fix for
PR60276 is no longer effective since it for unknown reason exempted
pure SLP.  The following removes this exemption, making
gcc.dg/vect/pr60276.c PASS even with --param vect-single-lane-slp=1

PR tree-optimization/60276
* tree-vect-stmts.cc (vectorizable_load): Do not exempt
pure_slp grouped loads from the STMT_VINFO_MIN_NEG_DIST
restriction.

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
FWIW, this project contains a subset of module interface files that
(reportedly) can be used to build a (probably incomplete) `std` module with
`libstdc++` using Clang (the README says it requires `libc++` but I've
confirmed with the author it is tested with both `libstdc++` and `libc++`):

https://github.com/alibaba/async_simple/tree/CXX20Modules/third_party_module/stdmodules

I am putting it out there in case someone is looking for a potential starting
point: maybe we could get going using Clang while GCC's modules support is
being worked into shape (and I am glad to see there was some progress on this
front for 14).

[Bug middle-end/54052] [11/12/13 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8763-gd629308c699bb8fe90c2afeb7fa1acb12cb5526b
Author: Richard Biener 
Date:   Mon Feb 19 11:10:50 2024 +0100

rtl-optimization/54052 - RTL SSA PHI insertion compile-time hog

The following tries to address the PHI insertion compile-time hog in
RTL fwprop observed with the PR54052 testcase where the loop computing
the "unfiltered" set of variables possibly needing PHI nodes for each
block exhibits quadratic compile-time and memory-use.

It does so by pruning the local DEFs with LR_OUT of the block, removing
regs that can never be LR_IN (defined by this block) in the dominance
frontier.

PR rtl-optimization/54052
* rtl-ssa/blocks.cc (function_info::place_phis): Filter
local defs by LR_OUT.

(cherry picked from commit c7151283dc747769d4ac4f216d8f519bda2569b5)

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 98529 Summary: [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529

   What|Removed |Added

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

[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|11.5|15.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #12 from Rainer Orth  ---
Fixed for GCC 15.

[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs

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

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

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

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

commit r15-430-gc4af8ebdb0318b5e9ed3dfdea5501a3260f3acea
Author: Rainer Orth 
Date:   Mon May 13 14:02:46 2024 +0200

testsuite: c++: Allow for std::printf in g++.dg/modules/stdio-1_a.H
[PR98529]

g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:

FAIL: g++.dg/modules/stdio-1_a.H -std=c++17  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"
FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"
FAIL: g++.dg/modules/stdio-1_a.H -std=c++2b  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"

The problem is that the module file doesn't contain

 Depset:0 decl entity:95 function_decl:'::printf'

as expected by the test, but

 Depset:0 decl entity:26 function_decl:'::std::printf'

This happens because Solaris  declares printf in namespace std
as allowed by C++11, Annex D, D.5.

This patch allows for both forms.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.

2024-05-13  Rainer Orth  

gcc/testsuite:
PR c++/98529
* g++.dg/modules/stdio-1_a.H (scan-lang-dump): Allow for
::std::printf.

[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Matthias Kretz :

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

commit r15-429-gfb1649f8b4ad5043dd0e65e4e3a643a0ced018a9
Author: Matthias Kretz 
Date:   Mon May 6 12:13:55 2024 +0200

libstdc++: Use __builtin_shufflevector for simd split and concat

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/114958
* include/experimental/bits/simd.h (__as_vector): Return scalar
simd as one-element vector. Return vector from single-vector
fixed_size simd.
(__vec_shuffle): New.
(__extract_part): Adjust return type signature.
(split): Use __extract_part for any split into non-fixed_size
simds.
(concat): If the return type stores a single vector, use
__vec_shuffle (which calls __builtin_shufflevector) to produce
the return value.
* include/experimental/bits/simd_builtin.h
(__shift_elements_right): Removed.
(__extract_part): Return single elements directly. Use
__vec_shuffle (which calls __builtin_shufflevector) to for all
non-trivial cases.
* include/experimental/bits/simd_fixed_size.h (__extract_part):
Return single elements directly.
* testsuite/experimental/simd/pr114958.cc: New test.

[Bug c/115068] New: RISC-V: Illegal instruction of vfwadd

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

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

Bug ID: 115068
   Summary: RISC-V: Illegal instruction of vfwadd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include 
#include 

vfloat64m8_t test_vfwadd_wf_f64m8_m(vbool8_t vm, vfloat64m8_t vs2, float rs1,
size_t vl) {
  return __riscv_vfwadd_wf_f64m8_m(vm, vs2, rs1, vl);
}

char global_memory[1024];
void *fake_memory = (void *)global_memory;

int main ()
{
  asm volatile("fence":::"memory");
  vfloat64m8_t vfwadd_wf_f64m8_m_vd =
test_vfwadd_wf_f64m8_m(__riscv_vreinterpret_v_i8m1_b8(__riscv_vundefined_i8m1()),
__riscv_vundefined_f64m8(), 1.0, __riscv_vsetvlmax_e64m8());
  asm volatile(""::"vr"(vfwadd_wf_f64m8_m_vd):"memory");

  return 0;
}

https://compiler-explorer.com/z/rq7K33zE5

main:
fence
lui a5,%hi(.LC0)
flw fa5,%lo(.LC0)(a5)
vsetvli a5,zero,e32,m4,ta,ma
vfwadd.wf   v0,v8,fa5,v0.t ---> vd should not be v0.
li  a0,0
ret

[Bug middle-end/54052] [11/12/13 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/92387] [11/12/13 Regression] gcc generates wrong debug information at -O1 since r10-1907-ga20f263ba1a76a

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/102250] [11/12/13 Regression] python is not documented as a Prerequisite for building for riscv

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/107169] [13 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/107231] [13 Regression] c-c++-common/goacc/kernels-loop-g.c: '-fcompare-debug' failure (length)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #14 from Thorsten Otto  ---
A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit:

commit 512c6ba04102295fccc62a173ee0086ca733c920
From: Richard Biener 
Date: Thu, 12 Nov 2020 11:29:12 +0100
Subject: [PATCH] Avoid PRE insert iteration when possible

[Bug analyzer/109077] [11/12/13 Regression] Analyzer headers not installed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/109772] [13 Regression] Memory layout optimization of std::chrono::hh_mm_ss is wrong

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/110269] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-4607-g2dc5d6b1e7e

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug sanitizer/110676] [11/12/13 Regression] strlen of array[1] should not be optimized to 0 if using ASAN

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/111059] [11/12/13 Regression] ICE: in gimplify_expr, at gimplify.cc:17253

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/111266] [13 Regression] Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/111668] [12/13 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/113158] [11/12/13 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/114159] [13 Regression] ICE: in call_info, at analyzer/call-info.cc:143 with -fanalyzer -fanalyzer-call-summaries --param=analyzer-max-svalue-depth=0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2