[Bug c++/106651] [C++23] P1169 - static operator()

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

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

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

https://gcc.gnu.org/g:303976a6076f2839354702fd2caa049fa7cbbdc2

commit r13-2892-g303976a6076f2839354702fd2caa049fa7cbbdc2
Author: Jakub Jelinek 
Date:   Tue Sep 27 08:36:28 2022 +0200

c++: Implement C++23 P1169R4 - static operator() [PR106651]

The following patch attempts to implement C++23 P1169R4 - static operator()
paper's compiler side (there is some small library side too not implemented
yet).  This allows static members as user operator() declarations and
static specifier on lambdas without lambda capture.
The synthetized conversion operator changes for static lambdas as it can
just
return the operator() static method address, doesn't need to create a thunk
for it.
The change in call.cc (joust) is to avoid ICEs because we assumed that len
could be different only if both candidates are direct calls but it can be
one direct and one indirect call, and to implement the
[over.match.best.general]/1 and [over.best.ics.general] changes from
the paper (implemented always as Jason is sure it doesn't make a difference
in C++20 and earlier unless static member function operator() or
static lambda which we accept with pedwarn in earlier standards too appears
and my testing confirmed that).

2022-09-27  Jakub Jelinek  

PR c++/106651
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_static_call_operator=202207L for C++23.
gcc/cp/
* cp-tree.h (LAMBDA_EXPR_STATIC_P): Implement C++23
P1169R4 - static operator().  Define.
* parser.cc (CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Document
that it also allows static.
(cp_parser_lambda_declarator_opt): Handle static lambda specifier.
(cp_parser_decl_specifier_seq): Allow RID_STATIC for
CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR.
* decl.cc (grok_op_properties): If operator() isn't a method,
use a different error wording, if it is static member function,
allow it (for C++20 and older with a pedwarn unless it is
a lambda function or template instantiation).
* call.cc (joust): Don't ICE if one candidate is static member
function and the other is an indirect call.  If the parameter
conversion on the other candidate is user defined conversion,
ellipsis or bad conversion, make static member function candidate
a winner for that parameter.
* lambda.cc (maybe_add_lambda_conv_op): Handle static lambdas.
* error.cc (dump_lambda_function): Print static for static lambdas.
gcc/testsuite/
* g++.dg/template/error30.C: Adjust expected diagnostics.
* g++.dg/cpp1z/constexpr-lambda13.C: Likewise.
* g++.dg/cpp23/feat-cxx2b.C: Test __cpp_static_call_operator.
* g++.dg/cpp23/static-operator-call1.C: New test.
* g++.dg/cpp23/static-operator-call2.C: New test.
* g++.old-deja/g++.jason/operator.C: Adjust expected diagnostics.

[Bug tree-optimization/107029] [13 Regression] ice during GIMPLE pass: reassoc

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

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

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

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

commit r13-2891-gcb8f25c5dc9f6d5207c826c2dafe25f68458ceaf
Author: Jakub Jelinek 
Date:   Tue Sep 27 08:26:18 2022 +0200

reassoc: Handle OFFSET_TYPE like POINTER_TYPE in
optimize_range_tests_cmp_bitwise [PR107029[

As the testcase shows, OFFSET_TYPE needs the same treatment as
POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the
newly added verification.  OFFSET_TYPE is signed though, so unlike
POINTER_TYPE/REFERENCE_TYPE it can also trigger with the
x < 0 && y < 0 && z < 0 to (x | y | z) < 0
optimization.

2022-09-27  Jakub Jelinek  

PR tree-optimization/107029
* tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): Treat
OFFSET_TYPE like POINTER_TYPE, except that OFFSET_TYPE may be
signed and so can trigger even the (b % 4) == 3 case.

* g++.dg/torture/pr107029.C: New test.

[Bug c++/85518] ICE mangling _FloatN types

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

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

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

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

commit r13-2887-gb04208895fed34171eac6bafb60c90048eb1cb0c
Author: Jakub Jelinek 
Date:   Tue Sep 27 08:04:06 2022 +0200

c++: Implement P1467R9 - Extended floating-point types and standard names
compiler part except for bfloat16 [PR106652]

The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc.  So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are
distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type.  The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at
least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx
are
also treated as extended floating-point types) and kept previous behavior
otherwise.  For float/double/long double the rules are actually written
that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes.  One gets
errors like:
In file included from /usr/include/math.h:43,
 from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
   86 | typedef __float128 _Float128;
  | ^~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare
anything [-fpermissive]
   86 | typedef __float128 _Float128;
  |^
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one
declaration
  214 | typedef float _Float32;
  | ^
/usr/include/bits/floatn-common.h:214:15: error: declaration does not
declare anything [-fpermissive]
  214 | typedef float _Float32;
  |   ^~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one
declaration
  251 | typedef double _Float64;
  | ^~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not
declare anything [-fpermissive]
  251 | typedef double _Float64;
  |^~~~
This is from snippets like:
 /* The remaining of this file provides support for older compilers.  */
 # if __HAVE_FLOAT128

 /* The type _Float128 exists only since GCC 7.0.  */
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 typedef __float128 _Float128;
 #  endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x}
support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex
_Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those.  The patch changes those
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
 #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13,
0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF  _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc.  

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

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

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

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

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

commit r13-2887-gb04208895fed34171eac6bafb60c90048eb1cb0c
Author: Jakub Jelinek 
Date:   Tue Sep 27 08:04:06 2022 +0200

c++: Implement P1467R9 - Extended floating-point types and standard names
compiler part except for bfloat16 [PR106652]

The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc.  So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are
distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type.  The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at
least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx
are
also treated as extended floating-point types) and kept previous behavior
otherwise.  For float/double/long double the rules are actually written
that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes.  One gets
errors like:
In file included from /usr/include/math.h:43,
 from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
   86 | typedef __float128 _Float128;
  | ^~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare
anything [-fpermissive]
   86 | typedef __float128 _Float128;
  |^
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one
declaration
  214 | typedef float _Float32;
  | ^
/usr/include/bits/floatn-common.h:214:15: error: declaration does not
declare anything [-fpermissive]
  214 | typedef float _Float32;
  |   ^~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one
declaration
  251 | typedef double _Float64;
  | ^~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not
declare anything [-fpermissive]
  251 | typedef double _Float64;
  |^~~~
This is from snippets like:
 /* The remaining of this file provides support for older compilers.  */
 # if __HAVE_FLOAT128

 /* The type _Float128 exists only since GCC 7.0.  */
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 typedef __float128 _Float128;
 #  endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x}
support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex
_Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those.  The patch changes those
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
 #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13,
0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF  _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc.

[Bug c++/102284] Can access object outside of its lifetime during constant evaluation

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Johel Ernesto Guerrero Peña  ---
This may be related. Assigning to another member doesn't end the lifetime of
the active one: https://godbolt.org/z/eMGY5ehnb.

```C++
#include 

struct symbol { };

constexpr symbol one{};

struct unit {
  const struct symbol* symbol = &one;

  struct not_one_t { };

  union to_the {
not_one_t not_one = {}; // Omits ¹ from NTTP.
int i;

to_the() = default;
constexpr to_the(int i) : i{i} {
  if (i == 1) {
// std::destroy_at(&this->i); // On GCC, doesn't help.
not_one = {};
// std::construct_at(¬_one); // On GCC, initializes `not_one`,
doesn't end the lifetime of `i`.
  }
}
  } exponent = {};

  constexpr unit(const struct symbol& s)
: symbol{&s} { }
  constexpr unit(const struct symbol& s, auto e)
: symbol{&s}, exponent{e} { }
};

template void print() { }

int main() {
  constexpr auto U = unit{one, 1};
  print();
  print();
  static_assert(&U.exponent.not_one);
  // static_assert(U.exponent.i == 1); // Works on GCC (and MSVC).
}
```

[Bug c++/107024] ICE in finish_expr_stmt, at cp/semantics.cc:872

[alex at clmbng dot com via Gcc-bugs]

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

--- Comment #3 from alex at clmbng dot com ---
Minimal test-case:

struct A { int fun(); };

template  
consteval auto aaa() { return A{}; }

template  
using aa = decltype(aaa<[]{}>());

template  
A a = aa{};

int main() 
{
return a<42>.fun();
}

[Bug tree-optimization/107046] New: [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf

[jeffreyalaw at gmail dot com via Gcc-bugs]

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

Bug ID: 107046
   Summary: [13 Regression] Recent FP range work causing inf-2 to
be miscompiled on rx-elf
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffreyalaw at gmail dot com
  Target Milestone: ---

gcc.c-torture/execute/ieee/inf-2.c is being mis-compiled as of:

commit b7fd7fb5011106c062df9275ca8fddcbce4ebdeb
Author: Aldy Hernandez 
Date:   Thu Sep 22 18:20:39 2022 +0200

frange: drop endpoints to min/max representable numbers for
-ffinite-math-only.

Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
think we can drop the numbers outside of the min/max representable
numbers to the representable number.

This means the endpoings to VR_VARYING for -ffinite-math-only can now
be the min/max representable, instead of -INF and +INF.

Saturating in the setter means that the upcoming implementation for
binary operators no longer have to worry about doing the right
thing for -ffinite-math-only.  If the range goes outside the limits,
it'll get chopped down.

Looking at the assembly code, test, testf and testl are all collapsing down to
calls to abort.
   .file   "k.c"
.section P,"ax"
.section.text.unlikely,"ax",@progbits
.global _test
.type   _test, @function
_test:
bsr _abort
.size   _test, .-_test
.global _testf
.type   _testf, @function
_testf:
bsr _abort
.size   _testf, .-_testf
.global _testl
.type   _testl, @function
_testl:
bsr _abort
.size   _testl, .-_testl
.global _main
.type   _main, @function
_main:
bsr _abort
.size   _main, .-_main
.ident  "GCC: (GNU) 13.0.0 20220923 (experimental)"

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

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Johel Ernesto Guerrero Peña  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107045#c1 for a minimal
reproducer:

Minimal: https://godbolt.org/z/hxrPvPPhs.

```C++
namespace std {
template struct X {
  friend void f();
};
}
```

```C++
export module mod;
import "std.hpp";
export std::X v;
```

[Bug c++/107045] [modules] ICE on instantiation of a ::std class template with a friend function imported from an importable header

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 100134.

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

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

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

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

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

Bug 107045 Summary: [modules] ICE on instantiation of a ::std class template 
with a friend function imported from an importable header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107045

   What|Removed |Added

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

[Bug c++/107045] [modules] ICE on use of std::vector from importable header

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Minimal: https://godbolt.org/z/hxrPvPPhs.

```C++
namespace std {
template struct X {
  friend void f();
};
}
```

```C++
export module mod;
import "std.hpp";
export std::X v;
```

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

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

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||dmalcolm at gcc dot gnu.org
   Last reconfirmed||2022-09-26

--- Comment #35 from David Malcolm  ---
Created attachment 53631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53631&action=edit
Refreshed version of Tom Tromey's patch

This is a refreshed version of Tom Tromey's patch from 2014, against last
week's trunk (specifically, against dc829c7613ddf562d1aecaf22eda965e87108ac8).

The new tests pass; am currently attempting a bootstrap and full regression
test.

Has the same caveats that Tom noted in the earlier comments.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Mon, Sep 26, 2022 at 08:38:56PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #4)
> > I think we need to expand the checking in array.cc
> > 
> >   /* Convert components of an array constructor to the type in ts.  */
> > 
> >   static match
> >   walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head)
> > 
> > I haven't had time to look deeper, but this function should be comparing
> > the typespecs of REAL and -'1' or +'1'.  That should fail.  I suspect that
> > the EXPR_OP of type_expr is allowing the array constructor walk to succeed.
> 
> You mean sth. like:
> 
> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> index bbdb5b392fc..78a15917cec 100644
> --- a/gcc/fortran/array.cc
> +++ b/gcc/fortran/array.cc
> @@ -1213,7 +1213,7 @@ walk_array_constructor (gfc_typespec *ts,
> gfc_constructor_base head)
> return m;
> }
>else if (!gfc_convert_type_warn (e, ts, 1, 1, true)
> -  && e->ts.type != BT_UNKNOWN)
> +  && (e->ts.type != BT_UNKNOWN || e->expr_type == EXPR_OP))
> return MATCH_ERROR;
>  }
>return MATCH_YES;
> 
> in addition to the fix from comment#2?  This works and regtests ok.
> 

Yes, that would work!  I was thinking of something more complex
such as looking at the types of the operand(s), but simplification
probably handles +1 and -1 correctly and punts on +'1' and -'1'.

[Bug c++/107045] New: [modules] ICE on use of std::vector from importable header

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 107045
   Summary: [modules] ICE on use of std::vector from importable
header
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/qeGb9hhsf.

```sh
CXX=g++
echo "./std.hpp std.gcm
mod mod.gcm" > mm.txt
echo "#include " > std.hpp
echo "export module mod;
import \"std.hpp\";
export std::vector v;" > mod.cpp
$CXX -std=c++23 -fmodules-ts -fmodule-mapper=mm.txt -x c++-header -c std.hpp
$CXX -std=c++23 -fmodules-ts -fmodule-mapper=mm.txt -c mod.cpp
```

Output:
```
mod.cpp:1:8: internal compiler error: in add_binding_entity, at
cp/module.cc:12850
1 | export module mod;
  |^~
0x22c5a9c internal_error(char const*, ...)
???:0
0x9b479b fancy_abort(char const*, int, char const*)
???:0
0xb222f3 walk_module_binding(tree_node*, bitmap_head*, bool (*)(tree_node*,
WMB_Flags, void*), void*)
???:0
0xaf184a depset::hash::add_namespace_entities(tree_node*, bitmap_head*)
???:0
0xb0c2a1 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0xb0d774 finish_module_processing(cpp_reader*)
???:0
0xa96874 c_parse_final_cleanups()
???:0
0xccf5d2 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

GCC 12/11 fail on import:
```
In module imported at /app/test.cpp:1:1:
mod: error: failed to read compiled module: Bad file data
mod: note: compiled module file is '/app/build/mod.gcm'
mod: fatal error: returning to the gate for a mechanical issue
compilation terminated.
```

[Bug ipa/107044] New: internal compiler error: in dump_possible_polymorphic_call_targets, at ipa-devirt.cc:3456

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 107044
   Summary: internal compiler error: in
dump_possible_polymorphic_call_targets, at
ipa-devirt.cc:3456
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: macro at orcam dot me.uk
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: riscv64-linux-gnu

Created attachment 53630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53630&action=edit
Reproducer, taken from 483.xalancbmk in SPEC CPU2006

With the `riscv64-linux-gnu' target and the attached source I get an ICE:

during GIMPLE pass: fre
dump file: TokenFactory.ii.112t.fre3
TokenFactory.ii: In member function 'xercesc_2_5::Token*
xercesc_2_5::TokenFactory::getGraphemePattern()':
TokenFactory.ii:177:3: internal compiler error: in
dump_possible_polymorphic_call_targets, at ipa-devirt.cc:3456
  177 |   TokenFactory::getGraphemePattern ()
  |   ^~~~
0x11427cf7 dump_possible_polymorphic_call_targets(_IO_FILE*, tree_node*, long,
ipa_polymorphic_call_context const&, bool)
/path/to/src/gcc/gcc/ipa-devirt.cc:3456
0x11d4ed63 eliminate_dom_walker::eliminate_stmt(basic_block_def*,
gimple_stmt_iterator*)
/path/to/src/gcc/gcc/tree-ssa-sccvn.cc:7007
0x11d4fa03 eliminate_dom_walker::before_dom_children(basic_block_def*)
/path/to/src/gcc/gcc/tree-ssa-sccvn.cc:7159
0x12915f1b dom_walker::walk(basic_block_def*)
/path/to/src/gcc/gcc/domwalk.cc:311
0x11d506a7 eliminate_with_rpo_vn(bitmap_head*)
/path/to/src/gcc/gcc/tree-ssa-sccvn.cc:7339
0x11d55c83 do_rpo_vn_1
/path/to/src/gcc/gcc/tree-ssa-sccvn.cc:8451
0x11d560d3 execute
/path/to/src/gcc/gcc/tree-ssa-sccvn.cc:8537
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccZIsvk3.out file, please attach this to
your bugreport.

with this compiler invocation:

$ riscv64-linux-gnu-g++ -fdump-tree-all -S -o TokenFactory.s -Ofast
--param=max-inline-insns-size=90 -march=rv64gc -mabi=lp64d TokenFactory.ii

GCC built with `-O0 -g' for the purpose of obtaining a reliable backtrace
only, the same ICE triggers with the usual `-O2' compilation.

NB this comes from the same program and is the same assertion as with
PR ipa/79931 and PR tree-optimization/80249.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> I think we need to expand the checking in array.cc
> 
>   /* Convert components of an array constructor to the type in ts.  */
> 
>   static match
>   walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head)
> 
> I haven't had time to look deeper, but this function should be comparing
> the typespecs of REAL and -'1' or +'1'.  That should fail.  I suspect that
> the EXPR_OP of type_expr is allowing the array constructor walk to succeed.

You mean sth. like:

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..78a15917cec 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1213,7 +1213,7 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
return m;
}
   else if (!gfc_convert_type_warn (e, ts, 1, 1, true)
-  && e->ts.type != BT_UNKNOWN)
+  && (e->ts.type != BT_UNKNOWN || e->expr_type == EXPR_OP))
return MATCH_ERROR;
 }
   return MATCH_YES;

in addition to the fix from comment#2?  This works and regtests ok.

[Bug bootstrap/107042] GCC build error after today's change

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

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

--- Comment #8 from Jonathan Wakely  ---
Because incremental rebuilds for trunk are not supported. If it works, that's
nice, if it doesn't, it's not a bug. Do a clean build.

[Bug bootstrap/107042] GCC build error after today's change

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

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

--- Comment #7 from Jonathan Wakely  ---
If you get a bootstrap error like this, always try a clean build before
reporting a bug.

[Bug tree-optimization/107043] range information not used in popcount

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-26
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Confirmed. The following two should be optimized too:
int g0(int n)
{
  int n1 = n & 0x8000;
  if (n1 == 0)
return 1;
  // n1 will be 0x8000 here.
  return (n1 >> 15) & 0x1;
}

int g1(int n)
{
  int n1 = n & 0x8000;
  if (n1 == 0)
return 1;
  // n>>15 will be xx1 here.
  return (n >> 15) & 0x1;
}

[Bug tree-optimization/107043] New: range information not used in popcount

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

Bug ID: 107043
   Summary: range information not used in popcount
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

This code could be compiled to a simple return of the value 1 but it isn't
because the range information for n does not survive long enough.

int g(int n)
{
  n &= 0x8000;
  if (n == 0)
return 1;
  return __builtin_popcount(n);
}

The code generated today is lengthy:

   0:   81 e7 00 80 00 00   and$0x8000,%edi
   6:   ba 01 00 00 00  mov$0x1,%edx
   b:   89 f8   mov%edi,%eax
   d:   c1 e8 0fshr$0xf,%eax
  10:   85 ff   test   %edi,%edi
  12:   0f 44 c2cmove  %edx,%eax
  15:   c3  ret

[Bug bootstrap/107042] GCC build error after today's change

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #6 from cqwrteur  ---
(In reply to Martin Liška from comment #5)
> Hm, you have | #define HAVE_AS_COMPRESS_DEBUG 2 which is an invalid value.
> Please remove the build directory and reconfigure it. Does it help?

it is working. hmhm

[Bug bootstrap/107042] GCC build error after today's change

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

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

--- Comment #5 from Martin Liška  ---
Hm, you have | #define HAVE_AS_COMPRESS_DEBUG 2 which is an invalid value.
Please remove the build directory and reconfigure it. Does it help?

[Bug bootstrap/107042] GCC build error after today's change

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
Created attachment 53629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53629&action=edit
cfg

[Bug bootstrap/107042] GCC build error after today's change

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

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

--- Comment #3 from Martin Liška  ---
It must be toplev config.log file, I will need the one under 'gcc' folder,
thanks.

[Bug bootstrap/107042] GCC build error after today's change

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
Created attachment 53628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53628&action=edit
config

[Bug bootstrap/107042] GCC build error after today's change

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-09-26
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Mine started with r13-2774-g26607a63da9922.

Please attach gcc/config.log file.

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #6 from Martin Liška  ---
> That looks like unpatched elfutils.  I know you mentioned[1] that you're
> using the latest elfutils but can you please confirm again?  Or maybe
> incorrect preprocessed file?
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29614#c2

Whoops, you are right. I've got 2 tested projects where only one contains the
latest elfutils snapshot.

[Bug bootstrap/107042] New: GCC build error after today's change

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 107042
   Summary: GCC build error after today's change
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

g++ -no-pie   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov.o json.o \
hash-table.o ggc-none.o libcommon.a ../libcpp/libcpp.a  
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -L./../zlib -lz -o gcov
../../../../../gcc/gcc/gcc.cc:1262:1: error: expected ',' or ';' before
'ASM_COMPRESS_DEBUG_SPEC'
 1262 | ASM_COMPRESS_DEBUG_SPEC
  | ^~~

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #5 from Siddhesh Poyarekar  ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Liška from comment #2)
> > > I assume this is elfutils #29614?
> > 
> > Yes.
> > 
> > Please take a look at the original unreduced testcase I attached here.
> 
> That looks like unpatched elfutils.  I know you mentioned[1] that you're
> using the latest elfutils but can you please confirm again?  Or maybe
> incorrect preprocessed file?
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29614#c2

OK maybe that's irrelevant from the gcc perspective because this is basically
warning on unreachable code, which we know tends to happen sometimes.  The
comment is mainly for the elfutils issue you're facing.

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #4 from Siddhesh Poyarekar  ---
(In reply to Martin Liška from comment #2)
> > I assume this is elfutils #29614?
> 
> Yes.
> 
> Please take a look at the original unreduced testcase I attached here.

That looks like unpatched elfutils.  I know you mentioned[1] that you're using
the latest elfutils but can you please confirm again?  Or maybe incorrect
preprocessed file?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29614#c2

[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

Thanks for the report!

[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675

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

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

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

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

commit r10-11004-gf5840677c146e4317d7fd53697dda60c616d3e58
Author: Harald Anlauf 
Date:   Tue Sep 20 22:41:48 2022 +0200

Fortran: error recovery on invalid ARRAY argument to FINDLOC [PR106986]

gcc/fortran/ChangeLog:

PR fortran/106986
* simplify.c (gfc_simplify_findloc): Do not try to simplify
intrinsic FINDLOC when the ARRAY argument has a NULL shape.

gcc/testsuite/ChangeLog:

PR fortran/106986
* gfortran.dg/pr106986.f90: New test.

(cherry picked from commit 5976fbf9d5dd9542fcb82eebb2185886fd52d000)

[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675

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

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

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

https://gcc.gnu.org/g:50592ed4703d2e1ade2b197c58b72da0b91933cc

commit r11-10274-g50592ed4703d2e1ade2b197c58b72da0b91933cc
Author: Harald Anlauf 
Date:   Tue Sep 20 22:41:48 2022 +0200

Fortran: error recovery on invalid ARRAY argument to FINDLOC [PR106986]

gcc/fortran/ChangeLog:

PR fortran/106986
* simplify.c (gfc_simplify_findloc): Do not try to simplify
intrinsic FINDLOC when the ARRAY argument has a NULL shape.

gcc/testsuite/ChangeLog:

PR fortran/106986
* gfortran.dg/pr106986.f90: New test.

(cherry picked from commit 5976fbf9d5dd9542fcb82eebb2185886fd52d000)

[Bug c++/106656] [C++23] P2513 - char8_t Compatibility and Portability Fixes

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Implemented in GCC 13.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106656 Summary: [C++23] P2513 - char8_t Compatibility and Portability Fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106656

   What|Removed |Added

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

[Bug c++/106656] [C++23] P2513 - char8_t Compatibility and Portability Fixes

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

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:567329fdd9d65a1e6254206fefff89fa151ba7f3

commit r13-2881-g567329fdd9d65a1e6254206fefff89fa151ba7f3
Author: Marek Polacek 
Date:   Fri Sep 23 18:06:34 2022 -0400

c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

P0482R6, which added char8_t, didn't allow

  const char arr[] = u8"howdy";

because it said "Declarations of arrays of char may currently be
initialized
with UTF-8 string literals. Under this proposal, such initializations would
become ill-formed."  This caused too many issues, so P2513R4 alleviates
some
of those compatibility problems.  In particular, "Arrays of char or
unsigned
char may now be initialized with a UTF-8 string literal."  This restriction
has been lifted for initialization only, not implicit conversions.  Also,
my reading is that 'signed char' was excluded from the allowable
conversions.

This is supposed to be treated as a DR in C++20.

PR c++/106656

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_char8_t
for C++20.

gcc/cp/ChangeLog:

* typeck2.cc (array_string_literal_compatible_p): Allow
initializing arrays of char or unsigned char by a UTF-8 string
literal.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/feat-cxx2b.C: Adjust.
* g++.dg/cpp2a/feat-cxx2a.C: Likewise.
* g++.dg/ext/char8_t-feature-test-macro-2.C: Likewise.
* g++.dg/ext/char8_t-init-2.C: Likewise.
* g++.dg/cpp2a/char8_t3.C: New test.
* g++.dg/cpp2a/char8_t4.C: New test.

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

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

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

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

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

commit r13-2880-g5e77d4082fa845f1182641a93cfbae71984244d2
Author: Aldy Hernandez 
Date:   Fri Sep 23 19:47:19 2022 +0200

Optimize [0 = x & MASK] in range-ops.

For [0 = x & MASK], we can determine that x is ~MASK.  This is
something we're picking up in DOM thanks to maybe_set_nonzero_bits,
but is something we should handle natively.

This is a good example of how much easier to maintain the range-ops
entries are versus the ad-hoc pattern matching stuff we had to do
before.  For the curious, compare the changes to range-op here,
versus maybe_set_nonzero_bits.

I'm leaving the call to maybe_set_nonzero_bits until I can properly
audit it to make sure we're catching it all in range-ops.  It won't
hurt, since both set_range_info() and set_nonzero_bits() are
intersect operations, so we'll never lose information if we do both.

PR tree-optimization/107009

gcc/ChangeLog:

* range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x &
MASK.
(range_op_bitwise_and_tests): New test.

[Bug c++/106784] Add __is_convertible built-in

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-2879-gbe4b32b9ef69b86b662cb7511b48cd1048a55403
Author: Marek Polacek 
Date:   Mon Sep 26 10:21:38 2022 -0400

c++: Instantiate less when evaluating __is_convertible

Jon reported that evaluating __is_convertible in a test led to
instantiating something ill-formed and so we failed to compile the test.
__is_convertible doesn't and shouldn't need to instantiate so much, so
let's limit it with a cp_unevaluated guard.  Use a helper function to
implement both built-ins.

PR c++/106784

gcc/cp/ChangeLog:

* method.cc (is_convertible_helper): New.
(is_convertible): Use it.
(is_nothrow_convertible): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_convertible3.C: New test.
* g++.dg/ext/is_nothrow_convertible3.C: New test.

[Bug rtl-optimization/78085] extra sign extend if used to store in 32bit and return 64bit and the upper bits are known to be zeroed.

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

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

--- Comment #4 from Andrew Pinski  ---
Most likely r13-1942-gc23a9c87cc62bd .

[Bug rtl-optimization/78085] extra sign extend if used to store in 32bit and return 64bit and the upper bits are known to be zeroed.

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

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

--- Comment #3 from Andrew Pinski  ---
>From REE:
Trying to eliminate extension:
(insn 9 8 15 2 (set (reg:DI 0 ax [orig:88 _3 ] [88])
(sign_extend:DI (reg:SI 0 ax [orig:84 _3 ] [84]))) "a.c":6:9 160
{*extendsidi2_rex64}
 (nil))
Tentatively merged extension with definition :
(insn 7 6 8 2 (parallel [
(set (reg:DI 0 ax)
(zero_extend:DI (and:SI (reg:SI 0 ax [86])
(const_int 3 [0x3]
(clobber (reg:CC 17 flags))
]) "a.c":5:4 -1
 (nil))
deferring rescan insn with uid = 7.
All merges were successful.
Eliminated the extension.
deferring deletion of insn with uid = 9.
Elimination opportunities = 1 realized = 1

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #3 from Martin Sebor  ---
Just a quick note from what I see in GDB.  The warning is issued by the 2nd run
of the waccess pass (-fdump-tree-waccess2) for the following statement in bb 22
in pread():

  iftmp.21_88 = __pread_alias (_50, _82, _81, _79);

_81's range reported by range_query::range_of_expr (vr, exp, stmt) is [58,
ULONG_MAX], matching the range in the warning.

A partial output of debug_ranger() for the function is below.  I must be
reading it wrong because  I don't see what the range above is derived from.

=== BB 19 
Imports: recvd_78  _83  
Exports: _51  recvd_78  recvd.17_80  _83  _94  _116  _125  
_83 [irange] UNDEFINED
 [local count: 169058114]:
if (_83 == 18446744073709551615)
  goto ; [34.00%]
else
  goto ; [66.00%]

19->22  (T) _83 :   [irange] UNDEFINED
19->20  (F) _83 :   [irange] UNDEFINED

=== BB 20 
Imports: _81  _83  
Exports: _81  _83  _85  _86  _87  
 _85 : _81(I)  _83(I)  
 _86 : _81(I)  _83(I)  _85  
 _87 : _81(I)  _83(I)  _85  _86  
_81 [irange] long unsigned int VARYING
_83 [irange] long unsigned int VARYING
 [local count: 280636469]:
_85 = _81 <= _83;
_86 = (int) _85;
_87 = __builtin_constant_p (_86);
if (_87 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

_86 : [irange] int [0, 1] NONZERO 0x1
_87 : [irange] int [0, 0] NONZERO 0x0
20->21  (T) _81 :   [irange] UNDEFINED
20->21  (T) _83 :   [irange] UNDEFINED
20->21  (T) _85 :   [irange] UNDEFINED
20->21  (T) _86 :   [irange] UNDEFINED
20->21  (T) _87 :   [irange] UNDEFINED
20->24  (F) _86 :   [irange] int [0, 1] NONZERO 0x1
20->24  (F) _87 :   [irange] int [0, 0] NONZERO 0x0

=== BB 21 
Imports: recvd_78  _81  _83  
Exports: _51  recvd_78  recvd.17_80  _81  _83  _94  _116  _125  
_81 [irange] UNDEFINED
_83 [irange] UNDEFINED
 [local count: 140318235]:
if (_81 <= _83)
  goto ; [50.00%]
else
  goto ; [50.00%]

21->22  (T) _81 :   [irange] UNDEFINED
21->22  (T) _83 :   [irange] UNDEFINED
21->23  (F) _81 :   [irange] UNDEFINED
21->23  (F) _83 :   [irange] UNDEFINED

=== BB 22 
 [local count: 127638877]:
iftmp.21_88 = __pread_alias (_50, _82, _81, _79);
goto ; [100.00%]

[Bug c/107016] [meta-bug] tracker bug for supporting "sparse" attributes in GCC

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

[Bug c++/107033] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:099a66498bf7a40764002793eba66c881a251b76

commit r13-2878-g099a66498bf7a40764002793eba66c881a251b76
Author: Patrick Palka 
Date:   Mon Sep 26 11:30:17 2022 -0400

c++ modules: variable template partial spec fixes [PR107033]

In r13-2775-g32d8123cd6ce87 I missed that we need to adjust the call to
add_mergeable_specialization in the MK_partial case to correctly handle
variable template partial specializations (it currently assumes we're
always dealing with one for a class template).  This fixes an ICE when
converting the testcase from that commit to use an importable header
instead of a named module.

PR c++/107033

gcc/cp/ChangeLog:

* module.cc (trees_in::decl_value): In the MK_partial case for
a variable template partial specialization, pass decl_p=true to
add_mergeable_specialization, and set spec to the VAR_DECL not
the TEMPLATE_DECL.
* pt.cc (add_mergeable_specialization): For a variable template
partial specialization, set the TREE_TYPE of the new
DECL_TEMPLATE_SPECIALIZATIONS node to the TREE_TYPE of the
VAR_DECL not the VAR_DECL itself.

gcc/testsuite/ChangeLog:

* g++.dg/modules/partial-2.cc, g++.dg/modules/partial-2.h: New
files, factored out from ...
* g++.dg/modules/partial-2_a.C, g++.dg/modules/partial-2_b.C: ...
these.
* g++.dg/modules/partial-2_c.H: New test.
* g++.dg/modules/partial-2_d.C: New test.

[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Mine then.

[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |10.5

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #9 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer

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

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

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

https://gcc.gnu.org/g:2460f7cdef7ef9c971de79271afc0db73687a272

commit r13-2876-g2460f7cdef7ef9c971de79271afc0db73687a272
Author: Aldy Hernandez 
Date:   Fri Sep 23 19:47:33 2022 +0200

Set ranges from unreachable edges for all known ranges.

In the conversion of DOM+evrp to DOM+ranger, we missed that evrp was
exporting ranges for unreachable edges for all SSA names for which we
have ranges for.  Instead we have only been exporting ranges for the
SSA name in the final conditional to the BB involving the unreachable
edge.

This patch adjusts adjusts DOM to iterate over the exports, similarly
to what evrp was doing.

Note that I also noticed that we don't calculate the nonzero bit mask
for op1, when 0 = op1 & MASK.  This isn't needed for this PR,
since maybe_set_nonzero_bits() is chasing the definition and
parsing the bitwise and on its own.  However, I'll be adding the
functionality for completeness sake, plus we could probably drop the
maybe_set_nonzero_bits legacy call entirely.

PR tree-optimization/107009

gcc/ChangeLog:

* tree-ssa-dom.cc
(dom_opt_dom_walker::set_global_ranges_from_unreachable_edges):
Iterate over exports.

gcc/testsuite/ChangeLog:

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

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> (In reply to kargl from comment #2)
> > gfortran's current behavior is correct.
> > 
> > 
> >12.3.4.4 File position after data transfer
> > 
> >In all other cases, the file is positioned after the record just
> >read or written and that record becomes the preceding record.
> > 
> >12.8.3 ENDFILE statement
> > 
> >Execution of an ENDFILE statement for a file connected for sequential
> >access writes an endfile record as the next record of the file.
> > 
> > After reading '5', the file is position at the record that contains '6'.
> > So, ENDIFLE writes the endfile record after the record with '6'.
> 
> Hmm, interpretation of text?
> 
 Yes, it is interpretation.

Let  denote the start of record and  the end of the record.
One has 

567

After reading '5', the file is positioned to after that record.  If * denotes
the current file, then one can have

5*6 or 5*6

Both meet the requirement of 12.3.4.4. Now by 12.8.3, the endfile will give

5EOF

while the latter would give

5*6EOF.

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #2 from Martin Liška  ---
> I assume this is elfutils #29614?

Yes.

Please take a look at the original unreduced testcase I attached here.

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

--- Comment #1 from Siddhesh Poyarekar  ---
recvd is uninitialized and it seems to be preventing optimization of the
fortify macro one way or for some reason.  I can take a look at why the
condition does not get folded away but a reproducer without undefined behaviour
may be more persuasive.  I assume this is elfutils #29614?

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

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

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

--- Comment #9 from Thomas Neumann  ---
Yes, commit 386ebf75f4c0342b1f823f4e4aba07abda3288d1 fixes the assert.

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
   See Also||https://github.com/Rust-GCC
   ||/gccrs/issues/1544
 Target|i586-msdosdjgpp,|i586-msdosdjgpp,
   |aarch64-none-elf|aarch64-none-elf,
   ||x86_64-apple-darwin20.6.0
   Assignee|unassigned at gcc dot gnu.org  |tneumann at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #8 from Thomas Schwinge  ---
Thomas Neumann, I suppose this is fixed via your commit
r13-2870-g386ebf75f4c0342b1f823f4e4aba07abda3288d1 "fix assert in
__deregister_frame_info_bases"?

[Bug libgomp/107041] New: [13 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'

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

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

Bug ID: 107041
   Summary: [13 Regression] C '-Wenum-int-mismatch' diagnostic for
OpenACC 'acc_on_device'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
mpolacek at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

Clean for C++:

$ printf '#include \nint foo(){ return
acc_on_device(acc_device_host); }\n' | build-gcc/gcc/xgcc -Bbuild-gcc/gcc
-Isource-gcc/libgomp -x c++ - -fopenacc -S -Wall

..., but not anymore for C:

$ printf '#include \nint foo(){ return
acc_on_device(acc_device_host); }\n' | build-gcc/gcc/xgcc -Bbuild-gcc/gcc
-Isource-gcc/libgomp -x c - -fopenacc -S -Wall
In file included from :1:
source-gcc/libgomp/openacc.h:103:5: warning: conflicting types for
‘acc_on_device’ due to enum/integer mismatch; have ‘int(acc_device_t)’
[-Wenum-int-mismatch]
  103 | int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW;
  | ^

That's commit r13-627-g7da9a089608b0ca09683332ce014fb6184842724 "c: Implement
new -Wenum-int-mismatch warning [PR105131]".

This causes excess errors (only!) for
'libgomp.oacc-c/../libgomp.oacc-c-c++-common/host_data-1.c' (when its
prerequisites are met); that's one of the few libgomp test cases where '-Wall'
is in effect.  (I'd "complained" about lack of '-Wall' testing before.)

OpenACC 'acc_on_device' is implemented as follows:

libgomp/openacc.h-#ifdef __cplusplus
libgomp/openacc.h:int acc_on_device (int __arg) __GOACC_NOTHROW;
libgomp/openacc.h-#else
libgomp/openacc.h:int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW;
libgomp/openacc.h-#endif

libgomp/openacc.h-#ifdef __cplusplus
libgomp/openacc.h-[...]
libgomp/openacc.h-
libgomp/openacc.h-/* Forwarding function with correctly typed arg.  */
libgomp/openacc.h-
libgomp/openacc.h-#pragma acc routine seq
libgomp/openacc.h:inline int acc_on_device (acc_device_t __arg)
__GOACC_NOTHROW
libgomp/openacc.h-{
libgomp/openacc.h:  return acc_on_device ((int) __arg);
libgomp/openacc.h-}
libgomp/openacc.h-#endif

gcc/omp-builtins.def:DEF_GOACC_BUILTIN_COMPILER (BUILT_IN_ACC_ON_DEVICE,
"acc_on_device",
gcc/omp-builtins.def-BT_FN_INT_INT,
ATTR_CONST_NOTHROW_LEAF_LIST)

libgomp/oacc-init.c:/* For -O and higher, the compiler always attempts to
expand acc_on_device, but
libgomp/oacc-init.c-   if the user disables the builtin, or calls it via a
pointer, we'll need this
libgomp/oacc-init.c-   version.
libgomp/oacc-init.c-
libgomp/oacc-init.c-   Compile this with optimization, so that the compiler
expands
libgomp/oacc-init.c-   this, rather than generating infinitely recursive
code.
libgomp/oacc-init.c-
libgomp/oacc-init.c:   The function just forwards its argument to
__builtin_acc_on_device.  It does
libgomp/oacc-init.c-   not verify that the argument is a valid acc_device_t
enumeration value.  */
libgomp/oacc-init.c-
libgomp/oacc-init.c-int __attribute__ ((__optimize__ ("O2")))
libgomp/oacc-init.c:acc_on_device (acc_device_t dev)
libgomp/oacc-init.c-{
libgomp/oacc-init.c:  return __builtin_acc_on_device (dev);
libgomp/oacc-init.c-}
libgomp/oacc-init.c-
libgomp/oacc-init.c:ialias (acc_on_device)

If I remember correctly, the reason for the "strange" prototyping/forwarding is
that GCC builtins don't allow for 'enum' arguments?  (I may be misremembering.)

---

Maybe a fix for this would fall out of Tom's patch for PR82391 "[openacc]
acc_on_device not folded at -O0"?  (I've paged out all state of that one,
unfortunately.)

[Bug c++/107033] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-26
 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #5 from Patrick Palka  ---
D'oh, thanks for the report.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 107037 Summary: [13 Regression] 541.leela_r compiling fail since r13-2779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107037

   What|Removed |Added

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

[Bug libstdc++/107037] [13 Regression] 541.leela_r compiling fail since r13-2779

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/107037] [13 Regression] 541.leela_r compiling fail since r13-2779

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

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

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

https://gcc.gnu.org/g:6904ed80a26f5216aa3b9ce8377fb50307c8e886

commit r13-2869-g6904ed80a26f5216aa3b9ce8377fb50307c8e886
Author: Jonathan Wakely 
Date:   Mon Sep 26 11:11:35 2022 +0100

libstdc++: Add #if around non-C++03 code in std::bitset [PR107037]

libstdc++-v3/ChangeLog:

PR libstdc++/107037
* include/std/bitset (_Base_bitset::_M_do_reset): Use
preprocessor conditional around non-C++03 code.
* testsuite/20_util/bitset/107037.cc: New test.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

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

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

--- Comment #5 from Christophe Lyon  ---
Could you share the preprocessed source file in the M3 and M4 cases along with
the full command line used to compile it?

[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
Started with r10-1214-g1bf32c1141e230

PR c++/60364 - noreturn after first decl not diagnosed.

* attribs.c (get_attribute_namespace): No longer static.
(decl_attributes): Avoid shadowing.  Preserve the C++11 form for
C++11
attributes.
(attr_noreturn_exclusions): Make it extern.
* attribs.h (get_attribute_namespace): Declare.
* tree-inline.c (function_attribute_inlinable_p): Use
get_attribute_name.

* c-attribs.c (handle_noreturn_attribute): No longer static.
* c-common.h (handle_noreturn_attribute, attr_noreturn_exclusions):
Declare.
* c-format.c (check_function_format): Use get_attribute_name.

* decl.c (duplicate_decls): Give an error when a function is
declared [[noreturn]] after its first declaration.
* parser.c (cp_parser_std_attribute): Don't treat C++11 noreturn
attribute as equivalent to GNU's.
* tree.c (std_attribute_table): Add noreturn.

[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.1.0, 10.4.1, 11.1.0,
   ||11.3.1, 12.1.0, 12.2.1,
   ||13.0
  Known to work||9.5.0
Summary|[[gnu::stdcall]] Crashes|[10/11/12/13 Regression]
   |the compiler, but   |[[gnu::stdcall]] Crashes
   |__attribute__((stdcall))|the compiler, but
   |and __stdcall worrks|__attribute__((stdcall))
   ||and __stdcall worrks

--- Comment #3 from Jonathan Wakely  ---
GCC 10/11/12 say:

cc1plus: out of memory allocating 18446744073537494608 bytes after a total of
3219456 bytes

GCC 9 is OK. Bisecting now...

[Bug c++/107023] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-09-26
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
Reproduces for me with -m32 -g

[Bug c++/107024] ICE in finish_expr_stmt, at cp/semantics.cc:872

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

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

--- Comment #2 from Martin Liška  ---

Test-case:

#include 
#include 
#include 

template 
struct Integral_pack
{
static constexpr size_t data[sizeof...(NN)] = { NN... };
std::vector vec { NN... };
};

template 
consteval auto apply_fold_impl(std::index_sequence)
{
return Integral_pack{};
};

template 
consteval auto apply_fold()
{
return apply_fold_impl(std::make_index_sequence{});
}

template 
using left_shift 
= decltype(apply_fold());

template 
auto ls_vec = left_shift{}.vec;

template 
using right_shift 
= decltype(apply_fold> R); },
C>());

template 
std::vector rs_vec = right_shift{}.vec;

int main() 
{
for(auto& i : ls_vec<12351, 15>) std::cout << i << " ";
std::cout << "\n";
for(auto& i : rs_vec<12351, 15>) std::cout << i << " ";
std::cout << "\n";
}

[Bug c++/107024] ICE in finish_expr_stmt, at cp/semantics.cc:872

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-09-26

--- Comment #1 from Martin Liška  ---
Please always include a test-case here and not via godbolt.

Confirmed.

[Bug c++/107023] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Can't reproduce ..

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Martin Liška from comment #4)
> Yep, it exits here:
> 
> #0  __GI_exit (status=1) at exit.c:142
> #1  0x002b0961 in povray_exit (i=1) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/povray.cpp:486
> #2  0x002e3ede in pov::Error (format=) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/userio.cpp:365
> #3  0x00270f16 in pov::Parse_Camera (Camera_Ptr=) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:1423
> #4  0x0028083f in pov::Parse_Frame () at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:6125
> #5  0x002c0557 in pov::Parse () at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:289
> 
> parse.cpp contains:
> 
> where New->Angle is infinite as assigned here:
> 1180  New->Angle = HUGE_VAL;
> 
> #if __GNUC_PREREQ (3, 3)
> # define HUGE_VAL (__builtin_huge_val ())
> #else

And the code that fails is guarded with

// apply "angle"
if (New->Angle != HUGE_VAL)
{
if ((New->Type == PERSPECTIVE_CAMERA) || (New->Type ==
ORTHOGRAPHIC_CAMERA))
{
if (New->Angle >= 180.0)
Error("Viewing angle has to be smaller
than 180 degrees.");

so it's somewhat "bad QOI" if we optimize

  mem = Inf;
  if (mem != Inf)
abort ();

with -ffinite-math-only because in some way there's no "math" involved here :P
But yeah, the above is just a cheap isinf() which we'd have folded before
and now we're folding the literal equality compare as well.

Meh.

-ffinite-math-only was supposed to give us leverage in associating ops and
not wory about turning +Inf into something else, like x + x - x is +Inf
if x + x overflows but we like to optimize it to 'x'.  That is, it was
more relaxing arithmetic folding than saying "any Inf invokes undefined
behavior".

The docs still say

@item -ffinite-math-only
@opindex ffinite-math-only
Allow optimizations for floating-point arithmetic that assume
that arguments and results are not NaNs or +-Infs.

blindly breaking programs without benefit isn't really what we should do,
but then this ship may have sailed 

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

--- Comment #7 from Martin Liška  ---
(In reply to Richard Biener from comment #6)
> (In reply to Martin Liška from comment #5)
> > >
> > > so I'd call that a testsuite issue.
> > > 
> > 
> > Yep, how should I fix the verifier? Just skip it if the expected value is
> > infinite?
> 
> No, don't build it with -fno-finite-math-only?

That's fine for TSVC, I can adjust that. The question is what to do with
511.povray_r as we want to support SPECs with -Ofast.

[Bug middle-end/106982] [10/11/12/13 Regression][OpenACC] ICE incorrect sharing of tree nodes with nested reduction / .GOACC_REDUCTION

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r13-2868-gd3df98807b58df186061ad52ff87cc09ba593e9b
Author: Tobias Burnus 
Date:   Mon Sep 26 12:45:28 2022 +0200

OpenACC: Fix reduction tree-sharing issue [PR106982]

The tree for var == incoming == outgound was
'MEM  [(double *)&reduced]' which caused the ICE
"incorrect sharing of tree nodes".

PR middle-end/106982

gcc/ChangeLog:

* omp-low.cc (lower_oacc_reductions): Add some unshare_expr.

gcc/testsuite/ChangeLog:

* c-c++-common/goacc/reduction-7.c: New test.
* c-c++-common/goacc/reduction-8.c: New test.

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Martin Liška from comment #5)
> >
> > so I'd call that a testsuite issue.
> > 
> 
> Yep, how should I fix the verifier? Just skip it if the expected value is
> infinite?

No, don't build it with -fno-finite-math-only?

[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu since r13-2251-g1930c5d05ceff2

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Fixed with r13-2867-g2387cfc7f6e206:

s390: fix wrong refactoring

Since r13-2251-g1930c5d05ceff2, the refactoring is not 1:1 and we end
up with a wrong rtx type.

gcc/ChangeLog:

* config/s390/s390.cc (s390_rtx_costs): Remove dest variable
and use only dst.

[Bug libstdc++/107037] [13 Regression] 541.leela_r compiling fail since r13-2779

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-09-26

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

--- Comment #5 from Martin Liška  ---
>
> so I'd call that a testsuite issue.
> 

Yep, how should I fix the verifier? Just skip it if the expected value is
infinite?

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-26

--- Comment #4 from Martin Liška  ---
Yep, it exits here:

#0  __GI_exit (status=1) at exit.c:142
#1  0x002b0961 in povray_exit (i=1) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/povray.cpp:486
#2  0x002e3ede in pov::Error (format=) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/userio.cpp:365
#3  0x00270f16 in pov::Parse_Camera (Camera_Ptr=) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:1423
#4  0x0028083f in pov::Parse_Frame () at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:6125
#5  0x002c0557 in pov::Parse () at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:289

parse.cpp contains:

where New->Angle is infinite as assigned here:
1180New->Angle = HUGE_VAL;

#if __GNUC_PREREQ (3, 3)
# define HUGE_VAL (__builtin_huge_val ())
#else

[Bug target/107025] gas doesn't accept code produced by -mcpu=thunderx3t110

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-09-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from ktkachov at gcc dot gnu.org ---
In the Arm architecture this is FEAT_LRCPC2. LLVM does have an MC (essentially
assembler-level) feature string for it called "rcpc-immo", so if we wanted to
support this I guess we'd want to be compatible.
That said, it may be cleaner to just remove support for thunderx3t110 if we
think it's the right time.

Unfortunately we do still have some cases where our features aren't
fine-grained enough and are tied to architecture levels that some CPUs don't
claim to support:
https://godbolt.org/z/axbnd4c5o

[Bug c++/106921] [11/12/13 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6

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

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

--- Comment #4 from Martin Liška  ---
Will take a look in next weeks.

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |13.0

[Bug libstdc++/107037] [13 Regression] 541.leela_r compiling fail since r13-2779

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||rejects-valid
 Blocks||26163
Summary|541.leela_r compiling fail  |[13 Regression] 541.leela_r
   |since r13-2779  |compiling fail since
   ||r13-2779


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c++/82877] negative array index accepted in a pointer difference expression in constexpr context

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug c++/107039] GCC not diagnosing UB in constant expression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
Dup of PR 82877 I think.

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

[Bug c++/107033] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug lto/107030] Emitted binary code changes when -g is enabled at -O2 -flto and optimize attribute

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-26
   Keywords||compare-debug-failure
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
The difference is that with -g 'd' is not emitted:

@@ -46,10 +57,217 @@
.size   a, 4
 a:
.zero   4
-   .align 8
-   .type   d, @object
-   .size   d, 8
-d:
-   .zero   8
+   .text
+.Letext0:
+   .section.debug_info,"",@progbits

with just -fwhole-program but without -flto 'd' is emitted in both cases.

[Bug middle-end/107028] [13 Regression][OpenACC] ICE in install_var_field, at omp-low.cc:797

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

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

make check-gcc RUNTESTFLAGS="--target_board=unix/-march=znver2/-Ofast
vect.exp=vect-tsvc-s1281.c"

doesn't work to reproduce since the harness appends -O2, but I can reproduce
with -Ofast -mavx2 on trunk.

value: inf, expected: inf

because

} else if (!strcmp(name, "s1281")) {
return INFINITY;

and

tatic _Bool is_checksum_same(real_t expected, real_t value)
{
  if (expected == INFINITY)
  return value == INFINITY;

is likely optimized away and we end up in

  else {
  real_t fraction = value / expected;
  return 0.99f <= fraction && fraction <= 1.01f;

so I'd call that a testsuite issue.

Do we know what goes wrong with povray?

[Bug c++/107039] New: GCC not diagnosing UB in constant expression

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 107039
   Summary: GCC not diagnosing UB in constant expression
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

GCC doesn't give diagnostic for the following program while clang and msvc do.
Demo: https://godbolt.org/z/o3K57fjeE

```
struct S
{
int a, b;
};

constexpr void fn( S &s )
{
(&s.b)[-1] = 123;
}

constexpr auto test = ([]{
S s;
fn(s);
}(), 0);
```

There should be a diagnostic for the above code.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #4 from Thomas Petazzoni  ---
Yes, same triplet. We do not (yet) have FDPIC support for ARM in Buildroot (we
have a patch series pending for that).

[Bug tree-optimization/107038] New: [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

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

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

Bug ID: 107038
   Summary: [13 Regression] Bogus -Wstringop-overflow= since
r13-2789-gb40b3035879cf695
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: amacleod at redhat dot com, msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53627&action=edit
Original unreduced test-case

Reduced from elfutils:

$ cat core-file.c
#include 
struct ar_hdr {
  char ar_mode[8];
  char ar_size[10];
};

int r;

struct Elf {
  int fildes;
} pread_retry(int fd, void *buf, size_t len, off_t offset) {
  ssize_t recvd;
  r = pread(fd, buf + recvd, len - recvd, offset);
}

void elf_begin_rand() {
  struct Elf *parent;
  struct ar_hdr h;
  pread_retry(parent->fildes, h.ar_size, sizeof(h.ar_size), 0);
}

$ gcc core-file.c -c -O2 -Werror=stringop-overflow -D_FORTIFY_SOURCE=3
In file included from /usr/include/features.h:490,
 from /usr/include/unistd.h:25,
 from core-file.c:1:
In function ‘pread’,
inlined from ‘pread_retry’ at core-file.c:13:7,
inlined from ‘elf_begin_rand’ at core-file.c:19:3:
/usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ writing 18 or more
bytes into a region of size 10 overflows the destination
[-Werror=stringop-overflow=]
   74 |   return __glibc_fortify (pread, __nbytes, sizeof (char),
  |  ^~~
core-file.c: In function ‘elf_begin_rand’:
core-file.c:4:8: note: destination object ‘ar_size’ of size 10
4 |   char ar_size[10];
  |^~~
/usr/include/bits/unistd.h:50:16: note: in a call to function ‘__pread_alias’
declared with attribute ‘access (write_only, 2, 3)’
   50 | extern ssize_t __REDIRECT (__pread_alias,
  |^~
cc1: some warnings being treated as errors

I'm attaching also original unreduced test-case.

[Bug libstdc++/107037] New: 541.leela_r compiling fail since r13-2779

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

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

Bug ID: 107037
   Summary: 541.leela_r compiling fail since r13-2779
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

When building 541.leela_r from spec2017, I encounter one error:

include/c++/13.0.0/bitset: In instantiation of 'void
std::_Base_bitset<_Nw>::_M_do_reset() [with long unsigned int _Nw = 7]':
include/c++/13.0.0/bitset:1145:19:   required from 'std::bitset<_Nb>&
std::bitset<_Nb>::reset() [with long unsigned int _Nb = 441]'
Playout.cpp:20:18:   required from here
include/c++/13.0.0/bitset:187:13: error: forming reference to reference type
'long unsigned int (&)[7]'
  187 | for (_WordT& __w : _M_w)
  | ^~~


The command is 
g++ -std=c++03 -m64 -c -o Playout.o -DSPEC -DNDEBUG -I.
-DSPEC_AUTO_SUPPRESS_OPENMP  -Ofast  -DSPEC_LP64  Playout.cpp

This issue is also reproducible on -O3 or -O2.

It seems compiling fine before commit
r13-2779-9194c13909b72d23e58fee72864a2663b12f6b19.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

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

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

--- Comment #3 from Christophe Lyon  ---
Interesting

Did you use the same target triplet?

arm*-*-uclinuxfdpiceabi is handled differently from
arm-buildroot-uclinux-uclibcgnueabi

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #2 from Thomas Petazzoni  ---
Thanks for the feedback. There must be something special in those
configurations, because I did build a Cortex-M4 configuration with gcc 11.3.0
just a few days ago, and it built fine.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
At quick glance, I think this is caused by the definition of CLEAR_INSN_CACHE
in gcc/config/arm/uclinux-eabi.h:

/* Clear the instruction cache from `beg' to `end'.  This makes an
   inline system call to SYS_cacheflush.  */
#undef CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END)  \
{   \
  register unsigned long _beg __asm ("a1") = (unsigned long) (BEG); \
  register unsigned long _end __asm ("a2") = (unsigned long) (END); \
  register unsigned long _flg __asm ("a3") = 0; \
  register unsigned long _scno __asm ("r7") = 0xf0002;  \
  __asm __volatile ("swi 0x0@ sys_cacheflush"   \
: "=r" (_beg)   \
: "0" (_beg), "r" (_end), "r" (_flg), "r" (_scno)); \
}

which makes explicit use of r7.

This code has been like that since it was committed in 2007
So I suspect nobody ever tried to build this configuration.

[Bug bootstrap/107018] [13 Regression] libgcc unwind-dw2-fde references undeclared variable

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

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

[Bug bootstrap/107018] [13 Regression] libgcc unwind-dw2-fde references undeclared variable

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2022-09-26
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW