[Bug d/107241] std.bitmanip.bigEndianToNative et al not inlined

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Iain Buclaw  ---
Looks like pr102765 to me.

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

[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||witold.baryluk+gcc at gmail 
dot co
   ||m

--- Comment #7 from Iain Buclaw  ---
*** Bug 107241 has been marked as a duplicate of this bug. ***

[Bug c++/107242] ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.cc:5284 with frounding-math

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-13

--- Comment #4 from Andrew Pinski  ---
(In reply to Arseny Solokha from comment #3)
> Testcase w/o dependency on libstdc++:

And reduced all the way:
struct cf {
  _Complex float _M_value;
};

cf
test_comparison ()
{
  constexpr _Complex float  a{2.2}, b{4.4};
  return {a + b};
}

[Bug c++/107242] ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.cc:5284 with frounding-math

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
Testcase w/o dependency on libstdc++:

template 
class complex;

template <>
struct complex {
  template 
  constexpr void
  operator+= (_Tp __z)
  {
_M_value += __z._M_value;
  }

  _Complex float _M_value;
};

constexpr complex
operator+ (complex __x, complex __y)
{
  complex __r = __x;

  __r += __y;

  return __r;
}

complex
test_comparison ()
{
  constexpr complex a{2.2}, b{4.4};

  return a + b;
}

% powerpc-e300c3-linux-gnu-g++-13 -Og -frounding-math -c micz0onj.cc
micz0onj.cc:32:1: internal compiler error: tree check: expected complex_cst,
have plus_expr in output_constant, at varasm.cc:5284
   32 | }
  | ^
0x803d1f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.cc:8827
0x819d94 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.h:3526
0x819d94 output_constant
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5284
0x14b1c1a output_constructor_regular_field
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5562
0x14b1c1a output_constructor
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5829
0x14b3625 assemble_constant_contents
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:3638
0x14b3d34 output_object_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:8070
0x14b3d34 output_object_blocks()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:8148

[Bug c++/107242] ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.cc:5284

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

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

--- Comment #2 from Andrew Pinski  ---
>From the original dump:
{
  const struct complex a = {._M_value=__complex__
(1.1002384185791015625e+0, 2.200476837158203125e+0)};
  const struct complex b = {._M_value=__complex__ (3.299523162841796875e+0,
4.40095367431640625e+0)};

  <>;
  <>;
  < = TARGET_EXPR >>>;
}
Which looks fine as we have COMPLEX_CST+COMPLEX_CST

But then in the gimple dump we get:
   = *.LC2D.78102;

Which is broken.

[Bug c++/107242] ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.cc:5284

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

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

--- Comment #1 from Andrew Pinski  ---
It is the gimplification which is causing issues.

[Bug target/107242] New: ICE: tree check: expected complex_cst, have plus_expr in output_constant, at varasm.cc:5284

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107242
   Summary: ICE: tree check: expected complex_cst, have plus_expr
in output_constant, at varasm.cc:5284
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-e300c3-linux-gnu

g++ 13.0.0 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e) ICEs
when compiling the following testcase, reduced from
libstdc++-v3/testsuite/26_numerics/complex/comparison_operators/more_constexpr.cc,
for a 32-bit BE target w/ -std=c++20 -Og -frounding-math -fno-ipa-pure-const:

#include 

std::complex
test_comparison ()
{
  constexpr std::complex a{1.1, 2.2};
  constexpr std::complex b{3.3, 4.4};

  return a + b;
}

% powerpc-e300c3-linux-gnu-g++-13 -std=c++20 -Og -frounding-math
-fno-ipa-pure-const -c micz0onj.cc
micz0onj.cc:10:1: internal compiler error: tree check: expected complex_cst,
have plus_expr in output_constant, at varasm.cc:5284
   10 | }
  | ^
0x803d1f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.cc:8827
0x819d94 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/tree.h:3526
0x819d94 output_constant
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5284
0x14b1c1a output_constructor_regular_field
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5562
0x14b1c1a output_constructor
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:5829
0x14b3625 assemble_constant_contents
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:3638
0x14b3d34 output_object_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:8070
0x14b3d34 output_object_blocks()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/varasm.cc:8148

powerpc-e300c3-linux-gnu-g++-13 -v
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-g++-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/13/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221009/work/gcc-13-20221009/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/13/include/g++-v13
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/13/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes
--with-gcc-major-version-only --disable-esp --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221009 (experimental) (GCC)

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Hongtao.liu  ---
looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
(reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
Not (LTU: (REG:CCCmode FLAGS_REG) (const_int 0)).
Now I got more confused.

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #10 from vfdff  ---
Created attachment 53698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53698=edit
the huge bb sligtly change after match ResLo

Thanks for your suggestion, and I think both ctz_table_index and
nop_atomic_bit_test_and_p only return one value, so I'll try to match ResHi and
ResLo separately as the bb only sligtly change after we first matched the ResLo

[Bug target/107238] aarch64: Wrong code converting pointer to __int128

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> File a bug with clang about not documenting their behavior ...

Oh there is one already:
https://github.com/llvm/llvm-project/issues/11644
Still open after (almost) 10 years.

[Bug target/107238] aarch64: Wrong code converting pointer to __int128

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

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

--- Comment #2 from Andrew Pinski  ---
clang does not even define the behavior here even though it should be as it is
an implementation defined behavior.
File a bug with clang about not documenting their behavior ...

[Bug target/107238] aarch64: Wrong code converting pointer to __int128

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Arrays-and-pointers-implementation.html#Arrays-and-pointers-implementation

> A cast from integer to pointer discards most-significant bits if the pointer 
> representation is smaller than the integer type, extends according to the 
> signedness of the integer type if the pointer representation is larger than 
> the integer type, otherwise the bits are unchanged.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

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

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

--- Comment #11 from Jonathan Wakely  ---
No, because that just makes it more awkward to write makefiles and build
scripts. We used to do that, and it had no real benefit. If you want to use
c++2a, you can use that. Other people just want to use c++20 across multiple
releases, some of which have full C++20 support and some don't.

To check the level of conformance you should check the macros defined by the
compiler when compiling, not rely on which command-line options happen to be
supported.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #10 from Lewis Hyatt  ---
The underlying issue is fixed for GCC 13 now.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[mail at 3v1n0 dot net via Gcc-bugs]

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

--- Comment #10 from Marco Trevisan  ---
I see the point, but then I also think that gcc-10 should not support
`--std=c++20` option but rather only the `--std=c++2a` one.

[Bug preprocessor/60723] Line directives with incorrect system header flag

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

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

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

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

commit r13-3264-gddb7f0a0cac48762ba6408d69538f8115c4a2739
Author: Lewis Hyatt 
Date:   Thu Oct 6 18:05:02 2022 -0400

preprocessor: Fix tracking of system header state [PR60014,PR60723]

The token_streamer class (which implements gcc mode -E and
-save-temps/-no-integrated-cpp) needs to keep track whether the last tokens
output were in a system header, so that it can generate line marker
annotations as necessary for a downstream consumer to reconstruct the
state. The logic for tracking it, which was added by r5-1863 to resolve
PR60723, has some edge case issues as revealed by the three new test
cases. The first, coming from the original PR60014, was incidentally fixed
by
r9-1926 for unrelated reasons. The other two were still failing on master
prior to this commit. Such code paths were not realizable prior to
r13-1544,
which made it possible for the token streamer to see CPP_PRAGMA tokens in
more
contexts.

The two main issues being corrected here are:

1) print.prev_was_system_token needs to indicate whether the previous token
output was in a system location. However, it was not being set on every
token,
only on those that triggered the main code path; specifically it was not
triggered on a CPP_PRAGMA token. Testcase 2 covers this case.

2) The token_streamer uses a variable "line_marker_emitted" to remember
whether a line marker has been emitted while processing a given token, so
that
it wouldn't be done more than once in case multiple conditions requiring a
line marker are true. There was no reason for this to be a member variable
that retains its value from token to token, since it is just needed for
tracking the state locally while processing a single given token. The fact
that it could retain its value for a subsequent token is rather difficult
to
observe, but testcase 3 demonstrates incorrect behavior resulting from
that. Moving this to a local variable also simplifies understanding the
control flow going forward.

gcc/c-family/ChangeLog:

PR preprocessor/60014
PR preprocessor/60723
* c-ppoutput.cc (class token_streamer): Remove member
line_marker_emitted to...
(token_streamer::stream): ...a local variable here. Set
print.prev_was_system_token on all code paths.

gcc/testsuite/ChangeLog:

PR preprocessor/60014
PR preprocessor/60723
* gcc.dg/cpp/pr60014-1.c: New test.
* gcc.dg/cpp/pr60014-1.h: New test.
* gcc.dg/cpp/pr60014-2.c: New test.
* gcc.dg/cpp/pr60014-2.h: New test.
* gcc.dg/cpp/pr60014-3.c: New test.
* gcc.dg/cpp/pr60014-3.h: New test.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

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

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

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

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

commit r13-3264-gddb7f0a0cac48762ba6408d69538f8115c4a2739
Author: Lewis Hyatt 
Date:   Thu Oct 6 18:05:02 2022 -0400

preprocessor: Fix tracking of system header state [PR60014,PR60723]

The token_streamer class (which implements gcc mode -E and
-save-temps/-no-integrated-cpp) needs to keep track whether the last tokens
output were in a system header, so that it can generate line marker
annotations as necessary for a downstream consumer to reconstruct the
state. The logic for tracking it, which was added by r5-1863 to resolve
PR60723, has some edge case issues as revealed by the three new test
cases. The first, coming from the original PR60014, was incidentally fixed
by
r9-1926 for unrelated reasons. The other two were still failing on master
prior to this commit. Such code paths were not realizable prior to
r13-1544,
which made it possible for the token streamer to see CPP_PRAGMA tokens in
more
contexts.

The two main issues being corrected here are:

1) print.prev_was_system_token needs to indicate whether the previous token
output was in a system location. However, it was not being set on every
token,
only on those that triggered the main code path; specifically it was not
triggered on a CPP_PRAGMA token. Testcase 2 covers this case.

2) The token_streamer uses a variable "line_marker_emitted" to remember
whether a line marker has been emitted while processing a given token, so
that
it wouldn't be done more than once in case multiple conditions requiring a
line marker are true. There was no reason for this to be a member variable
that retains its value from token to token, since it is just needed for
tracking the state locally while processing a single given token. The fact
that it could retain its value for a subsequent token is rather difficult
to
observe, but testcase 3 demonstrates incorrect behavior resulting from
that. Moving this to a local variable also simplifies understanding the
control flow going forward.

gcc/c-family/ChangeLog:

PR preprocessor/60014
PR preprocessor/60723
* c-ppoutput.cc (class token_streamer): Remove member
line_marker_emitted to...
(token_streamer::stream): ...a local variable here. Set
print.prev_was_system_token on all code paths.

gcc/testsuite/ChangeLog:

PR preprocessor/60014
PR preprocessor/60723
* gcc.dg/cpp/pr60014-1.c: New test.
* gcc.dg/cpp/pr60014-1.h: New test.
* gcc.dg/cpp/pr60014-2.c: New test.
* gcc.dg/cpp/pr60014-2.h: New test.
* gcc.dg/cpp/pr60014-3.c: New test.
* gcc.dg/cpp/pr60014-3.h: New test.

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

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

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

--- Comment #9 from Andrew Pinski  ---
Look at how ctz_table_index is done and used.
The matching is done in match.pd language and then inside
simplify_count_trailing_zeroes (tree-ssa-forwprop.cc) it is used 

nop_atomic_bit_test_and_p is another example but that is more complex and is
used inside tree-ssa-ccp.cc .

[Bug c++/93821] Define __cplusplus to 202002L in C++20

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

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

--- Comment #9 from Jonathan Wakely  ---
No. C++20 support in GCC 10 is missing a number of features, so it would be
misleading/incorrect to define it to 202002L.
https://gcc.gnu.org/projects/cxx-status.html#cxx20

You can just test for > 201703L if you want to know if partial C++20 support is
present. Or use the feature test macros for individual features.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107216
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058332.html

[Bug testsuite/107240] [13 regression]

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||pthaugen at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
I guess the first question is, is it expected that the vect-bitfield-write-2.c
loop should be vectorized on power7 which only has Altivec and not VSX?

[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 106825, which changed state.

Bug 106825 Summary: [modules] header unit  based 
std::shared_ptr<...>(...) use gets: undefined reference to 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 
example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/106825] [modules] header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
dup of the recently fixed PR104433 I think

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

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 106825 Summary: [modules] header unit  based 
std::shared_ptr<...>(...) use gets: undefined reference to 
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 
example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/104433] [modules] Importing and using std::make_shared causes linker errors

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||markmigm at gmail dot com

--- Comment #5 from Patrick Palka  ---
*** Bug 106825 has been marked as a duplicate of this bug. ***

[Bug fortran/107216] ICE in reduce_binary_aa, at fortran/arith.cc:1427

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Potential patch:

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..9bec299f160 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,10 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
 {
   e = c->expr;
+
+  if (e->expr_type == EXPR_OP)
+   gfc_simplify_expr (e, 0);
+
   if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
  && !e->ref && e->value.constructor)
{

This seems to fix pr107219, too.

[Bug d/107241] std.bitmanip.bigEndianToNative et al not inlined

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Hmm:
> __attribute__((weak))
> ulong swapEndian (const ulong val)

Note this is definitely a front-end issue .

[Bug d/107241] std.bitmanip.bigEndianToNative et al not inlined

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm:
__attribute__((weak))
ulong swapEndian (const ulong val)

[Bug d/107241] New: std.bitmanip.bigEndianToNative et al not inlined

[witold.baryluk+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 107241
   Summary: std.bitmanip.bigEndianToNative et al not inlined
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

gdc fails to inline number of small functions that should fully inline and end
in single instruction.

on amd64 / x86, for example std.bitmanip.bigEndianToNative causes a chain of
calls / jumps, even with @attribute("flatten")



import std.bitmanip;
import gcc.attributes;

@attribute("flatten")
size_t f(char[] b) {
return std.bitmanip.bigEndianToNative!(size_t,
8)(cast(ubyte[8])(b[2..10]));
}




gcc -O3 -march=znver2 -frelease


pure nothrow @nogc @safe ulong
std.bitmanip.swapEndian!(ulong).swapEndian(const(ulong)):
mov rax, rdi
bswap   rax
ret
pure nothrow @nogc @safe ulong std.bitmanip.endianToNativeImpl!(true, ulong,
8uL).endianToNativeImpl(ubyte[8]):
jmp pure nothrow @nogc @safe ulong
std.bitmanip.swapEndian!(ulong).swapEndian(const(ulong))
pure nothrow @nogc @safe ulong std.bitmanip.bigEndianToNative!(ulong,
8uL).bigEndianToNative(ubyte[8]):
jmp pure nothrow @nogc @safe ulong
std.bitmanip.endianToNativeImpl!(true, ulong, 8uL).endianToNativeImpl(ubyte[8])
ulong example.f(char[]):
mov rdi, QWORD PTR [rsi+2]
jmp pure nothrow @nogc @safe ulong
std.bitmanip.bigEndianToNative!(ulong, 8uL).bigEndianToNative(ubyte[8])




No issues with LDC.

ulong example.f(char[]):
mov rax, qword ptr [rsi + 2]
bswap   rax
ret



godbolt: https://godbolt.org/z/Pj3f7oGso

[Bug testsuite/107240] New: [13 regression]

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

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

Bug ID: 107240
   Summary: [13 regression]
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:25413fdb2ac24933214123e24ba165026452a6f2, r13-3219-g25413fdb2ac249

This fails on power 7 BE.  It works on power 8 BE.

make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-bitfield-write-2.c"
FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
# of expected passes4
# of unexpected failures2

commit 25413fdb2ac24933214123e24ba165026452a6f2
Author: Andre Vieira 
Date:   Tue Oct 11 10:49:27 2022 +0100

vect: Teach vectorizer how to handle bitfield accesses

[Bug fortran/107216] ICE in reduce_binary_aa, at fortran/arith.cc:1427

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-12
 Status|UNCONFIRMED |NEW

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

Strange.  Removing any of the typespecs in the array constructors avoids
the issue, i.e.

   print *, [real :: 1, 2] * [ 1, (2)]

would just fine.

For z1.f90, I find:

(gdb) p op2->expr_type
$9 = EXPR_FUNCTION

in reduce_binary before we call reduce_binary_aa and everything goes boom.

[Bug fortran/107217] ICE in gfc_arith_times, at fortran/arith.cc:715/704

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug c++/107239] Coroutine code generation bug

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 53697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53697=edit
testcase

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[mail at 3v1n0 dot net via Gcc-bugs]

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

Marco Trevisan  changed:

   What|Removed |Added

 CC||mail at 3v1n0 dot net

--- Comment #8 from Marco Trevisan  ---
Is this released on any gcc 10 point release version (as per debian stable
support)?

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #22 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Hongtao.liu from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Segher Boessenkool from comment #16)
> > > > Hi Roger,
> > > > 
> > > > (In reply to Roger Sayle from comment #15)
> > > > > Yes, a COMPARE rtx can be used to set various flags on x86, but many 
> > > > > other
> > > > > operations also legitimately set and/or use MODE_CC, often in a 
> > > > > parallel
> > > > > with the primary operation.
> > > > 
> > > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > > > MODE_CC *is*.
> > > > 
> > > > Setting something as ne:CC and then using it as somethingelse:CC has no
> > > > defined meaning.
> > > 
> > > This
> > > 
> > > (parallel [
> > > (set (reg:SI 97) 
> > > (neg:SI (ltu:SI (reg:CCC 17 flags)
> > > (const_int 0 [0]
> > > (clobber (reg:CC 17 flags))
> > > ])
> > > 
> > > still won't work correctly if reg:CCC 17 flags is set by a compare of
> > > 2 known values.
> > 
> > I guess Segher means it should be NE instead of LTU in the
> > x86_movcc_0_m1_neg, since the setters is NE to const 0.
> 
> Yes.

So the issue is with the consumer:

(insn 50 49 51 2 (parallel [
(set (reg:SI 93)
(neg:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]
(clobber (reg:CC 17 flags))
]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
 (expr_list:REG_DEAD (reg:CCC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

There are many similar patterns in different backends.  They work as long as
the flags register isn't a known constant since simplify-rtx.cc leaves them
alone.  They become a problem only when the flags register is a known constant.

[Bug fortran/107217] ICE in gfc_arith_times, at fortran/arith.cc:715/704

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7858368c3f3875f6bf634119e5731dc3c808a7c3

commit r13-3260-g7858368c3f3875f6bf634119e5731dc3c808a7c3
Author: Harald Anlauf 
Date:   Tue Oct 11 22:08:48 2022 +0200

Fortran: check types of operands of arithmetic binary operations [PR107217]

gcc/fortran/ChangeLog:

PR fortran/107217
* arith.cc (gfc_arith_plus): Compare consistency of types of
operands.
(gfc_arith_minus): Likewise.
(gfc_arith_times): Likewise.
(gfc_arith_divide): Likewise.
(arith_power): Check that both operands are of numeric type.

gcc/testsuite/ChangeLog:

PR fortran/107217
* gfortran.dg/pr107217.f90: New test.

[Bug libstdc++/107239] Coroutine code generation bug

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

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

--- Comment #1 from David Edelsohn  ---
https://twitter.com/novacisko/status/1580056176040980481

[Bug libstdc++/107239] New: Coroutine code generation bug

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

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

Bug ID: 107239
   Summary: Coroutine code generation bug
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: C++-Coroutine, wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

object duplicated without constructor

problem is at line 592 - lambda in co_await 

https://godbolt.org/z/nz1coM5YP

[Bug libstdc++/107189] Inconsistent range insertion implementations in std::_Rb_tree in

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

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

François Dumont  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-12
   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||fdumont at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from François Dumont  ---
Code looks perfectly consistent to me. There is just this _Alloc_node
instantiation to remove.

Why do you want to call the _M_emplace_hint_{unique,equal} ? I rather wondered
why the __is_same_value_type alternatives are doing so just to pass end() as a
hint. And the answer is just that it is more convenient. Look at the
_M_insert_unique overloads to see that the one called is the most convenient
one.

Thanks for the report.

[Bug target/107238] New: aarch64: Wrong code converting pointer to __int128

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

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

Bug ID: 107238
   Summary: aarch64: Wrong code converting pointer to __int128
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For this testcase:

__int128 f(int *p) {
return (__int128)p;
}

AArch64 GCC at -O2 generates:

f:
asr x1, x0, 63
ret

i.e. it sign-extends the pointer, but I think it should be a zero extend
instead. The ABI [1] says:

> Code and data pointers are either 64-bit or 32-bit unsigned types.

Indeed LLVM does a zero-extend:

f:  // @f
mov x1, xzr
ret

[1] :
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#pointers

[Bug tree-optimization/107229] [13 Regression] ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed since r13-3219-g25413fdb2ac24933

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Jeffrey A. Law  ---
Note that we're seeing linux kernel build failures that may have the same
underlying problem:

./cc1 -O2 -mabi=64 main.i -quiet -I./
../drivers/base/power/main.c: In function ‘__device_suspend’:
../drivers/base/power/main.c:1606:12: error: invalid ‘PHI’ argument
_142
during GIMPLE pass: ifcvt
../drivers/base/power/main.c:1606:12: internal compiler error: tree check:
expected class ‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at gimple-expr.cc:87
0x176e2f4 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/jlaw/test/gcc/gcc/tree.cc:8877
0xa058bb tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/jlaw/test/gcc/gcc/tree.h:3649
0xe9369a useless_type_conversion_p(tree_node*, tree_node*)
/home/jlaw/test/gcc/gcc/gimple-expr.cc:87
0x13a4bd3 verify_gimple_phi
/home/jlaw/test/gcc/gcc/tree-cfg.cc:5201
0x13a57dd verify_gimple_in_cfg(function*, bool)
/home/jlaw/test/gcc/gcc/tree-cfg.cc:5530


I'll monitor this bug and re-test the kernel build once Andre has a potential
patch.  If it turns out to be a distinct problem, then I'll open a new bug.

[Bug fortran/107237] Error: non-constant array in DATA statement (1)

[ptw at tpointsw dot uk via Gcc-bugs]

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

--- Comment #2 from Patrick Wallace  ---
Many thanks for the quick response, and profound apologies for this red
herring. The reason I got caught out is that the code I started with had been
copy/pasted from a PDF, using Acrobat Reader. The latter is (to my surprise)
capable of performing character recognition on an image of the original printed
publication and had interpreted a decimal one as lowercase lima.  BTW my own
code invariably starts with IMPLICIT NONE and I wish I had tried this in the
example!

[Bug fortran/107237] Error: non-constant array in DATA statement (1)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from anlauf at gcc dot gnu.org ---
It would help if you chose a font that can distinguish 'l' (ell) from '1'
(one).

Adding "implicit none" of -fimplicit-none tells you:

2 |   DATA A(l), A(2), A(3), A(4) /0.0, 0.0, 0.0, 0.0/
  |  1
Error: Symbol 'l' at (1) has no IMPLICIT type

[Bug analyzer/107225] FP with -Wanalyzer-mismatching-deallocation

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

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

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

As far as I can tell, the aliasing implementation gets confused at:

1313 |   x_hdrs[num_x_hdrs++] = strdup(line);
 |   ~^~

for the case where x_hdrs is NULL (which -fanalyzer does seem to complain
about) and considers that the write to NULL[0] could modify file's buffer
(which it clearly can't, or at least, it's clear to a human that it can't).

I think it's fixable by making the -fanalyzer's aliasing code consider that
writes through NULL don't alias anything.

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #15 from Patrick Palka  ---
The comment #5 testcase now works on trunk, but the comment #4 testcase still
fails to link.  Reduced:

$ cat 99377_a.H 
template
struct Widget
{
  Widget (int) { }

  bool First() const { return true; }

  bool Second () const { return true;}
};

inline void Frob (const Widget& w) noexcept
{
  w.First ();
}

$ 99377_b.C 
export module Foo:check;
import "99377_a.H";

export inline bool Check (const Widget& w)
{
  return w.Second ();
}

$ cat 99377_c.C 
export module Foo;
export import :check;

$ cat 99377_d.C 
import Foo;

int main ()
{
  return Check (0) ? 0 : 1;
}

$ g++ -fmodules-ts 99377_a.H 99377_b.C 99377_c.C 99377_d.C
/usr/bin/ld: /tmp/ccBHt33S.o: in function `Check@Foo(Widget const&)':
99377_d.C:(.text._ZW3Foo5CheckRK6WidgetIiE[_ZW3Foo5CheckRK6WidgetIiE]+0x14):
undefined reference to `Widget::Second() const'

[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 100134, which changed state.

Bug 100134 Summary: [modules] ICE when using a vector in a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134

   What|Removed |Added

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

[Bug c++/100134] [modules] ICE when using a vector in a module

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Should be fixed on trunk

[Bug c++/106820] [modules] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via header unit]: mishandling of "weak" usage generated via __gthr

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104433

--- Comment #9 from Patrick Palka  ---
Reduced:

$ cat 106820_a.H
static int __gthrw___pthread_key_create() __attribute__((__weakref__("foo")));

$ cat 106820_b.C
import "106820_a.H";

int main() {
  __gthrw___pthread_key_create();
}

$ g++ -fmodules-ts 106820_a.H 106820_b.C
106820_b.C:5:1: internal compiler error: in function_and_variable_visibility,
at ipa-visibility.cc:712

[Bug fortran/107237] New: Error: non-constant array in DATA statement (1)

[ptw at tpointsw dot uk via Gcc-bugs]

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

Bug ID: 107237
   Summary: Error: non-constant array in DATA statement (1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ptw at tpointsw dot uk
  Target Milestone: ---

Apologies if this report is incomplete or blemished. Hopefully the example is
sufficiently concise that the problem will be easy to reproduce.

Using gfortran under Windows 10, this apparently valid Fortran code:

  REAL A(4)
  DATA A(l), A(2), A(3), A(4) /0.0, 0.0, 0.0, 0.0/
  PRINT *, A(1)
  END

produces the reports:

   DATA A(l), A(2), A(3), A(4) /0.0, 0.0, 0.0, 0.0/
1
Error: non-constant array in DATA statement (1)

   DATA A(l), A(2), A(3), A(4) /0.0, 0.0, 0.0, 0.0/
  1
Error: Data element below array lower bound at (1)

Output from gfortran -v is as follows:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw
--with-isl=/mingw --prefix=/mingw --disable-win32-registry --target=mingw32
--with-arch=i586 --enable-languages=c,c++,objc,obj-c++,fortran,ada
--with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared
--enable-threads --with-dwarf2 --disable-sjlj-exceptions
--enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw
--with-libintl-prefix=/mingw --enable-libstdcxx-debug --with-tune=generic
--enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)

I get the same errors on a recently built Ubuntu platform.

[Bug middle-end/107236] [OpenMP] ICE for reverse offload: in expand_GOMP_TARGET_REV, at internal-fn.cc:376

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

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

--- Comment #1 from Tobias Burnus  ---
The problem seems to be that:

execute_omp_device_lower ()
...
tree lhs = gimple_call_lhs (stmt), rhs = NULL_TREE;
tree type = lhs ? TREE_TYPE (lhs) : integer_type_node;
switch (gimple_call_internal_fn (stmt))
  {
  case IFN_GOMP_TARGET_REV:
is never reached.

Thus, IFN_GOMP_TARGET_REV remains - and the assert that IFN_GOMP_TARGET_REV has
been removed fails, leading to the ICE.

It seems as if pass_omp_device_lower::gate(...) wrongly skips the generated
nested
function for parallel. The current check is:

  return (!(fun->curr_properties & PROP_gimple_lomp_dev)
  || (flag_openmp
  && cgraph_node::get (fun->decl)->calls_declare_variant_alt));

[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #8 from vfdff  ---
hi @Andrew Pinski
  For the 2nd issue, I also matched the huge pattern, but it need return two
value, it seems don't work with current framework? so should I have to split it
into two simples to match the high and low values of ResHi and ResLo
separately?
```
 (i64 ResLo, i64 ResHi) = Mul64(i64 In0, i64 In1) {
In0Hi = In0(D) & 4294967295;
In0Lo = In0(D) >> 32;
In1Hi = In1(D) & 4294967295;
In1Lo = In1(D) >> 32;
Mull_01 = In0Lo * In1Hi;
Addc = In0Hi * In1Lo + Mull_01;
addc32 = Addc << 32;
ResLo = In0Hi * In1Hi + addc32;
ResHi = ((long unsigned int) (addc32 > ResLo)) + In0Lo * In1Lo +
 (((long unsigned int) (Mull_01 > Addc)) << 32) + (Addc >> 32);
 }
```

[Bug middle-end/107236] New: [OpenMP] ICE for reverse offload: in expand_GOMP_TARGET_REV, at internal-fn.cc:376

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

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

Bug ID: 107236
   Summary: [OpenMP] ICE for reverse offload: in
expand_GOMP_TARGET_REV, at internal-fn.cc:376
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53696=edit
Testcase - compile as: gfortran -fopenmp test.f90

This only shows up if ENABLE_OFFLOADING is true during the GCC build.

The attached testcase fails with:

rev-test-ice.f90:5:33: internal compiler error: in expand_GOMP_TARGET_REV, at
internal-fn.cc:376
5 |   !$omp target device(ancestor:1)
  | ^
0x791309 expand_GOMP_TARGET_REV
   
/net/build1-fossa-cs/scratch/tburnus/fsf.mainline.x86_64-linux-gnu-amdgcn/src/gcc-mainline/gcc/internal-fn.cc:376
0xb2c147 expand_call_stmt

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #37 from Mikael Morin  ---
(In reply to Richard Biener from comment #14)
> I installed a workaround for the ICE, the fortran issue remains

Fortran issue now fixed as well, and backported for 12.3, 11.4, and 10.5
releases.
Closing.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #11 from Mikael Morin  ---
Fixed for 13.1, 12.3, 11.4 and 10.5.
Closing.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Mikael Morin
:

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

commit r12-8826-gd633e1cf67ad06c2fef6c33280b548f9c6ea9eba
Author: Mikael Morin 
Date:   Sat Sep 3 11:58:47 2022 +0200

fortran: Move clobbers after evaluation of all arguments [PR106817]

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

PR fortran/106817

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
to their own separate block.  Append the block of clobbers to
the procedure preliminary block after the argument evaluation
codes for all the arguments.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_4.f90: New test.

(cherry picked from commit 29919bf3b6449bafd02e795abbb1966e3990c1fc)

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #36 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Mikael Morin
:

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

commit r12-8825-g5d645a9dbda0174a25358bf5090640acedec1159
Author: Mikael Morin 
Date:   Mon Aug 29 11:19:29 2022 +0200

fortran: Fix invalid function decl clobber ICE [PR105012]

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
from the just calculated variable reference.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_out_15.f90: New test.

(cherry picked from commit edaf1e005c90b311c39b46d85cea17befbece112)

[Bug libgomp/107227] Compiler bug in private allocatable array in OpenACC compute statement

[shb at gatech dot edu via Gcc-bugs]

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

--- Comment #3 from Spencer Bryngelson  ---
Thanks @tschwinge! I found a few other replicate issues now that I look further
back, going at least to gcc10. Is there a plan to fix this? It seems important
(at least to me).

[Bug modula2/107235] m2/boot-bin/mc leaks file descriptors

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug modula2/107235] New: m2/boot-bin/mc leaks file descriptors

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

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

Bug ID: 107235
   Summary: m2/boot-bin/mc leaks file descriptors
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

Building the current devel/modula-2 branch on Solaris 11.3/SPARC fails like
this:

m2/boot-bin/mc --olang=c++ --h-file-prefix=G
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-compiler
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libiberty
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-gcc --quiet  --gcc-config-system
--extended-opaque -o=m2/gm2-compiler-boot/M2GCCDeclare.c
/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
failed to open
/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-compiler/M2GCCDeclare.mod

(same for m2/gm2-libs/NumberIO.def).

Running mc under truss reveals

8687/1:
open("/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/Debug.def",
O_RDONLY|O_XPG4OPEN) = 255
[...]
8687/1:
open("/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-compiler/M2GCCDeclare.mod",
O_RDONLY|O_XPG4OPEN) Err#24 EMFILE
8687/1: write(2, " f a i l e d   t o   o p".., 84)  = 84

The file is opened several times (and apparent never closed), but the last
attempt (which would use fd 256) fails with EMFILE.  This happens because
Solaris up to 11.3 has a low fd limit of 255.

Raising the resource limit to (say 1024) allows the open to succeed, but mc
fails again shortly thereafter due the the stdio's limit of 255 open files.

There's a work/hack around this by preloading

LD_PRELOAD_32=/usr/lib/extendedFILE.so.1

tjat allows the build to continue, but I'm pretty certain that mc leaks fds
here and could easily avoid this issue by closing files when they are no longer
needed.

[Bug modula2/107234] Format error in m2pp.cc (m2pp_integer_cst)

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug modula2/107234] New: Format error in m2pp.cc (m2pp_integer_cst)

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

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

Bug ID: 107234
   Summary: Format error in m2pp.cc (m2pp_integer_cst)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

Created attachment 53695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53695=edit
Proposed patch

Building the current devel/modula-2 branch on Solaris 11.3 fails:

/vol/gcc/src/hg/master/modula-2/gcc/m2/m2pp.cc: In function 'void
m2pp_integer_cst(pretty*, tree)':
/vol/gcc/src/hg/master/modula-2/gcc/m2/m2pp.cc:2067:26: warning: format '%lu'
expects argument of type 'long unsigned int', but argument 4 has type 'long
long unsigned int' [-Wformat=]
 2067 |   snprintf (val, 100, "%lud", TREE_INT_CST_LOW (t));
  |~~^
  |  |
  |  long unsigned int
  |%llu

This should use HOST_WIDE_INT_PRINT_UNSIGNED instead of hardcoding a specific
format.

[Bug modula2/107233] gm2 build hardcodes python3

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug modula2/107233] New: gm2 build hardcodes python3

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

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

Bug ID: 107233
   Summary: gm2 build hardcodes python3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

When trying to build the current devel/modula-2 branch on Solaris 11.3/SPARC
(only tried on 11.4 before), it fails trying to execute python3
unconditionally:

python3 /vol/gcc/src/hg/master/modula-2/gcc/m2/tools-src/def2texi.py -b./
-f/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/Builtins.def >
/var/gcc/modula-2/11.4-gcc-modula-2/gcc/m2/Builtins.texi
/bin/ksh: python3: not found
make[3]: *** [/vol/gcc/src/hg/master/modula-2/gcc/m2/Make-lang.in:167:
Builtins.texi-check] Error 127

This happens because Solaris 11.3, unlike 11.4, has no python3 command.  It
only
provides python2.7 and python3.4.

I believe this could easily be fixed by using Automake's AM_PATH_PYTHON([3.0])
(or whatever minimal python 3.x version is required), substituting the
resulting
$PYTHON into Make-lang.in and the scripts that currently hardcode python3
instead.

[Bug c++/103752] [12 Regression][ICE][modules] with import

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||andreemalcher at gmail dot com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 100583 has been marked as a duplicate of this bug. ***

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

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

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

Bug 100583 Summary: [modules] ICE when importing 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100583

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 100583 Summary: [modules] ICE when importing 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100583

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/100583] [modules] ICE when importing

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Jonathan Wakely  ---
Fixed by commit r12-7133-g1ce5395977f37e

Date:   Wed Feb 9 00:31:12 2022 -0500

c++: modules and explicit(bool) [PR103752]

We weren't streaming a C++20 dependent explicit-specifier.

PR c++/103752

gcc/cp/ChangeLog:

* module.cc (trees_out::core_vals): Stream explicit specifier.
(trees_in::core_vals): Likewise.
* pt.cc (store_explicit_specifier): No longer static.
(tsubst_function_decl): Clear DECL_HAS_DEPENDENT_EXPLICIT_SPEC_P.
* cp-tree.h (lookup_explicit_specifier): Declare.

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

[Bug tree-optimization/107232] [13 regression] insertion out of range in 'bit_insert_expr' breaks SPARC bootstrap

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-12
 CC||marxin at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107229
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Likely dup of PR107229.

[Bug tree-optimization/107232] [13 regression] insertion out of range in 'bit_insert_expr' breaks SPARC bootstrap

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107232] New: [13 regression] insertion out of range in 'bit_insert_expr' breaks SPARC bootstrap

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

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

Bug ID: 107232
   Summary: [13 regression] insertion out of range in
'bit_insert_expr' breaks SPARC bootstrap
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: avieira at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Between 20221010 (248c8aeebc49aae3fd96bd587367d12e7c8b3c3a) and 20221011
(576d524559776ee6744f478da600939ca5c2d502),
Solaris/SPARC bootstrap broke with

/vol/gcc/src/hg/master/local/gcc/ipa-sra.cc: In member function 'virtual void
ipa_sra_function_summaries::duplicate(cgraph_node*, cgraph_node*,
isra_func_summary*, isra_func_summary*)':
/vol/gcc/src/hg/master/local/gcc/ipa-sra.cc:388:1: error: insertion out of
range in 'bit_insert_expr'
  388 | ipa_sra_function_summaries::duplicate (cgraph_node *, cgraph_node *,
  | ^~
_ifc__128 = BIT_INSERT_EXPR <_ifc__39, 0, 18446744073709551584 (1 bits)>;
/vol/gcc/src/hg/master/local/gcc/ipa-sra.cc:388:1: error: insertion out of
range in 'bit_insert_expr'
_ifc__130 = BIT_INSERT_EXPR <_ifc__128, 0, 18446744073709551585 (1 bits)>;
/vol/gcc/src/hg/master/local/gcc/ipa-sra.cc:388:1: error: insertion out of
range in 'bit_insert_expr'
_ifc__75 = BIT_INSERT_EXPR <_ifc__130, 0, 18446744073709551586 (1 bits)>;
during GIMPLE pass: ifcvt
/vol/gcc/src/hg/master/local/gcc/ipa-sra.cc:388:1: internal compiler error:
verify_gimple failed

/vol/gcc/src/hg/master/local/gcc/lra.cc: In function 'void
setup_operand_alternative(lra_insn_recog_data_t, const operand_alternative*)':
/vol/gcc/src/hg/master/local/gcc/lra.cc:803:1: error: position plus size
exceeds size of referenced object in 'bit_field_ref'
  803 | setup_operand_alternative (lra_insn_recog_data_t data,
  | ^
_ifc__33 = BIT_FIELD_REF <_ifc__32, 1, 18446744073709551602>;
during GIMPLE pass: ifcvt
/vol/gcc/src/hg/master/local/gcc/lra.cc:803:1: internal compiler error:
verify_gimple failed

in stage 3.  This patch

commit 25413fdb2ac24933214123e24ba165026452a6f2
Author: Andre Vieira 
Date:   Tue Oct 11 10:49:27 2022 +0100

vect: Teach vectorizer how to handle bitfield accesses

seemed like a likely culprit, and indeed reverting it locally allowed the build
to succeed.

[Bug tree-optimization/107226] [13 regression] r13-3219-g25413fdb2ac249 caused a lot of testcase failures

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-10-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from avieira at gcc dot gnu.org ---
So this is a regression because SLP is using the new patterns for
BITFIELD_REF's of vector's. Seeing that I never actually found a good use of
supporting non-integral container types I will just remove that and that will
cause the pattern to not match BITFIELD_REF's of vectors.

I'll go test those changes.

[Bug c++/106820] [modules] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via header unit]: mishandling of "weak" usage generated via __gthr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||visibility
   Last reconfirmed||2022-10-12
 Status|UNCONFIRMED |NEW

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> I think I should be able to reproduce this on linux with an older glibc, or
> with libstdc++ modified to use weak symbols again. Trying that now ...

Confirmed. The ICE is still present on trunk.

[Bug c++/106820] [modules] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via header unit]: mishandling of "weak" usage generated via __gthr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||andreemalcher at gmail dot com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 100584 has been marked as a duplicate of this bug. ***

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

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

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

Bug 100584 Summary: [modules] ICE when using import ; with std::jthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100584

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/100584] [modules] ICE when using import ; with std::jthread

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||visibility
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
This is fixed in GCC 11.3 and later, but probably only because we no longer use
weak symbols for pthreads functions, since r11-9301-g293075002a7eaf

The compiler bug is probably still present, and this is almost certainly a dup
of PR 106820

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

[Bug c++/106820] [modules] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via header unit]: mishandling of "weak" usage generated via __gthr

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #6 from Jonathan Wakely  ---
(In reply to Mark Millard from comment #1)
> I've now tried this on fedora 36 with copies of the source code
> and got no failure in the fedora context.

That will be because we no longer use weak symbols for pthreads when linking to
glibc 2.34 or later (as found in recent Fedora releases).

I think I should be able to reproduce this on linux with an older glibc, or
with libstdc++ modified to use weak symbols again. Trying that now ...

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

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

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

Bug ID: 107231
   Summary: [13 Regression] c-c++-common/goacc/kernels-loop-g.c:
'-fcompare-debug' failure (length)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure, openacc
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: erozen at microsoft dot com
Blocks: 104277
  Target Milestone: ---

In a native x86_64-pc-linux-gnu build, when also running testing with '-m32'
('RUNTESTFLAGS="--target_board=unix\{,-m32\}"') I'm seeing a regression for
'-m32' (but not for default '-m64'):

[-PASS:-]{+FAIL:+} c-c++-common/goacc/kernels-loop-g.c (test for excess
errors)
PASS: c-c++-common/goacc/kernels-loop-g.c scan-tree-dump-not parloops1
"FAILED:"
PASS: c-c++-common/goacc/kernels-loop-g.c scan-tree-dump-times optimized
"(?n);; Function .*main._omp_fn.0" 1
PASS: c-c++-common/goacc/kernels-loop-g.c scan-tree-dump-times parloops1
"(?n)__attribute__\\(\\(oacc kernels parallelized, oacc function \\(, , \\),
oacc kernels, omp target entrypoint, noclone\\)\\)" 1
PASS: c-c++-common/goacc/kernels-loop-g.c scan-tree-dump-times parloops1
"SUCCESS: may be parallelized" 1

xgcc: error:
[...]/source-gcc/gcc/testsuite/c-c++-common/goacc/kernels-loop-g.c:
'-fcompare-debug' failure (length)

That's for both C and C++ testing.

Note that this test case is a bit "degenerate" in that it needs
'-fcompare-debug' to compile (safe-guard; refer to PR100400).

Reproduce:

$ build-gcc/gcc/xgcc -Bbuild-gcc/gcc/
source-gcc/gcc/testsuite/c-c++-common/goacc/kernels-loop-g.c -fopenacc
--param=openacc-kernels=decompose -O2 -g -S -fcompare-debug -m32 -save-temps
xgcc: error: source-gcc/gcc/testsuite/c-c++-common/goacc/kernels-loop-g.c:
‘-fcompare-debug’ failure (length)
$ diff -u kernels-loop-g.c.gkd kernels-loop-g.gk.c.gkd
--- kernels-loop-g.c.gkd2022-10-12 11:10:24.902809164 +0200
+++ kernels-loop-g.gk.c.gkd 2022-10-12 11:10:24.950809149 +0200
@@ -601,7 +601,7 @@
 (set (reg/v:SI 0 ax [orig:96 i ] [96])
 (const_int 0 [0]))
 (clobber (reg:CC 17 flags))
-])
"source-gcc/gcc/testsuite/c-c++-common/goacc/kernels-loop.c":36:21 discrim 3#
{*movsi_xor}
+])
"source-gcc/gcc/testsuite/c-c++-common/goacc/kernels-loop.c":36:21#
{*movsi_xor}
  (expr_list:REG_UNUSED (reg:CC 17 flags)
 (nil)))
 (code_label # 0 0 7 13 (nil) [1 uses])

The issue goes away if I revert commit
r13-3213-g80f414e6d73f9f1683f93d83ce63a6a482e54bee "Fix PR107193", commit
r13-3172-gf30e9fd33e56a5a721346ea6140722e1b193db42 "Set discriminators for call
stmts on the same line within the same basic block".

Alternatively, the issue goes away if I pass '-gno-statement-frontiers' (as I
found in the 'c-c++-common/ubsan/pr85213.c' hunk of commit
r13-2921-gf1adf45b17f7f1ede463524d80032bb2ec866ead "Add instruction level
discriminator support", referring to PR100733 "-fcompare-debug failure for
pr85213.c at -O1 -fdisable-tree-phiopt2").  If you confirm that this is indeed
what should currently be done, I'll push that flag onto
'c-c++-common/goacc/kernels-loop-g.c', for the time being?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104277
[Bug 104277] [meta-bug] gstatement-frontiers causes fcompare-debug issues

[Bug tree-optimization/107229] [13 Regression] ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed since r13-3219-g25413fdb2ac24933

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

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

--- Comment #2 from avieira at gcc dot gnu.org ---
So it seems I should have taken DECL_FIELD_OFFSET into account when computing
the bitpos in get_bitfield_rep (tree-if-conv.cc).

I am testing a patch for this whilst I also look at the failures in PR107226

[Bug c++/104433] [modules] Importing and using std::make_shared causes linker errors

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

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

--- Comment #4 from Jonathan Wakely  ---
That looks like PR 106820

[Bug bootstrap/107221] [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed

[Bug target/107160] [13 regression] r13-2641-g0ee1548d96884d causes verification failure in spec2006

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-12
 Ever confirmed|0   |1

--- Comment #6 from Kewen Lin  ---
Confirmed.

The option can be reduced to: -m64 -O3 -mcpu=power8 -ffast-math

The culprit loop is the one in function l1_norm of file vector.cc (actually
it's from the header file). The resulting gimple after loop vect pass looks
weird to me, it seems not to expose one issue related to math but one actual
vect issue. I'll check it further and post one reduced test case.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #21 from Segher Boessenkool  ---
(In reply to Hongtao.liu from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Segher Boessenkool from comment #16)
> > > Hi Roger,
> > > 
> > > (In reply to Roger Sayle from comment #15)
> > > > Yes, a COMPARE rtx can be used to set various flags on x86, but many 
> > > > other
> > > > operations also legitimately set and/or use MODE_CC, often in a parallel
> > > > with the primary operation.
> > > 
> > > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > > MODE_CC *is*.
> > > 
> > > Setting something as ne:CC and then using it as somethingelse:CC has no
> > > defined meaning.
> > 
> > This
> > 
> > (parallel [
> > (set (reg:SI 97) 
> > (neg:SI (ltu:SI (reg:CCC 17 flags)
> > (const_int 0 [0]
> > (clobber (reg:CC 17 flags))
> > ])
> > 
> > still won't work correctly if reg:CCC 17 flags is set by a compare of
> > 2 known values.
> 
> I guess Segher means it should be NE instead of LTU in the
> x86_movcc_0_m1_neg, since the setters is NE to const 0.

Yes.

>  (ne:CCC (reg:SI 87 [ a_lsm.8 ])
> (const_int 0 [0])))
> 
>  (define_expand "x86_movcc_0_m1_neg"
>[(parallel
>  [(set (match_operand:SWI48 0 "register_operand")
> - (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0
> + (neg:SWI48 (ne:SWI48 (reg:CCC FLAGS_REG) (const_int 0
>   (clobber (reg:CC FLAGS_REG))])])
> 
> It can pass the PR, but failed pr101617.c, the f1 case.
> 
> generate:
> testl   %edi, %edi
> movl$1, %edx
> movl$-1, %eax
> cmove   %edx, %eax
> 
> origin:
> negl%edi
> sbbl%eax, %eax
> orl $1, %eax

And this is why using a relation (e.g. ltu, an RTX_COMPARE) instead of a
compare (an RTX_BIN_ARITH) as setter cannot work.  The setter and the getter
are modified independently by very many parts of the compiler, and then
everything falls apart.

The only valid things on the RHS of a MODE_CC set are a reg, a compare, or
an unspec.  Everything else is undefined and problematical as well.

[Bug tree-optimization/107229] [13 Regression] ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed since r13-3219-g25413fdb2ac24933

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-12
 Status|UNCONFIRMED |NEW
Version|unknown |13.0
 CC||andre.simoesdiasvieira@arm.
   ||com, marxin at gcc dot gnu.org
   Target Milestone|--- |13.0
Summary|ICE at -O1 and -Os with |[13 Regression] ICE at -O1
   |"-ftree-vectorize": |and -Os with
   |verify_gimple failed|"-ftree-vectorize":
   ||verify_gimple failed since
   ||r13-3219-g25413fdb2ac24933

--- Comment #1 from Martin Liška  ---
Started with r13-3219-g25413fdb2ac24933.

[Bug libgomp/107227] Compiler bug in private allocatable array in OpenACC compute statement

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

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to Spencer Bryngelson from comment #0)
> 5 | !$acc parallel loop private(arr(1:10))
>   |1
> Error: Syntax error in OpenMP variable list at (1)

That's because, at this time, OpenACC subarray specifications do not apply to
'private' clauses, but only to data clauses.

This is being discussed in 
"private clause with subarrays" (only available to members of the GitHub
OpenACC organization).

[Bug jit/107230] New: libgccjit rejects -march=native

[helohe at bluewin dot ch via Gcc-bugs]

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

Bug ID: 107230
   Summary: libgccjit rejects -march=native
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: helohe at bluewin dot ch
  Target Milestone: ---

Using the tutorial example 1 and adding 

 gcc_jit_context_add_command_line_option (ctxt, "-march=native");
 gcc_jit_context_add_command_line_option (ctxt, "-mtune=native");

results in an error on both Mingw64 and Debian linux.

Bad value 'native' then valid options are listed which does include native
contradiction itself.


$ ./tut01-hello-world.exe
libgccjit.so: error: bad value 'native' for '-march=' switch
libgccjit.so: note: valid arguments to '-march=' switch are: nocona core2
nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell
core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake
icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake
bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64
x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000
nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3
athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3
btver1 btver2 native
Assembler messages:
Error: can't open C:\msys64\tmp\\libgccjit-123186/fake.s for reading: No such
file or directory
libgccjit.so: error: error invoking gcc driver
NULL result

[Bug c++/107218] [13 Regression] ICE in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with the same revision as PR107198.

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

[Bug c++/107198] [13 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9

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

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

--- Comment #2 from Martin Liška  ---
*** Bug 107218 has been marked as a duplicate of this bug. ***

[Bug fortran/107214] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||julian at codesourcery dot com,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE: base   |[13 Regression] ICE: base
   |pointer cycle detected  |pointer cycle detected
   ||since
   ||r13-2661-gb57abd072dd319a7
   Last reconfirmed||2022-10-12

--- Comment #1 from Martin Liška  ---
Started with r13-2661-gb57abd072dd319a7.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 107228 Summary: [13 Regression] ICE: in verify_range, at 
value-range.cc:1147 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107228

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/107228] [13 Regression] ICE: in verify_range, at value-range.cc:1147 -O2

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||vsevolod.livinskiy at gmail 
dot co
   ||m

--- Comment #9 from Martin Liška  ---
*** Bug 107228 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107229] New: ICE at -O1 and -Os with "-ftree-vectorize": verify_gimple failed

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

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

Bug ID: 107229
   Summary: ICE at -O1 and -Os with "-ftree-vectorize":
verify_gimple failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a very recent regression as it doesn't seem to fail with the
build from Compiler Explorer. 

[541] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221012 (experimental) [master r13-3246-g1c0670c62fc] (GCC) 
[542] % 
[542] % gcctk -O1 small.c; ./a.out
[543] % 
[543] % gcctk -O1 -ftree-vectorize small.c
small.c: In function ‘main’:
small.c:9:5: error: invalid position or size operand to ‘bit_field_ref’
9 | int main() {
  | ^~~~
_ifc__17 = BIT_FIELD_REF <_ifc__16, 21, 0xffc0>;
during GIMPLE pass: ifcvt
small.c:9:5: internal compiler error: verify_gimple failed
0xf3b99a verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.cc:5649
0xdf9d17 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2091
0xdfa2bb execute_todo
../../gcc-trunk/gcc/passes.cc:2145
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.
[544] % 
[544] % cat small.c
int a, c;
struct {
  long d;
  int : 8;
  int : 27;
  int e : 21;
} f;
void g(int b) { a = a & 1; }
int main() {
  while (c)
g(f.e);
  return 0;
}

[Bug libgomp/107227] Compiler bug in private allocatable array in OpenACC compute statement

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge  ---
Thanks for the report!

Probably a duplicate of PR93554: exactly same ICE, backtrace.

[Bug middle-end/95550] [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||tschwinge at gcc dot gnu.org
   Keywords||ice-on-valid-code
   Last reconfirmed||2022-10-12
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93554

--- Comment #3 from Thomas Schwinge  ---
Thanks for the report!

Probably a duplicate of PR93554: exactly same ICE, backtrace.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Hongtao.liu  ---
> generate:
> testl   %edi, %edi
> movl$1, %edx
> movl$-1, %eax
> cmove   %edx, %eax
> 
> origin:
> negl%edi
> sbbl%eax, %eax
> orl $1, %eax

It now go through *if-conversion succeeded through noce_try_cmove_arith*
instead of original *if-conversion succeeded through noce_try_cmove*.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Hongtao.liu  ---
(In reply to H.J. Lu from comment #18)
> (In reply to Segher Boessenkool from comment #16)
> > Hi Roger,
> > 
> > (In reply to Roger Sayle from comment #15)
> > > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > > operations also legitimately set and/or use MODE_CC, often in a parallel
> > > with the primary operation.
> > 
> > *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> > MODE_CC *is*.
> > 
> > Setting something as ne:CC and then using it as somethingelse:CC has no
> > defined meaning.
> 
> This
> 
> (parallel [
> (set (reg:SI 97) 
> (neg:SI (ltu:SI (reg:CCC 17 flags)
> (const_int 0 [0]
> (clobber (reg:CC 17 flags))
> ])
> 
> still won't work correctly if reg:CCC 17 flags is set by a compare of
> 2 known values.

I guess Segher means it should be NE instead of LTU in the
x86_movcc_0_m1_neg, since the setters is NE to const 0.

 (ne:CCC (reg:SI 87 [ a_lsm.8 ])
(const_int 0 [0])))

 (define_expand "x86_movcc_0_m1_neg"
   [(parallel
 [(set (match_operand:SWI48 0 "register_operand")
- (neg:SWI48 (ltu:SWI48 (reg:CCC FLAGS_REG) (const_int 0
+ (neg:SWI48 (ne:SWI48 (reg:CCC FLAGS_REG) (const_int 0
  (clobber (reg:CC FLAGS_REG))])])

It can pass the PR, but failed pr101617.c, the f1 case.

generate:
testl   %edi, %edi
movl$1, %edx
movl$-1, %eax
cmove   %edx, %eax

origin:
negl%edi
sbbl%eax, %eax
orl $1, %eax

[Bug libfortran/107223] GCC 12.2 fails compilation on Linux PowerPC In function 'bessel_jn_r17':

[skoerner at nvidia dot com via Gcc-bugs]

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

--- Comment #2 from Sebastian Koerner  ---
I used these packages (from source)
mpfr-4.1.0
gmp-6.2.1
mpc-1.2.1
binutils-2.38
gcc-12.2.0
isl-0.24

and this configure line
./configure --prefix=  --enable-gold --enable-plugin
--enable-languages=c,c++,fortran,objc,obj-c++ --with-gcc-major-version-only
--enable-shared --enable-static --disable-multilib --without-included-gettext
--enable-threads=posix --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --enable-linker-build-id --disable-libquadmath
--disable-libquadmath-support --enable-default-pie --enable-secureplt
--enable-multiarch --disable-werror  --with-cpu=power8
--enable-targets=powerpcle-linux --with-long-double-128
--enable-checking=release --build=powerpc64le-unknown-linux-gnu
--host=powerpc64le-unknown-linux-gnu --target=powerpc64le-unknown-linux-gnu

Now that I read it: disable-quadmath? But why is working on gcc 11.3.0 and with
12.2.0 on x86 and aarch64?

[Bug tree-optimization/107228] New: [13 Regression] ICE: in verify_range, at value-range.cc:1147 -O2

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 107228
   Summary: [13 Regression] ICE: in verify_range, at
value-range.cc:1147 -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/fsGf47Wfv

Reproducer:
bool a;
char b;
void fn1(int d, short x[], bool y[]) {
  for (short i = 0; i < d; i = 0) {
if ((x[i] + x[i]) ^ !y[i])
  a = 0;
b = y[i];
  }
}

Error:
>$ g++ -c -O2 func.cpp 
during GIMPLE pass: dom
func.cpp: In function 'void fn1(int, short int*, bool*)':
func.cpp:3:6: internal compiler error: in verify_range, at value-range.cc:1147
3 | void fn1(int d, short x[], bool y[]) {
  |  ^~~
0x90038d irange::verify_range()
/testing/gcc/gcc_src_master/gcc/value-range.cc:1147
0x1588a87 irange::operator=(irange const&)
/testing/gcc/gcc_src_master/gcc/value-range.cc:818
0x158bd67 irange::invert()
/testing/gcc/gcc_src_master/gcc/value-range.cc:2799
0x2178487 operator_logical_not::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_kind_t) const
/testing/gcc/gcc_src_master/gcc/range-op.cc:3614
0x2074635 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1086
0x2073c8d gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:692
0x20746af gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1140
0x2073c8d gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:692
0x2074fc0 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1228
0x20734e5 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:694
0x2077158 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
/testing/gcc/gcc_src_master/gcc/gimple-range-gori.cc:1358
0x20679ec ranger_cache::edge_range(vrange&, edge_def*, tree_node*,
ranger_cache::rfd_mode)
/testing/gcc/gcc_src_master/gcc/gimple-range-cache.cc:964
0x2063d4b gimple_ranger::range_on_edge(vrange&, edge_def*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:242
0x206d86b fold_using_range::range_of_phi(vrange&, gphi*, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:750
0x20706b8 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:491
0x2062de4 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:258
0x2062de4 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:319
0x20639c0 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:126
0x1398aaf cprop_operand
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:1968
0x139aa61 cprop_into_stmt
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:2045
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

gcc version 13.0.0 20221011 (0ecd0f1cc6f8f3ba818946a42b22c2ab61f46825)