[Bug target/111949] New: combine split points are not so good with targets that have (and (not x) y)

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

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

Bug ID: 111949
   Summary: combine split points are not so good with targets that
have (and (not x) y)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
bool f1(int a, bool b)
{
int c = a & b;
return (c ^ a)&1;
}
```
Currently GCC produces:
```
and w1, w1, 255
bic w0, w0, w1
and w0, w0, 1
```

Notice how there are 2 and.

If we look at combine dumps we will see:
Trying 3, 8 -> 10:
3: r98:SI=zero_extend(x1:QI)
  REG_DEAD x1:QI
8: r101:SI=~r98:SI&r103:SI
  REG_DEAD r98:SI
  REG_DEAD r103:SI
   10: r102:SI=r101:SI&0x1
  REG_DEAD r101:SI
Failed to match this instruction:
(set (reg:SI 102)
(and:SI (and:SI (not:SI (reg:SI 1 x1 [ b ]))
(reg:SI 103))
(const_int 1 [0x1])))
Successfully matched this instruction:
(set (reg:SI 101)
(not:SI (reg:SI 1 x1 [ b ])))
Failed to match this instruction:
(set (reg:SI 102)
(and:SI (and:SI (reg:SI 101)
(reg:SI 103))
(const_int 1 [0x1])))

The first part is good but the second part is not so good and shows that
combine not finding a good split point and using:
(and:SI (not:SI (reg:SI 1 x1 [ b ])) (reg:SI 103))
as the point how to split the above instruction.

(note I don't know if this should be a generic change or a target specific one
off hand, just filing it to keep track of what missed optimization I found).

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

Dimitar Dimitrov  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #9 from Dimitar Dimitrov  ---
Confirmed it is fixed.

[Bug libstdc++/111948] subrange modifies a const size object

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
This is the cause:

  constexpr
  subrange(__detail::__convertible_to_non_slicing<_It> auto __i, _Sent __s,
   __size_type __n)
  noexcept(is_nothrow_constructible_v<_It, decltype(__i)>
   && is_nothrow_constructible_v<_Sent, _Sent&>)
requires (_Kind == subrange_kind::sized)
  : _M_begin(std::move(__i)), _M_end(__s)
  {
if constexpr (_S_store_size)
  _M_size._M_size = __n;
  }

_M_size._M_size in the function body is already const.

[Bug libstdc++/111948] New: subrange modifies a const size object

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 111948
   Summary: subrange modifies a const size object
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/Gf4zWP3qT

testcase:

#include 

constexpr auto r = std::ranges::subrange(std::views::iota(0), 5);
static_assert(std::ranges::distance(r));

[Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

[mxlol233 at outlook dot com via Gcc-bugs]

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

--- Comment #3 from Xiao Ma  ---
Created attachment 56185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56185&action=edit
a patch on releases/gcc-13 to reproduce the bug.

steps:
1. git clone -b releases/gcc-13 https://github.com/gcc-mirror/gcc.git
2. cd gcc
3. #apply this patch
4. mkdir .build_accel && cd .build_accel && ../configure --target=rvgpu-none
--enable-languages=c --enable-as-accelerator-for=x86_64-pc-linux-gnu && make
all-gcc -j16
5. cd ../
6. mkdir .build_host && cd .build_host && ../configure --enable-languages=c
--enable-offload-targets=rvgpu-none=`pwd`/../../.install/rvgpu-none/ && make
all-gcc -j16
7. cd ../ && mkdir .tmp && cd .tmp
8. # touch a file:

```
/* { dg-do run } */


int
main (void)
{
  int i2, l = 0, r = 0, l2 = 0;
  int a[3][3][3];


  #pragma acc parallel
  #pragma acc loop collapse(4 - 1)
for (int i = 0; i < 2; i++)
  for (int j = 0; j < 2; j++)
for (int k = 0; k < 2; k++)
  a[i][j][k] = i + j * 4 + k * 16;
#pragma acc parallel
{
  #pragma acc loop collapse(2) reduction(|:l)
for (i2 = 0; i2 < 2; i2++)
  for (int j = 0; j < 2; j++)
for (int k = 0; k < 2; k++)
  if (a[i2][j][k] != i2 + j * 4 + k * 16)
l += 1;
}

  /*  Test loop with >= condition.  */
#pragma acc parallel
{
  #pragma acc loop collapse(2) reduction(|:l2)
for (i2 = 0; i2 < 2; i2++)
  for (int j = 1; j >= 0; j--)
for (int k = 0; k < 2; k++)
  if (a[i2][j][k] != i2 + j * 4 + k * 16)
l2 += 1;
}

for (i2 = 0; i2 < 2; i2++)
  for (int j = 0; j < 2; j++)
for (int k = 0; k < 2; k++)
  if (a[i2][j][k] != i2 + j * 4 + k * 16)
r += 1;


  return 0;
}


```
9. ../.build_host/gcc/cc1 -fopenacc  -quiet  -o a.s a.c
# you will see the log like this:
```NUM_POLY_INT_COEFFS=1
```
10. as --64 -o a.o a.s

11. ../.build_accel/gcc/lto1 -quiet  -o a.o.s a.o   
# you will see the log like this:
```
NUM_POLY_INT_COEFFS=2
‘
Segmentation fault
0xbf3e83 crash_signal
../../gcc/toplev.cc:314
0x7f92986f608f ???
   
/build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f929883b6e5 ???
../sysdeps/x86_64/multiarch/strlen-avx2.S:65
0x1773512 pp_quoted_string
../../gcc/pretty-print.cc:1845
0x177435a pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1359
0x176495f diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1592
0x1765149 diagnostic_impl
../../gcc/diagnostic.cc:1756
0x1767236 fatal_error(unsigned int, char const*, ...)
../../gcc/diagnostic.cc:2141
0xa90e11 lto_input_mode_table(lto_file_decl_data*)
../../gcc/lto-streamer-in.cc:2103
0x748626 lto_file_finalize
../../gcc/lto/lto-common.cc:2275
0x748626 lto_create_files_from_ids
../../gcc/lto/lto-common.cc:2298
0x748626 lto_file_read
../../gcc/lto/lto-common.cc:2353
0x748626 read_cgraph_and_symbols(unsigned int, char const**)
../../gcc/lto/lto-common.cc:2801
0x735356 lto_main()
../../gcc/lto/lto.cc:654
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 target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

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

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

--- Comment #5 from Andrew Pinski  ---
Really I wished the -fstack-protector changes were NOT backported since it was
not a regression and not a security issue (according to GCC's own security
policy).

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Keywords||ice-on-valid-code
   Last reconfirmed||2023-10-24
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
(In reply to Gianfranco from comment #3)
> Hello, after syncing gcc-13 with last fixes, the bug still occurs

Can you attach the preprocessed source?

[Bug ipa/111573] lambda functions often not inlined and optimized out

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/111828] rs6000: Parse inline asm string to figure out it requires HTM feature or not.

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

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

--- Comment #9 from Kewen Lin  ---
Peter had a check on gnu assembler (Thanks!) and found that even with -mpower10
specified it's still able to assemble HTM insns, so it means that for some
callee with power8 attributed has HTM inline asm, it can be successfully
compiled when it's inlined to a caller with power10 attributed (at least gnu
assembler involved). It sounds weird and unexpected that power10 attributed
function calls one power8 attributed function which has HTM insns, but it would
only break during runtime when running on Power10 (weird but safe if no power10
insns are exploited and run on power8 or power9 machine), so the point here is
to avoid inconsistent behaviors before and after inlining.

As Peter suggested, I think it's a good idea to make the inlining aggressive on
inline asm when the involved assembler can support that, but considering that
gcc configuration support --with-as and it's possible to have an assembler
which doesn't support HTM insns at power10 (like in future gnu assembler
changes its behavior if users complains, or other assembler alternatives decide
not to support it to avoid confusion etc.), it seems that we should also check
the given assembler's behavior at configuration?

[Bug target/111725] Missed one vsetivli insn

[lehua.ding at rivai dot ai via Gcc-bugs]

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

--- Comment #2 from Lehua Ding  ---
Confirmed fix.

[Bug target/111926] RISC-V: Use vsetvl insn replace csrr vlenb insn

[lehua.ding at rivai dot ai via Gcc-bugs]

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

--- Comment #3 from Lehua Ding  ---
(In reply to Kito Cheng from comment #1)
> Plz leave an option to let user has choice, performance things is hard to
> saw which is absolutely better for all uarch, my thought is leaving an
> option and let mtune and a command line option to control that.

Understood, I'll put the possible optimisation points I came across here. How
to do it is like you said still under consideration.

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #31 from Kewen Lin  ---
Thanks for the explanation from both of you!

(In reply to Richard Biener from comment #30)
> Created attachment 56175 [details]
> prototype patch

I confirmed that this fix can make test case (#c9 + #c10) and its reduced case
pass, but the original test case (#c1) can't pass with this, it can't pass with
-fstack-reuse=none + -fno-strict-aliasing + -O2 either, I think the original
case still suffers another latent bug.

[Bug target/111874] Missed mask_fold_left_plus with AVX512

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
> For the case of conditional (or loop masked) fold-left reductions the scalar
> fallback isn't implemented.  But AVX512 has vpcompress that could be used
> to implement a more efficient sequence for a masked fold-left, possibly
> using a loop and population count of the mask.
There's extra kmov + vpcompress + popcnt, I'm afraid the performance could be 
 worse than the scalar version.

[Bug target/111947] RISC-V vector: RTL Check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:7b2984ad76cac67b962eeb39eab62b6dacf7845e

commit r14-4876-g7b2984ad76cac67b962eeb39eab62b6dacf7845e
Author: Juzhe-Zhong 
Date:   Tue Oct 24 10:12:49 2023 +0800

RISC-V: Fix ICE of RTL CHECK on VSETVL PASS[PR111947]

ICE on vsetvli a5, 8 instruction demand info.

The AVL is const_int 8 which ICE on RENGO caller.

Committed as it is obvious fix.

PR target/111947

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc
(pre_vsetvl::compute_lcm_local_properties): Add REGNO check.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/pr111947.c: New test.

[Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

[mxlol233 at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Xiao Ma  ---
(In reply to Thomas Schwinge from comment #1)
> Created attachment 56178 [details]
> 0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch
> 
> (In reply to Xiao Ma from comment #0)

> I'm not sure about your initial analysis; I'm not familiar with the
> code/changes you cite.
> 
> However, please try building with the attached
> '0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch'.  If that triggers,
> we've (likely...) found (one of) your issue(s).

Thanks for your advice, I will check this out, and attach a patch to show how
to reproduce it, under the upstream gcc.

[Bug c++/111785] [modules] ICE when compiling fmt lib as module

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to Luis Caro Campos from comment #2)
> Thanks Patrick for looking into this. I think your message got cut off?
> 
> I've removed the calls to the GCC optimize pragmas, and still get an ICE:
> 
> src/fmt.cc:71:8: internal compiler error: in insert, at cp/module.cc:4920
>71 | export module fmt;
>   |^
> 0x9a371f trees_out::insert(tree_node*, walk_kind)
> ../../gcc/cp/module.cc:4920
> 0x9a6e37 trees_out::decl_node(tree_nod
> 
> 
> This time the error references a different line of the same module.cc file,
> in case that is relevant.

Hopefully this ICE is gone after the PR105322 fix r14-4806?

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

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

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

Bug 105322 Summary: [modules] ICE with constexpr object of local class type 
from another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105322

   What|Removed |Added

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

[Bug c++/105322] [modules] ICE with constexpr object of local class type from another function

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
.

[Bug c++/105322] [modules] ICE with constexpr object of local class type from another function

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|13.3|14.0

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

[Bug preprocessor/36887] Please report #pragma GCC poison" location

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #6 from Lewis Hyatt  ---
Added for GCC 14.

[Bug preprocessor/36887] Please report #pragma GCC poison" location

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

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

commit r14-4874-gcb05acdcea298b62e7fb00dcc153f5d506d085fe
Author: Lewis Hyatt 
Date:   Thu Sep 7 17:02:47 2023 -0400

libcpp: Improve the diagnostic for poisoned identifiers [PR36887]

The PR requests an enhancement to the diagnostic issued for the use of a
poisoned identifier. Currently, we show the location of the usage, but not
the location which requested the poisoning, which would be helpful for the
user if the decision to poison an identifier was made externally, such as
in a library header.

In order to output this information, we need to remember a location_t for
each identifier that has been poisoned, and that data needs to be preserved
as well in a PCH. One option would be to add a field to struct
cpp_hashnode,
but there is no convenient place to add it without increasing the size of
the struct for all identifiers. Given this facility will be needed rarely,
it seemed better to add a second hash map, which is handled PCH-wise the
same as the current one in gcc/stringpool.cc. This hash map associates a
new
struct cpp_hashnode_extra with each identifier that needs one. Currently
that struct only contains the new location_t, but it could be extended in
the future if there is other ancillary data that may be convenient to put
there for other purposes.

libcpp/ChangeLog:

PR preprocessor/36887
* directives.cc (do_pragma_poison): Store in the extra hash map the
location from which an identifier has been poisoned.
* lex.cc (identifier_diagnostics_on_lex): When issuing a diagnostic
for the use of a poisoned identifier, also add a note indicating
the
location from which it was poisoned.
* identifiers.cc (alloc_node): Convert to template function.
(_cpp_init_hashtable): Handle the new extra hash map.
(_cpp_destroy_hashtable): Likewise.
* include/cpplib.h (struct cpp_hashnode_extra): New struct.
(cpp_create_reader): Update prototype to...
* init.cc (cpp_create_reader): ...accept an argument for the extra
hash table and pass it to _cpp_init_hashtable.
* include/symtab.h (ht_lookup): New overload for convenience.
* internal.h (struct cpp_reader): Add EXTRA_HASH_TABLE member.
(_cpp_init_hashtable): Adjust prototype.

gcc/c-family/ChangeLog:

PR preprocessor/36887
* c-opts.cc (c_common_init_options): Pass new extra hash map
argument to cpp_create_reader().

gcc/ChangeLog:

PR preprocessor/36887
* toplev.h (ident_hash_extra): Declare...
* stringpool.cc (ident_hash_extra): ...this new global variable.
(init_stringpool): Handle ident_hash_extra as well as ident_hash.
(ggc_mark_stringpool): Likewise.
(ggc_purge_stringpool): Likewise.
(struct string_pool_data_extra): New struct.
(spd2): New GC root variable.
(gt_pch_save_stringpool): Use spd2 to handle ident_hash_extra,
analogous to how spd is used to handle ident_hash.
(gt_pch_restore_stringpool): Likewise.

gcc/testsuite/ChangeLog:

PR preprocessor/36887
* c-c++-common/cpp/diagnostic-poison.c: New test.
* g++.dg/pch/pr36887.C: New test.
* g++.dg/pch/pr36887.Hs: New test.

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-October
   ||/634018.html
   Keywords||patch

--- Comment #6 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634018.html

[Bug target/111947] RISC-V vector: RTL Check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Testcase output on r14-4873-g02aa322c8c:
> ./riscv64-unknown-linux-gnu-gcc red.c -S -o test.S -O2
red.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
2 | b() {
  | ^
during RTL pass: vsetvl
red.c: In function 'b':
red.c:10:1: internal compiler error: RTL check: expected code 'reg', have
'const_int' in rhs_regno, at rtl.h:1934
   10 | }
  | ^
0x961683 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
../../../gcc/gcc/rtl.cc:770
0x99934c rhs_regno(rtx_def const*)
../../../gcc/gcc/rtl.h:1934
0x999dec rhs_regno(rtx_def const*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2628
0x999dec pre_vsetvl::compute_lcm_local_properties()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2695
0x1734a89 pre_vsetvl::earliest_fuse_vsetvl_info()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2885
0x1735e29 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3524
0x17361b7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3571
0x17361b7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3554
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/111944] Spurious '' is used uninitialized in Boost.Variant2 (-Wuninitialized -Og)

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

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

--- Comment #3 from Andrew Pinski  ---
The IR definitely says it is unitialized:
  union variant_storage_impl D.73643;

   :
  boost::variant2::detail::variant_storage_impl, boost::variant2::detail::none, boost::variant2::monostate,
int>::variant_storage_impl<1> (&D.73643, D.77838);

[Bug target/111947] New: RISC-V vector: RTL Check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 111947
   Summary: RISC-V vector: RTL Check: expected code 'reg', have
'const_int' in rhs_regno, at rtl.h:1934
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56184&action=edit
-freport-bug output

Ran into an ICE with glibc with rtl checking enabled.

Bisected to/caused by commit: r14-4773-g29331e72d0c

during RTL pass: vsetvl
inet_ntop.c: In function 'inet_ntop':
inet_ntop.c:65:1: internal compiler error: RTL check: expected code 'reg', have
'const_int' in rhs_regno, at rtl.h:1934
   65 | }
  | ^
0x961683 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
../../../gcc/gcc/rtl.cc:770
0x99934c rhs_regno(rtx_def const*)
../../../gcc/gcc/rtl.h:1934
0x999dec rhs_regno(rtx_def const*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2628
0x999dec pre_vsetvl::compute_lcm_local_properties()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2695
0x1734a89 pre_vsetvl::earliest_fuse_vsetvl_info()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2885
0x1735e29 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3524
0x17361b7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3571
0x17361b7 pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3554

Reduced testcase from a glibc build failure:

char *a;
b() {
  int c[2];
  int d = 0;
  for (; d < 16; d += 2)
c[d / 2] = a[d | 1];
  if (c[0])
for (;;)
  ;
}

[Bug tree-optimization/111944] Spurious '' is used uninitialized in Boost.Variant2 (-Wuninitialized -Og)

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Spurious '' is   |Spurious '' is
   |used uninitialized in   |used uninitialized in
   |Boost.Variant2  |Boost.Variant2
   |(-Wuninitialized|(-Wuninitialized -Og)
   |-Og/-fsanitize=address) |

--- Comment #2 from Andrew Pinski  ---
Well for fsanitize=address we document:

> Note that sanitizers tend to increase the rate of false positive warnings, 
> most notably those around -Wmaybe-uninitialized. We recommend against 
> combining -Werror and [the use of] sanitizers.

[Bug c++/111890] ICE in tsubst_friend_function with friend function declared inside a concept constrainted class inside a template class

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #5 from Sam James  ---
10.5, tip of 11/12/13, trunk are all bad

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions since r12-5301-g0

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

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

--- Comment #3 from Sam James  ---
bisect says

045206450386bcd774db3bde0c696828402361c6 is the first bad commit
commit 045206450386bcd774db3bde0c696828402361c6
Author: Richard Biener 
Date:   Fri Nov 12 10:21:22 2021 +0100

tree-optimization/102880 - improve CD-DCE

i.e. r12-5301-g045206450386bc

[Bug target/111941] RISC-V ICE: in merge, at config/riscv/riscv-vsetvl.cc:1996

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Patrick O'Neill  ---
Confirmed to be fixed on r14-4873-g02aa322c8cf.

[Bug objc/111946] bogus cast increases required alignment for a simple class

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

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

--- Comment #1 from Andrew Pinski  ---
>I don't see an immediate pattern here


The pattern is strict alignment vs non-strict alignment targets.

[Bug objc/111946] New: bogus cast increases required alignment for a simple class

[rm at gnu dot org via Gcc-bugs]

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

Bug ID: 111946
   Summary: bogus cast increases required alignment for a simple
class
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rm at gnu dot org
  Target Milestone: ---

Created attachment 56183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56183&action=edit
super-trivial class

In the GNUstep project I noticed that I got very often a "warning: cast
increases required alignment of target type [-Wcast-align]" in most files, but
didn't see it always. The classes look fine. I tracked it down to be an
architecture problem. It does not happen e.g. on x86 and amd64, but happens on
sparc64, mips32-le. It happens since many GCC version and it is still present
in 13.2

At the time of writing, I could quickly reproduce it on 7.5.0, 10.2.1 and
13.2.0.

The problem can be reduced to an as trivial class like the attached file. On
more current compiler versions an issue about no root class found is issued,
but in practice this is not the case, we usually use the NSObject root class,
this is just the most minimal trivial example.
Since it happens even with old gcc versions and continues to, I could test on a
variety of platforms.

Compilation command:
gcc Polygon.m -c -Wcast-align

To sum up:

x86   (32bit LE) : NO
amd64 (64bit LE) : NO
MIPS  (32bit LE) : YES
sparc (32bit BE) : YES
sparc (64bit BE) : YES
PPC   (32bit BE) : NO

I don't see an immediate pattern here

[Bug fortran/30409] [fortran] missed optimization with pure function arguments

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

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

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> (In reply to kargl from comment #10)
> > (In reply to anlauf from comment #8)
> 
> > which is equivalent to 
> > 
> >tmp = 1 / y
> >do i = 1, n
> >   ... = expression1(..., tmp)
> >end do
> 
> No.  Strictly speaking, it is only equivalent to:
> 
> if (n > 0) tmp = 1 / y
> do i = 1, n
>... = expression1(..., tmp)
> end do

Ah, yes, I missed the possibility that the loop may not loop at all.

[Bug ada/111945] Attribute Image for Unbounded_String raises UTF_ENCODING.ENCODING_ERROR

[alexandre.dauquier at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Alexandre Dauquier  ---
Created attachment 56182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56182&action=edit
GPR build

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Intel rejects the code with:

pr104625.f90(10): error #8247: Selector in SELECT TYPE statements must be
polymorphic value.
select type (z => (y))
^

However, NAG thinks the code is actually valid.  And from reading the
standard, I do not immediately see that the parentheses should be a problem:

F2023 has:

C1162 (R1155) If selector is not a named variable, associate-name => shall
appear.

C1164 (R1155) The selector in a select-type-stmt shall be polymorphic.

F2018 has the same wording (slight shift in actual number of constraint).


For this reason changing to ice-on-valid.

[Bug ada/111945] New: Attribute Image for Unbounded_String raises UTF_ENCODING.ENCODING_ERROR

[alexandre.dauquier at gmail dot com via Gcc-bugs]

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

Bug ID: 111945
   Summary: Attribute Image for Unbounded_String raises
UTF_ENCODING.ENCODING_ERROR
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexandre.dauquier at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56181&action=edit
Minimum working example

The following code is failing with Gnat 12.2.0. It passes with 13.2.0 though
(so it might already be known ? But I have not found it).

Note, I have picked Characters.Latin_1.Reserved_128 on purpose.

```ada
-- File 'print_non_graphic_character.adb'
with Ada.Characters.Latin_1;
with Ada.Text_IO;
with Ada.Strings.Unbounded;

procedure Print_Non_Graphic_Character is
   Text_String : constant String := "Non Graphic Character: " &
Ada.Characters.Latin_1.Reserved_128;
   Text_Unbounded_String : constant Ada.Strings.Unbounded.Unbounded_String :=
  Ada.Strings.Unbounded.To_Unbounded_String (Text_String);
begin
   Ada.Text_IO.Put_Line (Text_String);
   Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.To_String
(Text_Unbounded_String));
   Ada.Text_IO.Put_Line (Text_Unbounded_String'Image);
end Print_Non_Graphic_Character;
```

Note that it also fails with:

```ada
Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.Unbounded_String'Image
(Text_Unbounded_String));
```

```
-- File 'print_non_graphic_character.gpr'
project Print_Non_Graphic_Character is
   for Main use ("print_non_graphic_character.adb");
   for Object_Dir use ".objs";

   package Compiler is
  -- "-Og" -- Optimize for debug
  -- "-g" -- Generate debug info
  for Default_Switches ("Ada") use ("-g", "-gnat2020", "-Og");
   end Compiler;

   package Binder is
  for Switches ("Ada") use ("-Es"); --  Symbolic traceback
   end Binder;
end Print_Non_Graphic_Character;
```

Cmdline: `gprbuild -p -gnatef print_non_graphic_character.gpr`

Output:
```stdout
Non Graphic Character: �
Non Graphic Character: �

raised ADA.STRINGS.UTF_ENCODING.ENCODING_ERROR : bad input at Item (25)
[./non_graphic_character/.objs/print_non_graphic_character]
0x40e8fb Ada.Strings.Utf_Encoding.Raise_Encoding_Error at a-stuten.adb:126
0x40f38b Ada.Strings.Utf_Encoding.Strings.Decode at a-suenst.adb:163
0x4049a8 Print_Non_Graphic_Character at print_non_graphic_character.adb:13
0x404efa Main at b__print_non_graphic_character.adb:279
[/lib/x86_64-linux-gnu/libc.so.6]
0x7f5e62118d08
[./non_graphic_character/.objs/print_non_graphic_character]
0x404658 _start at ???
0xfffe
```

Output with Gnat 13.2.0 (though I didn't expect the quotation marks):
```stdout
Non Graphic Character: �
Non Graphic Character: �
"Non Graphic Character: �"
"Non Graphic Character: �"
```

Environnement of the bug (with Gnat 12.2.0):

```
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/dalex78/bin/gnat_native/12.2.1_11f3b811/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure
--prefix=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gcc/install
--with-build-time-tools=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/binutils/install/bin
--enable-languages=c,ada,c++ --enable-libstdcxx --enable-libstdcxx-threads
--enable-libada --disable-nls --without-libiconv-prefix --disable-libstdcxx-pch
--enable-lto --disable-multilib --enable-threads=posix --with-gnu-ld
--with-gnu-as
--with-mpfr=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpfr/install
--with-gmp=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/gmp/install
--with-mpc=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/mpc/install
--with-isl=/home/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-linux/isl/install
--build=x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)
```

[Bug target/106807] RISC-V: libatomic routines are infinate loops

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com

--- Comment #4 from Patrick O'Neill  ---
Now that the inline subword atomics patch has landed/been backported for GCC 13
can we safely close this issue?

https://inbox.sourceware.org/gcc-patches/20230426170129.1076929-1-patr...@rivosinc.com/

[Bug target/100265] [RISCV] Use proper fences for atomic load/store

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

 CC||patrick at rivosinc dot com

--- Comment #2 from Patrick O'Neill  ---
I believe this issue should be resolved now that the atomics fixes from a few
months ago have landed/the atomics mappings are defined in the RISC-V PSABI
doc.
https://inbox.sourceware.org/gcc-patches/20230427162301.1151333-1-patr...@rivosinc.com/

Also backported for GCC 13.3
https://inbox.sourceware.org/gcc-patches/20230725180206.284777-1-patr...@rivosinc.com/

Thanks!

[Bug rtl-optimization/111822] [12/13/14 Regression] during RTL pass: lr_shrinkage ICE: in operator[], at vec.h:910 with -O2 -m32 -flive-range-shrinkage -fno-dce -fnon-call-exceptions

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
I was confused at first while just checking the range because 10 has a
different ICE:

$ g++-10 /tmp/foo.cxx -o /tmp/foo -c -O2 -m32 -flive-range-shrinkage -fno-dce
-fnon-call-exceptions
during RTL pass: lr_shrinkage
/tmp/foo.cxx: In member function 'void SQVM::CallNative()':
/tmp/foo.cxx:41:1: internal compiler error: Segmentation fault
   41 | }
  | ^
0xc86baf crash_signal
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/toplev.c:328
0x84d9a6 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool)
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/cfganal.c:1036
0x84db87 pre_and_rev_post_order_compute(int*, int*, bool)
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/cfganal.c:1049
0x81c940 init_alias_analysis()
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/alias.c:3391
0x14d9f91 sched_init()
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/haifa-sched.c:7326
0x14e4ebd haifa_sched_init()
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/haifa-sched.c:7363
0xc3e02b schedule_insns()
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/sched-rgn.c:3514
0xc3e6db schedule_insns()
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/sched-rgn.c:3508
0xc3e6db rest_of_handle_live_range_shrinkage
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/sched-rgn.c:3710
0xc3e6db execute
/usr/src/debug/sys-devel/gcc-10.5.0/gcc-10.5.0/gcc/sched-rgn.c:3797
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Anyway, bisecting.

[Bug c++/111944] Spurious '' is used uninitialized in Boost.Variant2 (-Wuninitialized -Og)

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #1 from Ed Catmur  ---
Correction, it does affect sanitizers (-O2 -fsanitize=address) as well as -Og.

[Bug c++/111944] New: Spurious '' is used uninitialized in Boost.Variant2 (-Wuninitialized -Og)

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 111944
   Summary: Spurious '' is used uninitialized in
Boost.Variant2 (-Wuninitialized -Og)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Since 12.1, with Boost 1.71 or later,

#include 
int main() {
boost::variant2::variant r;
r.emplace();
}

In member function 'constexpr void
boost::variant2::detail::variant_storage_impl, T1, T ...>::emplace_impl(boost::mp11::mp_true,
boost::mp11::mp_size_t, A&& ...) [with long unsigned int I = 1; A = {}; T1 =
boost::variant2::detail::none; T = {boost::variant2::monostate, int}]',
inlined from 'constexpr void
boost::variant2::detail::variant_storage_impl, T1, T ...>::emplace(boost::mp11::mp_size_t, A&& ...) [with long
unsigned int I = 1; A = {}; T1 = boost::variant2::detail::none; T =
{boost::variant2::monostate, int}]' at boost/variant2/variant.hpp:705:27,
inlined from 'constexpr void
boost::variant2::detail::variant_base_impl::emplace_impl(boost::mp11::mp_true, A&& ...) [with long unsigned int J =
1; U = boost::variant2::monostate; A = {}; T = {boost::variant2::monostate,
int}]' at boost/variant2/variant.hpp:902:20,
inlined from 'constexpr void
boost::variant2::detail::variant_base_impl::emplace(A&& ...)
[with long unsigned int I = 0; A = {}; T = {boost::variant2::monostate, int}]'
at boost/variant2/variant.hpp:921:33,
inlined from 'constexpr U& boost::variant2::variant::emplace(A&& ...)
[with U = boost::variant2::monostate; A = {}; E = void; T =
{boost::variant2::monostate, int}]' at boost/variant2/variant.hpp:1690:49:
boost/variant2/variant.hpp:696:9: warning: '' is used uninitialized
[-Wuninitialized]
  696 | *this = variant_storage_impl( mp11::mp_size_t(),
std::forward(a)... );
  | ^
boost/variant2/variant.hpp: In member function 'constexpr U&
boost::variant2::variant::emplace(A&& ...) [with U =
boost::variant2::monostate; A = {}; E = void; T = {boost::variant2::monostate,
int}]':
boost/variant2/variant.hpp:696:17: note: '' declared here
  696 | *this = variant_storage_impl( mp11::mp_size_t(),
std::forward(a)... );
  |
^~~

Boost.Variant2 has a suppression at this line for Wmaybe-uninitialized
referencing asan, (a) this isn't with sanitizer, and (b) it's Wuninitialized.
This only appears to affect -Og, though, so fairly minor.

[Bug c++/111895] error: invalid operands of types 'unsigned char:2' and 'int' to binary 'operator!=' on enum class bitfield cast to bool

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
A better fix would be to use convert_bitfield_to_declared_type I reckon.

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

--- Comment #5 from Andrew Pinski  ---
Another testcase:
```
int f(unsigned int x, unsigned int y)
{
  int t = __builtin_popcount (x&y);
  int t1 = __builtin_popcount (x|y);
  return t + t1;
}
```

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #4 from Andrew Pinski  ---
So this was introduced with r14-674-g5fdcfe3c5776 .

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
I have a fix.

Basically the pattern:
```
/* popcount(X&Y) + popcount(X|Y) is popcount(x) + popcount(Y).  */
(simplify
  (plus:c (POPCOUNT:s (bit_and:s @0 @1)) (POPCOUNT:s (bit_ior:cs @0 @1)))
  (plus (POPCOUNT @0) (POPCOUNT @1)))
```

Needs a small help with the type that popcount returns. So:
```
/* popcount(X&Y) + popcount(X|Y) is popcount(x) + popcount(Y).  */
(simplify
  (plus:c (POPCOUNT:s (bit_and:s @0 @1)) (POPCOUNT:s (bit_ior:cs @0 @1)))
  (plus (POPCOUNT:type @0) (POPCOUNT:type @1)))
```

[Bug fortran/30409] [fortran] missed optimization with pure function arguments

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> (In reply to anlauf from comment #8)
> I'm not sure what you are worried about here.  If one has
> 
>do i = 1, n
>   ... = expression1(..., 1/y)
>end do
> 
> then this is equivalent to
> 
>do i = 1, n
>   tmp = 1 / y
>   ... = expression1(..., tmp)
>end do

OK so far.

> which is equivalent to 
> 
>tmp = 1 / y
>do i = 1, n
>   ... = expression1(..., tmp)
>end do

No.  Strictly speaking, it is only equivalent to:

if (n > 0) tmp = 1 / y
do i = 1, n
   ... = expression1(..., tmp)
end do

[Bug fortran/30409] [fortran] missed optimization with pure function arguments

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

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #8)
> The suggested optimization needs to take into account that the evaluation
> of the temporary expression might trap, or that allocatable variables are
> not allocated, etc.
> 
> The trap etc. would not occur if the trip count of the loop is zero for the
> non-hoisted variant, so we need to make sure not to generate failing code
> for the hoisted one.
> 
> Similarly, for conditional code in the loop body, like
> 
>   if (cond) then
>  expression1 (..., 1/y)
>   else
>  expression2 (..., 1/z)
>   end if
> 
> where cond protects from traps even for finite trip counts, these conditions
> may also need to be identified, and an appropriate block generated.

I'm not sure what you are worried about here.  If one has

   do i = 1, n
  ... = expression1(..., 1/y)
   end do

then this is equivalent to

   do i = 1, n
  tmp = 1 / y
  ... = expression1(..., tmp)
   end do

which is equivalent to 

   tmp = 1 / y
   do i = 1, n
  ... = expression1(..., tmp)
   end do

I suppose I could do something exceedingly stupid such as

   function expression1(..., xxx)
  common /foo/y
  y = 0
  ...
   end

but this would then lead to invalid Fortran when i = 2 in the
above initial loops as (1/y) is invalid Fortran if y = 0.

[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
The coarray cases in comment#2 will be rejected with:

diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 1cc65d7fa49..08081dacde4 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -8967,6 +8967,9 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses
*omp_clauses,
   else if (omp_clauses->detach->symtree->n.sym->attr.dimension > 0)
gfc_error ("The event handle at %L must not be an array element",
   &omp_clauses->detach->where);
+  else if (omp_clauses->detach->symtree->n.sym->attr.codimension)
+   gfc_error ("The event handle at %L must not be a coarray",
+  &omp_clauses->detach->where);
   else if (omp_clauses->detach->symtree->n.sym->ts.type == BT_DERIVED
   || omp_clauses->detach->symtree->n.sym->ts.type == BT_CLASS)
gfc_error ("The event handle at %L must not be part of "


I assume that these are not allowed.

[Bug tree-optimization/111913] [14 Regression] ICE with __builtin_popcount(X) + __builtin_popcount(Y) simplification

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

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

--- Comment #2 from Andrew Pinski  ---
Works at r14-673 but fails at r14-1170.

[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||12.1.0
  Known to fail||11.4.0
 Status|NEW |WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
This PR appears fixed.  Can it be closed?  Or is there anything left?

[Bug tree-optimization/111943] New: ICE in gimple_split_edge, at tree-cfg.cc:3019 on 20050510-1.c with new -fharden-control-flow-redundancy

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 111943
   Summary: ICE in gimple_split_edge, at tree-cfg.cc:3019 on
20050510-1.c with new -fharden-control-flow-redundancy
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

Following testcase causes ICE with new -fharden-control-flow-redundancy

$ cat 20050510-1.c
/* { dg-require-effective-target indirect_jumps } */
/* { dg-require-effective-target label_values } */

void bar (int k)
{
  void *label = (k) ? &&x : &&y;
  if (k)
goto *label;

x:
  if (k)
dont_remove ();
y:
  return;
}



$ gcc 20050510-1.c -fharden-control-flow-redundancy
--param=max-jump-thread-duplication-stmts=0 -Ofast
20050510-1.c: In function ‘bar’:
20050510-1.c:12:5: warning: implicit declaration of function ‘dont_remove’
[-Wimplicit-function-declaration]
   12 | dont_remove ();
  | ^~~
during GIMPLE pass: hardcfr
20050510-1.c:4:6: internal compiler error: in gimple_split_edge, at
tree-cfg.cc:3019
4 | void bar (int k)
  |  ^~~
0x7f2c1b gimple_split_edge
/home/mjires/git/GCC/master/gcc/tree-cfg.cc:3019
0xad6acb split_edge(edge_def*)
/home/mjires/git/GCC/master/gcc/cfghooks.cc:670
0xc83916 gimple_find_edge_insert_loc
/home/mjires/git/GCC/master/gcc/gimple-iterator.cc:829
0xc8457b gsi_insert_seq_on_edge_immediate(edge_def*, gimple*)
/home/mjires/git/GCC/master/gcc/gimple-iterator.cc:873
0x1d5468e rt_bb_visited::insert_exit_check_on_edge(gimple*, edge_def*)
/home/mjires/git/GCC/master/gcc/gimple-harden-control-flow.cc:706
0x1d5468e rt_bb_visited::check(auto_vec&, int, auto_sbitmap
const&)
/home/mjires/git/GCC/master/gcc/gimple-harden-control-flow.cc:807
0x1d530b6 execute
/home/mjires/git/GCC/master/gcc/gimple-harden-control-flow.cc:1476
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/mjires/checks/master/bin/gcc
COLLECT_LTO_WRAPPER=/home/mjires/checks/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/checks/master
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231023 (experimental) (GCC)

[Bug rtl-optimization/111942] New: ICE in rtl_split_edge, at cfgrtl.cc:1943 on pr98096.c with new -fharden-control-flow-redundancy

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 111942
   Summary: ICE in rtl_split_edge, at cfgrtl.cc:1943 on pr98096.c
with new -fharden-control-flow-redundancy
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

Following testcase causes ICE with new -fharden-control-flow-redundancy

$ cat pr98096.c
/* Test for correct naming of label operands in asm goto in case of presence of
   input/output operands. */
/* { dg-do compile { target lra } } */
int i, j;
int f(void) {
  asm goto ("# %0 %2" : "+r" (i) ::: jmp);
  i += 2;
  asm goto ("# %0 %1 %l[jmp]" : "+r" (i), "+r" (j) ::: jmp);
 jmp: return i;
}



$ gcc pr98096.c -fharden-control-flow-redundancy -fnon-call-exceptions
during RTL pass: expand
pr98096.c: In function ‘f’:
pr98096.c:10:1: internal compiler error: in rtl_split_edge, at cfgrtl.cc:1943
   10 | }
  | ^
0x755d25 rtl_split_edge
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:1943
0xad6acb split_edge(edge_def*)
/home/mjires/git/GCC/master/gcc/cfghooks.cc:670
0xaec884 commit_one_edge_insertion(edge_def*)
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2058
0xaf14e1 commit_edge_insertions()
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2127
0xad2a1d execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6906
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/mjires/checks/master/bin/gcc
COLLECT_LTO_WRAPPER=/home/mjires/checks/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/checks/master
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231023 (experimental) (GCC)

[Bug middle-end/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

--- Comment #7 from Sam James  ---
tip of 12/13/14 all work with -fno-tree-dse, 11 fails the same as before

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049 since r14-4793-gdad311874ac3b3

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[14 Regression] in  |[14 Regression] in
   |decompose, at   |decompose, at
   |wide-int.h:1049 |wide-int.h:1049 since
   ||r14-4793-gdad311874ac3b3

--- Comment #8 from Sam James  ---
dad311874ac3b3cf4eca1c04f67cae80c953f7b8 is the first bad commit
commit dad311874ac3b3cf4eca1c04f67cae80c953f7b8
Author: Patrick Palka 
Date:   Fri Oct 20 10:45:00 2023 -0400

c++: remove NON_DEPENDENT_EXPR, part 1

i.e. r14-4793-gdad311874ac3b3

[Bug target/111867] aarch64: Wrong code for bf16 literal load when the arch support +fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
I will handle this next week (after I start my new job).

[Bug target/111941] New: RISC-V ICE: in merge, at config/riscv/riscv-vsetvl.cc:1996

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 111941
   Summary: RISC-V ICE: in merge, at
config/riscv/riscv-vsetvl.cc:1996
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56180&action=edit
-freport-bug output

First bad commit: r14-4773-g29331e72d0c
Confirmed to still be present on trunk: r14-4809-g55731b59e60

Building newlib 4.1.0 fails on ldtoa.c

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/ldtoa.c;h=1cc97151afb693b04c864243a4466038b06ac94f;hb=415fdd4279b85eeec9d54775ce13c5c412451e08

creduce'd testcase:

./bin/riscv64-unknown-elf-gcc -fno-builtin -O2 -march=rv64gv_zbb -mabi=lp64d -S
-o test.S red.c
./bin/riscv64-unknown-elf-gcc -fno-builtin -O2 -march=rv32gv_zbb -mabi=ilp32d
-S -o test.S red.c

> cat red.c
typedef struct {
  short a[0]
} b;
c;
d[];
b e;
*f;
j() {
  short *g = d;
  int h;
  unsigned short i;
  for (; h < 10; h++)
i |= *f++;
  if (i)
i = 1;
  h = 0;
  for (; h < 10; h++)
g[h] = e.a[h];
  c = i;
}

[Bug middle-end/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Sam James from comment #5)
> the bisect indicates r12-248-gb58dc0b803057c was the fix:

Maybe it still fails with -fno-tree-dse but then again it might depend on dse
happening so ...

[Bug ipa/111940] ICE: in initialize_node_lattices, at ipa-cp.cc:1598 with -O2 -fno-devirtualize-speculatively -fno-weak

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-10-23
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
confirmed.

[Bug c++/111929] [14 Regression] in decompose, at wide-int.h:1049

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug ipa/111940] New: ICE: in initialize_node_lattices, at ipa-cp.cc:1598 with -O2 -fno-devirtualize-speculatively -fno-weak

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111940
   Summary: ICE: in initialize_node_lattices, at ipa-cp.cc:1598
with -O2 -fno-devirtualize-speculatively -fno-weak
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56179&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-devirtualize-speculatively -fno-weak
testcase.C 
during IPA pass: cp
testcase.C:13:24: internal compiler error: in initialize_node_lattices, at
ipa-cp.cc:1598
   13 | SQObjectPtr _sourcename;
  |^
0xe4aecd initialize_node_lattices
/repo/gcc-trunk/gcc/ipa-cp.cc:1598
0xe4aecd ipcp_propagate_stage
/repo/gcc-trunk/gcc/ipa-cp.cc:4302
0xe4aecd ipcp_driver
/repo/gcc-trunk/gcc/ipa-cp.cc:6701
0xe4aecd execute
/repo/gcc-trunk/gcc/ipa-cp.cc:6776
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4866-20231023153002-g458db9b6149-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4866-20231023153002-g458db9b6149-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231023 (experimental) (GCC)

[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065

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

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

--- Comment #2 from Andrew Pinski  ---
Could not reproduce it with r14-4823-g8abddb187b33480d8827f44ec655f45734a1749d
.

[Bug target/111937] [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Created attachment 56178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56178&action=edit
0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch

(In reply to Xiao Ma from comment #0)
> Recently, I wanted to port an open source gpgpu target (a custom
> modification of RISCV) to GCC/openmp (Following the approach of gcu and
> nvptx, using offloading (https://gcc.gnu.org/wiki/Offloading)).

Interesting!  Please keep us posted how this works out.

> However, the
> upstream after this patch
> (https://github.com/mxlol233-ventus/gcc/commit/
> 3496ca4e6566fc3c5f1093a0290bb88c34d368f8#diff-
> 98b71abedd6e59eb80cb43e75ebb507ffa8bf540ee88aa099c6c7fe7cf90ae3e),
> NUM_POLY_INT_COEFFS became greater than 1, while for the x86-64-*-* target,
> NUM_POLY_INT_COEFFS=1. This makes it impossible for a RISC-V*-*-* lto1 to
> parse the data in the LTO sections (e.g. gnu.offload_lto_*) of the object
> files generated by x86-64-*-*.

I'm not sure about your initial analysis; I'm not familiar with the
code/changes you cite.

However, please try building with the attached
'0001-WIP-STATIC_ASSERT-MAX_MACHINE_MODE-256.patch'.  If that triggers, we've
(likely...) found (one of) your issue(s).

[Bug target/111939] New: ICE: in extract_constrain_insn, at recog.cc:2692 insn does not satisfy its constraints: {*vec_extractv2di_1} with -Ofast -mapxf -mabi=ms -mavxifma -mno-avx

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111939
   Summary: ICE: in extract_constrain_insn, at recog.cc:2692 insn
does not satisfy its constraints: {*vec_extractv2di_1}
with -Ofast -mapxf -mabi=ms -mavxifma -mno-avx
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56177&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Ofast -mapxf -mabi=ms -mavxifma -mno-avx testcase.c
testcase.c: In function 'foo0':
testcase.c:18:1: error: insn does not satisfy its constraints:
   18 | }
  | ^
(insn 90 89 24 2 (set (reg:DI 77 r17 [ _8+8 ])
(vec_select:DI (reg:V2DI 20 xmm0 [172])
(parallel [
(const_int 1 [0x1])
]))) "testcase.c":13:18 7389 {*vec_extractv2di_1}
 (expr_list:REG_DEAD (reg:V2DI 20 xmm0 [172])
(nil)))
during RTL pass: cprop_hardreg
testcase.c:18:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x7efe99 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x7eff20 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x7e0676 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x142102b copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:836
0x1422424 execute
/repo/gcc-trunk/gcc/regcprop.cc:1423
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4866-20231023153002-g458db9b6149-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4866-20231023153002-g458db9b6149-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231023 (experimental) (GCC)

[Bug target/111935] gcc ICE with risc-v vector intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed, still happens on the trunk.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Martin Jambor  ---
I'm adding this to the things to look at.  But if our bisecting script is
correct te ICE has been introduced by r10-3604-g38a734350fd787, so let me CC
Aldy as well.

[Bug tree-optimization/111794] RISC-V: Missed SLP optimization due to mask mode precision

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:32b74c9e1d46932a4bbb1f46353bfc43c702c20a

commit r14-4868-g32b74c9e1d46932a4bbb1f46353bfc43c702c20a
Author: Robin Dapp 
Date:   Sun Oct 15 22:36:59 2023 +0200

vect: Allow same precision for bit-precision conversions.

In PR111794 we miss a vectorization because on riscv type precision and
mode precision differ for mask types.  We can still vectorize when
allowing assignments with the same precision for dest and source which
is what this patch does.

gcc/ChangeLog:

PR tree-optimization/111794
* tree-vect-stmts.cc (vectorizable_assignment): Add
same-precision exception for dest and source.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/slp-mask-1.c: New test.
* gcc.target/riscv/rvv/autovec/slp-mask-run-1.c: New test.

[Bug fortran/111938] Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'

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

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

--- Comment #1 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> 'EXEC_OACC_ATOMIC') are handled in 'gcc/fortran/frontend-passes.c'

> Disabling the OpenMP handling, and running 'gomp.exp', I don't get much, but
> still one ICE in 'gfortran.dg/gomp/pr92977.f90'

Aha: PR92977, PR93462.

> [...], so I
> conclude this code is doing something useful for OpenMP, and we should
> investigate whether OpenACC also needs to be handled?

That I already had suspected almost a decade ago;

"OpenACC fortran front end":

| Doesn't gcc/fortran/frontend-passes:gfc_code_walker need to be updated
| for OpenACC?

;'-)

[Bug fortran/111938] New: Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'

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

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

Bug ID: 111938
   Summary: Missing OpenACC/Fortran handling in
'gcc/fortran/frontend-passes.c'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

I've noticed that none of the OpenACC 'EXEC_OACC_[...]' codes (other than
'EXEC_OACC_ATOMIC') are handled in 'gcc/fortran/frontend-passes.c'
('gfc_code_walker'), and similarly the respective 'gfc_omp_clauses' members not
'WALK_SUBEXPR'ed.

At least a lot of (possibly, all?) OpenMP 'EXEC_OMP_[...]' codes and
'gfc_omp_clauses' members appear to be handled.  (Not verified in detail.)

Disabling the OpenMP handling, and running 'gomp.exp', I don't get much, but
still one ICE in 'gfortran.dg/gomp/pr92977.f90', and a dump scanning FAIL in
'gfortran.dg/gomp/workshare2.f90' (nothing for 'check-target-libgomp'), so I
conclude this code is doing something useful for OpenMP, and we should
investigate whether OpenACC also needs to be handled?

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

--- Comment #4 from Jonathan Wakely  ---
Testing a patch:

--- a/libstdc++-v3/src/libbacktrace/Makefile.am
+++ b/libstdc++-v3/src/libbacktrace/Makefile.am
@@ -49,9 +49,13 @@ WARN_FLAGS = -W -Wall -Wwrite-strings
-Wmissing-format-attribute \
 -Wcast-qual
 C_WARN_FLAGS = $(WARN_FLAGS) -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wno-unused-but-set-variable
 CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
-AM_CFLAGS = $(C_WARN_FLAGS)
+AM_CFLAGS = \
+   $(glibcxx_lt_pic_flag) $(glibcxx_compiler_shared_flag) \
+   $(C_WARN_FLAGS)
 AM_CFLAGS += $(EXTRA_CFLAGS)
-AM_CXXFLAGS = $(CXX_WARN_FLAGS) -fno-rtti -fno-exceptions
+AM_CXXFLAGS = \
+   $(glibcxx_lt_pic_flag) $(glibcxx_compiler_shared_flag) \
+   $(CXX_WARN_FLAGS) -fno-rtti -fno-exceptions
 AM_CXXFLAGS += $(EXTRA_CXXFLAGS)

 obj_prefix = std_stacktrace

[Bug c++/99804] cannot convert bit field enum to its own type in a template member function

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Fixed by r14-4793-gdad311874ac3b3, strange.

[Bug middle-end/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #5 from Sam James  ---
the bisect indicates r12-248-gb58dc0b803057c was the fix:

b58dc0b803057c0e6032e0d9bd92cd834f72c75c is the first bad commit
commit b58dc0b803057c0e6032e0d9bd92cd834f72c75c
Author: Richard Biener 
Date:   Tue Apr 27 14:32:27 2021 +0200

tree-optimization/99912 - delete trivially dead stmts during DSE

DSE performs a backwards walk over stmts removing stores but it
leaves removing resulting dead SSA defs to later passes.  This
eats into its own alias walking budget if the removed stores kept
loads live.  The following patch adds removal of trivially dead
SSA defs which helps in this situation and reduces the amount of
garbage followup passes need to deal with.

[Bug tree-optimization/64450] Optimize 0>=p-q to q>=p for char*p,*q;

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Mine ...

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es via Gcc-bugs]

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

--- Comment #12 from Alberto Luaces  ---
It seems to be slightly different:

(gdb) p expr->ts.type
$7 = BT_PROCEDURE
(gdb) p expr->symtree->name
$8 = 0x770244e8 "@1179"

(gdb) p expr->where
$9 = {nextc = 0x0, lb = 0x0}

Maybe it will be clearer if I manage to write the example.

[Bug c++/111919] [14 Regression] ICE: tree check: did not expect class 'type', have 'type' (integer_type) in contains_placeholder_p, at tree.cc:4144 on valid code

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Created attachment 56176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56176&action=edit
partially reduced C++ source code

I have another test case.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #17 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #16)

> Just saw the branch updates, thanks! FWIW, I did observe this issue in
> gcc-13 only but not gcc-11 or gcc-12. But that might be owed to the fact
> that Debian's gcc-11 and gcc-12 packages had not received the latest branch
> updates yet.

Yes, I know it has been observed on the latest GCC-13 only.  It was an
oversight in the code from the beginning, which got triggered by another change
in the compiler.  I haven't checked which change exactly, but I guess it must
have been some backported change. So if the same/similar thing gets backported
to GCC-11 or GCC-12 it might trigger this bug there, too.  Hence the preventive
measure.  It's a rather obvious bug/fix, so should be safe.

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||link-failure
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |13.3
   Last reconfirmed||2023-10-23

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

--- Comment #3 from Jonathan Wakely  ---
The problem is that libstdc++_libbacktrace.a is not compiled with -fPIC

[Bug target/96265] building nvptx-none on aarch64-linux-gnu

[mxlol233 at outlook dot com via Gcc-bugs]

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

Xiao Ma  changed:

   What|Removed |Added

 CC||mxlol233 at outlook dot com

--- Comment #3 from Xiao Ma  ---
I think this issue and #111937
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111937) have the same root cause: 
aarch64 also sets NUM_POLY_INT_COEFFS to 2, which makes it incompatible with
the default value for nvptx (which is 1).

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to vincenzo Innocente from comment #0)
> it silently compiles with
> [innocent@patatrack01 ctest]$ c++ -O3 -Wall -pthread -fPIC -shared
> -std=c++23 -lstdc++exp getStacktrace.cc
> 
> but the symbols are undefined

This is simply because you need to list libraries after the files that depend
on them:
https://c-faq.com/lib/libsearch.html

When the linker sees -lstdc++exp there are no undefined references to any of
the symbols it provides, so the linker ignores it. Then it sees getStacktrace.o
which has undefined refs but it's too late, the archive has already been
processed.

The library should be compiled as PIC though, which is a separate issue.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #16 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #15)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > 
> > Do we need anything else before the fix can be merged?
> 
> No, should be fine.  I'll leave this PR open for a while in case anything
> else related pops up.  Thanks for testing.

Just saw the branch updates, thanks! FWIW, I did observe this issue in gcc-13
only but not gcc-11 or gcc-12. But that might be owed to the fact that Debian's
gcc-11 and gcc-12 packages had not received the latest branch updates yet.

[Bug target/111937] New: [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1, the `poly_xxx` made `lto_input_mode_table` unable to parse binary gimple data.

[mxlol233 at outlook dot com via Gcc-bugs]

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

Bug ID: 111937
   Summary: [RISCV][lto][offload] When `NUM_POLY_INT_COEFFS` > 1,
the `poly_xxx`  made `lto_input_mode_table` unable to
parse binary gimple data.
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mxlol233 at outlook dot com
  Target Milestone: ---

Recently, I wanted to port an open source gpgpu target (a custom modification
of RISCV) to GCC/openmp (Following the approach of gcu and nvptx, using
offloading (https://gcc.gnu.org/wiki/Offloading)). However, the upstream after
this patch
(https://github.com/mxlol233-ventus/gcc/commit/3496ca4e6566fc3c5f1093a0290bb88c34d368f8#diff-98b71abedd6e59eb80cb43e75ebb507ffa8bf540ee88aa099c6c7fe7cf90ae3e),
NUM_POLY_INT_COEFFS became greater than 1, while for the x86-64-*-* target,
NUM_POLY_INT_COEFFS=1. This makes it impossible for a RISC-V*-*-* lto1 to parse
the data in the LTO sections (e.g. gnu.offload_lto_*) of the object files
generated by x86-64-*-*.

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #30 from Richard Biener  ---
Created attachment 56175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56175&action=edit
prototype patch

This is an (untested) fix, API wise needs some cleanup still.  It's the most
simple fix that doesn't completely give up on TBAA.

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[bettio.davide at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Davide Bettio  ---
(In reply to Richard Biener from comment #1)
> uint32_t from_unaligned_u32(uint32_t *unaligned)
> {
> uint32_t tmp;
> tmp = *unaligned;
> 
> note this isn't an unaligned access since you dereference a uint32_t pointer

Let me explain better my purpose: I was writing a function for reading uint32_t
and uint64_t values at any address, including odd ones such as 0x2345.

So as far as I know the only generic way to do this is either casting them to
uint8_t and reading them as 4 or 8 bytes, or using memcpy.
My expectation is that memcpy is always replaced with a load instruction when
fast unaligned memory access is available.

Let me know if I am making any wrong assumptiom.

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

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

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

--- Comment #1 from Richard Biener  ---
uint32_t from_unaligned_u32(uint32_t *unaligned)
{
uint32_t tmp;
tmp = *unaligned;

note this isn't an unaligned access since you dereference a uint32_t pointer

[Bug tree-optimization/111915] [14 Regression] ICE in vect with option `-O2 -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-ccp` since r14-2117-gdd86a5a69cbda4

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/111915] [14 Regression] ICE in vect with option `-O2 -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-ccp` since r14-2117-gdd86a5a69cbda4

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

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

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

https://gcc.gnu.org/g:00eb0812e6464307f9f971d2a743d720015e70cf

commit r14-4865-g00eb0812e6464307f9f971d2a743d720015e70cf
Author: Richard Biener 
Date:   Mon Oct 23 13:42:53 2023 +0200

tree-optimization/111915 - mixing grouped and non-grouped accesses

The change to allow SLP of non-grouped accesses failed to check
for the case of mixing with grouped accesses.

PR tree-optimization/111915
* tree-vect-slp.cc (vect_build_slp_tree_1): Check all
accesses are either grouped or not.

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

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

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

https://gcc.gnu.org/g:738d44348e7392a9f8e370afa3a9d8c24ee080cd

commit r14-4864-g738d44348e7392a9f8e370afa3a9d8c24ee080cd
Author: Richard Biener 
Date:   Mon Oct 23 13:29:30 2023 +0200

ipa/111914 - perform parameter init after remapping types

The following addresses a mismatch in SSA name vs. symbol when
we emit a dummy assignment when not optimizing.  The temporary
we create is not remapped by initialize_inlined_parameters because
we have no easy way to get at it.  The following instead emits
the additional statement after we have remapped the type of
the replacement variable.

PR ipa/111914
* tree-inline.cc (setup_one_parameter): Move code emitting
a dummy load when not optimizing ...
(initialize_inlined_parameters): ... here to after when
we remapped the parameter type.

* gcc.dg/pr111914.c: New testcase.

[Bug ipa/111914] ICE with function pointer array as argument with non-constant size

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Richard Biener  ---
Fixed on trunk, not worth backporting.

[Bug tree-optimization/111916] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu (the generated code hangs) since r14-4612-g6decda1a35be5764101987c210b5693a0d914e58

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

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

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

https://gcc.gnu.org/g:458db9b6149b2e9bef94ab76909eb914ed9f675a

commit r14-4866-g458db9b6149b2e9bef94ab76909eb914ed9f675a
Author: Richard Biener 
Date:   Mon Oct 23 14:08:41 2023 +0200

tree-optimization/111916 - SRA of BIT_FIELD_REF of constant pool entries

The following adjusts a leftover BIT_FIELD_REF special-casing to only
cover the cases general code doesn't handle.

PR tree-optimization/111916
* tree-sra.cc (sra_modify_assign): Do not lower all
BIT_FIELD_REF reads that are sra_handled_bf_read_p.

* gcc.dg/torture/pr111916.c: New testcase.

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|linkw at gcc dot gnu.org   |rguenth at gcc dot 
gnu.org

--- Comment #29 from Richard Biener  ---
I will try to implement the simple approach.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #15 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> 
> Do we need anything else before the fix can be merged?

No, should be fine.  I'll leave this PR open for a while in case anything else
related pops up.  Thanks for testing.

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:626bb2e165daa88f5c7cd66b9db49f03921474a9

commit r11-11075-g626bb2e165daa88f5c7cd66b9db49f03921474a9
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug libstdc++/111936] std::stacktrace cannot be used in a shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #1 from vincenzo Innocente  ---
here is a minimal malloc hook that I would like to use
[innocent@patatrack01 ctest]$ cat getStacktrace.cc
#include 

  std::string get_stacktrace() {
 std::string trace;
 for (auto & entry : std::stacktrace::current() ) trace +=
entry.description() + '#';
 return trace;
  }


#include 
#include 
#include 

extern "C"
void * myMallocHook(size_t size, void const * caller) {
  __malloc_hook = nullptr;
  auto p = malloc(size);
  std::cout << "asked " << size
<< " at " << get_stacktrace()
<< std::endl;
  __malloc_hook = myMallocHook;
  return p;
}

namespace {
struct Hook {
  Hook() {
  __malloc_hook = myMallocHook;
  }
};

  Hook hook;

}

compiled as
c++ -O3 -Wall -pthread -fPIC -shared -std=c++23 -lstdc++exp getStacktrace.cc

gives the undefined symbol

 setenv LD_PRELOAD ./a.out ; ls ; unsetenv LD_PRELOAD
ls: symbol lookup error: ./a.out: undefined symbol:
_ZNSt17__stacktrace_impl10_S_currentEPFiPvmES0_i

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:4414818f4e5de54ea3c353e2ebb2e79a89ae211b

commit r12-9938-g4414818f4e5de54ea3c353e2ebb2e79a89ae211b
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Iain Sandoe  ---
so, should be fixed on trunk.

[Bug libquadmath/111928] [14 Regression] Build broken for baremetal targets after r14-4825-g6a6d3817afa02b

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:538dcde872abba589b3c8a57181bd7f91018c67a

commit r14-4863-g538dcde872abba589b3c8a57181bd7f91018c67a
Author: Iain Sandoe 
Date:   Mon Oct 23 13:07:50 2023 +0100

configure, libquadmath: Remove unintended AC_CHECK_LIBM [PR111928]

This was a rebase error, that managed to pass testing on Darwin and
Linux (but fails on bare metal).

PR libquadmath/111928

libquadmath/ChangeLog:

* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove AC_CHECK_LIBM.

Signed-off-by: Iain Sandoe 

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Oleg Endo
:

https://gcc.gnu.org/g:4e1320e4af413b7126f3b998096f60f8b7d5cb32

commit r13-7976-g4e1320e4af413b7126f3b998096f60f8b7d5cb32
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

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

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

Tamar Christina  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #24 from Tamar Christina  ---
ok, should be actually fixed now

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Oleg Endo :

https://gcc.gnu.org/g:267e369afbb963d8d84d7a9f0cb9fb18672d99a8

commit r14-4862-g267e369afbb963d8d84d7a9f0cb9fb18672d99a8
Author: Oleg Endo 
Date:   Mon Oct 23 22:08:37 2023 +0900

SH: Fix PR 111001

gcc/ChangeLog:

PR target/111001
* config/sh/sh_treg_combine.cc
(sh_treg_combine::record_set_of_reg):
Skip over nop move insns.