[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #38 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #37)
> (In reply to CVS Commits from comment #36)
> 
> > For the curious, a particular hot spot for IPA in this area was:
> > 
> > ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
> > {
> > ...
> > ...
> >   value_range save (m_vr);
> >   m_vr.union_ (*other_vr);
> >   return m_vr != save;
> > }
> > 
> > The problem isn't the resizing (since we do that at most once) but the
> > fact that for some functions with lots of callers we end up a huge
> > range that gets copied and compared for every meet operation.  Maybe
> > the IPA algorithm could be adjusted somehow??.
> 
> isn't the the same thing as 
> 
>   return m_vr.union_ (*other_vr);
> 
> which should be much faster without all the copying... ?

Indeed.  That is in the committed version of the patch.  I just forgot to
update the message.

The reason I didn't originally do as you suggested was that there was a bug in
the union code that returned TRUE for a union that hadn't changed anything. 
That has also been fixed in trunk.

[Bug tree-optimization/109950] New: can array subscripts be assumed to be non-negative?

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 109950
   Summary: can array subscripts be assumed to be non-negative?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

There is a lot of historical code which has been using `int` for array indexes:

```
extern int data[];
extern int next;

int
test_function(int* outptr)
  {
*outptr = data[next];
return next >= 0;
  }
```

In this example, the value of `next` is used as an array index. Despite the
unknown size, elements in an array can't have negative indexes, so maybe here
`next >= 0` can be optimized to a constant?


Specifically about x86_64, there is some more optimization that we can do: The
value of `next` can be loaded into a 32-bit register, zeroing the upper half
implicitly, without using a sign-extension instruction, as in machine code:

```
48 63 05 IMM32   ; movsxd rax, dword ptr [rip + IMM32]
   8B 05 IMM32   ; moveax, dword ptr [rip + IMM32]
```

The former contains an operand size override prefix, takes up one more byte,
and costs an extra cycle to decode.

[Bug target/109949] new test case experimental/simd/pr109261_constexpr_simd.cc in r12-9647-g3acbaf1b253215 fails

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I see the same test failing on trunk and the gcc 12 commit mentions it being a
backport.  The test is not in gcc 13 currently.

[Bug target/109949] New: new test case experimental/simd/pr109261_constexpr_simd.cc in r12-9647-g3acbaf1b253215 fails

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

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

Bug ID: 109949
   Summary: new test case
experimental/simd/pr109261_constexpr_simd.cc in
r12-9647-g3acbaf1b253215 fails
   Product: gcc
   Version: 12.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3acbaf1b25321508d780a8220b772fc9cd871b13, r12-9647-g3acbaf1b253215

This fails on power 10 but passes on power 9 and earlier.

make  -k check
RUNTESTFLAGS="conformance.exp=experimental/simd/pr109261_constexpr_simd.cc"
FAIL: experimental/simd/pr109261_constexpr_simd.cc -maltivec -mpower9-vector
-O2 -Wno-psabi (test for excess errors)
# of unexpected failures1


commit 3acbaf1b25321508d780a8220b772fc9cd871b13 (HEAD, refs/bisect/bad)
Author: Matthias Kretz 
Date:   Thu Mar 23 09:32:58 2023 +0100

libstdc++: Add missing constexpr to simd


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-12-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-12-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-12-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-12-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-12-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-12-test/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc
-maltivec -mpower9-vector -O2 -Wno-psabi -std=gnu++17
-fdiagnostics-plain-output -S -o pr109261_constexpr_simd.s
In file included from
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/simd:82,
 from
/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:5:
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/bits/simd_ppc.h:
In instantiation of 'static int
std::experimental::parallelism_v2::_MaskImplPpc<_Abi, 
>::_S_popcount(std::experimental::parallelism_v2::simd_mask<_Tp, _Abi>) [with
_Tp = char; _Abi =
std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16>;
 =
std::experimental::parallelism_v2::__detail::_MachineFlagsTemplate<31, 9>]':
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/bits/simd.h:4955:
  required from 'constexpr int
std::experimental::parallelism_v2::popcount(const simd_mask<_Tp, _Ap>&) [with
_Tp = char; _Abi = simd_abi::_VecBuiltin<16>]'
/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:46:
  required from 'void test01() [with T = char; V =
std::experimental::parallelism_v2::simd >]'
/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:67:
  required from 'void iterate_abis() [with T = char]'
/home/seurer/gcc/git/gcc-12-test/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:74:
  required from here
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/bits/simd_ppc.h:133:
error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_cntm'
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/bits/simd_ppc.h:
In instantiation of 'static int
std::experimental::parallelism_v2::_MaskImplPpc<_Abi, 
>::_S_popcount(std::experimental::parallelism_v2::simd_mask<_Tp, _Abi>) [with
_Tp = wchar_t; _Abi =
std::experimental::parallelism_v2::simd_abi::_VecBuiltin<16>;
 =
std::experimental::parallelism_v2::__detail::_MachineFlagsTemplate<31, 9>]':
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/experimental/bits/simd.h:4955:
  required from 'constexpr int
std::experimental::parallelism_v2::popcount(const 

[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-24
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
   Keywords||ice-on-invalid-code

--- Comment #1 from Kewen Lin  ---
Confirmed, thanks for reporting.

Both bif __builtin_pack_vector_int128 and __builtin_unpack_vector_int128 are
put in stanza power7 instead of vsx, so they miss to check vsx available or
not.

  const vsq __builtin_pack_vector_int128 (unsigned long long, \
  unsigned long long);
PACK_V1TI packv1ti {}

  void __builtin_ppc_speculation_barrier ();
SPECBARR speculation_barrier {}

  const unsigned long __builtin_unpack_vector_int128 (vsq, const int<1>);
UNPACK_V1TI unpackv1ti {}

But the underlying insn patterns do need VSX support, see:

(define_insn "pack"
  [(set (match_operand:FMOVE128_VSX 0 "register_operand" "=wa")
(unspec:FMOVE128_VSX
 [(match_operand:DI 1 "register_operand" "wa")
  (match_operand:DI 2 "register_operand" "wa")]
 UNSPEC_PACK_128BIT))]
  "TARGET_VSX"   // here
  "xxpermdi %x0,%x1,%x2,0"
  [(set_attr "type" "vecperm")])

(define_insn "unpack"
  [(set (match_operand:DI 0 "register_operand" "=wa,wa")
(unspec:DI [(match_operand:FMOVE128_VSX 1 "register_operand" "0,wa")
(match_operand:QI 2 "const_0_to_1_operand" "O,i")]
 UNSPEC_UNPACK_128BIT))]
  "VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)"  // here
{
  if (REGNO (operands[0]) == REGNO (operands[1]) && INTVAL (operands[2]) == 0)
return ASM_COMMENT_START " xxpermdi to same register";

  operands[3] = GEN_INT (INTVAL (operands[2]) == 0 ? 0 : 3);
  return "xxpermdi %x0,%x1,%x1,%3";
}
  [(set_attr "type" "vecperm")])

; Iterator for 128-bit VSX types for pack/unpack
(define_mode_iterator FMOVE128_VSX [V1TI KF])

both vector_mem for V1TI and KF are VSX.

So the fix would be to move these two bifs to be under stanza vsx.

[Bug target/109900] _mm256_abs_epi8 is not expanded on gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed as mentioned.

[Bug tree-optimization/107880] bool tautology missed optimisation

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Turns out this was there before but was removed (r7-4801-g0eb078fe20d443e2)
because it caused some issues.
See PR 71762 .

[Bug target/109900] _mm256_abs_epi8 is not expanded on gimple level

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
Fixed for GCC14.

[Bug target/109900] _mm256_abs_epi8 is not expanded on gimple level

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-1145-g1ede03e2d0437ea9c2f7453fcbe263505b4e0def
Author: liuhongt 
Date:   Fri May 19 13:55:50 2023 +0800

Fold _mm{,256,512}_abs_{epi8,epi16,epi32,epi64} into gimple ABS_EXPR.

Also for 64-bit vector abs intrinsics _mm_abs_{pi8,pi16,pi32}.

gcc/ChangeLog:

PR target/109900
* config/i386/i386.cc (ix86_gimple_fold_builtin): Fold
_mm{,256,512}_abs_{epi8,epi16,epi32,epi64} and
_mm_abs_{pi8,pi16,pi32} into gimple ABS_EXPR.
(ix86_masked_all_ones): Handle 64-bit mask.
* config/i386/i386-builtin.def: Replace icode of related
non-mask simd abs builtins with CODE_FOR_nothing.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr109900.c: New test.

[Bug tree-optimization/99997] Missed optimisation with -Os

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

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

--- Comment #5 from Andrew Pinski  ---
I suspect if we do something about:
  # iftmp.0_8 = PHI <0(3), 1(4)>
  _9 = (_Bool) iftmp.0_8;


First things might just work. Let me look into that. Plus there might be an
expand issue ...

[Bug fortran/109948] New: ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 109948
   Summary: ICE(segfault) in gfc_expression_rank() from
gfc_op_rank_conformable()
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Bisected down to recent g:611be07e48956c8b7371eb580eef124990114fd3

$ cat test_associate.f90
subroutine foo(y, x)
implicit none
type tlap
  real,allocatable :: z(:)
end type tlap
type(tlap) :: y
real :: x(:)
associate(z=>y%z)

if (getpid() == 1) then
  where ( z < 0.0 ) x(:) = z(:)
else
  where ( z < 0.0 ) x(:) = z(:)
endif

end associate
end subroutine foo

$ gfortran -O1 -c test_associate.f90
f951: internal compiler error: Segmentation fault
0xd362af crash_signal
/data/g13/gcc/toplev.cc:314
0x2abfcecf ???
   
/tmp/glibc-2.37/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7ca895 gfc_expression_rank(gfc_expr*)
/data/g13/gcc/fortran/resolve.cc:5643
0x7caa44 gfc_op_rank_conformable(gfc_expr*, gfc_expr*)
/data/g13/gcc/fortran/resolve.cc:5676
0x71228c eval_intrinsic
/data/g13/gcc/fortran/arith.cc:1669
0x789edc match_level_4
/data/g13/gcc/fortran/matchexp.cc:646
0x789edc match_and_operand
/data/g13/gcc/fortran/matchexp.cc:693
0x789f66 match_or_operand
/data/g13/gcc/fortran/matchexp.cc:722
0x78a076 match_equiv_operand
/data/g13/gcc/fortran/matchexp.cc:765
0x78a188 match_level_5gfc_op_rank_conformable(
/data/g13/gcc/fortran/matchexp.cc:811
0x7892e4 gfc_match_expr(gfc_expr**)
/data/g13/gcc/fortran/matchexp.cc:870
0x7bf2e0 match_actual_arg
/data/g13/gcc/fortran/primary.cc:1688
0x7c0c88 gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
/data/g13/gcc/fortran/primary.cc:1953
0x7c3455 gfc_match_rvalue(gfc_expr**)
/data/g13/gcc/fortran/primary.cc:3695
0x7894fe match_primary
/data/g13/gcc/fortran/matchexp.cc:157
0x7894fe match_level_1
/data/g13/gcc/fortran/matchexp.cc:211
0x7894fe match_mult_operand
/data/g13/gcc/fortran/matchexp.cc:267
0x7897c8 match_add_operand
/data/g13/gcc/fortran/matchexp.cc:356
0x789a9c match_level_2
/data/g13/gcc/fortran/matchexp.cc:480
0x789c56 match_level_3
/data/g13/gcc/fortran/matchexp.cc:551
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/100864] (a&!b) | b is not opimized to a | b for comparisons

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
The a & !b issue is recorded as PR 106164.

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #7 from Andrew Pinski  ---
The patch which fixes PR 89263 also fixes this one.

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||89263

--- Comment #4 from Andrew Pinski  ---
The patch which fixes this is the same as PR 89263 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263
[Bug 89263] Simplify bool expression to OR

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||89263

--- Comment #6 from Andrew Pinski  ---
The patch simple which fixes PR 89263.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263
[Bug 89263] Simplify bool expression to OR

[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare

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

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

Bug 96923 Summary: Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

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

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

Bug 96923 Summary: Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
Ok, this in the end is a dup of bug 89263.

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

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

Bug 96923 Summary: Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 96923 Summary: Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

--- Comment #7 from Andrew Pinski  ---
*** Bug 96923 has been marked as a duplicate of this bug. ***

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #7 from palmer at gcc dot gnu.org ---
(In reply to Rory Bolt from comment #6)
> Ah... that code makes so much sense now...
> 
> So my original comment about simply using a different constant was too
> simplistic; what is being attempted is to shift the constant 1 into the
> correct byte position since the flag is only a single byte but the atomic
> store is done on a word... so the shift logic will need to be rewritten for
> big endian targets. This also explains the masking of the low order address
> bits...
> 
> Interesting!

That seems likely to be the culprit.  Do you have time to send a patch?

We should probably also poke through the other sub-word patterns and make sure
nothing else got dropped for BE.

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

[rory.bolt at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Rory Bolt  ---
Ah... that code makes so much sense now...

So my original comment about simply using a different constant was too
simplistic; what is being attempted is to shift the constant 1 into the correct
byte position since the flag is only a single byte but the atomic store is done
on a word... so the shift logic will need to be rewritten for big endian
targets. This also explains the masking of the low order address bits...

Interesting!

[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet

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

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

--- Comment #2 from Jonathan Wakely  ---
To be clear, a move-only value type is OK. A move-only error type is not.

[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Martin Seemann from comment #0)
> GCC13 introduce monadic operations for `std::expected`, including r-value
> ref-qualified overloads, which suggests that it should be possible to use an
> expected with a move-only value or error type.

No, see https://cplusplus.github.io/LWG/issue3843

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Patrick O'Neill  ---
I don't have a big-endian environment set up to validate the issue/test a fix
and I likely won't be able to get to this for a while.

The relevant code is here (untouched by the recent patches):
Trunk
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/sync.md;h=9fc626267de3840ce15d196bff72440a980fd234;hb=HEAD#l535

GCC 12
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/sync.md;h=86b41e6b00a9331ed4b46e73cc66c102c6d2d981;hb=2ee5e4300186a92ad73f1a1a64cb918dc76c8d67#l155

The main difference from 12->trunk in this testcase is that AMOOR now uses
.aqrl instead of a fence. That does not affect this testcase, so a fix on trunk
should be applicable to the 12 branch (and vice-versa).

Thanks for the bug report!

[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions

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

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

--- Comment #7 from Matthias Kretz (Vir)  ---
Created attachment 55146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55146=edit
patch that resolves it for me

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Patrick O'Neill  ---
Sorry about the nonsense comment, I clicked enter too early. I'm taking a look
at this.

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com

--- Comment #3 from Patrick O'Neill  ---
The recent patches just copied the libatomic code inline

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #37 from Andrew Macleod  ---
(In reply to CVS Commits from comment #36)

> For the curious, a particular hot spot for IPA in this area was:
> 
> ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
> {
> ...
> ...
>   value_range save (m_vr);
>   m_vr.union_ (*other_vr);
>   return m_vr != save;
> }
> 
> The problem isn't the resizing (since we do that at most once) but the
> fact that for some functions with lots of callers we end up a huge
> range that gets copied and compared for every meet operation.  Maybe
> the IPA algorithm could be adjusted somehow??.

isn't the the same thing as 

  return m_vr.union_ (*other_vr);

which should be much faster without all the copying... ?

[Bug fortran/104350] ICE in gfc_array_dimen_size(): Bad dimension

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 55145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55145=edit
Better patch.

This patch seems to work and regtest ok.

[Bug c/109450] VLA struct definition vs use in the function declaration

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:42d1612eb5c3b2ee327bc3336bfcbc43a0d0fc5b

commit r14-1143-g42d1612eb5c3b2ee327bc3336bfcbc43a0d0fc5b
Author: Martin Uecker 
Date:   Sun May 21 19:32:01 2023 +0200

Fix ICEs related to VM types in C 2/2 [PR109450]

Size expressions were sometimes lost and not gimplified correctly,
leading to ICEs and incorrect evaluation order.  Fix this by 1) not
recursing pointers when gimplifying parameters, which was incorrect
because it might access variables declared later for incomplete
structs, and 2) adding a decl expr for variably-modified arrays
that are pointed to by parameters declared as arrays.

PR c/109450

gcc/
* function.cc (gimplify_parm_type): Remove function.
(gimplify_parameters): Call gimplify_type_sizes.

gcc/c/
* c-decl.cc (add_decl_expr): New function.
(grokdeclarator): Add decl expr for size expression in
types pointed to by parameters declared as arrays.

gcc/testsuite/
* gcc.dg/pr109450-1.c: New test.
* gcc.dg/pr109450-2.c: New test.
* gcc.dg/vla-26.c: New test.

[Bug c/106465] ICE for VLA in struct in parameter of nested function

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r14-1142-gf9b5be322358ee63798e02a9103b6bbe459e7aea
Author: Martin Uecker 
Date:   Thu Apr 13 19:37:12 2023 +0200

Fix ICEs related to VM types in C 1/2 [PR70418, PR107557, PR108423]

Size expressions were sometimes lost and not gimplified correctly, leading
to
ICEs and incorrect evaluation order.  Fix this by 1) not recursing into
pointers when gimplifying parameters in the middle-end (the code is merged
with
gimplify_type_sizes), which is incorrect because it might access variables
declared later for incomplete structs, and 2) tracking size expressions for
struct/union members correctly, 3) emitting code to evaluate size
expressions
for missing cases (nested functions, empty declarations, and
structs/unions).

PR c/70418
PR c/106465
PR c/107557
PR c/108423

gcc/c/
* c-decl.cc (start_decl): Make sure size expression are
evaluated only in correct context.
(grokdeclarator): Size expression in fields may need a bind
expression, make sure DECL_EXPR is always created.
(grokfield, declspecs_add_type): Pass along size expressions.
(finish_struct): Remove unneeded DECL_EXPR.
(start_function): Evaluate size expressions for nested functions.
* c-parser.cc (c_parser_struct_declarations,
c_parser_struct_or_union_specifier): Pass along size expressions.
(c_parser_declaration_or_fndef): Evaluate size expression.
(c_parser_objc_at_property_declaration,
c_parser_objc_class_instance_variables): Adapt.
* c-tree.h (grokfield): Adapt declaration.

gcc/testsuite/
* gcc.dg/nested-vla-1.c: New test.
* gcc.dg/nested-vla-2.c: New test.
* gcc.dg/nested-vla-3.c: New test.
* gcc.dg/pr70418.c: New test.
* gcc.dg/pr106465.c: New test.
* gcc.dg/pr107557-1.c: New test.
* gcc.dg/pr107557-2.c: New test.
* gcc.dg/pr108423-1.c: New test.
* gcc.dg/pr108423-2.c: New test.
* gcc.dg/pr108423-3.c: New test.
* gcc.dg/pr108423-4.c: New test.
* gcc.dg/pr108423-5.c: New test.
* gcc.dg/pr108423-6.c: New test.
* gcc.dg/typename-vla-2.c: New test.
* gcc.dg/typename-vla-3.c: New test.
* gcc.dg/typename-vla-4.c: New test.
* gcc.misc-tests/gcov-pr85350.c: Adapt.

[Bug c/108423] [12/13/14 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r14-1142-gf9b5be322358ee63798e02a9103b6bbe459e7aea
Author: Martin Uecker 
Date:   Thu Apr 13 19:37:12 2023 +0200

Fix ICEs related to VM types in C 1/2 [PR70418, PR107557, PR108423]

Size expressions were sometimes lost and not gimplified correctly, leading
to
ICEs and incorrect evaluation order.  Fix this by 1) not recursing into
pointers when gimplifying parameters in the middle-end (the code is merged
with
gimplify_type_sizes), which is incorrect because it might access variables
declared later for incomplete structs, and 2) tracking size expressions for
struct/union members correctly, 3) emitting code to evaluate size
expressions
for missing cases (nested functions, empty declarations, and
structs/unions).

PR c/70418
PR c/106465
PR c/107557
PR c/108423

gcc/c/
* c-decl.cc (start_decl): Make sure size expression are
evaluated only in correct context.
(grokdeclarator): Size expression in fields may need a bind
expression, make sure DECL_EXPR is always created.
(grokfield, declspecs_add_type): Pass along size expressions.
(finish_struct): Remove unneeded DECL_EXPR.
(start_function): Evaluate size expressions for nested functions.
* c-parser.cc (c_parser_struct_declarations,
c_parser_struct_or_union_specifier): Pass along size expressions.
(c_parser_declaration_or_fndef): Evaluate size expression.
(c_parser_objc_at_property_declaration,
c_parser_objc_class_instance_variables): Adapt.
* c-tree.h (grokfield): Adapt declaration.

gcc/testsuite/
* gcc.dg/nested-vla-1.c: New test.
* gcc.dg/nested-vla-2.c: New test.
* gcc.dg/nested-vla-3.c: New test.
* gcc.dg/pr70418.c: New test.
* gcc.dg/pr106465.c: New test.
* gcc.dg/pr107557-1.c: New test.
* gcc.dg/pr107557-2.c: New test.
* gcc.dg/pr108423-1.c: New test.
* gcc.dg/pr108423-2.c: New test.
* gcc.dg/pr108423-3.c: New test.
* gcc.dg/pr108423-4.c: New test.
* gcc.dg/pr108423-5.c: New test.
* gcc.dg/pr108423-6.c: New test.
* gcc.dg/typename-vla-2.c: New test.
* gcc.dg/typename-vla-3.c: New test.
* gcc.dg/typename-vla-4.c: New test.
* gcc.misc-tests/gcov-pr85350.c: Adapt.

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r14-1142-gf9b5be322358ee63798e02a9103b6bbe459e7aea
Author: Martin Uecker 
Date:   Thu Apr 13 19:37:12 2023 +0200

Fix ICEs related to VM types in C 1/2 [PR70418, PR107557, PR108423]

Size expressions were sometimes lost and not gimplified correctly, leading
to
ICEs and incorrect evaluation order.  Fix this by 1) not recursing into
pointers when gimplifying parameters in the middle-end (the code is merged
with
gimplify_type_sizes), which is incorrect because it might access variables
declared later for incomplete structs, and 2) tracking size expressions for
struct/union members correctly, 3) emitting code to evaluate size
expressions
for missing cases (nested functions, empty declarations, and
structs/unions).

PR c/70418
PR c/106465
PR c/107557
PR c/108423

gcc/c/
* c-decl.cc (start_decl): Make sure size expression are
evaluated only in correct context.
(grokdeclarator): Size expression in fields may need a bind
expression, make sure DECL_EXPR is always created.
(grokfield, declspecs_add_type): Pass along size expressions.
(finish_struct): Remove unneeded DECL_EXPR.
(start_function): Evaluate size expressions for nested functions.
* c-parser.cc (c_parser_struct_declarations,
c_parser_struct_or_union_specifier): Pass along size expressions.
(c_parser_declaration_or_fndef): Evaluate size expression.
(c_parser_objc_at_property_declaration,
c_parser_objc_class_instance_variables): Adapt.
* c-tree.h (grokfield): Adapt declaration.

gcc/testsuite/
* gcc.dg/nested-vla-1.c: New test.
* gcc.dg/nested-vla-2.c: New test.
* gcc.dg/nested-vla-3.c: New test.
* gcc.dg/pr70418.c: New test.
* gcc.dg/pr106465.c: New test.
* gcc.dg/pr107557-1.c: New test.
* gcc.dg/pr107557-2.c: New test.
* gcc.dg/pr108423-1.c: New test.
* gcc.dg/pr108423-2.c: New test.
* gcc.dg/pr108423-3.c: New test.
* gcc.dg/pr108423-4.c: New test.
* gcc.dg/pr108423-5.c: New test.
* gcc.dg/pr108423-6.c: New test.
* gcc.dg/typename-vla-2.c: New test.
* gcc.dg/typename-vla-3.c: New test.
* gcc.dg/typename-vla-4.c: New test.
* gcc.misc-tests/gcov-pr85350.c: Adapt.

[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r14-1142-gf9b5be322358ee63798e02a9103b6bbe459e7aea
Author: Martin Uecker 
Date:   Thu Apr 13 19:37:12 2023 +0200

Fix ICEs related to VM types in C 1/2 [PR70418, PR107557, PR108423]

Size expressions were sometimes lost and not gimplified correctly, leading
to
ICEs and incorrect evaluation order.  Fix this by 1) not recursing into
pointers when gimplifying parameters in the middle-end (the code is merged
with
gimplify_type_sizes), which is incorrect because it might access variables
declared later for incomplete structs, and 2) tracking size expressions for
struct/union members correctly, 3) emitting code to evaluate size
expressions
for missing cases (nested functions, empty declarations, and
structs/unions).

PR c/70418
PR c/106465
PR c/107557
PR c/108423

gcc/c/
* c-decl.cc (start_decl): Make sure size expression are
evaluated only in correct context.
(grokdeclarator): Size expression in fields may need a bind
expression, make sure DECL_EXPR is always created.
(grokfield, declspecs_add_type): Pass along size expressions.
(finish_struct): Remove unneeded DECL_EXPR.
(start_function): Evaluate size expressions for nested functions.
* c-parser.cc (c_parser_struct_declarations,
c_parser_struct_or_union_specifier): Pass along size expressions.
(c_parser_declaration_or_fndef): Evaluate size expression.
(c_parser_objc_at_property_declaration,
c_parser_objc_class_instance_variables): Adapt.
* c-tree.h (grokfield): Adapt declaration.

gcc/testsuite/
* gcc.dg/nested-vla-1.c: New test.
* gcc.dg/nested-vla-2.c: New test.
* gcc.dg/nested-vla-3.c: New test.
* gcc.dg/pr70418.c: New test.
* gcc.dg/pr106465.c: New test.
* gcc.dg/pr107557-1.c: New test.
* gcc.dg/pr107557-2.c: New test.
* gcc.dg/pr108423-1.c: New test.
* gcc.dg/pr108423-2.c: New test.
* gcc.dg/pr108423-3.c: New test.
* gcc.dg/pr108423-4.c: New test.
* gcc.dg/pr108423-5.c: New test.
* gcc.dg/pr108423-6.c: New test.
* gcc.dg/typename-vla-2.c: New test.
* gcc.dg/typename-vla-3.c: New test.
* gcc.dg/typename-vla-4.c: New test.
* gcc.misc-tests/gcov-pr85350.c: Adapt.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #11 from Arthur O'Dwyer  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Arthur O'Dwyer from comment #7)
> > // https://godbolt.org/z/Ea43Y65z4
> > struct Widget {
> > int i = 1;
> ...
> > In this case, Widget has no constructors,
> 
> No, it has a constructor because of the NSDMI. NSDMI causes a non-trivial
> constexpr constructor to be created.

Fair. I meant Widget has no _program-defined_ constructors (such as would have
unknown effects and might invisibly-to-the-compiler escape a copy of ``). I
might still be using the wrong term. But you found a better example without
that wrinkle, anyway. :)

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
The patch in comment 11 is just a related spot improvement.
The PR itself is still unfixed.

[Bug rtl-optimization/109940] [14 Regression] ICE in decide_candidate_validity since g:53dddbfeb213ac4ec39f550aa81eaa4264375d2c

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Guess that makes it mine. :)  It's been a few years since I wrote
this code, but I vaguely remember hitting the problem that the
DF walk orders weren't the “natural” ones, and having to work
around it.

The code iterates backwards over what was the DF_BACKWARD postorder,
which I think was the workaround.  Now that DF_BACKWARD (correctly)
gives an RPO over a backward traversal, and DF_FORWARD is a true
forward RPO, the fix will probably be to switch from using DF_BACKWARD
to DF_FORWARD.

[Bug libstdc++/109947] New: std::expected monadic operations do not support move-only error types yet

[aemseemann at gmail dot com via Gcc-bugs]

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

Bug ID: 109947
   Summary: std::expected monadic operations do not support
move-only error types yet
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aemseemann at gmail dot com
  Target Milestone: ---

GCC13 introduce monadic operations for `std::expected`, including r-value
ref-qualified overloads, which suggests that it should be possible to use an
expected with a move-only value or error type.

However, the following [example](https://godbolt.org/z/aoWeaqoGz) does not
compile due to an attempt to use unique_ptr's the deleted copy constructor:

```cpp
#include 
#include 

int main() 
{   
using expected = std::expected>;

expected e{42};
std::move(e).and_then([](auto&&) -> expected {
return 0;
});

return 0;
}

```

The issue seems to be the use of `std::move(value())` in the &&-qualified
overloads of the monadic operations (e.g.
[here](https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/expected#L880)
which selects the `value() &` overload that in turn attempts a copy of the
error type in the  [exception
path](https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/expected#L740).

When replacing the value access with `std::move(*this).value()` the example
compiles successfully.

[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction

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

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

--- Comment #34 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #33)
> Created attachment 55142 [details]
> Disable dynamic shift instructions patch

First of all, thanks for digging into this.  This issue has been a can of
worms, due to all sorts of reasons.

As you have discovered, some code patterns take the shift instruction route,
which is basically decided earlier by the various middle-end optimizations. 
There have also been some changes to those parts recently, but I haven't been
watching what it does for SH.

> unsigned int f(char v){
> return (v & FLAG) == FLAG;
> }

Bit-tests of char and unsigned char should be covered by the test-suite and
should work -- at least originally.  However, what might be triggering this
problem is the '== FLAG' comparison.  When I was working on this issue I only
used '== 0' or '!= 0' comparison.  I can imagine that your test code triggers
some other middle end optimizations and hence we get this.

Can you try to rewrite your test code to something like this?

unsigned int f(char v){
return (v & FLAG) != 0;
}

... and see if it generates the tst instruction as expected?


> I also compiled my project with '-m2e' and new '-mdisable-dynshift'
> options and tested it in SH-2E mone on Renesas's emulator that comes
> with High-performance Embedded Workshop and all unit tests run as expected.

I'm not sure what the purpose of the '-mdisable-dynshift' option would be here
though.  For '-m2e' TARGET_DYNSHIFT is already 'false'.  So the option seems
misnamed.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[schwab--- via Gcc-bugs]

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

--- Comment #15 from Andreas Schwab  ---
TASK_SIZE is 0xF000UL on m68k.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[userm57 at yahoo dot com via Gcc-bugs]

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

--- Comment #14 from Stan Johnson  ---
I can try to capture the offending "cc1plus" and "as" processes just before the
compilation of gimple-match.cc fails in stage2; the output will look something
like this (for a different cc1plus process number 19431 that is currently
running):

# cat /proc/19431/maps
8000-82027000 r-xp  08:05 1823425   
/var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus
82028000-8202a000 r--p 02028000 08:05 1823425   
/var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus
8202a000-82036000 rw-p 0202a000 08:05 1823425   
/var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus
82036000-8207 rwxp  00:00 0  [heap]
8207-82601000 rwxp  00:00 0  [heap]
c000-c002 r-xp  08:05 1682956/lib/ld.so.1
c002-c0022000 r--p 0002 08:05 1682956/lib/ld.so.1
c0022000-c0023000 rw-p 00022000 08:05 1682956/lib/ld.so.1
c0023000-c0026000 rw-p  00:00 0 
c0028000-c0044000 r-xp  08:05 1515049/usr/lib/libmpc.so.3.3.1
c0044000-c0045000 ---p 0001c000 08:05 1515049/usr/lib/libmpc.so.3.3.1
c0045000-c0046000 r--p 0001b000 08:05 1515049/usr/lib/libmpc.so.3.3.1
c0046000-c0047000 rw-p 0001c000 08:05 1515049/usr/lib/libmpc.so.3.3.1
c0048000-c00b3000 r-xp  08:05 1672972/usr/lib/libmpfr.so.6.2.0
c00b3000-c00b5000 ---p 0006b000 08:05 1672972/usr/lib/libmpfr.so.6.2.0
c00b5000-c00b6000 r--p 0006b000 08:05 1672972/usr/lib/libmpfr.so.6.2.0
c00b6000-c00b7000 rw-p 0006c000 08:05 1672972/usr/lib/libmpfr.so.6.2.0
c00b8000-c0113000 r-xp  08:05 1515186/usr/lib/libgmp.so.10.4.1
c0113000-c0115000 ---p 0005b000 08:05 1515186/usr/lib/libgmp.so.10.4.1
c0115000-c0116000 r--p 0005b000 08:05 1515186/usr/lib/libgmp.so.10.4.1
c0116000-c0117000 rw-p 0005c000 08:05 1515186/usr/lib/libgmp.so.10.4.1
c0118000-c012a000 r-xp  08:05 411479 /lib/libz.so.1.2.13
c012a000-c012b000 ---p 00012000 08:05 411479 /lib/libz.so.1.2.13
c012b000-c012c000 r--p 00011000 08:05 411479 /lib/libz.so.1.2.13
c012c000-c012d000 rw-p 00012000 08:05 411479 /lib/libz.so.1.2.13
c012e000-c0172000 r-xp  08:05 1682625/lib/libm.so.6
c0172000-c0173000 ---p 00044000 08:05 1682625/lib/libm.so.6
c0173000-c0174000 r--p 00043000 08:05 1682625/lib/libm.so.6
c0174000-c0176000 rw-p 00044000 08:05 1682625/lib/libm.so.6
c0176000-c02df000 r-xp  08:05 1682906/lib/libc.so.6
c02df000-c02e ---p 00169000 08:05 1682906/lib/libc.so.6
c02e-c02e2000 r--p 0016a000 08:05 1682906/lib/libc.so.6
c02e2000-c02e6000 rw-p 0016c000 08:05 1682906/lib/libc.so.6
c02e6000-c0ad2000 rw-p  00:00 0 
c0ad5000-c25dd000 rw-p  00:00 0 
ef91f000-ef948000 rw-p  00:00 0  [stack]

> Git checkout master

Thanks, I'll try compiling that version manually and also capture the relevant
/proc output.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
> Am 23.05.2023 um 19:44 schrieb userm57 at yahoo dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
> 
> --- Comment #12 from Stan Johnson  ---
>> That’s indeed unhelpful.  Cat /proc/maps of some executable might help
> 
> Sorry, I don't know how to do that. I don't see /proc/maps.

Try /proc/1/maps

It’s a file in the per process directories

> Regarding downloading mainline gcc-14, it's not at ftp.gnu.org. I tried the
> following, but I must be using the wrong repository. Please advise on where I
> should find gcc-14.
> 
> $ git clone git://gcc.gnu.org/git/gcc.git
> $ cd gcc
> $ git reset --hard
> HEAD is now at 0d2ab259bc5 Improve cost computation for single-bit bit
> insertions.
> $ git checkout releases/gcc-14
> error: pathspec 'releases/gcc-14' did not match any file(s) known to git
> $ git checkout releases/gcc-13
> Already on 'releases/gcc-13'
> Your branch is up to date with 'origin/releases/gcc-13'.
> $ git checkout mainline/gcc-14
> error: pathspec 'mainline/gcc-14' did not match any file(s) known to git

Git checkout master

Should do what I meant

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[adam at wozniakconsulting dot com via Gcc-bugs]

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

--- Comment #26 from Adam Wozniak  ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to Andreas Schwab from comment #10)
> > It is a valid preprocessing token ("non-whitespace character that cannot be
> > one of the above").
> 
> Ah right, yes. It's a preprocessing token, but is never converted to a
> token, so doesn't need to be a keyword, identifier etc.

i feel like it should work for stringification reasons too.  e.g.

#define X(x) #x
const char *letterA = X(A);   // this works
const char *notequal = X(≠);  // this does not

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Arthur O'Dwyer from comment #7)
> But does w go out of the scope at the end of make2? Similar question to make
> in the original testcase, does the temp go out of scope?

For both of these testcases GCC currently warns even:
: In function 'Widget make2()':
:6:35: warning: storing the address of local variable '
w' in 'global' [-Wdangling-pointer=]
6 | Widget make2() { Widget w; global =  return w; }
  |~~~^~~~
:6:1: note: ' w' declared here
6 | Widget make2() { Widget w; global =  return w; }
  | ^~
:5:9: note: 'global' declared here
5 | Widget *global = nullptr;
  | ^~

So Maybe this is undefined code after all.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Arthur O'Dwyer from comment #7)
> > // https://godbolt.org/z/Ea43Y65z4
> > struct Widget {
> > int i = 1;
> ...
> > In this case, Widget has no constructors,
> 
> No, it has a constructor because of the NSDMI . NSDMI causes a non-trival
> constexpr constructor to be created.

Now this version does not:
```
struct Widget {
int i;
int a[4];
};
Widget *global = 0;
Widget make2() { Widget w; w.i = 1; global =  return w; }
void g() { global->i = 42; }
int main() {
  Widget w = make2();
  int i = w.i;
  g();
  return (i == w.i);
// Does this need to be reloaded and
// compared? or is it obviously true?  
}
```

But does w go out of the scope at the end of make2? Similar question to make in
the original testcase, does the temp go out of scope?

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Arthur O'Dwyer from comment #7)
> // https://godbolt.org/z/Ea43Y65z4
> struct Widget {
> int i = 1;
...
> In this case, Widget has no constructors,

No, it has a constructor because of the NSDMI . NSDMI causes a non-trival
constexpr constructor to be created.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #7 from Arthur O'Dwyer  ---
Richard Biener wrote:
> Are we using the wrong check or is escaping 'this'
> for these kind of classes invoking undefined behavior?

Wow, this got a lot of traffic quickly!  Sounds like you (Richard, Andrew) are
on top of the issue here, where a constructor is involved; but once you start
talking about heuristics and checks, I think it would be productive for you two
to make sure you're both on the same page with *this* example:

// https://godbolt.org/z/Ea43Y65z4
struct Widget {
int i = 1;
int a[4];
};
Widget *global = nullptr;
Widget make2() { Widget w; global =  return w; }
void g() { global->i = 42; }
int main() {
  Widget w = make2();
  int i = w.i;
  g();
  return (i == w.i);
// Does this need to be reloaded and
// compared? or is it obviously true?  
}

In this case, Widget has no constructors, and I think it would be perfectly
defensible for the compiler to say that "global = " is not a valid way to
escape the address of that prvalue result (even though copy elision will make
the w in make() and the w in main() the same object). But do both of *you* have
the same answer to that paradox? If you don't, then you might also not agree
about what the appropriate heuristic should be in the original case and might
end up talking past each other.

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #25 from joseph at codesourcery dot com  ---
Older versions of C++ - up to C++20 - would reject such characters (not 
allowed in identifiers based on the list of allowed characters in that 
standard version) even when not converted to a token, because (a) those 
older versions had (as-if) conversion of extended characters to UCNs in 
translation phase 1, and (b) UCNs not permitted in identifiers still 
matched the syntax for identifier preprocessing tokens ("Otherwise, the 
next preprocessing token is the longest sequence of characters that 
matches the syntax of a preprocessing token, even if that would cause 
further lexical analysis to fail") and then violated a semantic rule on 
which UCNs are allowed in identifiers.

C++23 instead converts UCNs to extended characters in phase 3 rather than 
doing the reverse conversion, and has (as of N4944, at least), 
[lex.pptoken], "... single non-whitespace characters that do not lexically 
match the other preprocessing token categories ... If any character not in 
the basic character set matches the last category, the program is 
ill-formed.".  That's part of the description of preprocessing tokens, 
before they get converted to tokens.  I think it has the same effect of 
disallowing the use of such a character (outside contexts such as string 
literals) - even if a different diagnostic might be better.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
> Am 23.05.2023 um 19:28 schrieb userm57 at yahoo dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
> 
> --- Comment #10 from Stan Johnson  ---
>> The question is how much virtual memory is exposed to a user 
>> process, that is - how large is the address space?
> 
> I'm not sure, but I see this:
> 
> $ prlimit
> RESOURCE   DESCRIPTION SOFT  HARD UNITS
> AS address space limitunlimited unlimited bytes

That’s indeed unhelpful.  Cat /proc/maps of some executable might help

> CORE   max core file size 0 unlimited bytes
> CPUCPU time   unlimited unlimited seconds
> DATA   max data size  unlimited unlimited bytes
> FSIZE  max file size  unlimited unlimited bytes
> LOCKS  max number of file locks held  unlimited unlimited locks
> MEMLOCKmax locked-in-memory address space   8388608   8388608 bytes
> MSGQUEUE   max bytes in POSIX mqueues819200819200 bytes
> NICE   max nice prio allowed to raise 0 0 
> NOFILE max number of open files1024  4096 files
> NPROC  max number of processes26236 26236 processes
> RSSmax resident set size  unlimited unlimited bytes
> RTPRIO max real-time priority 0 0 
> RTTIME timeout for real-time tasksunlimited unlimited microsecs
> SIGPENDING max number of pending signals  26236 26236 signals
> STACK  max stack size   8388608 unlimited bytes
> 
> As long as those are also the limits for portage, it should be ok.
> 
>> Note mainline would be gcc 14.0, you can probably download a recent
>> snapshot.
> 
> ok, I've downloaded the latest gcc snapshot using git. I'll try a manual
> bootstrap of that. Do you recommend that I use QEMU m68k (virt) running Debian
> SID or Gentoo, or doesn't it matter?

I don’t think that matters.

[Bug tree-optimization/107004] [12 Regression] GCC12 warning in OOB access: array subscript is partly outside array bounds

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

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

--- Comment #5 from Rogério de Souza Moraes  ---
I tried to apply the patch r13-3596-ge7310e24b1c0ca67, but it has not fixed the
issue. Although, the issue is not reproducible on GCC 13.1.0.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[userm57 at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Stan Johnson  ---
> The question is how much virtual memory is exposed to a user 
> process, that is - how large is the address space?

I'm not sure, but I see this:

$ prlimit
RESOURCE   DESCRIPTION SOFT  HARD UNITS
AS address space limitunlimited unlimited bytes
CORE   max core file size 0 unlimited bytes
CPUCPU time   unlimited unlimited seconds
DATA   max data size  unlimited unlimited bytes
FSIZE  max file size  unlimited unlimited bytes
LOCKS  max number of file locks held  unlimited unlimited locks
MEMLOCKmax locked-in-memory address space   8388608   8388608 bytes
MSGQUEUE   max bytes in POSIX mqueues819200819200 bytes
NICE   max nice prio allowed to raise 0 0 
NOFILE max number of open files1024  4096 files
NPROC  max number of processes26236 26236 processes
RSSmax resident set size  unlimited unlimited bytes
RTPRIO max real-time priority 0 0 
RTTIME timeout for real-time tasksunlimited unlimited microsecs
SIGPENDING max number of pending signals  26236 26236 signals
STACK  max stack size   8388608 unlimited bytes

As long as those are also the limits for portage, it should be ok.

> Note mainline would be gcc 14.0, you can probably download a recent
> snapshot.

ok, I've downloaded the latest gcc snapshot using git. I'll try a manual
bootstrap of that. Do you recommend that I use QEMU m68k (virt) running Debian
SID or Gentoo, or doesn't it matter?

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[adam at wozniakconsulting dot com via Gcc-bugs]

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

--- Comment #24 from Adam Wozniak  ---
(In reply to Jonathan Wakely from comment #23)
> (In reply to Adam Wozniak from comment #20)
> > i get this response:
> > 
> > This page contains the following errors:
> > error on line 20 at column 54: AttValue: " or ' expected
> > Below is a rendering of the page up to the first error.
> 
> That seems to be a problem at your end, the page is well-formed:
> https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Fgit%2Fgitweb.
> cgi%3Fp%3Dgcc.git%3Bh%3D7d112d6670a0e0e662

works now.  did not before.  weird.

[Bug c++/97720] throw in try in noexcept fn calls terminate without handling the exception

[m101010a at gmail dot com via Gcc-bugs]

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

--- Comment #6 from m101010a at gmail dot com ---
> represent the second case in the action table as an empty exception 
> specification like C++98 throw()

That will deal with this issue and PR88218, but won't solve PR55918 since using
throw() causes the stack to unwind.  I don't believe there's a way to solve
PR55918 without modifying the personality function in some way; if terminate is
called in the handler then we're already in phase 2, which means the stack has
already been unwound.

[Bug target/109747] [12/13 Regression] SLP cost of constructors is off

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] SLP   |[12/13 Regression] SLP cost
   |cost of constructors is off |of constructors is off
  Known to work||14.0
   Priority|P3  |P2

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.  Note fixing on the branch(es) will eventually cause more
SLP vectorization which isn't always desired.  So I'm at least waiting for
regressions on trunk because of this.

[Bug target/109747] [12/13/14 Regression] SLP cost of constructors is off

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

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

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

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

commit r14-1139-gb6b8870ec585947a03a797f9037d02380316e235
Author: Richard Biener 
Date:   Tue May 23 15:03:00 2023 +0200

tree-optimization/109747 - SLP cost of CTORs

The x86 backend looks at the SLP node passed to the add_stmt_cost
hook when costing vec_construct, looking for elements that require
a move from a GPR to a vector register and cost that.  But since
vect_prologue_cost_for_slp decomposes the cost for an external
SLP node into individual pieces this cost gets applied N times
without a chance for the backend to know it's just dealing with
a part of the SLP node.  Just looking at a part is also not perfect
since the GPR to XMM move cost applies only once per distinct
element so handling the whole SLP node one more correctly reflects
cost (albeit without considering other external SLP nodes).

The following addresses the issue by passing down the SLP node
only for one piece and nullptr for the rest.  The x86 backend
is currently the only one looking at it.

In the future the cost of external elements is something to deal
with globally but that would require the full SLP tree be available
to costing.

It's difficult to write a testcase, at the tipping point not
vectorizing is better so I'll followup with x86 specific adjustments
and will see to add a testcase later.

PR tree-optimization/109747
* tree-vect-slp.cc (vect_prologue_cost_for_slp): Pass down
the SLP node only once to the cost hook.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 23 May 2023, userm57 at yahoo dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
> 
> --- Comment #8 from Stan Johnson  ---
> > How much virtual memory does the m68k host have?
> 
> Swap space in the m68k virt VM is configurable; I'm using 1 GiB in two 512 MiB
> partitions. I noticed that compilation goes further with two 512 MiB 
> partitions
> that with one 1 GiB partition, even though the second 512 MiB swap partition
> isn't used (see above). And I know I tested 2 GiB swap at one point, and that
> also failed. The virt VM is configured with 3399672K memory.

The question is how much virtual memory is exposed to a user process,
that is - how large is the address space?

> While observing the failure, it appears to happen when the assembler "as"
> becomes more active (so probably when cc1plus is about done). Assembler memory
> increases quickly, and swap space is not really exhausted, despite the error
> message.

That's odd, I never noticed the assembler taking much memory.

> > Can you try current mainline to see if that's enough to pass native 
> > bootstrap in qemu?
> 
> Native (manual) bootstrap of gcc-13.1 in QEMU (virt and q800) failed in 
> Gentoo,
> but the failure was slightly different (it failed in stage 3 instead of stage
> 2). And I used Gentoo's configure options, as documented above. I could try no
> configure options, followed by "make bootstrap"; would that be helpful? If 
> yes,
> should I use Gentoo or Debian SID?

Note mainline would be gcc 14.0, you can probably download a recent
snapshot.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #6 from Andrew Pinski  ---
Note here is a testcase which fails even with C++98 (basically changing the
default assignment in the class to the ctor):
```
struct Widget {
Widget();
int i;
int a[4];
};
Widget *global = 0;
Widget::Widget() : i(1) { global = this; }
Widget make() __attribute__((noinline));
Widget make() { return Widget(); }
void g() { global->i = 42; }
int main() {
  Widget w = make();
  int i = w.i;
  g();
  if (i == w.i) __builtin_abort();
// Does this need to be reloaded and
// compared? or is it obviously true? 
  return 0; 
}
```

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
   Last reconfirmed||2023-05-23
 Ever confirmed|0   |1

--- Comment #5 from Paul Thomas  ---
Created attachment 55144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55144=edit
Fix for this PR

Thanks for reporting this. The patch "fingered" in comment #4 is certainly
responsible for this regression. In particular, it is the first chunk in
resolve.cc that is the culprit.

The attached patch feels to be a bit of sticking plaster on top of sticking
plaster and so I will go back to hunt down the root cause of these
namespace-less symbols.

I fear that you will have to make your procedures impure for the time being or,
if you don't need the added finalization features, revert to a previous version
of gfortran.

Regards and apologies for the inconvenience.

Paul

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #5 from Richard Biener  ---
It seems a copy CTOR or DTOR is required to make it TREE_ADDRESSABLE.  So
adding either

  ~Widget();

or

  Widget(const Widget&);

to the Widget class declaration fixes the testcase.  Are we using the wrong
check or is escaping 'this' for these kind of classes invoking undefined
behavior?

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Known to fail|4.1.2, 4.5.3, 4.7.4, 4.9.0  |

--- Comment #4 from Richard Biener  ---
The testcase is very related to the old PR and shows the issue manifests itself
also for !TYPE_NEEDS_CONSTRUCTING types.

I wonder whether we need a CTOR at all here to show the issue.

I also wonder how we can query whether the type has a CTOR (as opposed to
"needs" one).  The function type is

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x76fdef18
fields 
public abstract external autoinline decl_3 QI t.ii:1:8 align:16
warn_if_not_align:0 context 
full-name "Widget::~Widget() noexcept ()"
not-really-extern chain >
context 
full-name "struct Widget"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  reference_to_this
 chain >

so the type has TYPE_NEEDS_CONSTRUCTING set but it isn't TREE_ADDRESSABLE.

[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support

[ian at airs dot com via Gcc-bugs]

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

--- Comment #9 from Ian Lance Taylor  ---
If you really want to you can port the LoongArch changes back to 1.18.  I don't
think that would be too hard--it's mostly a matter of adding build tags in
various places.  But it's up to you.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #3 from Andrew Pinski  ---
Note to make it fail at -O2 and above is simple just add [[gnu::noipa]] to make
definition like this:
[[gnu::noipa]]
Widget make() { return Widget(); }

[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions

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

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

--- Comment #6 from Christophe Lyon  ---

> trunk or the backport? I tested trunk on gcc185. Will check.

That's on trunk (didn't check on the branch)

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[userm57 at yahoo dot com via Gcc-bugs]

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

--- Comment #8 from Stan Johnson  ---
> How much virtual memory does the m68k host have?

Swap space in the m68k virt VM is configurable; I'm using 1 GiB in two 512 MiB
partitions. I noticed that compilation goes further with two 512 MiB partitions
that with one 1 GiB partition, even though the second 512 MiB swap partition
isn't used (see above). And I know I tested 2 GiB swap at one point, and that
also failed. The virt VM is configured with 3399672K memory.

While observing the failure, it appears to happen when the assembler "as"
becomes more active (so probably when cc1plus is about done). Assembler memory
increases quickly, and swap space is not really exhausted, despite the error
message.

> Can you try current mainline to see if that's enough to pass native 
> bootstrap in qemu?

Native (manual) bootstrap of gcc-13.1 in QEMU (virt and q800) failed in Gentoo,
but the failure was slightly different (it failed in stage 3 instead of stage
2). And I used Gentoo's configure options, as documented above. I could try no
configure options, followed by "make bootstrap"; would that be helpful? If yes,
should I use Gentoo or Debian SID?

[Bug ipa/109886] UBSAN error: shift exponent 64 is too large for 64-bit type when compiling gcc.c-torture/compile/pr96796.c

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

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

--- Comment #5 from Martin Jambor  ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Aldy Hernandez from comment #2)
> > > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > > integer/pointer, but if range_cast is being called on a parm_type of
> > > RECORD_TYPE, someone's trying to cast a structure to an integer.  Is that
> > > the intent here, because that will not work with ranges??
> > 
> > That is correct. The generated code has a VIEW_CONVERT_EXR from an integer
> > type to a RECORD_TYPE.
> 
> Eeeech.  In that case, then what you suggest is reasonable.  Bail if
> param_type is not supported by the underlying range.  Maybe the IPA experts
> could opine?

With LTOed type mismateches or with K style code, IPA has to be prepared to
deal with such cases, unfortunately.  So a check like that indeed looks
reasonable.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

--- Comment #2 from Richard Biener  ---
The fix for PR40389, r0-94078-g4d61856d0a221c, changed this to look at type
addressability (from LHS addressability).

[Bug target/109944] vector CTOR with byte elements and SSE2 has STLF fail

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

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

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

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

commit r14-1137-gf504b70eb0fc1339322960041a85606df4547897
Author: Richard Biener 
Date:   Tue May 23 15:12:33 2023 +0200

Account for vector splat GPR->XMM move cost

The following also accounts for a GPR->XMM move cost for splat
operations and properly guards eliding the cost when moving from
memory only for SSE4.1 or HImode or larger operands.  This
doesn't fix the PR fully yet.

PR target/109944
* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
For vector construction or splats apply GPR->XMM move
costing.  QImode memory can be handled directly only
with SSE4.1 pinsrb.

[Bug tree-optimization/108752] word_mode vectorization is pessimized by hard limit on nunits

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

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

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

https://gcc.gnu.org/g:9d5034aad9868bed45472ef5bfac22dd9ac0e0cb

commit r14-1136-g9d5034aad9868bed45472ef5bfac22dd9ac0e0cb
Author: Richard Biener 
Date:   Tue May 23 15:58:52 2023 +0200

Generic vector op costing adjustment

This is a small adjustment to the work done for PR108752 and
better reflects the cost of the generated sequence.

PR tree-optimization/108752
* tree-vect-stmts.cc (vectorizable_operation): For bit
operations with generic word_mode vectors do not cost
an extra stmt.  For plus, minus and negate also cost the
constant materialization.

[Bug tree-optimization/109945] Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
   Last reconfirmed||2023-05-23
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Version|unknown |14.0

--- Comment #1 from Richard Biener  ---
ESCAPED, points-to vars: { }

intD.9 mainD.2827 ()
{
  intD.9 w$iD.2845;
  intD.9 iD.2831;
  struct WidgetD.2773 wD.2829;
  intD.9 _1; 
  boolD.2740 _2;
  intD.9 _7; 

   :
  # USE = nonlocal  
  # CLB = nonlocal escaped
  wD.2829 = makeD.2813 (); [return slot optimization]
  w$i_9 = wD.2829.iD.2778;
  i_5 = w$i_9;
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  gD.2825 ();
  _1 = w$i_9;
  _2 = _1 == i_5;
  _7 = (intD.9) _2;
  wD.2829 ={v} {CLOBBER(eol)};
  return _7;

}

so indeed GCC points-to doesn't consider

  wD.2829 = makeD.2813 (); [return slot optimization]

as escape point for the return.  We have

  /* And if we applied NRV the address of the return slot escapes as well.  */
  if (gimple_call_return_slot_opt_p (stmt)
  && gimple_call_lhs (stmt) != NULL_TREE
  && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (stmt
{

but in this case the type is not TREE_ADDRESSABLE.  I'm not sure why this
check is here.  Removing it fixes the issue.  A !is_gimple_reg (lhs)
check may be a substitute in case we can get stale return-slot-opt flags?

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

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

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Adam Wozniak from comment #20)
> i get this response:
> 
> This page contains the following errors:
> error on line 20 at column 54: AttValue: " or ' expected
> Below is a rendering of the page up to the first error.

That seems to be a problem at your end, the page is well-formed:
https://validator.w3.org/nu/?doc=https%3A%2F%2Fgcc.gnu.org%2Fgit%2Fgitweb.cgi%3Fp%3Dgcc.git%3Bh%3D7d112d6670a0e0e662

[Bug tree-optimization/109943] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-6834-g41ade3399bd

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |13.2
 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Without looking in detail if it now fails to undo a propagation that might now
confuse ranger.

[Bug rtl-optimization/109940] [14 Regression] ICE in decide_candidate_validity since g:53dddbfeb213ac4ec39f550aa81eaa4264375d2c

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
If that makes a difference then it should be because the compute_rd () dataflow
computes something different.  The CFG is quite regular as well so I guess we
now hit a latent issue present before but not exposed with the other iteration
order (but the dataflow solution shouldn't depend on the iteration order).

Somebody familiar with the pass needs to sit down and analyze what goes wrong.

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[adam at wozniakconsulting dot com via Gcc-bugs]

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

--- Comment #22 from Adam Wozniak  ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to Andreas Schwab from comment #10)
> > It is a valid preprocessing token ("non-whitespace character that cannot be
> > one of the above").
> 
> Ah right, yes. It's a preprocessing token, but is never converted to a
> token, so doesn't need to be a keyword, identifier etc.

Correct.

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[adam at wozniakconsulting dot com via Gcc-bugs]

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

--- Comment #21 from Adam Wozniak  ---
(In reply to Andrew Pinski from comment #16)
> It is funny arguing with folks who write parts of GCC on an idea of
> integrated vs seperate preprocessor really.

yeah, i've been pounding out C since the late 80s, my dinosaur is probably
showing.  they'll probably call me in 2038 like they called the old COBOL
programmers for Y2K.

it's weird to me to think of them not separately.  i've even used the C
preprocessor in contexts unrelated to parsing C code.

it's also weird to see someone who thinks of the C preprocessor only in terms
of its service to the compiler.

whatever, that's drifting off topic.

main point for me was, i don't see any other reason to disallow these unicode
chars other than "the spec says so".  i don't see any HARM in allowing them,
and i certainly see use cases where there is BENEFIT to allowing them.

not all macro args get turned into C++ identifiers.  some get thrown away. 
some get stringified.  in the particular case where i tripped over this, they
get thrown away, and i have ANOTHER postprocessing step that picks them up and
does other magic stuff with them.

also, there's probably a really good case for allowing some of these things,
like emoji, actually be allowed as C++ identifiers.

[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions

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

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

--- Comment #5 from Matthias Kretz (Vir)  ---
Th(In reply to Christophe Lyon from comment #4)
> The new testcase fails on arm and aarch64.

trunk or the backport? I tested trunk on gcc185. Will check.

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

[adam at wozniakconsulting dot com via Gcc-bugs]

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

--- Comment #20 from Adam Wozniak  ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Adam Wozniak from comment #13)
> > (In reply to Jakub Jelinek from comment #11)
> > > Bisection points to r10-3309-g7d112d6670a0e0e662
> > 
> > that link gives me an error
> 
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7d112d6670a0e0e662
> 
> Does that link work?

i get this response:

This page contains the following errors:
error on line 20 at column 54: AttValue: " or ' expected
Below is a rendering of the page up to the first error.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||schwab at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
How much virtual memory does the m68k host have?  Is it possible to extend that
to 2GB?  ISTR that linux on 32bit platforms had a 1GB userland virtual memory
setup at some point (and maybe for some platforms).

In theory it's possible to backport the split of the gimple-match.cc TUs.  Can
you try current mainline to see if that's enough to pass native bootstrap in
qemu?

[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
The new testcase fails on arm and aarch64.

For instance on arm, the log shows:

/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:45: error:
non-constant condition for static assertion
/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:46: error:
non-constant condition for static assertion
/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:56: error:
non-constant condition for static assertion
/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:56: error:
'constexpr _Tp std::experimental::parallelism_v2::hmin(const simd<_Tp, _Ap>&)
[with _Tp = char; _Abi = simd_abi::_VecBuiltin<16>]' called in a constant
expression
/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:57: error:
non-constant condition for static assertion
/libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:57: error:
'constexpr _Tp std::experimental::parallelism_v2::hmax(const simd<_Tp, _Ap>&)
[with _Tp = char; _Abi = simd_abi::_VecBuiltin<16>]' called in a constant
expression

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

[userm57 at yahoo dot com via Gcc-bugs]

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

--- Comment #6 from Stan Johnson  ---
Thanks, let me know if you need me to check anything here.

The problem has existed since at least gcc-12. Initially I thought the QEMU
q800 VM had run out of memory, but switching to a virt VM with ~3 GB memory and
1 GiB swap also failed. Further checking showed that the virt VM was not
actually out of memory (unless I wasn't able to monitor memory changes quickly
enough looking at /proc/swaps and /proc/meminfo every minute).

[Bug c++/109946] New: linker error undefined reference to `vtable for std::bad_expected_access'

[saifi.khan at nishan dot io via Gcc-bugs]

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

Bug ID: 109946
   Summary: linker error undefined reference to `vtable for
std::bad_expected_access'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saifi.khan at nishan dot io
  Target Milestone: ---

Environment: Archlinux kernel 6.3.2 glibc 2.37 gcc 13.1 gcc 14.0.0

Consider the following code

import "iostream";
import "string";
import "string_view";
import "expected";
import "charconv";
import "system_error";

namespace parser {

enum class error {
  input_invalid
  , overflow
};

auto logic (std::string_view str) -> std::expected  {
  int value {0};

  std::from_chars_result result { std::from_chars (str.begin (), str.end
(), value) };

  if (result.ec == std::errc{}) {
return value;
  }
  else if (result.ec == std::errc::invalid_argument) {
return std::unexpected {error::input_invalid};
  }
  else if (result.ec == std::errc::result_out_of_range) {
return std::unexpected {error::overflow};
  }
}

}

auto test () -> void {
  std::string str { "9876dairy" };

  const auto result { parser::logic (str) };

  if (result.has_value ()) {
std::cout << result.value ()
  << '\n';
  }
  else if (result.error () == parser::error::input_invalid) {
std::cout << "E: input invalid"
  << '\n';
  }
  else if (result.error () == parser::error::overflow) {
std::cout << "overflow"
  << '\n';
  }
  else {
std::cout << "unexpected"
  << '\n';
  }
}

The code compiles and program work fine with

- gcc 13.1.1
- gcc 14.0.0

as long as i don't use the option -fmodules-ts.

When using the -fmodules-ts flag, the following linker error is seen:

/usr/bin/ld: /tmp/cchUGnbx.o: warning: relocation against
`_ZTVSt19bad_expected_accessIvE' in read-only section
`.text._ZNSt19bad_expected_accessIvED2Ev[_ZNSt19bad_expected_accessIvED5Ev]'
/usr/bin/ld: /tmp/cchUGnbx.o: in function
`std::bad_expected_access::bad_expected_access()':
/opt/gcc/include/c++/14.0.0/expected:80: undefined reference to `vtable for
std::bad_expected_access'
/usr/bin/ld: /tmp/cchUGnbx.o: in function
`std::bad_expected_access::~bad_expected_access()':
/opt/gcc/include/c++/14.0.0/expected:85: undefined reference to `vtable for
std::bad_expected_access'
/usr/bin/ld:
/tmp/cchUGnbx.o:(.data.rel.ro._ZTISt19bad_expected_accessIN6parser5errorEE[_ZTISt19bad_expected_accessIN6parser5errorEE]+0x10):
undefined reference to `typeinfo for std::bad_expected_access'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status

[Bug testsuite/98874] PowerPC test gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses wrong dg-options

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #2 from Peter Bergner  ---
This looks to be fixed since:

commit c1b1c4e58bda152ae932b45396ab67b07dd8c3fe
Author: Jonathan Wakely 
AuthorDate: Wed Jul 6 19:11:05 2022 +0100
Commit: Jonathan Wakely 
CommitDate: Thu Jul 7 10:29:37 2022 +0100

testsuite: Fix incorrect -mfloat128-type option

[Bug c++/109945] New: Escape analysis hates copy elision: different result with -O1 vs -O2

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

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

Bug ID: 109945
   Summary: Escape analysis hates copy elision: different result
with -O1 vs -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Background:
https://quuxplusone.github.io/blog/2021/03/07/copy-elision-borks-escape-analysis/
The background paradox here is, "When class Widget is subject to copy elision,
then any unseen function can return a prvalue Widget whose address has already
escaped!" Aaron Puchert and I were discussing this, with examples. (He thinks
the resolution of the paradox is "you *must* treat a lot more things as
escaped"; I think an acceptable resolution would be "you may treat copy-elision
itself as a magic that invalidates pointers and references even though the
object is still in the same place.")
But then I came up with an example that didn't rely on copy elision at all. We
both agree this code is perfectly well-defined — yet GCC miscompiles it at -O1!

// https://godbolt.org/z/bTnv68nhG
struct Widget {
Widget();
int i = 1;
int a[4];
};
Widget *global = nullptr;
Widget::Widget() { global = this; }
Widget make() { return Widget(); }
void g() { global->i = 42; }
int main() {
  Widget w = make();
  int i = w.i;
  g();
  return (i == w.i);
// Does this need to be reloaded and
// compared? or is it obviously true?  
}

gcc -O0 and gcc -O2 both correctly return 0 from main.
gcc -O1 wrongly returns 1 from main.

*At least* since C++17, I think the -O1 result is flat-out wrong codegen. We
have `global == `, and so the call to `g()` can definitely modify `w.i`.

(Clang always treats Widgets' addresses as escaped, no matter what Widget looks
like. MSVC's escape analysis is more complicated and I have not yet been able
to trick it into wrong codegen.)

[Bug target/109944] New: vector CTOR with byte elements and SSE2 has STLF fail

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

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

Bug ID: 109944
   Summary: vector CTOR with byte elements and SSE2 has STLF fail
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I've experimented with CTORs from smaller elements and byte handling with
plain SSE2 is quite bad (for word we have pinsrw).

void foo(char *a, char *m, char d, char e)
{
  char b = *m;
  char c = m[2];
  a[0] = b;
  a[1] = c;
  a[2] = d;
  a[3] = e;
  a[4] = b;
  a[5] = c;
  a[6] = b;
  a[7] = c;
  a[8] = b;
  a[9] = c;
  a[10] = b;
  a[11] = c;
  a[12] = b;
  a[13] = c;
  a[14] = b;
  a[15] = c;
}

generates

movzbl  2(%rsi), %r8d
movl%edx, %r9d
movzbl  (%rsi), %edx
movzbl  %cl, %ecx
movzbl  %r9b, %r9d
movq%r8, %rax
salq$8, %rax
orq %rdx, %rax
salq$8, %rax
orq %r8, %rax
salq$8, %rax
orq %rdx, %rax
salq$8, %rax
orq %rax, %rcx
orq %r8, %rax
salq$8, %rcx
salq$8, %rax
orq %r9, %rcx
orq %rdx, %rax
salq$8, %rcx
salq$8, %rax
orq %r8, %rcx
orq %r8, %rax
salq$8, %rcx
salq$8, %rax
orq %rdx, %rcx
orq %rdx, %rax
movq%rcx, -24(%rsp)
movq%rax, -16(%rsp)
movdqa  -24(%rsp), %xmm0
movups  %xmm0, (%rdi)

while we can handle a splat from QImode via

movzbl  (%rsi), %eax
movd%eax, %xmm0
punpcklbw   %xmm0, %xmm0
punpcklwd   %xmm0, %xmm0
pshufd  $0, %xmm0, %xmm0
movups  %xmm0, (%rdi)

I think we can go and for a generic V16QImode CTOR and SSE2 create two
V8HImode vectors using pinsrw, for the first from zero-extended QImode
values of the even elements and for the second from zero-extended and
left-shifted values of the odd elements and then IOR the two vectors.

Alternatively the above needs to be pessimized better in the cost model.

Btw, for HImode elements I see we do

movzwl  (%rsi), %eax
movd%eax, %xmm0
movdqa  %xmm0, %xmm1
movdqa  %xmm0, %xmm2
pinsrw  $1, 4(%rsi), %xmm1
...

not sure why we don't do

pxor %xmm1, %xmm1
pinsrw  $0, (%rsi), %xmm1

and thus avoid the round-trip through the GPR for the initial element?

[Bug libstdc++/60441] Incorrect textual representation for std::mersenne_twister_engine

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

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

--- Comment #2 from Jonathan Wakely  ---
Ignore that, it doesn't work. Due to the way we've implemented the mersenne
twister state, we really do need to remember how much of the state has been
used already, which is why we serialize the _M_p index into the textual
representation.

[Bug c++/109942] Function template declared extern is implicitly instantiated on -O optimization level when return type is auto

[simon-pfahler at gmx dot de via Gcc-bugs]

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

Simon Pfahler  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Simon Pfahler  ---
I see your point, and have realized that there is no way around explicitly
stating the return types. That was wishful thinking on my part.

Still, I feel like the behavior should be identical for any optimization level,
but this is more personal opinion and of little relevance for
standard-compliance.

Marked this issue as resolved, since even if it is a bug (as you said,
debatable), it certainly isn't a relevant one.

[Bug c++/109942] Function template declared extern is implicitly instantiated on -O optimization level when return type is auto

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

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

--- Comment #2 from Jonathan Wakely  ---
You can add [[gnu::noinline]] to the function template if you really want to
prevent  it from being inlined, but it won't prevent it being instantiated.

[Bug libstdc++/109941] [feat req] Add an option to mark STL types as nodiscard

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Roy Jacobson  ---
The linked bug is about nodiscard applied to the class together with ignoring
temporary objects. But GCC will when the type is the return value or when the
nodiscard is applied to the constructor:

class [[nodiscard]] err {};
err f();

void g() {
f(); // Warning emitted
}

struct RAII {
[[nodiscard]] RAII(int x);
};

void h() {
RAII(0); // Warning emitted
}

[Bug c++/109942] Function template declared extern is implicitly instantiated on -O optimization level when return type is auto

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

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

--- Comment #1 from Jonathan Wakely  ---
I think it's debatable whether GCC's behaviour is incorrect. The definition of
the function template can be seen, and no explicit specialization has been
declared for foo, so the compiler is allowed to inline the definition.

It *has* to instantiate it the definition, to determine the return type. Since
it has to instantiate it anyway, it might as well inline it as well.

So even if this failed to link, you wouldn't get faster compile times because
the definition must be instantiated anyway.

[Bug tree-optimization/109943] New: [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-6834-g41ade3399bd

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

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

Bug ID: 109943
   Summary: [13/14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since
r13-6834-g41ade3399bd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

void foo(void);
static int b = 5;
static int *c = 
static char(a)(char d, char g) {
;
return d % g;
}
static void e(unsigned char d, unsigned g) {
char h = a(g, d);
if (h)
if ((d) >= 0) {
foo();
};
}
static void f(int d) { e(b, d); }
int main() {
f(*c);
*c = 0;
}

gcc-trunk -O3 generates:

main:
movl$0, b(%rip)
xorl%eax, %eax
ret

However, including additional info via __builtin_unreachable results to worse
code:

void foo(void);
static int b = 5;
static int *c = 
static char(a)(char d, char g) {
if ((g) <= 0) {
__builtin_unreachable();
}
return d % g;
}
static void e(unsigned char d, unsigned g) {
char h = a(g, d);
if (h)
if ((d) >= 0) {
foo();
};
}
static void f(int d) { e(b, d); }
int main() {
f(*c);
*c = 0;
}

gcc-trunk (and 13) -O3 generates:

main:
movlb(%rip), %ecx
movsbl  %cl, %eax
movzbl  %cl, %ecx
cltd
idivl   %ecx
testl   %edx, %edx
jne .L11
movl$0, b(%rip)
xorl%eax, %eax
ret
.L11:
pushq   %rax
callfoo
xorl%edx, %edx
xorl%eax, %eax
movl%edx, b(%rip)
popq%rcx
ret

https://godbolt.org/z/n34Tsr3vq

gcc-12 can generate optimized code for both cases

Started with r13-6834-g41ade3399bd

[Bug libstdc++/109941] [feat req] Add an option to mark STL types as nodiscard

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/109941] [feat req] Add an option to mark STL types as nodiscard

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||85973

--- Comment #3 from Jonathan Wakely  ---
That doesn't currently work with GCC, so there's not much point doing it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
[Bug 85973] [[nodiscard]] on class shall emit a warning for unused anonymous
variable

[Bug testsuite/101528] [11 regression] gcc.target/powerpc/int_128bit-runnable.c fails after r11-8743

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #8 from Peter Bergner  ---
(In reply to Carl Love from comment #7)
> I believe this bugzilla is ready to close.

Marking as fixed.  Thanks Carl.

[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems

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

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

--- Comment #11 from Peter Bergner  ---
Mike, can we marked this as FIXED now?  ...or are there other changes needed?

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #5 from Aldy Hernandez  ---
fixed.  Thanks for reporting.

[Bug tree-optimization/109934] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r14-1133-g8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Author: Aldy Hernandez 
Date:   Tue May 23 12:34:45 2023 +0200

Remove buggy special case in irange::invert [PR109934].

This patch removes a buggy special case in irange::invert which seems
to have been broken for a while, and probably never triggered because
the legacy code was handled elsewhere, and the non-legacy code was
using an int_range_max of int_range<255> which made it extremely
likely for num_ranges == 255.  However, with auto-resizing ranges,
int_range_max will start off at 3 and can hit this bogus code in the
unswitching code.

PR tree-optimization/109934

gcc/ChangeLog:

* value-range.cc (irange::invert): Remove buggy special case.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr109934.c: New test.

[Bug target/108724] [11 Regression] Poor codegen when summing two arrays without AVX or SSE

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

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

--- Comment #10 from Richard Biener  ---
On trunk we're back to vectorizing but as intended with DImode which makes us
save half of the loads and stores and we think the extended required arithmetic
covers up for that (by quite some margin).

movabsq $9223372034707292159, %rcx
movq(%rdx), %rax
movq(%rsi), %rsi
movq%rcx, %rdx
andq%rax, %rdx
andq%rsi, %rcx
xorq%rsi, %rax
addq%rcx, %rdx
movabsq $-9223372034707292160, %rcx
andq%rcx, %rax
xorq%rdx, %rax
movq%rax, (%rdi)

vs

movl(%rdx), %eax
addl(%rsi), %eax
movl%eax, (%rdi)
movl4(%rdx), %eax
addl4(%rsi), %eax
movl%eax, 4(%rdi)

[Bug libstdc++/109941] [feat req] Add an option to mark STL types as nodiscard

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Roy Jacobson  ---
Right, libc++ do that as well since 2019 -
https://reviews.llvm.org/D65900?id=213975.

Although with the RAII classes I think you need to [[nodiscard]] the
constructor which I think (?) is a compiler extension. And you're also much
less likely to have false positives with that so you can actually do that
unconditionally :)

[Bug c++/109942] New: Function template declared extern is implicitly instantiated on -O optimization level when return type is auto

[simon-pfahler at gmx dot de via Gcc-bugs]

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

Bug ID: 109942
   Summary: Function template declared extern is implicitly
instantiated on -O optimization level when return type
is auto
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon-pfahler at gmx dot de
  Target Milestone: ---

Created attachment 55143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55143=edit
preprocessed *.ii file

Declaring a template function as extern, but not providing a definition should
lead to a linker error. This does not work on higher optimization levels, if
the template function's return type is `auto`.

The code is:

```
template
auto foo() { return; }

extern template auto foo();

int main() { foo(); }
```

This fails to link when the command line is `g++ test.cpp`, as it should. But
for `g++ -O test.cpp`, the compilation and linkage works. Explicitly stating
the return type (replacing `auto` by `void`) leads to correct behavior (linker
failure on any optimization level).

Similar examples can be constructed where compilation with optimizatio <=-O1
leads to expected failure, while compilation is successfull for optimization
>=-O2.

This is problematic when return types can not easily be determined and
explicitly stated.
The bug leads to unwanted instantiation of the template, which means longer
compile time if a definition would be provided in a different compilation unit.

Additional info:
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

Complete command line:
`g++ test.cpp` or `g++ -O test.cpp`

Compiler output message for `g++ test.cpp`:
/usr/bin/ld: /tmp/ccBQx0I3.o: in function `main':
test.cpp:(.text+0x5): undefined reference to `auto foo()'
collect2: error: ld returned 1 exit status

Compiler output message for `g++ -O test.cpp`:
Nothing, as compilation is successful.

Preprocessed file (*.ii) is attached.

Let me know if there is information missing.