[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> OK, it's a late IPA pass doing the clones it seems.  The scalar node got the
> 'const' stripped btw, but the call fntype still has it via the attributes.
> 
> It loses 'const' by
> 
> Old value = 252968993
> New value = 251920417
> set_const_flag_1 (node=,
> set_const=false, looping=false, changed=0x7fffda5f) at
> /home/rguenther/src/trunk/gcc/cgraph.cc:2696
> 2696  DECL_LOOPING_CONST_OR_PURE_P (node->decl) = false;
> (gdb) bt
> #0  set_const_flag_1 (node=, 
> set_const=false, looping=false, changed=0x7fffda5f)
> at /home/rguenther/src/trunk/gcc/cgraph.cc:2696
> #1  0x00da633f in cgraph_node::set_const_flag (
> this=, set_const=false, 
> looping=false) at /home/rguenther/src/trunk/gcc/cgraph.cc:2789
> #2  0x015e2910 in tree_profiling ()
> at /home/rguenther/src/trunk/gcc/tree-profile.cc:818
> #3  0x015e2b9f in (anonymous
> namespace)::pass_ipa_tree_profile::execute
> (this=0x42a0c70) at /home/rguenther/src/trunk/gcc/tree-profile.cc:888
> 
> but the IL happily continues to treat the calls as 'const' because
> flags_from_decl_or_type on the call fntype has
> 
> 849   else if (TYPE_P (exp))
> 850 {
> 851   if (TYPE_READONLY (exp))
> 852 flags |= ECF_CONST;
> 
> note that __attribute__((pure)) is not duplicated on the type and so the
> IPA profile effect will change the IL in fixup_cfg (), rewriting virtual
> operands there.
> making things consistent.

Just to note, since types are shared we cannot simply strip the attribute
from the function decls type.  If the instead unshare it and do the type
change local to the decl the calls to the function won't pick up this change.

So the only way out here is to never go const -> non-const (or pure ->
non-pure)
because that cannot work reliably (consider indirect calls for example).

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #15 from Richard Biener  ---
I can confirm we get

.L3:
vmovupd (%rsi), %ymm1
vmovupd 32(%rsi), %ymm0
addl$1, %eax
addq$64, %rdi
addq$64, %rsi
vblendpd$14, %ymm1, %ymm0, %ymm3
vblendpd$14, %ymm0, %ymm1, %ymm2
vfnmadd213pd-64(%rdi), %ymm5, %ymm3
vfmadd213pd -32(%rdi), %ymm7, %ymm1
vfnmadd132pd%ymm4, %ymm3, %ymm2
vfnmadd132pd%ymm6, %ymm1, %ymm0
vmovupd %ymm2, -64(%rdi)
vmovupd %ymm0, -32(%rdi)
cmpl%edx, %eax
jb  .L3

instead of

.L3:
vmovupd (%rdx), %ymm1
vmovupd (%rdx), %ymm0
addl$1, %ecx
addq$64, %rax
vfmadd213pd -32(%rax), %ymm3, %ymm1
vfnmadd213pd-64(%rax), %ymm2, %ymm0
addq$64, %rdx
vfnmadd231pd-32(%rdx), %ymm3, %ymm0
vfnmadd231pd-32(%rdx), %ymm2, %ymm1
vmovupd %ymm0, -64(%rax)
vmovupd %ymm1, -32(%rax)
cmpl%esi, %ecx
jb  .L3

the good case sees

   [local count: 214748368]:
  # ivtmp.27_211 = PHI 
  # ivtmp.32_209 = PHI 
  # ivtmp.34_28 = PHI 
  _53 = (void *) ivtmp.34_28;
  vect_x_re_54.13_193 = MEM  [(const double *)_53];
  vect_x_im_60.21_176 = MEM  [(const double *)_53 +
32B];
  _54 = (void *) ivtmp.32_209;
  vect_y_re_62.9_200 = MEM  [(double *)_54];
  vect_y_re_62.10_198 = MEM  [(double *)_54 + 32B];
  vect__154.17_185 = .FMA (vect_x_re_54.13_193, _197, vect_y_re_62.10_198);
  vect__66.16_188 = .FNMA (vect_x_re_54.13_193, _196, vect_y_re_62.9_200);
  vect_y_re_68.23_173 = .FNMA (vect_x_im_60.21_176, _197, vect__66.16_188);
  vect_y_re_68.23_172 = .FNMA (vect_x_im_60.21_176, _196, vect__154.17_185);
  MEM  [(double *)_54] = vect_y_re_68.23_173;
  MEM  [(double *)_54 + 32B] = vect_y_re_68.23_172;
  ivtmp.27_210 = ivtmp.27_211 + 1;
  ivtmp.32_208 = ivtmp.32_209 + 64;
  ivtmp.34_51 = ivtmp.34_28 + 64;
  if (bnd.6_207 > ivtmp.27_210)
goto ; [90.00%]

while the bad has

   [local count: 214748368]:
  # ivtmp.31_65 = PHI 
  # ivtmp.36_63 = PHI 
  # ivtmp.38_203 = PHI 
  _61 = (void *) ivtmp.38_203;
  vect_x_im_60.13_211 = MEM  [(const double *)_61];
  vect_x_im_60.14_209 = MEM  [(const double *)_61 +
32B];
  vect_x_re_54.15_208 = VEC_PERM_EXPR ;
  vect_x_re_54.23_192 = VEC_PERM_EXPR ;
  _58 = (void *) ivtmp.36_63;
  vect_y_re_62.9_218 = MEM  [(double *)_58];
  vect_y_re_62.10_216 = MEM  [(double *)_58 + 32B];
  vect__41.18_202 = .FMA (vect_x_im_60.13_211, _215, vect_y_re_62.10_216);
  vect_y_re_68.17_205 = .FNMA (vect_x_re_54.15_208, _214, vect_y_re_62.9_218);
  vect_y_re_68.25_189 = .FNMA (vect_x_re_54.23_192, _198, vect_y_re_68.17_205);
  vect_y_re_68.25_188 = .FNMA (_199, vect_x_im_60.14_209, vect__41.18_202);
  MEM  [(double *)_58] = vect_y_re_68.25_189;
  MEM  [(double *)_58 + 32B] = vect_y_re_68.25_188;
  ivtmp.31_64 = ivtmp.31_65 + 1;
  ivtmp.36_62 = ivtmp.36_63 + 64;
  ivtmp.38_59 = ivtmp.38_203 + 64;
  if (ivtmp.31_64 < bnd.6_225)
goto ; [90.00%]

the blends do not look like no-ops so I wonder if this is really computing
the same thing ... (it swaps lane 0 from the two loads from x but not the
stores)

[Bug tree-optimization/107865] [12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (Error: loop 3's number of iterations '_61 > 0 ? (uint128_t) (_61 + -1) : 0' references the released

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-4295-gbcc2449384f2092cbdf5d6ac2357aeabe3212b2e
Author: Richard Biener 
Date:   Fri Nov 25 08:27:42 2022 +0100

tree-optimization/107865 - ICE with outlining of loops

The following makes sure to clear loops number of iterations when
outlining them as part of a SESE region as can happen with
auto-parallelization.  The referenced SSA names become stale otherwise.

PR tree-optimization/107865
* tree-cfg.cc (move_sese_region_to_fn): Free the number of
iterations of moved loops.

* gfortran.dg/graphite/pr107865.f90: New testcase.

[Bug tree-optimization/107865] [12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 (Error: loop 3's number of iterations '_61 > 0 ? (uint128_t) (_61 + -1) : 0' references the released SSA

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |verify_loop_structure, at   |verify_loop_structure, at
   |cfgloop.cc:1748 (Error: |cfgloop.cc:1748 (Error:
   |loop 3's number of  |loop 3's number of
   |iterations '_61 > 0 ?   |iterations '_61 > 0 ?
   |(uint128_t) (_61 + -1) : 0' |(uint128_t) (_61 + -1) : 0'
   |references the released SSA |references the released SSA
   |name '_61') |name '_61')
  Known to work||13.0
  Known to fail||12.2.0
   Priority|P3  |P2

[Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3.

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107866
   Summary: gcc trunk's UBSan  misses a Nll-pointer-dereference at
-O3.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, `gcc-trunk -O3 -fsanitize=undefined` misses the
NULL-pointer-dereference, while `gcc-trunk -Ox -fsanitize=address` (x=0,1, 2,
s) can detect it.

gcc-12 has the same issue.
gcc-11 can detect the bug at all optimization levels.
clang can also detect it at all optimization levels.

Compiler explorer: https://godbolt.org/z/WhrzP6zdf

% cat a.c
int *a;
void main() {
  for (;;) {
a = 0;
if (*a)
  break;
  }
}
%
% gcc-tk -O3 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
Segmentation fault
% gcc-tk -O2 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
a.c:5:9: runtime error: load of null pointer of type 'int'
%

[Bug libstdc++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine

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

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

--- Comment #5 from Jonathan Wakely  ---
https://cplusplus.github.io/LWG/issue3809

[Bug tree-optimization/107867] New: [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08

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

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

Bug ID: 107867
   Summary: [13 Regression] ICE in init_from_control_deps, at
gimple-predicate-analysis.cc:1699 since
r13-2314-ga8ebd27d0ab69b08
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

One more ICE with the same test-case as PR107803:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr107803.C -Wextra
-fno-tree-ccp -Os
during GIMPLE pass: uninit
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr107803.C: In function ‘int
main()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr107803.C:10:1: internal
compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1747
   10 | main()
  | ^~~~
0x947200 predicate::init_from_control_deps(vec
const*, unsigned int, bool)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:1747
0x1f79316 predicate::init_from_control_deps(vec
const*, unsigned int, bool)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:1722
0x1f79316 uninit_analysis::init_use_preds(predicate&, basic_block_def*,
basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:2003
0x1f7c98f uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:2154
0x1f7cf7a uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
/home/marxin/Programming/gcc/gcc/gimple-predicate-analysis.cc:2195
0x1410e5c find_uninit_use
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1234
0x141178e warn_uninitialized_phi
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1304
0x141178e execute_late_warn_uninitialized
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1425
0x141178e execute
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.cc:1442
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/107867] [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |13.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107803
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-25

[Bug lto/107829] Trivial compile time tracking code

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:2b3a3d7fe3420b6b49810b2a7f5d120c53310335

commit r13-4296-g2b3a3d7fe3420b6b49810b2a7f5d120c53310335
Author: Martin Liska 
Date:   Wed Nov 23 10:38:54 2022 +0100

lto: fix usage of timer in materialize_cgraph

PR lto/107829

gcc/lto/ChangeLog:

* lto.cc (materialize_cgraph): Call timevar_push before
  materialization starts.

[Bug lto/107829] Trivial compile time tracking code

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed for master.

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

[gdrzewo at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Grzegorz Drzewiecki  ---
(In reply to Jonathan Wakely from comment #1)
> When you call this->o << t then there is no exact match, so an implicit
> conversion to unsigned char happens.

OK. But what botter me. I've added global operator like:

std::ostream &operator<<(std::ostream &os, unsigned char c) {
return os << static_cast(c);
}

With this one my example works fine:

f << cat << " vs " << dog << "\n\r";

stdout: 67 vs 68.

There is different conversion for either global operator or template operator.

[Bug tree-optimization/107868] New: [10 regression] Wrong code on AArch64 at -O1 with new/delete

[victor.donascimento at arm dot com via Gcc-bugs]

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

Bug ID: 107868
   Summary: [10 regression] Wrong code on AArch64 at -O1 with
new/delete
   Product: gcc
   Version: 10.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.donascimento at arm dot com
  Target Milestone: ---

The libstdc++ execution test 20_util/allocator/1.cc test fails on the head of
the gcc-10 release branch when compiled at at the -O1 optimization level.

The cddce1 tree dump reports the following elimination:

Eliminating unnecessary statements: 
Deleting : _4 = ~check_delete.1_3;  
Deleting : operator delete (_11, 256);
Deleting : _2 = ~check_new.0_1; 
Deleting : _11 = operator new (256);

leading to the spurious loss of calls to both the new and delete operators.

bisecting between basepoints/gcc-10 and basepoints/gcc-11 identified the
following commit as introducing the error:

r10-2217-g8e8e7af514344588ff3e3da25c0cb74c12dc6a0d
Author: Martin Liska 
Date:   Fri Aug 2 08:07:15 2019 +0200

Mark DECL_SET_IS_OPERATOR_DELETE for user-provided delete operators.

and the following as fixing the bug:

r11-3611-g0b945f959f03a6185a3130f30bfd524d01d4142c
Author: Richard Biener 
Date:   Thu Oct 1 10:44:27 2020 +0200

make use of CALL_FROM_NEW_OR_DELETE_P

Is the above patch an appropriate fix for the issue or does it mask any further
shortcommings in the compiler?

If we're happy with the fix, should it be backported to GCC 10?
Many thanks.

Here is a reduced testcase:

#include 

struct gnu { };
bool check_new = false;
bool check_delete = false;

void*
operator new(std::size_t n) noexcept(false)
{
  check_new = true;
  return NULL;
}

void operator delete(void *v) noexcept
{
  check_delete = true;
  return;
}

void operator delete(void *v, std::size_t) noexcept
{
  ::operator delete(v);
}

void test01()
{
  std::allocator obj;

  if (!check_new)
__builtin_abort();

  obj.deallocate(pobj, 256);
  if (!check_delete)
__builtin_abort();
}

int main()
{
  test01();
  return 0;
}

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|gcc trunk's UBSan  misses a |[12/13 Regression] gcc
   |Null-pointer-dereference at |trunk's UBSan  misses a
   |-O3.|Null-pointer-dereference at
   ||-O3.
   Target Milestone|--- |12.3
 CC||rguenth at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #1 from Jakub Jelinek  ---
This isn't reported since r12-3918-g5b8b1522e04adc20980f396571be1929a32d148a
I wonder what is the point of -O3 -fsanitize=undefined, -fsanitize= severely
slows down the code for instrumentation and at the same time you ask for as
many optimizations as possible.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #2 from Li Shaohua  ---
(In reply to Jakub Jelinek from comment #1)
> This isn't reported since r12-3918-g5b8b1522e04adc20980f396571be1929a32d148a
> I wonder what is the point of -O3 -fsanitize=undefined, -fsanitize= severely
> slows down the code for instrumentation and at the same time you ask for as
> many optimizations as possible.

I understand that optimization could optimize away UBs in a program. However,
in this case, if you check the assembly code, the NULL pointer is still there
and UBSAN is called to check it. So I believe this is a sanitizer issue.

Many fuzzing tools these days are still using -O3 -fsanitize=xxx to compile
programs for fast execution speed. So I believe no matter that optimization
lever is used, as long as the UB is not optimized away, sanitizers should warn
properly.

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Grzegorz Drzewiecki from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > When you call this->o << t then there is no exact match, so an implicit
> > conversion to unsigned char happens.
> 
> OK. But what botter me. I've added global operator like:
> 
> std::ostream &operator<<(std::ostream &os, unsigned char c) {

Adding this is undefined behaviour, you're not allowed to redefine what it
means to write fundamental types to std::istream.

> return os << static_cast(c);
> }
> 
> With this one my example works fine:
> 
> f << cat << " vs " << dog << "\n\r";
> 
> stdout: 67 vs 68.
> 
> There is different conversion for either global operator or template
> operator.

No there isn't. You've just changed what the "this->o << t" expression inside
the template operator does. That template operator is still called, but now it
uses a different function to print the enum. You can easily verify this by
stepping through the code in a debugger.

There is no GCC bug here, this is just how C++ works.

[Bug bootstrap/107869] New: garbled output from configure for darwin and bsd

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

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

Bug ID: 107869
   Summary: garbled output from configure for darwin and bsd
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-darwin*, *-*-freebsd*, *-*-netbsd*

As pointed out in
https://gcc.gnu.org/pipermail/gcc-help/2022-November/142023.html we have this
in gcc/configure.ac

# Test for stack protector support in target C library.
AC_CACHE_CHECK(__stack_chk_fail in target C library,
...
   *-*-darwin* | *-*-freebsd* | *-*-netbsd*)
 AC_CHECK_FUNC(__stack_chk_fail,[gcc_cv_libc_provides_ssp=yes],
   [echo "no __stack_chk_fail on this target"])
;;

That AC_CHECK_FUNC comes after the earlier message which hasn't
printed its result yet, so the output of AC_CHECK_FUNC gets nested within the
output of AC_CACHE_CHECK. Then the echo makes it even worse, by adding a third
message inside the
other two. The output ends up as:

checking linker --sysroot support... no
checking __stack_chk_fail in target C library... checking for
__stack_chk_fail... no
no __stack_chk_fail on this target
no
checking sys/sdt.h in the target C library... no

[Bug target/107551] __builtin_cpu_is returns a negative integer for x86-64

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|g++ 12.2 test fails |__builtin_cpu_is returns a
   ||negative integer for x86-64
 Status|WAITING |ASSIGNED

--- Comment #9 from Martin Liška  ---
Thanks a lot for the values! It's the same story as PR103661, grr. Apparently,
I didn't fix it entirely.

[Bug target/107551] __builtin_cpu_is returns a negative integer for x86-64

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #10 from Martin Liška  ---
One can easily reproduce that locally with:

  assert (__builtin_cpu_supports ("x86-64") >= 0);

[Bug bootstrap/107869] garbled output from configure for darwin and bsd

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

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

--- Comment #1 from Jonathan Wakely  ---
There's another similar case in libstdc++-v3/configure:

checking whether to build libbacktrace support... checking for sys/mman.h...
(cached) yes
yes

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

[adrian.perl at web dot de via Gcc-bugs]

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

Adrian Perl  changed:

   What|Removed |Added

 CC||adrian.perl at web dot de

--- Comment #5 from Adrian Perl  ---
Created attachment 53963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53963&action=edit
Test applications

I also noticed this behaviour in gcc 11.2 and could reproduce it in all version
since 10.2 (even in the current trunk).

Since this issues has existed for some time now, I had a look at the code
myself and possibly found a fix. Please be aware that I am a complete novice in
regards to the gcc-sourcecode.

As the example posted by David Ledger (https://godbolt.org/z/8r8oGG4z5) was the
simplest one I could find, I used it to debug the issue.

Having a look at the generated tree using -fdump-tree-all-graph I found out
that the destructor of A gets indeed called twice, first by the destructor of
class Awaitable and then once more in a finally-clause.
...
 resume.4:;
  <;
}
  finally
{
  Awaitable::~Awaitable (&Aw0);
}
}
  finally
{
  A::~A (&D.58267);
}
...
The finally clauses are generated by the maybe_promote_temps-function in
coroutines.cc, which modifies the lifetime-management of temporaries in
co_await statements in order to keep them alive across a suspension point. For
this purpose it recursivly searches all initializers to the right of the
co_await expression, using the helper functions flatten_await_stmt and
find_interesting_subtree.
In this recursion it finds the initialization of the Awaitable and also the
initialization of its member. So both the temporary Awaitable-instance and its
member get promoted, which leads to the generation of a (correct) destructor
call for the Awaitable and the (incorrect) call for its member.

So the error seems to be in the recursion, which also finds and promotes
initializations in sub-scopes like the constructor. 

Therefore I modified the check for relevant subexpressions to exclude trees
below constructor calls, as can be seen in this patch:

Patch:
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 01a3e831ee5..349b68ea239 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2684,6 +2684,10 @@ find_interesting_subtree (tree *expr_p, int *dosub, void
*d)
  return expr;
}
 }
+  else if (TREE_CODE(expr) == CONSTRUCTOR)
+{
+  *dosub = 0; /* We don't need to consider this any further.  */
+}
   else if (tmp_target_expr_p (expr)
   && !p->temps_used->contains (expr))
 {
-- 
2.34.1

I checked the results of the patched compiler using most of the examples posted
in this and related bug reports (99576, 100611, 102217, 101244, 101976) and
always got the correct results, also matching the output of clang. I have
attached these test applications.

I also noticed that the incorrect behaviour is gone as soon as the Awaitable
has a user defined constructor. This likely moves the initalization of the
Awaitable to a seperate tree which does not get evaluated by
find_interesting_subtree. I checked the .dot-files and there was indeed an
additional tree for the constructor when it is defined by the user.

It would be great if someone could have a look at the patch, as I am unsure if
it could have any unforseen sideeffects.
Another (better?) fix for this issue could be to always generate the
constructor-tree.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-25

--- Comment #1 from Martin Liška  ---
@Richi: What do you think?

[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.5
   Last reconfirmed|2022-11-25 00:00:00 |
 Status|NEW |ASSIGNED
 Target||aarch64
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Possibly yes.  Let me see if it can be backported.

[Bug ada/107810] [13 regression] gnat.dg/unchecked_convert9.adb FAILs

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Confirmed.  The test is still OK in 32-bit mode.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

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

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

--- Comment #3 from Richard Biener  ---
For some reason we think that the .UBSAN_NULL call doesn't clobber the load
from nullptr:

[local count: 118111600]:
+  # VUSE <.MEM_3(D)>
+  pretmp_7 = MEM[(int *)0B];

[local count: 1073741824]:
-  # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(5)>
+  # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(3)>
   # .MEM_4 = VDEF <.MEM_2>
   a = 0B;
   # .MEM_6 = VDEF <.MEM_4>
   # USE = nonlocal escaped 
   # CLB = nonlocal escaped 
   .UBSAN_NULL (0B, 0B, 4);
-  # VUSE <.MEM_6>
-  _1 = MEM[(int *)0B];
-  if (_1 != 0)
+  if (pretmp_7 != 0)

that's because

DEF_INTERNAL_FN (UBSAN_NULL, ECF_LEAF | ECF_NOTHROW, ". R . ")

and thus .UBSAN_NULL only _reads_ from the first argument passed (but also
possibly constant NULL(?) valued operands are considered special).  The
same happens at -O2 btw.  At -O1 we eliminate the load.

Ah, and call_may_clobber_ref_p_1 has

  if (gimple_call_internal_p (call))
switch (auto fn = gimple_call_internal_fn (call))
  {
/* Treat these internal calls like ECF_PURE for aliasing,
   they don't write to any memory the program should care about.
   They have important other side-effects, and read memory,
   so can't be ECF_NOVOPS.  */
  case IFN_UBSAN_NULL:
  case IFN_UBSAN_BOUNDS:
  case IFN_UBSAN_VPTR:
  case IFN_UBSAN_OBJECT_SIZE:
  case IFN_UBSAN_PTR:
  case IFN_ASAN_CHECK:
return false;

so they are not a barrier for the motion of loads which is what happens
here.

Note that only at -O3 we keep the trapping load because we fail to eliminate
the conditional there and have

   [local count: 118111600]:
  # VUSE <.MEM_3(D)>
  pretmp_7 = MEM[(int *)0B];
  if (pretmp_7 != 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 955630224]:
  # .MEM_1 = PHI <.MEM_3(D)(2)>
  # .MEM_8 = VDEF <.MEM_1>
  a = 0B;
  # .MEM_11 = VDEF <.MEM_8>
  # USE = anything
  # CLB = anything
  __builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data0, 0);

   [local count: 118111600]:
  # .MEM_4 = VDEF <.MEM_3(D)>
  a = 0B;
  # .MEM_10 = VDEF <.MEM_4>
  # USE = anything
  # CLB = anything
  __builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data1, 0);

in the end.

[Bug tree-optimization/107867] [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
forwprop has the same issue.

[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Fixed, thanks for the report.

[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:71f3036b8a83da7fb559923bc80687ea1dabe14a

commit r13-4303-g71f3036b8a83da7fb559923bc80687ea1dabe14a
Author: Tamar Christina 
Date:   Fri Nov 25 12:57:24 2022 +

sve2: Fix expansion of division [PR107830]

SVE has an actual division optab, and when using -Os we don't
optimize the division away.  This means that we need to distinguish
between a div which we can optimize and one we cannot even during
expansion.

gcc/ChangeLog:

PR target/107830
* config/aarch64/aarch64.cc
(aarch64_vectorize_can_special_div_by_constant): Check validity
during
codegen phase as well.

gcc/testsuite/ChangeLog:

PR target/107830
* gcc.target/aarch64/sve2/pr107830-1.c: New test.
* gcc.target/aarch64/sve2/pr107830-2.c: New test.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #16 from Michael_S  ---
On unrelated note, why loop overhead uses so many instructions?
Assuming that I am as misguided as gcc about load-op combining, I would write
it as:
  sub %rax, %rdx
.L3:
  vmovupd   (%rdx,%rax), %ymm1
  vmovupd 32(%rdx,%rax), %ymm0
  vfmadd213pd32(%rax), %ymm3, %ymm1
  vfnmadd213pd (%rax), %ymm2, %ymm0
  vfnmadd231pd   32(%rdx,%rax), %ymm3, %ymm0
  vfnmadd231pd (%rdx,%rax), %ymm2, %ymm1
  vmovupd %ymm0,   (%rax)
  vmovupd %ymm1, 32(%rax)
  addq$64, %rax
  decl%esi
  jb  .L3

The loop overhead in my variant is 3 x86 instructions==2 macro-ops,
vs 5 x86 instructions==4 macro-ops in gcc variant.
Also, in gcc variant all memory accesses have displacement that makes them
1 byte longer. In my variant only half of accesses have displacement.

I think, in the past I had seen cases where gcc generates optimal or
near-optimal
code sequences for loop overhead. I wonder why it can not do it here.

[Bug target/107860] Compilation failure, ambiguous fisttp

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #6 from simon at pushface dot org ---
The situation with aarch64-apple-darwin vs x86_64-apple-darwin isn't I think
quite like the standard cross-compilation scenario, because of Apple's Rosetta
x86_64 emulation and the fact that all the low-level tools (as, ld, ...)
support both architectures.

If I take an x86_64-apple-darwin compiler and run it on aarch64-apple-darwin it
will generate x86_64 assembler and invoke as, ld with the right switches to
create x86_84 binaries and executables; the executables will run on aarch64
under Rosetta or on x86_64 natively.

So I'm not sure what --build, --host should have been set to (given I don't
want a cross-compiler; the cross- facilities are provided by macOS under the
hood).

In what I was trying to do, the host machine was aarch64-apple-darwin22, but
notably aarch64 running Rosetta. The boot compiler was x86_64-apple-darwin21.

Anyway, the issue here was the way that configure invoked the assembler;
/usr/bin/as will assume it's targeting aarch64 (aka arm64) unless told
different.

These are the results of compiling the test case:

   $ cat conftest-filds-fists.s
   // $gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s
   filds (%ebp)
   fists (%ebp)

with /usr/bin/as -c -b conftest-filds-fists.s -o conftest-filds-fists.o

(a) on x86_64

Apple clang version 14.0.0 (clang-1400.0.29.201)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx12.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu penryn -fdebug-compilation-dir=/Users/simon/tmp
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.201)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s

(b) on aarch64

$ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
arm64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu apple-m1 -target-feature +v8.5a -target-feature +fp-armv8
-target-feature +neon -target-feature +crc -target-feature +crypto
-target-feature +dotprod -target-feature +fp16fml -target-feature +ras
-target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature
+zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sm4
-target-feature +sha3 -target-feature +sha2 -target-feature +aes
-fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s
conftest-filds-fists.s:2:16: error: unknown token in expression
filds (%ebp)
   ^
conftest-filds-fists.s:2:15: error: invalid operand
filds (%ebp)
  ^
conftest-filds-fists.s:3:16: error: unknown token in expression
fists (%ebp)
   ^
conftest-filds-fists.s:3:15: error: invalid operand
fists (%ebp)
  ^
(c) on aarch64, with -arch x86_64

$ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o -arch
x86_64
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu penryn
-fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s



I think the solution to this PR might be to set it as INVALID or WONTFIX? up to
you.

[Bug target/107860] Compilation failure, ambiguous fisttp

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

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

--- Comment #7 from Andrew Pinski  ---
The same issue you would run into even on Linux with qemu and gnu as (though
gcc does not add the right target options to as as it assumes you have one that
targets your target by default.

[Bug libstdc++/107850] [12/13 Regression] std::erase_if (map) forces predicate to takes a const value_type

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

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

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

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

commit r13-4306-gf54ceb2062c7fef294f85ae093914fa6c7ca35b8
Author: Jonathan Wakely 
Date:   Thu Nov 24 21:09:03 2022 +

libstdc++: Call predicate with non-const values in std::erase_if [PR107850]

As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.

It's not strictly nevessary to change it for the set and unordered_set
overloads, because they only give const access to the elements anyway.
I've done it for them too just to keep them all consistent.

libstdc++-v3/ChangeLog:

PR libstdc++/107850
* include/bits/erase_if.h (__erase_nodes_if): Use non-const
reference to the container.
* include/experimental/map (erase_if): Likewise.
* include/experimental/set (erase_if): Likewise.
* include/experimental/unordered_map (erase_if): Likewise.
* include/experimental/unordered_set (erase_if): Likewise.
* include/std/map (erase_if): Likewise.
* include/std/set (erase_if): Likewise.
* include/std/unordered_map (erase_if): Likewise.
* include/std/unordered_set (erase_if): Likewise.
* testsuite/23_containers/map/erasure.cc: Check with
const-incorrect predicate.
* testsuite/23_containers/set/erasure.cc: Likewise.
* testsuite/23_containers/unordered_map/erasure.cc: Likewise.
* testsuite/23_containers/unordered_set/erasure.cc: Likewise.
* testsuite/experimental/map/erasure.cc: Likewise.
* testsuite/experimental/set/erasure.cc: Likewise.
* testsuite/experimental/unordered_map/erasure.cc: Likewise.
* testsuite/experimental/unordered_set/erasure.cc: Likewise.

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Adrian Perl from comment #5)
> Created attachment 53963 [details]

thanks for the analysis and the patch.

> Patch:
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 01a3e831ee5..349b68ea239 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -2684,6 +2684,10 @@ find_interesting_subtree (tree *expr_p, int *dosub,
> void *d)
> return expr;
>   }
>  }
> +  else if (TREE_CODE(expr) == CONSTRUCTOR)
> +{
> +  *dosub = 0; /* We don't need to consider this any further.  */
> +}

small nit - the { } are not needed here ^

>else if (tmp_target_expr_p (expr)
>  && !p->temps_used->contains (expr))
>  {
> -- 
> 2.34.1

Your reasoning (I know that several of the outstanding issues are related to
'promotion' of temporaries to the frame) and the patch seem reasonable.  

Have you bootstrapped the compiler with the changes and run the whole of the
testsuite? (I do agree that this change should only affect coroutines, but we
still do the full check too).

The test-cases would need to be added to the gcc/testsuite/g++.dg/coroutines
(with names that reflect the PRs that they test).

once you have things to that stage, then please post the patch to
gcc-patc...@gcc.gnu.org (along with the test cases added), and we can go from
there.

[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 53964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53964&action=edit
gcc13-pr84469.patch

Untested fix.

[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE:  |[11/12 Regression] ICE:
   |verify_gimple failed at -O2 |verify_gimple failed at -O2
   |with pointers and bitwise   |with pointers and bitwise
   |caluclation |calculation

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk I believe.

[Bug target/106875] [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53965&action=edit
gcc13-pr106875.patch

Untested fix.

[Bug target/83670] [10/11/12/13 Regression] m32c ICE in leaf_function_p, at final.c:4368

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #9 from Andre Vehreschild  ---
Created attachment 53966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53966&action=edit
Prevent the ICE

I have no clue whether the attached patch is any good. It makes compile of
libgcc continue somewhat further, but then it fails when assigning registers
for a jump_ins.

[Bug fortran/107870] New: A possible typo in the documentation of 'FLOOR'

[ninorpereira at gmail dot com via Gcc-bugs]

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

Bug ID: 107870
   Summary: A possible typo in the documentation of 'FLOOR'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ninorpereira at gmail dot com
  Target Milestone: ---

the documentation says: FLOOR(A) returns the greatest integer less than or
equal to X.
better is: FLOOR(A) returns the greatest integer less than or equal to A.
(and then the example must be changed from x to a, or
FLOOR(X) returns the greatest integer less than or equal to X (and then
the example can stay the same).

[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
   Keywords||documentation
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  The standard uses A, so let's use that.

The standard nowadays also says about the KIND argument:

KIND (optional) shall be a scalar integer constant expression.

(instead of "initialization expression".)

We might adjust that for all affected intrinsics.

[Bug libstdc++/107871] New: _Iter_sink:: _M_overflow missing some difference type casting

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 107871
   Summary: _Iter_sink:: _M_overflow missing some difference type
casting
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

struct O {
  using difference_type = std::ranges::__detail::__max_diff_type;
  O& operator=(const char&);
  O& operator*();
  O& operator++();
  O& operator++(int);
};

int main() {
  std::format_to_n(O{}, 4, "{}", " ");
}

https://godbolt.org/z/x78qjfse6

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #17 from Richard Biener  ---
(In reply to Michael_S from comment #16)
> On unrelated note, why loop overhead uses so many instructions?
> Assuming that I am as misguided as gcc about load-op combining, I would
> write it as:
>   sub %rax, %rdx
> .L3:
>   vmovupd   (%rdx,%rax), %ymm1
>   vmovupd 32(%rdx,%rax), %ymm0
>   vfmadd213pd32(%rax), %ymm3, %ymm1
>   vfnmadd213pd (%rax), %ymm2, %ymm0
>   vfnmadd231pd   32(%rdx,%rax), %ymm3, %ymm0
>   vfnmadd231pd (%rdx,%rax), %ymm2, %ymm1
>   vmovupd %ymm0,   (%rax)
>   vmovupd %ymm1, 32(%rax)
>   addq$64, %rax
>   decl%esi
>   jb  .L3
>   
> The loop overhead in my variant is 3 x86 instructions==2 macro-ops,
> vs 5 x86 instructions==4 macro-ops in gcc variant.
> Also, in gcc variant all memory accesses have displacement that makes them
> 1 byte longer. In my variant only half of accesses have displacement.
> 
> I think, in the past I had seen cases where gcc generates optimal or
> near-optimal
> code sequences for loop overhead. I wonder why it can not do it here.

I don't think we currently consider IVs based on the difference of two
addresses.  The cost benefit of no displacement is only size, otherwise
I have no idea why we have biased the %rax accesses by -32.  Why we
fail to consider decrement-to-zero for the counter IV is probably because
IVCANON would add such IV but the vectorizer replaces that and IVOPTs
doesn't consider re-adding that.

[Bug fortran/107872] New: ICE on recursive DT with DTIO

[jwmwalrus at gmail dot com via Gcc-bugs]

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

Bug ID: 107872
   Summary: ICE on recursive DT with DTIO
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com
  Target Milestone: ---

Hi.

The code below throws the following ICE:

$ gfortran -c -fbacktrace test2.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

--8<--
module mod1
type t
integer :: data
type(t), allocatable :: next
contains
procedure, private :: write_t
generic :: write(formatted) => write_t
end type
contains
recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
if (ALLOCATED(this%next)) &
write (unit, '(dt)') this%next
end subroutine
end module
-->8--


$ gfortran --version
GNU Fortran (Debian 12.2.0-9) 12.2.0
Copyright (C) 2022 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.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #18 from Alexander Monakov  ---
The apparent 'bias' is introduced by instruction scheduling: haifa-sched lifts
a +64 increment over memory accesses, transforming +0 and +32 displacements to
-64 and -32. Sometimes this helps a little bit even on modern x86 CPUs.

Also note that 'vfnmadd231pd 32(%rdx,%rax), %ymm3, %ymm0' would be
'unlaminated' (turned to 2 uops before renaming), so selecting independent IVs
for the two arrays actually helps on this testcase.

[Bug c++/107873] New: C++ without SUPPORTS_ONE_ONLY

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

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

Bug ID: 107873
   Summary: C++ without SUPPORTS_ONE_ONLY
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aoliva at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53967&action=edit
working patch with SUPPORTS_ONE_ONLY, incomplete fix for !SUPPORTS_ONE_ONLY

I've attempted disabling SUPPORTS_ONE_ONLY to use a linker that supported weak
symbols but had some issues with comdat, and that didn't go well.

Several symbols with vague linkage, and that thus should be output as weak
definitions, were issued as strong definitions instead.  The scenarios involved
make_decl_one_only's checking of DECL_INITIAL before it was set, such as when
deciding between .common or .weak for typeinfo objects and for static variables
in inlined functions.  The attached patch fixes that, and bootstraps on
x86_64-linux-gnu with SUPPORTS_ONE_ONLY, and also on another non-pthreads
target without SUPPORTS_ONE_ONLY.

Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because pthread_once
is not weakref'ed in libstdc++: flag_weak is set to false, so we define
__GXX_WEAK__=0.  According to my reading of the documentation, __GXX_WEAK__
means whether symbols with vague linkage can be output as unifiable definitions
in multiple translation units (so SUPPORTS_ONE_ONLY could have it enabled
through comdat even with -fno-weak), so I tried this patchlet:

diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index 333f3e138d611..15ef47c0c04f5 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -939,7 +939,15 @@ c_cpp_builtins (cpp_reader *pfile)

   if (c_dialect_cxx ())
 {
-  if (flag_weak && SUPPORTS_ONE_ONLY)
+  /* __GXX_WEAK__'s name is misleading, the documentation says it
+tests for one-only spuport, but SUPPORTS_ONE_ONLY is also
+slightly misleading, because weak symbols can be used for
+one-only support even if !SUPPORtS_ONE_ONLY.  Here we
+approximate the supprots_one_only() test that may clear
+flag_weak, but we use the flag_weak result instead of
+TARGET_SUPPORTS_WEAK, because the user may have disabled weak
+symbols with -fno-weak.  */
+  if (flag_weak || SUPPORTS_ONE_ONLY)
cpp_define (pfile, "__GXX_WEAK__=1");
   else
cpp_define (pfile, "__GXX_WEAK__=0");


However, libstdc++ also uses it as telling whether weak undef / weakref is
available at all, a significant latent ambiguity that seems tricky and risky to
resolve without introducing two new macros, one for each independent meaning. 
(there are tests in g++.dg and libstdc++ testsuites that use it in one meaning
or the other)

Without SUPPORTS_ONE_ONLY, despite the availability of weak symbols, and
regardless of arranging for flag_weak to remain enabled, some symbols with
vague linkage fail to be output.  I have not investigated further, but one
example of simple test that fails in this configuration is g++.dg/abi/vtt1.C.

So the attached patch, though fixing some latent problems and not introducing
any to comdat-enabled C++, doesn't go all the way in making a comdat-less C++
compiler possible, so I'm not planning on submitting it for inclusion at this
point.  However, since I don't have plans to pursue this further, I hereby
contribute it as a starting point for anyone who might be interested in taking
it towards completion.

[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 53968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53968&action=edit
Revised patch

(In reply to Mikael Morin from comment #9)
> It seems the semantics when an argument has the value attribute is the same
> as the case ELEM_CHECK_VARIABLE in my previous comment.
> So forcing the value of the elemental argument to ELEM_CHECK_VARIABLE at
> some appropriate place could possibly work.

Many thanks for the explanations!

Looking at the involved code, the most simple solution I came up with is
attached.  It scans over the actual arguments associated with the dummies,
and when we find one with the VALUE attribute, we enforce the dependency
check.  It fixes the testcase and regtests fine.

I was struggling with the actual generated code, which is rather a temporary
for the arguments with INTENT(INOUT/OUT), but that should be functionally
equivalent.

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:2a7a103dd46cc079252302be69cfef188caee74d

commit r12-8942-g2a7a103dd46cc079252302be69cfef188caee74d
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.cc (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

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

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

--- Comment #1 from Jonathan Wakely  ---
This isn't valid code, you can't use max diff type for your own types. It can
only be used by the library for iota_view, but that doesn't have output
iterators.

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

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

https://gcc.gnu.org/g:55e5ef55a0eee1cb329754f30889d93567daae18

commit r11-10394-g55e5ef55a0eee1cb329754f30889d93567daae18
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.c (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11095-gb3b48f883d31910f2672640de2f5ff59e765488c
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.c (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #7 from Andrew Pinski  ---
I am trying to understand this. Is it ok to use the SSE registers inside
purgatory or not?

Now that the vectorizer is used turned on at -O2 and above, without -mno-sse,
on x86_64 target, the vector instructions are generated. and since this is
inside a tiny bootloader, I am suspecting you can't use SSE instructions here.

So the real fix is to use -mno-sse for x86_64 while compiling files under
purgatory .

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #8 from Andrew Pinski  ---
Looks like only ppc64 does:

ppc64_PURGATORY_EXTRA_CFLAGS += -m64 -msoft-float \
-fno-exceptions

Most likely purgatory/arch/x86_64/Makefile needs the following added the end of
the file instead:
x86_64_PURGATORY_EXTRA_CFLAGS += -mno-sse

(-mgeneral-regs-only might work these days too)


purgatory/arch/arm64/Makefile needs the following added too:
arm64_PURGATORY_EXTRA_CFLAGS += -mgeneral-regs-only

Other targets might need other CFLAGS set here for the same reason.

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #9 from Andrew Pinski  ---
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/Makefile?id=1b03cf7adc3c156ecab2618acb1ec585336a3f75
was the commit to "fix" this but as I think I mentioned here it is just a
workaround for expecting SSE code to work and GCC might emit SSE code in other
places without the autovectorizer enabled so 

[Bug c++/107873] C++ without SUPPORTS_ONE_ONLY

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Alexandre Oliva from comment #0)
> Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because
> pthread_once is not weakref'ed in libstdc++: flag_weak is set to false, so
> we define __GXX_WEAK__=0.  

N.B. for recent glibc no pthreads symbols should be weakrefs.

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #4 from Roger Sayle  ---
I believe that tweaking i386.md's *concat3_? patterns, that call
i386-expand.cc's split_double_concat, should resolve/improve the issue. 
Specifically in this case *concatditi3_[1234].  Currently, these patterns
expect the source operands (specifically the zero_extend operand) to be
registers, hence combine reports:

Trying 10, 9 -> 11:
   10: r96:TI=zero_extend([r92:DI+0x8])
  REG_DEAD r92:DI
9: {r95:TI=r94:TI<<0x40;clobber flags:CC;}
  REG_DEAD r94:TI
  REG_UNUSED flags:CC
   11: {r97:TI=r95:TI|r96:TI;clobber flags:CC;}
  REG_DEAD r96:TI
  REG_DEAD r95:TI
  REG_UNUSED flags:CC
...
Failed to match this instruction:
(set (reg:TI 97)
(ior:TI (ashift:TI (reg:TI 94 [ *y_3(D) ])
(const_int 64 [0x40]))
(zero_extend:TI (mem:DI (plus:DI (reg/v/f:DI 92 [ yD.1994 ])
(const_int 8 [0x8])) [1 MEM[(const long long unsigned
intD.1
6 *)y_3(D) + 8B]+0 S8 A64]

If *concatditi3_1 allowed a memory_operand for operand 3, it would match.
The oversight is that the zero_extendditi2 pattern (in insn #10) accepts memory
operands.  I suspect changing the predicates for operands 0, 1 and 3 to be
nonimmediate_operand, but then providing constraints for each permissible
variation should work.

Using the  expansion of these splitters should also fix the (pre-existing)
-m32 code generation issue, as pointed out by Jakub in comment #3.

Perhaps:
(define_insn_and_split "*concat3_1"
  [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r")
(any_or_plus:
  (ashift: (match_operand: 1 "nonimmediate_operand" "r,o,r")
(match_operand: 2 "const_int_operand"))
  (zero_extend: (match_operand:DWIH 3 "nonimmediate_operand"
"r,r,o"]

I hope this helps.

[Bug fortran/107874] New: merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

Bug ID: 107874
   Summary: merge not using all its arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

The F2018 standard 15.5.3 requires all actual arguments in a function reference
to be evaluated.

In the program below, merge has three scalar arguments; ifort evaluates
all three, gfortran evaluates only the useful two, which violates 15.5.3.

program testmerge9
  implicit none
  integer i
  logical:: x(2)=(/.true., .false./), y ! avoiding [ ] allows f95 option
  do i = 1,2
 y = merge(tstuff(),fstuff(),x(i))
 print *,y
  end do
contains
  logical function tstuff()
print *,'tstuff'
tstuff = .true.
  end function tstuff

  logical function fstuff()
print *,'fstuff'
fstuff = .false.
  end function fstuff
end program testmerge9

Steve Kargl said "Looks like a bug. Feel free to send a bug report with this
patch."

diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index bb938026828..c5b63d356e1 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -7538,9 +7538,9 @@ gfc_conv_intrinsic_merge (gfc_se * se, gfc_expr * expr)
   gfc_conv_intrinsic_function_args (se, expr, args, num_args);
   if (expr->ts.type != BT_CHARACTER)
 {
-  tsource = args[0];
-  fsource = args[1];
-  mask = args[2];
+  tsource = gfc_evaluate_now (args[0], &se->pre);
+  fsource = gfc_evaluate_now (args[1], &se->pre);
+  mask = gfc_evaluate_now (args[2], &se->pre);
 }
   else
 {

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #8 from Andrew Pinski  ---
Fixed for GCC 10 by the same patch which fixed PR 87954 .

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
.

[Bug middle-end/68557] Missed x86 peephole optimization for multiplying by a bool

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed for GCC 13 by r13-673-gd863ba23fb1612 (aka 98865 ).

[Bug tree-optimization/42195] missed xnor optimization.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80588
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 13 by r13-1779-g375668e0508 .

[Bug c++/107875] New: Deduction for class template specialization types seems to be broken with init-declarator-list

[8ygd87qg at gmail dot com via Gcc-bugs]

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

Bug ID: 107875
   Summary: Deduction for class template specialization types
seems to be broken with init-declarator-list
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 8ygd87qg at gmail dot com
  Target Milestone: ---

Consider the following program (compiled with -std=c++20):

#include 
template 
struct X {};
X x1, x2;
static_assert(!std::is_same_v);
int main() {}

Relevant godbolt link: https://godbolt.org/z/h9Wd4K7sn

According to https://eel.is/c++draft/dcl.type.class.deduct#1, it seems that
type deduction should be done for x1 and x2 separately, and they should have
the same type (and if they don't, then the compilation should at least give a
diagnostic, perhaps an error). I am not well-versed with standardese, so please
bear with me if something is wrong (and please point out if the standard seems
to be ambiguous in this case).

When x1 and x2 are declared in separate statements (like X x1; X x2;), they
should have different types since the lambda in the template parameter
specialization always has a distinct type whenever it is called. So if type
deduction is carried out for x1 and x2 separately in the first example, they
should have different types (even if somehow they're assigned the same types,
the static_assert should fail).

In any case, the above program should not compile. However, GCC trunk and
12.2.1 both seem to allow this program to compile. Clang however seems to have
an expected behavior and gives the following error:

:4:1: error: template arguments deduced as 'X<(lambda at
:2:20){}>' in declaration of 'x1' and deduced as 'X<(lambda at
:2:20){}>' in declaration of 'x2'
X x1, x2;
^ ~~  ~~
1 error generated.
Compiler returned: 1

It'd be great if this is fixed in case it turns out to be a bug. Thanks!