[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[dantipov at cloudlinux dot com via Gcc-bugs]

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

Dmitry Antipov  changed:

   What|Removed |Added

 CC||dantipov at cloudlinux dot com

--- Comment #3 from Dmitry Antipov  ---
Thanks. BTW is it possible to make the diagnostics some more
developer-friendly? In particular, plain 'gcc test.c' doesn't specify any
target-specific options explicitly, and it may be required to look through
'arm_acle.h' to realize that the thing like 'gcc -march=armv8.5-a+rng test.c'
is required instead.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #4 from Jakub Jelinek  ---
Why?  You shouldn't use the builtins directly, they are implementation detail
for implementing the intrinsics and the intrinsics don't suffer ever from this
problem
because they ensure the correct target options already.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[dantipov at cloudlinux dot com via Gcc-bugs]

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

--- Comment #5 from Dmitry Antipov  ---
# cat t-rand.c 
#include 
#include 

int main(int argc, char *argv[]) {
  uint64_t v;
  __rndr(&v);
  return 0;
}

# gcc t-rand.c 
In file included from t-rand.c:2:
/usr/lib/gcc/aarch64-redhat-linux/12/include/arm_acle.h: In function ‘main’:
/usr/lib/gcc/aarch64-redhat-linux/12/include/arm_acle.h:313:1: error: inlining
failed in call to ‘always_inline’ ‘__rndr’: target specific option mismatch
  313 | __rndr (uint64_t *__res)
  | ^~
t-rand.c:6:3: note: called from here
6 |   __rndr(&v);
  |   ^~

So, what target-specific option is wrong if none of them was specified?

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #6 from Jakub Jelinek  ---
That message indeed could at least print the diff between the target options of
the caller and callee as a follow-up note.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

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

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, GCC could be more helpful here. The intrinsics and their use is documented
in the ACLE document:
https://github.com/ARM-software/acle/blob/main/main/acle.md#random-number-generation-intrinsics
There is work ongoing to augument it with more user-friendly information about
compiler flags, but GCC could keep track of the options used to gate these
builtins/intrinsics and report a hint

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[13 regression] ICE in  |[13 regression] ICE in
   |possibly_call_in_translatio |possibly_call_in_translatio
   |n_unit_p, at cgraph.cc:4184 |n_unit_p, at cgraph.cc:4184
   ||since
   ||r13-5285-g106f99406312d7ed

--- Comment #1 from Martin Liška  ---
I see the same crash on Linux, started with r13-5285-g106f99406312d7ed.

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-25

--- Comment #2 from Martin Liška  ---
The problematic symbol is:

Breakpoint 1, cgraph_edge::possibly_call_in_translation_unit_p
(this=0x77629270) at /home/marxin/Programming/gcc/gcc/cgraph.cc:4159
4159  gcc_checking_assert (in_lto_p && caller->prevailing_p ());
(gdb) p node->debug()
_ZN1aIN12_GLOBAL__N_11fEED1Ev/5 (__dt_comp )
  Type: function
  Visibility: semantic_interposition external virtual
  References: 
  Referring: 
  Read from file: a-pr88049_0.o
  Unit id: 1
  Function flags:
  Called by: _Z41__static_initialization_and_destruction_0v/2 
  Calls: 

(gdb) p debug_tree(node->decl)
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
method basetype 
arg-types 
chain >>
pointer_to_this >
addressable external virtual QI
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049_0.C:12:11
align:16 warn_if_not_align:0 context >
$2 = void

[Bug tree-optimization/108449] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1512

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

--- Comment #4 from Guo Youtao  ---
Created attachment 54340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54340&action=edit
the preprocessed file generated by g++-11

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

--- Comment #5 from Guo Youtao  ---
This bug can still be triggered in gcc-11 and gcc-12.

Here are the codes (the preprocessed file is attached)
```
#include 
#include 

template 
constexpr auto is_pointer_v = std::is_pointer::value;

template 
auto Wrap1(int) -> std::integral_constant().operator->())>>;

template 
auto Wrap1(...) -> std::is_pointer;

int main() {
  static_assert(!is_pointer_v>); // this line can compile
  static_assert(decltype(Wrap1>(0))::value); // error
  return 0;
}
```

The err msgs
```
% g++-11 a.cc -save-temps
a.cc: In instantiation of 'constexpr const auto is_pointer_v':
a.cc:8:49:   required by substitution of 'template > std::integral_constant().operator->())> > Wrap1(int) [with Tp =
std::unique_ptr; decltype (& Tp::operator*)*  = ]'
a.cc:15:53:   required from here
a.cc:5:16: error: the type 'const auto' of 'constexpr' variable
'is_pointer_v' is not literal
5 | constexpr auto is_pointer_v = std::is_pointer::value;
  |^~~~
a.cc:5:16: error: 'const auto is_pointer_v' has incomplete type
a.cc: In function 'int main()':
a.cc:15:59: error: static assertion failed
   15 |   static_assert(decltype(Wrap1>(0))::value); //
this line incurs error
  | ~~^
```


GCC version:
```
% gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.3.0_2/bin/../libexec/gcc/x86_64-apple-darwin21/11/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: ../configure --prefix=/usr/local/opt/gcc
--libdir=/usr/local/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release
--with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,d
--program-suffix=-11 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd
--with-pkgversion='Homebrew GCC 11.3.0_2'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--enable-libphobos --build=x86_64-apple-darwin21 --with-system-zlib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Homebrew GCC 11.3.0_2)
```

If remove the parameter `decltype(&Tp::operator*)* = nullptr` then codes can be
compiled.

The error also happens in gcc-12.

[Bug sanitizer/108514] ASAN at -O0 missed a stack-use-after-scope

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
>   for (; b != 9; b = 9) {
> int g=7;
> f = &g;
>   }
>   e = (c = d, a) || *f;

Here again, a is non-zero and thus *f does not need to be evaluated. That's
what you see with -O0. With -O1 it's evaluated as a result of optimization.
Note clang does not report the use-after-score at all in this case.

[Bug rtl-optimization/108508] [12/13 Regression] ICE in insert_def_after, at rtl-ssa/accesses.cc:622 since r12-4759-g95bb87b2458bfa

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-25
 CC||aoliva at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[12/13 Regression] ICE in
   |insert_def_after, at|insert_def_after, at
   |rtl-ssa/accesses.cc:622 |rtl-ssa/accesses.cc:622
   ||since
   ||r12-4759-g95bb87b2458bfa

--- Comment #1 from Martin Liška  ---
It's there likely since the introduction of -fharden-conditional-branches:
r12-4759-g95bb87b2458bfa.

[Bug c++/108536] New: Difference when using requires and enable_if with class constructor

[hr.jonas.hansen at gmail dot com via Gcc-bugs]

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

Bug ID: 108536
   Summary: Difference when using requires and enable_if with
class constructor
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hr.jonas.hansen at gmail dot com
  Target Milestone: ---

In the code below I have used a requires-clause. This requires-clause used to
be an enable_if. When using enable_if the code compiles without errors, but
using the requires-clause (see below) causes a compilation error when combined
with the rest of the example. That is, the example contains two classes ClassA
and ClassB. If either of the classes ClassA and ClassB are removed then the
code compiles without errors.


Compile with: g++ -std=c++20 example.cpp



#include 

struct Base {
Base() noexcept = default;

template >
// If this requires-clause is replaces with an enable_if then the code
compiles fine
requires(!std::is_same_v
 && std::is_constructible_v)
Base(F&&) {}
};

struct Derived : public Base {
using Base::Base;
void operator()() const;
};

class ClassA {
// The class ClassB must be present for the bug to manifest
class ClassB;

// This is the only usage of 'Derived'
Derived const f;
};

// This class and its contructor must be included for the bug to manifest
class ClassA::ClassB {
ClassB();
};

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

Daniel Lundin  changed:

   What|Removed |Added

 CC||daniel.lundin.mail at gmail 
dot co
   ||m

--- Comment #3 from Daniel Lundin  ---
This is a bug as in the wrong text is displayed in the diagnostic message. gcc
picks `__int128` and it is not an unsigned type.

Decimal integer constants use the the quoted list in 6.4.4.1: `int` then `long`
then `long long`. Therefore this normative text (from C99 to C23) applies: "If
all of the types in the list for the constant are signed, the extended integer
type shall be signed."

gcc behaves just like required too, since `__int128` ought to be one of the
extended integer types and it is signed.

I would guess this message is some remain from C90 where extended integer types
didn't exist. Compiling with -std=c90 adds an additional warning "warning: this
decimal constant is unsigned only in ISO C90". It would appear that this is the
correct warning that should always be displayed. Seems to be a minor bug that
occurred during the switch (gcc 5.0.0) from gnu90 to gnu11 as default option.

[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
Btw. started with r8-7594-g078c5aff5ed83e9c.

[Bug tree-optimization/108498] [11/12/13 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging

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

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

--- Comment #25 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:617be7ba436bcbf9d7b883968c6b3c011206b56c

commit r13-5342-g617be7ba436bcbf9d7b883968c6b3c011206b56c
Author: Jakub Jelinek 
Date:   Wed Jan 25 10:50:27 2023 +0100

store-merging: Disable string_concatenate mode if start or end aren't byte
aligned [PR108498]

The first of the following testcases is miscompiled on powerpc64-linux -O2
-m64 at least, the latter at least on x86_64-linux -m32/-m64.
Since GCC 11 store-merging has a separate string_concatenation mode which
turns stores into setting a MEM_REF from a STRING_CST.
This mode is triggered if at least one of the to be merged stores
is a STRING_CST store and either the first store (to earliest address)
is that STRING_CST store or the first store is 8-bit INTEGER_CST store
and then there are some rules when to turn that mode off or not merge
further stores into it.

The problem with these 2 testcases is that the actual implementation
relies on start/width of the store to be at byte boundaries, as it
simply creates a char array, MEM_REF can be only on byte boundaries
and the char array too, plus obviously STRING_CST as well.
But as can be easily seen in the second testcase, nothing verifies this,
while the first store has to be a STRING_CST (which will be aligned)
or 8-bit INTEGER_CST, that 8-bit INTEGER_CST store could be a bitfield
store, nothing verifies any stores in between whether they actually are
8-bit and aligned, the only major requirement is that all the stores
are consecutive.

For GCC 14 I think we should reconsider this, simply treat STRING_CST
stores during the merging like INTEGER_CST stores and deal with it only
during split_group where we can create multiple parts, this part
would be a normal store, this part would be STRING_CST store, this part
another normal store etc.  But that is quite a lot of work, the following
patch just disables the string_concatenate mode if boundaries aren't byte
aligned in the spot where we disable it if it is too short too.
If that happens, we'll just try to do the merging using normal 1/2/4/8 etc.
byte stores as usually with RMW masking for any bits that shouldn't be
touched or punt if we end up with too many stores compared to the original.

Note, an original STRING_CST store will count as one store in that case,
something we might want to reconsider later too (but, after all,
CONSTRUCTOR
stores (aka zeroing) already have the same problem, they can be large and
expensive and we still count them as one store).

2023-01-25  Jakub Jelinek  

PR tree-optimization/108498
* gimple-ssa-store-merging.cc (class store_operand_info):
End coment with full stop rather than comma.
(split_group): Likewise.
(merged_store_group::apply_stores): Clear string_concatenation if
start or end aren't on a byte boundary.

* gcc.c-torture/execute/pr108498-1.c: New test.
* gcc.c-torture/execute/pr108498-2.c: New test.

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

--- Comment #3 from Richard Biener  ---
Hmm,

make check-g++ RUNTESTFLAGS="--target_board=unix/\{,-m32\} lto.exp=pr88049_0.C"

works just fine for me?

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

--- Comment #10 from Richard Biener  ---
We don't converge:

Predication says _347 and _346 are equal on edge 108 -> 20
Setting value number of g_6_lsm.126_456 to _346 (changed)
Iterating to 25 BB20
...
Setting value number of g_6_lsm.126_456 to _347 (changed)
Iterating to 25 BB20
...
Predication says _347 and _346 are equal on edge 108 -> 20
Setting value number of g_6_lsm.126_456 to _346 (changed)
Iterating to 25 BB20
...
Setting value number of g_6_lsm.126_456 to _347 (changed)
Iterating to 25 BB20
...

[Bug other/93090] RFE: Add a frontend for the Rust programming language

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

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

--- Comment #6 from Jonathan Wakely  ---
Can this be closed now?

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

--- Comment #4 from Martin Liška  ---
Yeah, the test is normally run with -r argument, so just run it with;

g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049_0.C -flto
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049_0.C:12:11:
warning: ‘a<  >::~a() noexcept [with
 = {anonymous}::f]’ used but never defined
   12 |   virtual ~a();
  |   ^
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049_0.C:9:28:
warning: ‘a d(char) [with e = {anonymous}::f]’ used but never defined
9 | template  a d(char);
  |^
during IPA pass: fnsummary
lto1: internal compiler error: in possibly_call_in_translation_unit_p, at
cgraph.cc:4184
0x6aa523 cgraph_edge::possibly_call_in_translation_unit_p()
/home/marxin/Programming/gcc/gcc/cgraph.cc:4184
0xb65ad0 read_ipa_call_summary
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.cc:4406
0xb69a1f inline_read_section
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.cc:4616
0xb69e98 ipa_fn_summary_read
/home/marxin/Programming/gcc/gcc/ipa-fnsummary.cc:4648
0xcedcf6 ipa_read_summaries_1
/home/marxin/Programming/gcc/gcc/passes.cc:3001
0x8ae4e4 read_cgraph_and_symbols(unsigned int, char const**)
/home/marxin/Programming/gcc/gcc/lto/lto-common.cc:2936
0x894892 lto_main()
/home/marxin/Programming/gcc/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.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/108537] New: constexpr UB pointer dereference compiles if the dereferenced value is not used

[ed at edwardrosten dot com via Gcc-bugs]

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

Bug ID: 108537
   Summary: constexpr UB pointer dereference compiles if the
dereferenced value is not used
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at edwardrosten dot com
  Target Milestone: ---

The following code compiles successfully:

constexpr int a(){
int* b = new int[1];
int r= &b[100]-b; //UB
b[100];  //UB
delete[] b;
return r;
}


template int N=0;

int foo(){
return N;
}


b[100] is unconditionally undefined behaviour, even though the value is never
used.

Tested on a scattering of versions (10.3, 11.2, 12.2) with -std=c++2a -O2

[Bug tree-optimization/108498] [11/12 Regression] ppc64 big endian generates uninitialized reads with -fstore-merging

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ppc64 |[11/12 Regression] ppc64
   |big endian generates|big endian generates
   |uninitialized reads with|uninitialized reads with
   |-fstore-merging |-fstore-merging

--- Comment #26 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Daniel Lundin from comment #3)
> gcc behaves just like required too, since `__int128` ought to be one of the
> extended integer types and it is signed.

But it's not an extended integer type, see comment 2.

I think that will change for C23, which allows intmax_t to be be defined to
long long even if there are larger extended integer types. But in GCC today,
there are no extended integer types.

[Bug c++/108536] Difference when using requires and enable_if with class constructor

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

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug, you've just transformed your working code to use a
requires-clause incorrectly.

This works fine:

template >
requires (!std::derived_from)
 && std::constructible_from
Base(F&&) {}

[Bug other/93090] RFE: Add a frontend for the Rust programming language

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

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Jonathan Wakely from comment #6)
> Can this be closed now?

Yes.

I think there is still some money in the Bountysource campaign, not sure what
will happen with it. I'll contact them and make sure the money doesn't go to
waste.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

--- Comment #11 from Richard Biener  ---
So the issue is that we oscillate between recognizing the PHI as degenerate
because of an equivalence recorded on the non-backedge(!) to the backedge value
which in turn changes because of this change:

Value numbering stmt = g_6_lsm.126_456 = PHI 
Setting value number of g_6_lsm.126_456 to _347
...
Value numbering stmt = _350 = g_6_lsm.126_456;
Setting value number of _350 to _347 (changed)
_347 is available for _347
Value numbering stmt = _352 = _348 ^ _350;
_347 is available for _347
Match-and-simplified _348 ^ _350 to _346
RHS _348 ^ _350 simplified to _346
Setting value number of _352 to _346 (changed)
_346 is available for _346
Value numbering stmt = g_6_lsm.126_304 = _352;
Setting value number of g_6_lsm.126_304 to _346 (changed)
_346 is available for _346
Looking for changed values of backedge 19->20 destination PHIs
Setting value number of g_481.64_448 to g_481.64_448
Setting value number of .MEM_464 to .MEM_409
Predication says _347 and _346 are equal on edge 108 -> 20
Setting value number of g_6_lsm.126_456 to _346 (changed)
Iterating to 25 BB20
...
Value numbering stmt = g_6_lsm.126_456 = PHI 
Predication says _347 and _346 are equal on edge 108 -> 20
Setting value number of g_6_lsm.126_456 to _346
...
Value numbering stmt = _350 = g_6_lsm.126_456;
Setting value number of _350 to _346 (changed)
_346 is available for _346
Value numbering stmt = _352 = _348 ^ _350;
_346 is available for _346
Match-and-simplified _348 ^ _350 to _347
RHS _348 ^ _350 simplified to _347
Setting value number of _352 to _347 (changed)
_347 is available for _347
Value numbering stmt = g_6_lsm.126_304 = _352;
Setting value number of g_6_lsm.126_304 to _347 (changed)
_347 is available for _347
Looking for changed values of backedge 19->20 destination PHIs
Setting value number of g_481.64_448 to g_481.64_448
Setting value number of .MEM_464 to .MEM_409
Setting value number of g_6_lsm.126_456 to _347 (changed)
Iterating to 25 BB20

and repeat.

And we have:

  _348 = _346 ^ _347;

and

 [local count: 42914375]:
# g_1198.66_449 = PHI <_358(141), 0(17)>
# g_6_lsm.126_131 = PHI 
g_481_lsm.127_447 = 1;
_57 = g_6_lsm.126_131;
_58 = _57 ^ _348;
g_6_lsm.126_338 = _58;
if (_346 != _347)
  goto ; [5.50%]
else
  goto ; [94.50%]

 [local count: 40554084]:
goto ; [100.00%]


So when the value we compare to oscillates.  Interestingly when I try
to feed a similar case into FRE1 that "works":

int foo (int a, int b, int n)
{
  int val = a;
  if (a == b)
{
  do
{
  val = (a ^ b) ^ val;
}
  while (--n > 0);
}
  return val;
}

but maybe this is by luck.  So what we need to avoid is for an equivalence
a == b, to oscillate between 'a' and 'b' as result.

[Bug c++/108536] Difference when using requires and enable_if with class constructor

[hr.jonas.hansen at gmail dot com via Gcc-bugs]

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

--- Comment #2 from hr.jonas.hansen at gmail dot com ---
I can see that, and that would work. But it really seems like a work-around? Is
there a reason for the difference in behavior?

[Bug rust/93090] RFE: Add a frontend for the Rust programming language

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
 CC||dkm at gcc dot gnu.org,
   ||gcc-rust at gcc dot gnu.org
  Component|other   |rust
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely  ---
Fixed for GCC 13 then

[Bug c++/108536] Difference when using requires and enable_if with class constructor

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

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

--- Comment #3 from Jonathan Wakely  ---
Because a requires-clause is not just different syntax for enable_if, it works
differently. Different things are different. 

If you want exactly the same behaviour as your enable_if version (which you
didn't show here) then just use that.

[Bug c++/108538] New: unexpected -Wnarrowing errors in -fpermissive mode

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 108538
   Summary: unexpected -Wnarrowing errors in -fpermissive mode
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

int main()
{
unsigned char a[1] = { -1 };
return a[0];
}

$ g++ -fpermissive nar.cpp 
nar.cpp: In function ‘int main()’:
nar.cpp:3:28: error: narrowing conversion of ‘-1’ from ‘int’ to ‘unsigned char’
[-Wnarrowing]
3 | unsigned char a[1] = { -1 };


While I know that some -Wnarrowing
warnings were promoted to an errors,
was it the right decision also in
-fpermissive mode, which accepts most
of the C code?

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
I don't know what the assert really wants to check but

  /* If callee is local to the original translation unit, it will be
 defined.  */
  if (!TREE_PUBLIC (callee->decl) && !DECL_EXTERNAL (callee->decl))
return true;

is now possibly "wrong".  The cases I changed are DECL_EXTERNAL && !TREE_PUBLIC
to no longer make them TREE_PUBLIC (not sure why the FE sets DECL_EXTERNAL,
possibly because it's a declaration).  But "local to the original TU" should
be just !TREE_PUBLIC, no?

Anyway, I can't make real sense of what the function should do, my
understanding of the comment doesn't match up with the code ...

Honza?

[Bug ipa/108511] [13 regression] ICE in possibly_call_in_translation_unit_p, at cgraph.cc:4184 since r13-5285-g106f99406312d7ed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
It depends on the selected C++ standard.  C++11 does not allow narrowing
conversions unconditionally.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||needs-reduction

--- Comment #12 from Richard Biener  ---
I have a patch but the testcase is too large.

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Andreas Schwab from comment #1)
> It depends on the selected C++ standard.  C++11 does not allow narrowing
> conversions unconditionally.

Yes, I am not disputing that.
But I used -fpermissive mode to
compile the mix of c/c++.
-fpermissive downgrades many C++
errors to a warning, eating most
of the regular C. So my question
here is explicitly about -fpermissive
mode, I think it should downgrade
-Wnarrowing back into the warning.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

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

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

commit r13-5348-gc29d85359add807200a1a851026b4e4a9d6b714c
Author: Richard Biener 
Date:   Wed Jan 25 13:31:46 2023 +0100

tree-optimization/108523 - fix endless iteration in VN

The following fixes not converging iteration in value-numbering of
PHI nodes when we use an equivalence to prove the PHI node is
degenerate.  We have to avoid the situation where we oscillate
between the two equivalent values because the result is fed back
via a backedge.

PR tree-optimization/108523
* tree-ssa-sccvn.cc (visit_phi): Avoid using the exclusive
backedge value for the result when using predication to
prove equivalence.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

--- Comment #14 from Richard Biener  ---
Fixed, but I'll see if somebody comes up with a reduced testcase.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #12 from Siddhesh Poyarekar  ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array. 
> 
> do you mean for the following example:
> 
> typedef struct {
>   char pad;
>   char data[];
> } F2;
> 
> typedef struct {
>   unsigned pad;
>   F2 flex;
> } S2;
> 
> although C standard disallow the above, GCC extension treats S2.flex.data as
> a flex-array? 
> 
> How about:
> 
> typedef struct {
>   char pad;
>   char data[];
> } F2;
> 
> typedef struct {
>   F2 flex;
>   unsigned pad;
> } S2;
> 
> do we have any documentation on this Gcc extension?

There's an open bug to document these semantics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650(In reply to
rguent...@suse.de from comment #11)
> On Tue, 24 Jan 2023, qing.zhao at oracle dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
> > 
> > --- Comment #10 from Qing Zhao  ---
> > > --- Comment #9 from Richard Biener  ---
> > > 
> > > GCC handles for example
> > > 
> > > struct A { char data[1]; };
> > > struct B { int n; struct A a; };
> > > 
> > > as if the a.data[] array is a flex-array.
> > 
> > Okay. Then the maximum size of __builtin_object_size for it should be -1,
> > right?
> 
> I think so.

Why?  If the a B object is allocated with a visible allocator call, we can
return the correct size here too.

[Bug c++/104234] ICE with -fmodules-ts and std::map/_Rb_tree

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-25

[Bug libstdc++/107792] Output of default contract violation handler could be improved

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Done

[Bug c++/108539] New: Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

[arheik at dnainternet dot net via Gcc-bugs]

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

Bug ID: 108539
   Summary: Wrong register usage for -m16 -masm=intel -march=i386
on asm volatile
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arheik at dnainternet dot net
  Target Milestone: ---

Consider the following code (test.cpp):

void test(unsigned char& a, unsigned char& b)
{
unsigned char _a, _b;
asm volatile(
"mov dx, 0\n"
"mov bx, 0\n"
: "=dl" (_a), "=dh" (_b)
:
: "bx"
);
a = _a;
b = _b;
}

void main(void)
{
unsigned char a, b;
test(a, b);
}

Compiled with:
g++ -m16 -masm=intel -march=i386 -ffreestanding -fno-inline -mregparm=3
-fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-ident -O2 test.cpp -o
- -S

This generates for test():

_Z4testRhS_:
.LFB0:
pushesi
.LCFI0:
pushebx
.LCFI1:
mov ecx, edx
#APP
# 4 "test.cpp" 1
mov dx, 0
mov bx, 0

# 0 "" 2
#NO_APP
mov ebx, esi
mov BYTE PTR [eax], bl
mov BYTE PTR [ecx], dl
pop ebx
.LCFI2:
pop esi
.LCFI3:
ret

In which bl usage is clearly wrong (dh is missing) and ebx/eax/esi usage looks
suspect.

Compling with -mregparm=0 produces for test():

_Z4testRhS_:
.LFB0:
pushebx
.LCFI0:
#APP
# 4 "test.cpp" 1
mov dx, 0
mov bx, 0

# 0 "" 2
#NO_APP
mov eax, DWORD PTR 8[esp]
mov BYTE PTR [eax], cl
mov eax, DWORD PTR 12[esp]
mov BYTE PTR [eax], dl
pop ebx
.LCFI1:
ret

Which should use dh instead of cl.

[Bug c++/108539] Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

[arheik at dnainternet dot net via Gcc-bugs]

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

--- Comment #1 from arheik at dnainternet dot net ---
Reproduced with these:

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

and

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

[Bug c++/108539] Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That is just misunderstanding of the inline asm syntax, please read the
documentation.
"=dl" doesn't mean that _a output is in %dl register, but either in %edx
register or
in any of the index registers (%eax %ebx %ecx %edx %esi %edi %ebp).
"=dh" means either in %edx register or in nowhere (h isn't a valid constraint).
So, when doing RA _b needs to be put into %edx (the low 8 bits of that aka %dl)
and _a into some index register other than %edx.

[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119

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

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

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

This hack works around it, by pretending the VAR_DECLs don't have
DECL_VALUE_EXPR between the deduction of the type and actually finalizing their
DECL_VALUE_EXPR (for !processing_template_decl only where we do the deduction
with temporarily incremented processing_template_decl).

[Bug c++/108525] [13 Regression] ICE in write_method_parms with static on lambda with ... argument

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-5372-g9d4c00cdaccc3decd07740e817387ce844ef3ac9
Author: Jakub Jelinek 
Date:   Wed Jan 25 15:13:30 2023 +0100

c++: Fix up mangling of static lambdas [PR108525]

Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.

2023-01-25  Jakub Jelinek  

PR c++/108525
* mangle.cc (write_closure_type_name): Don't assume all
lambda operator() fns are methods.

* g++.dg/cpp23/static-operator-call5.C: New test.

[Bug c++/108525] [13 Regression] ICE in write_method_parms with static on lambda with ... argument

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Christophe Lyon
:

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

commit r10-11174-gfea013065580084578b1b78d8f727c0323f2a9a0
Author: Christophe Lyon 
Date:   Tue Jan 24 09:46:30 2023 +

[PATCH] aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.c (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Christophe Lyon
:

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

commit r11-10485-gd7f8b1c54bd054d214a73d4b534d599365f8658b
Author: Christophe Lyon 
Date:   Tue Jun 14 21:08:33 2022 +

aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.c (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Christophe Lyon
:

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

commit r12-9067-gf593bfa059fbd2c145d8dd2bae4860959e9e55fe
Author: Christophe Lyon 
Date:   Tue Jun 14 21:08:33 2022 +

aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.cc (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-25
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||diagnostic

--- Comment #3 from Jonathan Wakely  ---
(In reply to Stas Sergeev from comment #2)
> But I used -fpermissive mode to
> compile the mix of c/c++.

It seems like you might be expecting more from -fpermissive than it actually
provides. It only affects a very limited set of diagnostics, and isn't a
general "compile invalid code" switch.

It might be reasonable to make it affect narrowing diagnostics though. The
downside would be complicating the code by adding even more interactions
between different switches and dialects.

Confirming as an enhancement request to relax some narrowing errors with
-fpermissive, but C++ front end maintainers should decide whether that's
actually desirable.

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #9 from Christophe Lyon  ---
Fixed.

[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops

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

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

--- Comment #10 from Tobias Burnus  ---
> now filed as PR middle-end/108459.

This has been fixed to mainline. Cross ref: also about collapsed loops but
otherwise unrelated: PR middle-end/108435 (loop-var with function nesting
issue)

 * * *

Patch for this PR, sorry-ing for non-unit loop steps, but otherwise working:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610584.html

Follow-up work needed (once accepted): Handling some/all cases of non-unit
steps; for some thoughts on handling this, see:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610351.html

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #13 from Qing Zhao  ---
> On Jan 25, 2023, at 2:32 AM, rguenther at suse dot de 
>  wrote:
>> 
>> A little confused here:  
>>when the structure with a trailing flexible-array member is a middle
>> field of 
>>an outer structure, GCC extension will treat it as a flexible-array
>> too? But the
>>maximum size of this flexible-array will be bounded by the size of the
>> padding
>>of that field? 
>> Is the above understanding correct?
> 
> That's correct - at least when using the get_ref_base_and_extent
> API.  I see that when using array_ref_flexible_size_p it doesn't
> return true (but it's technically not _flexible_, we just treat it with
> a bound size that doesn't match the declared bound).
For the current array_ref_flexible_size_p, we include the following 3 cases:

   A. a ref to a flexible array member at the end of a structure;
   B. a ref to an array with a different type against the original decl;
  for example:

   short a[16] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
   (*((char(*)[16])&a[0]))[i+8]

   C. a ref to an array that was passed as a parameter;
  for example:

   int test (uint8_t *p, uint32_t t[1][1], int n) {
   for (int i = 0; i < 4; i++, p++)
 t[i][0] = …;

It basically mean: return true if REF is to an array whose actual size might be
larger than its upper bound implies. 

I feel that the case "when the structure with a trailing flexible-array member
is a middle field of an outer structure” still fit here, but not very sure,
need more thinking...

> 
> The first is handled by the function just fine,

No, even the first case is not recognized by the current
“array_ref_flexible_size_p”, it’s not been identified as a flexible array right
now.
Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
extension).

> it's the second with the bound size that's not and that isn't a good fit 
> there,
> though we do handle padding to the end of a declaration where
> we return true.
> 
>> Handle them separately instead?
> 
> I'm not sure how important it is to hande the middle array
> extending to padding, ISTR there was some real world code
> "miscompiled" when treating the array domain as written.

We can leave the 2nd case in a later time to resolve -:)
>

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

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

https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28

commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe 
Date:   Mon Jan 16 14:07:20 2023 +

modula-2: Fixes for preprocessing [PR102343, PR108182].

Modula-2 uses the C preprocessor to implement handling for conditional
code and macros.  However, this is not done directly, because the process
is applied recursively to imported definitions and modules.

The cc1gm2 executable records the parameters as a template command line
needed to create a composite 'cc1 -E' for each file to be preprocessed
starting with the main file from the original command line.

This patch fixes the capture of the C preprocessor template to include
the target information needed for correct multilib operation.

In order to match the existing semantics of '-E, -M and -MM' these have
to be handled as a 'pre-processor only' job (i.e. the recursion is omitted
and only the main file is processed).

Whereas C-family front ends always pre-process, Modula-2 only does so
when specifically requested (via the -fcpp option).

'-MD, -MMD and -MQ' also require special handling, since (in principle)
these options can be applied to any command line (with -fcpp) providing
dependency information as a by-product.

TODO: the preprocessor is not able to determine def and mod dependencies
for Modula-2 and so the output of this only shows the object to module
dep.  We should be able to append the .def and .mod dependencies.

The patch amends save-temps handling to cater for the preprocessor
recursion and to avoid writing saved files into the source directories.

The patch changes the extension for Modula-2 preprocessed source to .m2i
to avoid clashes with .i.

The main driver code is amended to add default handlers for .mod and .m2i
so that a useful error message will be emitted if the Modula-2 compiler
is not built-in.

The compiler will now also handle code generation from a .m2i preprocessed
source.

TODO: We should not need to pass the '-c' option to the compiler to alter
the processing of init code.

Signed-off-by: Iain Sandoe 

PR modula2/102343
PR modula2/108182

gcc/ChangeLog:

* gcc.cc: Provide default specs for Modula-2 so that when the
language is not built-in better diagnostics are emitted for
attempts to use .mod or .m2i file extensions.

gcc/m2/ChangeLog:

* gm2-compiler/M2Comp.mod: Early exit for pre-processor-only jobs.
* gm2-compiler/M2Options.def (SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Options.mod:(SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Preprocess.def (PreprocessModule): Add flag to
indicate the main file.
* gm2-compiler/M2Preprocess.mod: Handle Preprocess-only jobs,
handle MD, MMD and MQ options.
* gm2-gcc/m2options.h (M2Options_SetPPOnly, M2Options_GetPPOnly,
M2Options_SetDumpDir, M2Options_SetMD, M2Options_GetMD,
M2Options_SetMMD, M2Options_GetMMD, M2Options_SetMQ,
M2Options_GetMQ,
M2Options_SetObj, M2Options_GetObj): New.
* gm2-gcc/m2type.cc (m2type_InitBaseTypes): Early exit for pre-
processor-only jobs.
* gm2-lang.cc (gm2_langhook_init): Handle preprocess-only commands.
(gm2_langhook_option_lang_mask): Claim C and Driver options so that
we can intercept them for building pre-processor commands.
(gm2_langhook_init_options): Collect the preprocessor line here.
Save options that have different actions for preprocessor and
compile
commands.
(gm2_langhook_handle_option): Only handle the modula-2 options
here.
(gm2_langhook_post_options): Do not create a back-end for pre-
processor-only jobs.
* gm2spec.cc (lang_specific_driver): Ignore PCH options, append a
scaffold-main for cases where we are building a main module with
-c.
* lang-specs.h: Revise to handle preprocessor-only jobs and to
consume pre-processed files.
* lang.opt: Remove Driver and C options copies (we claim these
separately).

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

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

https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28

commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe 
Date:   Mon Jan 16 14:07:20 2023 +

modula-2: Fixes for preprocessing [PR102343, PR108182].

Modula-2 uses the C preprocessor to implement handling for conditional
code and macros.  However, this is not done directly, because the process
is applied recursively to imported definitions and modules.

The cc1gm2 executable records the parameters as a template command line
needed to create a composite 'cc1 -E' for each file to be preprocessed
starting with the main file from the original command line.

This patch fixes the capture of the C preprocessor template to include
the target information needed for correct multilib operation.

In order to match the existing semantics of '-E, -M and -MM' these have
to be handled as a 'pre-processor only' job (i.e. the recursion is omitted
and only the main file is processed).

Whereas C-family front ends always pre-process, Modula-2 only does so
when specifically requested (via the -fcpp option).

'-MD, -MMD and -MQ' also require special handling, since (in principle)
these options can be applied to any command line (with -fcpp) providing
dependency information as a by-product.

TODO: the preprocessor is not able to determine def and mod dependencies
for Modula-2 and so the output of this only shows the object to module
dep.  We should be able to append the .def and .mod dependencies.

The patch amends save-temps handling to cater for the preprocessor
recursion and to avoid writing saved files into the source directories.

The patch changes the extension for Modula-2 preprocessed source to .m2i
to avoid clashes with .i.

The main driver code is amended to add default handlers for .mod and .m2i
so that a useful error message will be emitted if the Modula-2 compiler
is not built-in.

The compiler will now also handle code generation from a .m2i preprocessed
source.

TODO: We should not need to pass the '-c' option to the compiler to alter
the processing of init code.

Signed-off-by: Iain Sandoe 

PR modula2/102343
PR modula2/108182

gcc/ChangeLog:

* gcc.cc: Provide default specs for Modula-2 so that when the
language is not built-in better diagnostics are emitted for
attempts to use .mod or .m2i file extensions.

gcc/m2/ChangeLog:

* gm2-compiler/M2Comp.mod: Early exit for pre-processor-only jobs.
* gm2-compiler/M2Options.def (SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Options.mod:(SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Preprocess.def (PreprocessModule): Add flag to
indicate the main file.
* gm2-compiler/M2Preprocess.mod: Handle Preprocess-only jobs,
handle MD, MMD and MQ options.
* gm2-gcc/m2options.h (M2Options_SetPPOnly, M2Options_GetPPOnly,
M2Options_SetDumpDir, M2Options_SetMD, M2Options_GetMD,
M2Options_SetMMD, M2Options_GetMMD, M2Options_SetMQ,
M2Options_GetMQ,
M2Options_SetObj, M2Options_GetObj): New.
* gm2-gcc/m2type.cc (m2type_InitBaseTypes): Early exit for pre-
processor-only jobs.
* gm2-lang.cc (gm2_langhook_init): Handle preprocess-only commands.
(gm2_langhook_option_lang_mask): Claim C and Driver options so that
we can intercept them for building pre-processor commands.
(gm2_langhook_init_options): Collect the preprocessor line here.
Save options that have different actions for preprocessor and
compile
commands.
(gm2_langhook_handle_option): Only handle the modula-2 options
here.
(gm2_langhook_post_options): Do not create a back-end for pre-
processor-only jobs.
* gm2spec.cc (lang_specific_driver): Ignore PCH options, append a
scaffold-main for cases where we are building a main module with
-c.
* lang-specs.h: Revise to handle preprocessor-only jobs and to
consume pre-processed files.
* lang.opt: Remove Driver and C options copies (we claim these
separately).

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
so fixed on trunk

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #20 from Iain Sandoe  ---
there are undoubtedly improvements we can make to the driver - but in terms of
basic correctness, this can be considered fixed on trunk.

[Bug tree-optimization/108540] New: [13 Regression] Frange miscompilation of ruby since r13-3261

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

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

Bug ID: 108540
   Summary: [13 Regression] Frange miscompilation of ruby since
r13-3261
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r13-3261-ga0c1a059101a3067d96211cbc4fae5905796d1db ruby is miscompiled
with LTO on powerpc64le-linux.
I've hand reduced it to:
#include 

__attribute__((noipa)) void
bar (const char *cp, unsigned long size, char sign, int dsgn)
{
  if (__builtin_strcmp (cp, "ZERO") != 0 || size != 4 || sign != '-' || dsgn !=
1)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (int x, int ch, ...)
{
  va_list ap;
  const char *cp = "";
  unsigned long size = 0;
  char sign = '\0';
  double d;
  va_start (ap, ch);
  switch (x)
{
case 42:
  d = va_arg (ap, double);
  if (__builtin_isinf (d))
{
  if (d < 0)
sign = '-';
  cp = "Inf";
  size = 3;
  break;
}
  if (__builtin_isnan (d))
{
  cp = "NaN";
  size = 3;
  break;
}
  if (d < 0)
{
  d = -d;
  sign = '-';
}
  else if (d == 0.0 && __builtin_signbit (d))
sign = '-';
  else
sign = '\0';
  if (ch == 'a' || ch == 'A')
{
  union U { long long l; double d; } u;
  int dsgn;
  u.d = d;
  if (u.l < 0)
{
  dsgn = 1;
  u.l &= 0x7fffLL;
}
  else
dsgn = 0;
  if (__builtin_isinf (d))
{
  cp = "INF";
  size = 3;
}
  else if (__builtin_isnan (d))
{
  cp = "NAN";
  size = 3;
}
  else if (d == 0)
{
  cp = "ZERO";
  size = 4;
}
  else
{
  cp = "WRONG";
  size = 5;
}
  bar (cp, size, sign, dsgn);
}
}
  va_end (ap);
}

int
main ()
{
  foo (42, 'a', -0.0);
  return 0;
}

[Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-25
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
   Target Milestone|--- |13.0
 Ever confirmed|0   |1
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
stdarg.h isn't needed, so:
__attribute__((noipa)) void
bar (const char *cp, unsigned long size, char sign, int dsgn)
{
  if (__builtin_strcmp (cp, "ZERO") != 0 || size != 4 || sign != '-' || dsgn !=
1)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (int x, int ch, double d)
{
  const char *cp = "";
  unsigned long size = 0;
  char sign = '\0';
  switch (x)
{
case 42:
  if (__builtin_isinf (d))
{
  if (d < 0)
sign = '-';
  cp = "Inf";
  size = 3;
  break;
}
  if (__builtin_isnan (d))
{
  cp = "NaN";
  size = 3;
  break;
}
  if (d < 0)
{
  d = -d;
  sign = '-';
}
  else if (d == 0.0 && __builtin_signbit (d))
sign = '-';
  else
sign = '\0';
  if (ch == 'a' || ch == 'A')
{
  union U { long long l; double d; } u;
  int dsgn;
  u.d = d;
  if (u.l < 0)
{
  dsgn = 1;
  u.l &= 0x7fffLL;
}
  else
dsgn = 0;
  if (__builtin_isinf (d))
{
  cp = "INF";
  size = 3;
}
  else if (__builtin_isnan (d))
{
  cp = "NAN";
  size = 3;
}
  else if (d == 0)
{
  cp = "ZERO";
  size = 4;
}
  else
{
  cp = "WRONG";
  size = 5;
}
  bar (cp, size, sign, dsgn);
}
}
}

int
main ()
{
  foo (42, 'a', -0.0);
  return 0;
}

The testcase is hand-written from what I see in
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L529
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L1229
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/missing/dtoa.c#L3387
where hdtoa is inlined into cvt which is inlined into vfprintf.  This reduced
testcase reproduces on x86_64-linux too.

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #14 from Siddhesh Poyarekar  ---
(In reply to Qing Zhao from comment #13)
> > 
> > The first is handled by the function just fine,
> 
> No, even the first case is not recognized by the current
> “array_ref_flexible_size_p”, it’s not been identified as a flexible array
> right now.
> Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
> extension).

In the first case, array_ref_flexible_size_p recognizes S2.flex.data as having
flexible size.  The tests in my patch[1] for this bug checks for this.

However, array_ref_flexible_size_p does not recognize S2.flex as having
flexible size.  It might make sense to support that, i.e. any struct or union
with the last element as a flex array should be recognized as having flexible
size.

[1] https://sourceware.org/pipermail/gcc-patches/2022-December/608912.html

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

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

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

--- Comment #1 from Alexander Monakov  ---
We diverge in sched1 due to extra calls to advance_one_cycle when scheduling a
BB that is empty apart from one debug insn. The following patch adds a hexdump
of automaton state to make the problem evident:

diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
index 420c45dff..c09398897 100644
--- a/gcc/sched-rgn.cc
+++ b/gcc/sched-rgn.cc
@@ -3098,8 +3098,14 @@ save_state_for_fallthru_edge (basic_block last_bb,
state_t state)
 memcpy (bb_state[f->dest->index], state,
dfa_state_size);
 if (sched_verbose >= 5)
-  fprintf (sched_dump, "saving state for edge %d->%d\n",
-  f->src->index, f->dest->index);
+  {
+   fprintf (sched_dump, "saving state for edge %d->%d\n",
+f->src->index, f->dest->index);
+   for (size_t i = 0; i < dfa_state_size; i++)
+ fprintf (sched_dump, "%02x%c", i[(unsigned char *)state],
+  (i+1) % 16 ? ' ' : '\n');
+   fprintf(sched_dump, "\n---\n");
+  }
   }
 }

With the above patch it's obvious we advance the automaton state a few extra
times when scheduling BB 3, and then inherit the modified state to BB 4.

I think we don't need to schedule blocks that only contain debug insns. IBM
folks, care to test the following?

diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 4efaa9445..f00a92e26 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -5040,7 +5040,7 @@ no_real_insns_p (const rtx_insn *head, const rtx_insn
*tail)
 {
   while (head != NEXT_INSN (tail))
 {
-  if (!NOTE_P (head) && !LABEL_P (head))
+  if (!NOTE_P (head) && !LABEL_P (head) && !DEBUG_INSN_P (head))
return 0;
   head = NEXT_INSN (head);
 }
diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
index 420c45dff..c09398897 100644
--- a/gcc/sched-rgn.cc
+++ b/gcc/sched-rgn.cc
@@ -2753,7 +2753,7 @@ free_block_dependencies (int bb)

   get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), &head, &tail);

-  if (no_real_insns_p (head, tail))
+  if (0 && no_real_insns_p (head, tail))
 return;

   sched_free_deps (head, tail, true);

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #15 from Qing Zhao  ---
> On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org 
>  wrote:
>> 
>>> The first is handled by the function just fine,
>> 
>> No, even the first case is not recognized by the current
>> “array_ref_flexible_size_p”, it’s not been identified as a flexible array
>> right now.
>> Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
>> extension).
> 
> In the first case, array_ref_flexible_size_p recognizes S2.flex.data as having
> flexible size.  The tests in my patch[1] for this bug checks for this.
Oh, yes. That’s right.
> 
> However, array_ref_flexible_size_p does not recognize S2.flex as having
> flexible size.  It might make sense to support that, i.e. any struct or union
> with the last element as a flex array should be recognized as having flexible
> size.

Since S2.flex is not an “array_ref”, it’s correct for array_ref_fleixble_size_p
to return false for it, I think. 
We might add a new utility routine to determine whether a ref to a struct or
union have flexible array?

[Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow

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

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

Bug ID: 108541
   Summary: ASAN since GCC 9 missed a stack-buffer-overflow
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -O0 missed the stack-buffer-overflow while
other opt levels caught it. This issue happens since GCC-9. GCC-8 and before
worked fine.

I also noticed that there is an incompatible pointer assignment `i = &m`, but
anyway the bufferoverflow should be reported.

Clang can detect it at all opt levels.

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

% cat a.c
struct a {
  long b;
  int c;
  long d;
  short e;
  long f;
  long g;
};
struct {
  struct a b;
  unsigned : 6;
} h, *i;
int j;
int main() {
  struct a *k;
  &k;
  long l[3];
  l[j] = 4;
  int m = 1;
  i = &m;
  *i = h;
  return m;
}
% 
% gcc-tk -fsanitize=address -w -O0 a.c && ./a.out
% 
% gcc-tk -fsanitize=address -w -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f8605800030
at pc 0x004012e0 bp 0x7ffdfd9e9b10 sp 0x7ffdfd9e9b08
WRITE of size 56 at 0x7f8605800030 thread T0
#0 0x4012df in main /a.c:21
#1 0x7f860810f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010cd in _start (/a.s+0x4010cd) (BuildId:
62f9205a5d8cda9f9cd98eb2592c0ba25a6a0a20)

Address 0x7f8605800030 is located in stack of thread T0 at offset 48 in frame
#0 0x401195 in main /app/example.c:14

  This frame has 2 object(s):
[48, 52) 'm' (line 19) <== Memory access at offset 48 partially overflows
this variable
[64, 88) 'l' (line 17) <== Memory access at offset 48 partially underflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /a.c:21 in main
Shadow bytes around the buggy address:
...
%

[Bug c++/108536] Difference when using requires and enable_if with class constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
invalid as explained .

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Guo Youtao from comment #5)
> This bug can still be triggered in gcc-11 and gcc-12.

That is unrelated bug. Most likely an issue with pointer to member functions
which is might have some known issues too.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from David Binderman  ---
(In reply to Richard Biener from comment #14)
> Fixed, but I'll see if somebody comes up with a reduced testcase.

I have a reduction running with cvise.

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

--- Comment #7 from Guo Youtao  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Guo Youtao from comment #5)
> > This bug can still be triggered in gcc-11 and gcc-12.
> 
> That is unrelated bug. Most likely an issue with pointer to member functions
> which is might have some known issues too.

Should I open a new topic for this bug since this is unrelated?

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from David Binderman  ---
cvise produces:

int g_149, g_167, g_481;
main() {
  int *l_1478 = &g_149;
  *l_1478 ^= g_167;
lbl_1481:
  for (;;) {
g_481 = 1;
for (; g_481; g_481 += 1) {
  g_167 ^= *l_1478;
  if (g_149)
goto lbl_1481;
}
  }
}

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #4 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #3)
> It seems like you might be expecting more from -fpermissive than it actually
> provides. It only affects a very limited set of diagnostics, and isn't a
> general "compile invalid code" switch.

I always used it to compile the
(valid) C code in C++ mode. I thought
that's what it is for. It violates the
C++ standard up and down. And that
-Wnarrowing case is "better" than others
because it was a warning in c++03.
Other problems that -fpermissive allows,
were always an errors in any c++ mode.

[Bug analyzer/108524] -Wanalyzer-infinite-recursion false positives seen in qemu's JSON parser

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25

--- Comment #1 from David Malcolm  ---
I'm testing a fix for this.

[Bug analyzer/108507] [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-25

--- Comment #1 from David Malcolm  ---
Also seen on aarch64-unknown-linux-gnu:
  https://godbolt.org/z/Yzbxvf8j4

I'll add -Wno-stringop-overflow to the failing test (the point of the test is
to see if -fanalyzer can detect the problem).

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

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

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

--- Comment #2 from Richard Earnshaw  ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away.  I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode_supported_p() in arm.cc. 
When it isn't a builtin type we end up with a BLKmode object that the compiler
creates a stack-slot for, even though no RTL is ever generated to use the slot
in this case.

[Bug c++/108542] New: [13 Regression] ICE in instantiate_type, at cp/class.cc:8833

[gscfq--- via Gcc-bugs]

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

Bug ID: 108542
   Summary: [13 Regression] ICE in instantiate_type, at
cp/class.cc:8833
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20221106 and 20221120 :


$ cat z1.cc
template
void f (T n) {}
[[pre: f]]


$ g++-13-20230122 -c z1.cc
z1.cc:3:8: internal compiler error: in instantiate_type, at cp/class.cc:8833
3 | [[pre: f]]
  |^
0x7d34ef instantiate_type(tree_node*, tree_node*, int)
../../gcc/cp/class.cc:8833
0x7b2c27 implicit_conversion_error
../../gcc/cp/call.cc:4658
0x7c05bc perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:13366
0x97e5cc contextual_conv_bool(tree_node*, int)
../../gcc/cp/typeck.cc:6952
0x97e5cc condition_conversion(tree_node*)
../../gcc/cp/typeck.cc:6961
0x81665a grok_contract(tree_node*, tree_node*, tree_node*, cp_expr, unsigned
int)
../../gcc/cp/contracts.cc:783
0x8f0a2f cp_parser_contract_attribute_spec
../../gcc/cp/parser.cc:29740
0x8f0a2f cp_parser_std_attribute_spec
../../gcc/cp/parser.cc:29886
0x8f0a2f cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.cc:30011
0x8f0f51 cp_parser_attributes_opt
../../gcc/cp/parser.cc:28909
0x8e11e7 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:15734
0x8e1aa1 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15217
0x90c638 cp_parser_declaration
../../gcc/cp/parser.cc:15030
0x90d010 cp_parser_translation_unit
../../gcc/cp/parser.cc:5090
0x90d010 c_parse_file()
../../gcc/cp/parser.cc:49400
0x9f4e01 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248

[Bug c++/108543] New: ICE in build_call_expr_loc_array, at tree.cc:10686

[gscfq--- via Gcc-bugs]

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

Bug ID: 108543
   Summary: ICE in build_call_expr_loc_array, at tree.cc:10686
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.cc
#include 


$ g++-13-20230122 -c z1.cc -fsanitize=address -fno-sanitize=kernel-address
-fsanitize=pointer-subtract
In file included from .../gcc-13-20230122/include/c++/13.0.1/vector:67,
 from z1.cc:1:
.../gcc-13-20230122/include/c++/13.0.1/bits/stl_bvector.h: In function
'std::ptrdiff_t std::operator-(const _Bit_iterator_base&, const
_Bit_iterator_base&)':
.../gcc-13-20230122/include/c++/13.0.1/bits/stl_bvector.h:269:50: internal
compiler error: Segmentation fault
  269 |   return (int(_S_word_bit) * (__x._M_p - __y._M_p)
  |  ^~~~
0xeb575f crash_signal
../../gcc/toplev.cc:314
0x114833e build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
../../gcc/tree.cc:10686
0x114842f build_call_expr_loc(unsigned int, tree_node*, int, ...)
../../gcc/tree.cc:10719
0x98b393 pointer_diff
../../gcc/cp/typeck.cc:6728
0x98b393 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.cc:5350
0x7c8c8c build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:7369
0x97de10 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../gcc/cp/typeck.cc:4722
0x8d16e3 cp_parser_binary_expression
../../gcc/cp/parser.cc:10283
0x8d1eb4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0x8d35f2 cp_parser_expression
../../gcc/cp/parser.cc:10614
0x8e50c1 cp_parser_primary_expression
../../gcc/cp/parser.cc:5722
0x8e8a76 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7731
0x8fbfff cp_parser_unary_expression
../../gcc/cp/parser.cc:9095
0x8d0bff cp_parser_cast_expression
../../gcc/cp/parser.cc:
0x8d190c cp_parser_simple_cast_expression
../../gcc/cp/parser.cc:32523
0x8d190c cp_parser_binary_expression
../../gcc/cp/parser.cc:10168
0x8d1eb4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0x8d35f2 cp_parser_expression
../../gcc/cp/parser.cc:10614
0x8e50c1 cp_parser_primary_expression
../../gcc/cp/parser.cc:5722
0x8e8a76 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7731

[Bug fortran/108544] New: ICE in check_host_association, at fortran/resolve.cc:6135

[gscfq--- via Gcc-bugs]

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

Bug ID: 108544
   Summary: ICE in check_host_association, at
fortran/resolve.cc:6135
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
module m
   implicit none
contains
   subroutine s
  select type (s => 1)
  end select
   end
end


$ cat z3.f90
module m
contains
   subroutine s
  select type (s => null())
  end select
   end
end


$ cat z4.f90
module m
   type t
   end type
   type(t) :: x
contains
   subroutine s
  select type (s => x)
  end select
   end
end


$ gfortran-13-20230122 -c z1.f90
f951: internal compiler error: Segmentation fault
0xdaa49f crash_signal
../../gcc/toplev.cc:314
0x838506 check_host_association
../../gcc/fortran/resolve.cc:6135
0x838506 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7194
0x83fa6c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7162
0x83fa6c gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11982
0x8416a7 resolve_codes
../../gcc/fortran/resolve.cc:17629
0x8415de resolve_codes
../../gcc/fortran/resolve.cc:17612
0x84176e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17664
0x8292d2 gfc_parse_file()
../../gcc/fortran/parse.cc:6862
0x8774bf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

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

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

--- Comment #3 from Richard Earnshaw  ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some pointless vectorizations it
would generate better code for cases like this.

[Bug fortran/108545] New: [13 Regression] ICE in install_var_field, at omp-low.cc:799

[gscfq--- via Gcc-bugs]

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

Bug ID: 108545
   Summary: [13 Regression] ICE in install_var_field, at
omp-low.cc:799
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220911 and 20220918 :


$ cat z1.f90
program p
   type t
  integer, pointer :: a(:)
   end type
   type(t), volatile :: x
   !$omp target enter data map(to: x%a)
end


$ cat z2.f90
program p
   type t
  integer, pointer :: a(:)
   end type
   type(t) :: x
   !$omp target enter data map(to: x%a)
end


$ gfortran-13-20230122 -c z2.f90 -fopenmp
$ gfortran-12  -c z1.f90 -fopenmp
$
$ gfortran-13-20230122 -c z1.f90 -fopenmp
during GIMPLE pass: omplower
z1.f90:6:39:

6 |!$omp target enter data map(to: x%a)
  |   ^
internal compiler error: in install_var_field, at omp-low.cc:799
0xc6accb install_var_field
../../gcc/omp-low.cc:798
0xc6f882 scan_sharing_clauses
../../gcc/omp-low.cc:1678
0xc71c24 scan_omp_target
../../gcc/omp-low.cc:3111
0xc7282d scan_omp_1_stmt
../../gcc/omp-low.cc:4327
0xaf96a6 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:608
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xaf9761 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xaf9761 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xc6852d scan_omp
../../gcc/omp-low.cc:4377
0xc7c73a execute_lower_omp
../../gcc/omp-low.cc:14691
0xc7c73a execute
../../gcc/omp-low.cc:14755

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

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

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

--- Comment #8 from Jonathan Wakely  ---
Yes please

[Bug fortran/108546] New: [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910

[gscfq--- via Gcc-bugs]

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

Bug ID: 108546
   Summary: [11/12/13 Regression] ICE in expand_expr_real_1, at
expr.cc:10910
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10, between 20191110 and 20191117 :


$ cat z1.f90
module m
   use iso_c_binding
contains
   subroutine s(x)
  type(c_ptr), optional :: x
  !$omp target is_device_ptr(x)
  if (c_associated(x)) stop
  !$omp end target
   end
end


$ cat z2.f90# compiles, for reference only
module m
   use iso_c_binding
contains
   subroutine s(x)
  type(c_ptr) :: x
  !$omp target is_device_ptr(x)
  if (c_associated(x)) stop
  !$omp end target
   end
end


$ gfortran-13-20230122 -c z2.f90 -fopenmp
$ gfortran-10-20191110 -c z1.f90 -fopenmp
$
$ gfortran-13-20230122 -c z1.f90 -fopenmp
during RTL pass: expand
z1.f90:6:35:

6 |   !$omp target is_device_ptr(x)
  |   ^
internal compiler error: in expand_expr_real_1, at expr.cc:10910
0xa570bf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:10904
0xa5e66e expand_expr
../../gcc/expr.h:310
0xa5e66e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc/expr.cc:8582
0xa6a23a do_store_flag
../../gcc/expr.cc:13113
0xa6574e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:10259
0x94fba2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3983
0x94fba2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x9548d7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x95739e execute
../../gcc/cfgexpand.cc:6831

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Keith Thompson  ---
FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60559_COMPLEX__ are defined.

It's probably too late to make such a change in C23.

(__STDC_IEC_60559_COMPLEX__ is replacing __STDC_IEC_559_COMPLEX__,
which is obsolescent.)

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see very similar for this legal C code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled as follows:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {

[Bug c/102760] ICE: in decompose, at wide-int.h:984

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to David Binderman from comment #6)
> I see very similar for this legal C code:

That seems like a different issue, please file it seperately.

[Bug target/99435] avr: incorrect I/O address ranges for some cores

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25

--- Comment #2 from Georg-Johann Lay  ---
Still wainting for a reply.

[Bug c/108547] New: ice in decompose, at wide-int.h:984 for -O2 with -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108547
   Summary: ice in decompose, at wide-int.h:984 for -O2 with -Wall
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This legal C source code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled with recent gcc trunk, does this:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {
  |  ^
0x1df0eb9 value_sat_pred_p(tree_node*, tree_node*, tree_code, bool)
../../trunk.d1/gcc/wide-int.h:0

The bug first seems to appear sometime before git hash g:9b111debbfb79a0a
dated 20221229.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > I see very similar for this legal C code:
> 
> That seems like a different issue, please file it seperately.

Done, see 108547.

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.5
 Status|UNCONFIRMED |NEW
Summary|ICE in  |[10/11/12/13 Regression]
   |build_call_expr_loc_array,  |ICE in
   |at tree.cc:10686|build_call_expr_loc_array,
   ||at tree.cc:10686
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed, reducing...

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Georg-Johann Lay  ---
The code is optimized fine with -Os.

With -Og, you can expect less optimized code.  For the provided code and -Og,
you can improve code quality by means of -mstrict-X (where I am not sure
whether it would be appropriate to have -mstrict-X as the default).

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #1 from Andrew Pinski  ---
Here is the full backtrace:
0xc7c58b wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:984
0xc7c7a4 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:1034
0xc7bd5e generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:790
0x1084abf wi::binary_traits
>, generic_wide_int >,
wi::int_traits >
>::precision_type, wi::int_traits > >::precision_type>::result_type
wi::bit_and >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:2338
0x1081df1 wi::binary_traits
>, generic_wide_int >,
wi::int_traits >
>::precision_type, wi::int_traits > >::precision_type>::operator_result
operator& >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:3309
0x2c9c925 value_sat_pred_p
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:731
0x2c9ca99 subset_of
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:765
0x2c9cb89 subset_of
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:792
0x2c9cc09 predicate::includes(vec const&) const
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:815
0x2c9cc71 predicate::superset_of(predicate const&) const
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:834
0x2ca09e6 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
   
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:2250
0x2ca0a86 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
   
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:2263
0x19370ab find_uninit_use
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1234
0x193745f warn_uninitialized_phi
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1304
0x193791e execute_late_warn_uninitialized
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1425
0x19379f5 execute
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1442
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
#7  0x02c9c926 in value_sat_pred_p (val=0x77265138,
boundary=0x773f7a80, cmpc=BIT_AND_EXPR, exact_p=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:731
731   wide_int andw = wi::to_wide (val) & wi::to_wide (boundary);
(gdb) p debug_tree(val)
  constant 0>
$7 = void
(gdb) p debug_tree(boundary)
 
constant 1>
$8 = void

Confirmed.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com via Gcc-bugs]

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

User99627  changed:

   What|Removed |Added

 CC||user99627 at gmx dot com

--- Comment #10 from User99627  ---
Created attachment 54342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54342&action=edit
Complete Arduino compile trace after compiling the sample sketch (see comment)

I'm running Manjaro and I cannot chose which version of avr-gcc I run on my
system. It currently is avr-gcc 12.2.0. As a consequence I cannot run most
Arduino sketches either, so long as I'm using the system AVR compiler.

Here's a sample sketch that exhibits the error (see attachments):

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  enum { OPEN, CLOSE };

  static uint32_t prevMillis;  // Unsigned long, not int! ;)
  static uint16_t interval;
  static uint8_t state;// Defaults to OPEN

  uint32_t currentMillis = millis();
  if (currentMillis - prevMillis >= interval)
  {
prevMillis = currentMillis;
// Could use a switch/case here:
if (state == OPEN)
{
  interval = random(3000, 1);
  Serial.print("interval blink : ");
  Serial.println(interval);
  state = CLOSE;
}
if (state == CLOSE)
{
  interval = 300;
  Serial.println("open");
  state = OPEN;
}
  }
}

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #3 from Andrew Pinski  ---
Here is a slightly better testcase that does not depend on implicit conversion
from a function pointer to an integer.

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
long t;
int func_7_uc_10li_19(int);
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += t;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

--- Comment #2 from Marek Polacek  ---
struct _Bit_iterator_base {
  long _M_p;
  friend bool operator<(_Bit_iterator_base __x, _Bit_iterator_base __y) {
return &__x._M_p - &__y._M_p;
  }
};

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is trying to simplifying:
((NOT (us_8.1_2 != 0)))
OR ((func_7_ptr_13.8_9 != 0) AND (_8 != 0) AND (func_7_ptr_13.8_9 & 1)
AND (NOT (_49 != 0)) AND (NOT (prephitmp_37 != 0)))
OR ((func_7_ptr_13.8_9 & 1) AND (NOT (_49 != 0)) AND (NOT (_11 != 0)))
OR ((NOT (_30 != 0)) AND (NOT (_49 != 0)) AND (NOT (prephitmp_37 !=
0)))

Note the & 1 there  That seems like the issue, trying to simplify:
(func_7_ptr_13.8_9 != 0) AND (func_7_ptr_13.8_9 & 1)

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

--- Comment #3 from Marek Polacek  ---
Started with r255404.

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I have a fix.

[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||7.5.0
  Known to fail||10.4.1, 11.3.1, 12.2.1,
   ||8.5.0, 9.5.0

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Martin Liška from comment #7)
> Btw. started with r8-7594-g078c5aff5ed83e9c.

Right.  Adding known to work and known to fail versions.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com via Gcc-bugs]

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

--- Comment #11 from User99627  ---
I can also tell the bug occurs regardless of the -flto flag is present or not.

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Steve, I'm going to commit your patch.

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

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

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

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

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

commit r13-5374-g9fb9da3d38513d320bfea72050f7a59688595e0b
Author: Steve Kargl 
Date:   Wed Jan 25 20:38:43 2023 +0100

Fortran: ICE in gfc_compare_array_spec [PR108528]

gcc/fortran/ChangeLog:

PR fortran/108528
* array.cc (compare_bounds): Return false instead of generating an
internal error on an invalid argument type.

gcc/testsuite/ChangeLog:

PR fortran/108528
* gfortran.dg/pr108528.f90: New test.