[Bug target/107432] __builtin_convertvector generates inefficient code

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---

> Guess expand_vector_conversion can be optimized.

  if (INTEGRAL_TYPE_P (TREE_TYPE (ret_type))
  && SCALAR_FLOAT_TYPE_P (TREE_TYPE (arg_type)))
code = FIX_TRUNC_EXPR;
  else if (INTEGRAL_TYPE_P (TREE_TYPE (arg_type))
   && SCALAR_FLOAT_TYPE_P (TREE_TYPE (ret_type)))
code = FLOAT_EXPR;

It only supports floatmn2/fix_truncmn2 for float <-> integer.

But we can also supports extendmn2/zero_extendmn2/truncmn2 for float <-> float,
integer <-> integer.

Or are there any concerns and VEC_PACK_TRUNC_EXPR,
VEC_PACK_FIX_TRUNC_EXPR,VEC_PACK_FLOAT_EXPR are used on purpose?

[Bug middle-end/107436] Is -fsignaling-nans still experimental?

[florian.schanda at bmw dot de via Gcc-bugs]

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

--- Comment #2 from Florian Schanda  ---
Hi Andrew,

thank you so much for your reply. The architecture in question is Goldmont,
is the flag alright for that target?

> A third party library depending on signaling NaNs is slightly an
> issue in general considering -fsignaling-nans is not on by default
> and some (many?) targets fpu have issues with signaling NaNs in general ...

Tell me about it :)

[Bug target/107432] __builtin_convertvector generates inefficient code

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---

> It's lowered by pass_lower_vector, ideally, can we use truncmn2 in
> expand_VEC_CONVERT if src is bigger integer mode than dest.

Currently, expand_vector_conversion uses VEC_PACK_TRUNC_EXPR

---cut begins
  else if (modifier == NARROW)
{
  switch (code)
{
CASE_CONVERT:
  code1 = VEC_PACK_TRUNC_EXPR;
  optab1 = optab_for_tree_code (code1, arg_type, optab_default);
  break;

---Cut ends

But BB vectorizer can do the right thing for 

void
foo (long long* a, int* b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}



vmovdqu ymm0, YMMWORD PTR [rdi]
vpmovqd XMMWORD PTR [rsi], ymm0
vzeroupper
ret


  vect__1.5_16 = MEM  [(long long int *)a_10(D)];
  vect__2.6_18 = (vector(4) int) vect__1.5_16;
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  MEM  [(int *)b_11(D)] = vect__2.6_18;
  return;


Guess expand_vector_conversion can be optimized.

[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249

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

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||rsandifo at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #11 from Kewen Lin  ---
The failures on powerpc should be fixed now.

Hi Andre/Richard, for now effective target vect_long_long isn't supported on
aarch64-*-*, it looks like an oversight?

[Bug target/107432] __builtin_convertvector generates inefficient code

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> typedef int v4si __attribute__((vector_size(16)));
> typedef long long v4di __attribute__((vector_size(32)));
> 
> v4si
> foo (v4di a)
> {
> return __builtin_convertvector (a, v4si);
> }
> 
> hmm, we actually support truncv4div4si2, but some how gcc failed to generate
> .VEC_CONVERT with truncmn2.
> 

/* IFN_VEC_CONVERT is supposed to be expanded at pass_lower_vector.  So this
   dummy function should never be called.  */

static void
expand_VEC_CONVERT (internal_fn, gcall *)
{
  gcc_unreachable ();
}

It's lowered by pass_lower_vector, ideally, can we use truncmn2 in
expand_VEC_CONVERT if src is bigger integer mode than dest.

[Bug target/107432] __builtin_convertvector generates inefficient code

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
typedef int v4si __attribute__((vector_size(16)));
typedef long long v4di __attribute__((vector_size(32)));

v4si
foo (v4di a)
{
return __builtin_convertvector (a, v4si);
}

hmm, we actually support truncv4div4si2, but some how gcc failed to generate
.VEC_CONVERT with truncmn2.

hmm, what's optab for convert_optab_handler?

[Bug testsuite/107240] [13 Regression] FAIL: gcc.dg/vect/vect-bitfield-write-2.c since r13-3219-g25413fdb2ac249

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:225f9c8805fb1ba68a877383095f38a9563526ee

commit r13-3535-g225f9c8805fb1ba68a877383095f38a9563526ee
Author: Kewen Lin 
Date:   Thu Oct 27 22:30:16 2022 -0500

testsuite: Adjust vect-bitfield-read-* with vect_shift and vect_long_long
[PR107240]

The test cases vect-bitfield-read-* requires vector shift
target support, they need one explicit vect_shift effective
target requirement checking.  Besides, the vectype for struct
in test cases vect-bitfield-read-{2,4} is vector of long long,
we need to check effective target vect_long_long for them.
This patch can help to fix all remaining vect-bitfield-{read,
write}-* test failures on powerpc.

PR testsuite/107240

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-bitfield-read-1.c: Add effective target checking
vect_shift.
* gcc.dg/vect/vect-bitfield-read-3.c: Likewise.
* gcc.dg/vect/vect-bitfield-read-5.c: Likewise.
* gcc.dg/vect/vect-bitfield-read-6.c: Likewise.
* gcc.dg/vect/vect-bitfield-read-7.c: Likewise.
* gcc.dg/vect/vect-bitfield-read-2.c: Add effective target checking
vect_shift and replace vect_int with vect_long_long.
* gcc.dg/vect/vect-bitfield-read-4.c: Likewise.

[Bug tree-optimization/107447] New: [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107447
   Summary: [13 Regression] ICE: verify_flow_info failed (error:
returns_twice call is not first in basic block 2)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221023 snapshot (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) ICEs
when compiling the following testcase w/ -O2:

int n;

void
bar (int, int);

__attribute__ ((noinline, returns_twice)) int
zero (void)
{
  return 0;
}

void
foo (void)
{
  (void) zero ();

  n = 0;

  for (;;)
bar (zero (), n);
}

% gcc-13 -O2 -c ozyot3yy.c
ozyot3yy.c: In function 'foo':
ozyot3yy.c:13:1: error: returns_twice call is not first in basic block 2
   13 | foo (void)
  | ^~~
_7 = zero ();
during GIMPLE pass: lim
ozyot3yy.c:13:1: internal compiler error: verify_flow_info failed
0xa0dd1d verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cfghooks.cc:284
0xe08403 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2103
0xe0891e execute_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2145

[Bug c/61469] language feature: Support for enum underlying type

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #12 from Joseph S. Myers  ---
Implemented for GCC 13.

[Bug c++/96496] Conversion to enum with underlying type bool produces wrong result

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

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

commit r13-3534-ge0997c14af5e8bc4d26e28549cbce99364a1601f
Author: Joseph Myers 
Date:   Fri Oct 28 00:37:28 2022 +

c: C2x enums with fixed underlying type [PR61469]

C2x adds support for enums with a fixed underlying type specified
("enum e : long long;" and similar).  Implement this in the C front
end.  The same representation is used for these types as in C++, with
two macros moved from cp-tree.h to c-common.h.

Such enums can have bool as the underlying type, and various C
front-end code checking for boolean types is adjusted to use a new
C_BOOLEAN_TYPE_P to handle such enums the same way as bool.  (Note
that for C++ we have bug 96496 that enums with underlying type bool
don't work correctly there.)

There are various issues with the wording for such enums in the
current C2x working draft (including but not limited to wording in the
accepted paper that failed to make it into the working draft), which I
intend to raise in NB comments.  I think what I've implemented and
added tests for matches the intent.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/61469

gcc/c-family/
* c-common.h (ENUM_UNDERLYING_TYPE, ENUM_FIXED_UNDERLYING_TYPE_P):
New.  Moved from cp/cp-tree.h.
* c-warn.cc (warnings_for_convert_and_check): Do not consider
conversions to enum with underlying type bool to overflow.

gcc/c/
* c-convert.cc (c_convert): Handle enums with underlying boolean
type like bool.
* c-decl.cc (shadow_tag_warned): Allow shadowing declarations for
enums with enum type specifier, but give errors for storage class
specifiers, qualifiers or alignment specifiers in non-definition
declarations of such enums.
(grokdeclarator): Give error for non-definition use of type
specifier with an enum type specifier.
(parser_xref_tag): Add argument has_enum_type_specifier.  Pass it
to lookup_tag and use it to set ENUM_FIXED_UNDERLYING_TYPE_P.
(xref_tag): Update call to parser_xref_tag.
(start_enum): Add argument fixed_underlying_type.  Complete enum
type with a fixed underlying type given in the definition.  Give
error for defining without a fixed underlying type in the
definition if one was given in a prior declaration.  Do not mark
enums with fixed underlying type as packed for -fshort-enums.
Store the enum type in the_enum.
(finish_enum): Do not adjust types of values or check their range
for an enum with a fixed underlying type.  Set underlying type of
enum and variants.
(build_enumerator): Check enumeration constants for enum with
fixed underlying type against that type and convert to that type.
Increment in the underlying integer type, with handling for bool.
(c_simulate_enum_decl): Update call to start_enum.
(declspecs_add_type): Set specs->enum_type_specifier_ref_p.
* c-objc-common.cc (c_get_alias_set): Use ENUM_UNDERLYING_TYPE
rather than recomputing an underlying type based on size.
* c-parser.cc (c_parser_declspecs)
(c_parser_struct_or_union_specifier, c_parser_typeof_specifier):
Set has_enum_type_specifier for type specifiers.
(c_parser_enum_specifier): Handle enum type specifiers.
(c_parser_struct_or_union_specifier): Update call to
parser_xref_tag.
(c_parser_omp_atomic): Check for boolean increment or decrement
using C_BOOLEAN_TYPE_P.
* c-tree.h (C_BOOLEAN_TYPE_P): New.
(struct c_typespec): Add has_enum_type_specifier.
(struct c_declspecs): Add enum_type_specifier_ref_p.
(struct c_enum_contents): Add enum_type.
(start_enum, parser_xref_tag): Update prototypes.
* c-typeck.cc (composite_type): Allow for enumerated types
compatible with bool.
(common_type, comptypes_internal, perform_integral_promotions):
Use ENUM_UNDERLYING_TYPE.
(parser_build_binary_op, build_unary_op, convert_for_assignment)
(c_finish_return, c_start_switch, build_binary_op): Check for
boolean types using C_BOOLEAN_TYPE_P.

gcc/cp/
* cp-tree.h (ENUM_FIXED_UNDERLYING_TYPE_P, ENUM_UNDERLYING_TYPE):
Remove.  Moved to c-common.h.

gcc/testsuite/
* gcc.dg/c11-enum-4.c, gcc.dg/c11-enum-5.c, gcc.dg/c11-enum-6.c,
gcc.dg/c2x-enum-6.c, gcc.dg/c2x-enum-7.c, gcc.dg/c2x-enum-8.c,

[Bug c/61469] language feature: Support for enum underlying type

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

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

commit r13-3534-ge0997c14af5e8bc4d26e28549cbce99364a1601f
Author: Joseph Myers 
Date:   Fri Oct 28 00:37:28 2022 +

c: C2x enums with fixed underlying type [PR61469]

C2x adds support for enums with a fixed underlying type specified
("enum e : long long;" and similar).  Implement this in the C front
end.  The same representation is used for these types as in C++, with
two macros moved from cp-tree.h to c-common.h.

Such enums can have bool as the underlying type, and various C
front-end code checking for boolean types is adjusted to use a new
C_BOOLEAN_TYPE_P to handle such enums the same way as bool.  (Note
that for C++ we have bug 96496 that enums with underlying type bool
don't work correctly there.)

There are various issues with the wording for such enums in the
current C2x working draft (including but not limited to wording in the
accepted paper that failed to make it into the working draft), which I
intend to raise in NB comments.  I think what I've implemented and
added tests for matches the intent.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/61469

gcc/c-family/
* c-common.h (ENUM_UNDERLYING_TYPE, ENUM_FIXED_UNDERLYING_TYPE_P):
New.  Moved from cp/cp-tree.h.
* c-warn.cc (warnings_for_convert_and_check): Do not consider
conversions to enum with underlying type bool to overflow.

gcc/c/
* c-convert.cc (c_convert): Handle enums with underlying boolean
type like bool.
* c-decl.cc (shadow_tag_warned): Allow shadowing declarations for
enums with enum type specifier, but give errors for storage class
specifiers, qualifiers or alignment specifiers in non-definition
declarations of such enums.
(grokdeclarator): Give error for non-definition use of type
specifier with an enum type specifier.
(parser_xref_tag): Add argument has_enum_type_specifier.  Pass it
to lookup_tag and use it to set ENUM_FIXED_UNDERLYING_TYPE_P.
(xref_tag): Update call to parser_xref_tag.
(start_enum): Add argument fixed_underlying_type.  Complete enum
type with a fixed underlying type given in the definition.  Give
error for defining without a fixed underlying type in the
definition if one was given in a prior declaration.  Do not mark
enums with fixed underlying type as packed for -fshort-enums.
Store the enum type in the_enum.
(finish_enum): Do not adjust types of values or check their range
for an enum with a fixed underlying type.  Set underlying type of
enum and variants.
(build_enumerator): Check enumeration constants for enum with
fixed underlying type against that type and convert to that type.
Increment in the underlying integer type, with handling for bool.
(c_simulate_enum_decl): Update call to start_enum.
(declspecs_add_type): Set specs->enum_type_specifier_ref_p.
* c-objc-common.cc (c_get_alias_set): Use ENUM_UNDERLYING_TYPE
rather than recomputing an underlying type based on size.
* c-parser.cc (c_parser_declspecs)
(c_parser_struct_or_union_specifier, c_parser_typeof_specifier):
Set has_enum_type_specifier for type specifiers.
(c_parser_enum_specifier): Handle enum type specifiers.
(c_parser_struct_or_union_specifier): Update call to
parser_xref_tag.
(c_parser_omp_atomic): Check for boolean increment or decrement
using C_BOOLEAN_TYPE_P.
* c-tree.h (C_BOOLEAN_TYPE_P): New.
(struct c_typespec): Add has_enum_type_specifier.
(struct c_declspecs): Add enum_type_specifier_ref_p.
(struct c_enum_contents): Add enum_type.
(start_enum, parser_xref_tag): Update prototypes.
* c-typeck.cc (composite_type): Allow for enumerated types
compatible with bool.
(common_type, comptypes_internal, perform_integral_promotions):
Use ENUM_UNDERLYING_TYPE.
(parser_build_binary_op, build_unary_op, convert_for_assignment)
(c_finish_return, c_start_switch, build_binary_op): Check for
boolean types using C_BOOLEAN_TYPE_P.

gcc/cp/
* cp-tree.h (ENUM_FIXED_UNDERLYING_TYPE_P, ENUM_UNDERLYING_TYPE):
Remove.  Moved to c-common.h.

gcc/testsuite/
* gcc.dg/c11-enum-4.c, gcc.dg/c11-enum-5.c, gcc.dg/c11-enum-6.c,
gcc.dg/c2x-enum-6.c, gcc.dg/c2x-enum-7.c, gcc.dg/c2x-enum-8.c,

[Bug testsuite/107446] New test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa has excess errors

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Sorry, I must have bisected it on multiple systems.

[Bug middle-end/107443] [10/11/12/13 Regression] Removing switch with __builtin_unreachable causes missed optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
   Last reconfirmed||2022-10-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||8.1.0
Summary|Switch conversion removing  |[10/11/12/13 Regression]
   |code|Removing switch with
   ||__builtin_unreachable
   ||causes missed optimizations
  Known to work||7.1.0

--- Comment #1 from Andrew Pinski  ---
Testcase which shows this is a regression and switch conversion just exposed
it:
void dead (unsigned n);
void foo (unsigned n);

void func (unsigned n)
{
  switch(n) {
  case 0:
__builtin_unreachable();
  case 1:
__builtin_unreachable();
  case 2:
__builtin_unreachable();
  case 3:
__builtin_unreachable();
  case 4:
__builtin_unreachable();
  case 5:
__builtin_unreachable();
  case 6:
__builtin_unreachable();
  case 7:
__builtin_unreachable();
default:
;
  }
  foo (n);
  if (n < 8)
dead (n);
}

after building the CFG we get with the above testcase:
Removing basic block 10
Removing basic block 9
Removing basic block 8
Removing basic block 7
Removing basic block 6
Removing basic block 5
Removing basic block 4
Removing basic block 3
Merging blocks 2 and 11

[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors

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

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

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

[Bug testsuite/107446] New test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa has excess errors

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You filed this 2 days ago ...
Must not have recorded it.

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

[Bug testsuite/107446] New: New test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa has excess errors

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

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

Bug ID: 107446
   Summary: New test case gcc.dg/analyzer/pipe-glibc.c in
r13-3466-g792f039fc37faa has excess errors
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:792f039fc37faa3446725a643c8018f084e8ccab, r13-3466-g792f039fc37faa

I only saw this on a power 9.  It ran OK on power 8 and power 10 machines.

configure --enable-languages=c,fortran,c++ --with-cpu=power9
--disable-bootstrap --disable-multilib

make  -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/pipe-glibc.c"
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
# of unexpected failures1


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
-fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -S -o pipe-glibc.s^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c: In
function 'write_to_pipe':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
warning: use of possibly-NULL 'stream' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:27:12:
note: (1) this call could return NULL^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
note: (2) argument 4 ('stream') from (1) could be NULL where non-null
expected^M
: note: argument 4 of '__builtin_fwrite' must be non-null^M
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled106355.cc   
-fdiagnostics-plain-output  -S -o exceptions_enabled106355.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled106355.cc
-fdiagnostics-plain-output -S -o exceptions_enabled106355.s^M
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
warning: use of possibly-NULL 'stream' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]


commit 792f039fc37faa3446725a643c8018f084e8ccab (HEAD, refs/bisect/bad)
Author: David Malcolm 
Date:   Mon Oct 24 16:38:22 2022 -0400

analyzer: handle "pipe" and "pipe2" [PR106300]

[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89967
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-27

--- Comment #9 from Andrew Pinski  ---
Oh yes PR 89967.

[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases

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

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

--- Comment #8 from Andrew Pinski  ---
I suspect you could get a similar testcase with ARM neon too.

[Bug target/107445] Redundant moves for subregs move

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Exact dup of bug 106694.

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

[Bug target/106694] Redundant move instructions in ARM SVE intrinsics use cases

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

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

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

[Bug target/107445] Redundant moves for subregs move

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

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

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

Compile at -march=armv8.8-a+sve  -O3

[Bug target/107445] Redundant moves for subregs move

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

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

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

[Bug c/107445] New: Redundant moves for subregs move

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 107445
   Summary: Redundant moves for subregs move
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

Here is the testcase:
https://godbolt.org/z/4bcfx5a86

coalesce:
ld4d{z24.d - z27.d}, p0/z, [x0]
mov z5.d, z24.d
mov z4.d, z25.d
mov z3.d, z26.d
mov z2.d, z27.d
cmp w1, 0
ble .L2
mov w0, 0
ld1dz1.d, p0/z, [x2]
ld1dz0.d, p0/z, [x3]
.L3:
add w0, w0, 1
movprfx z5.d, p0/z, z5.d
mad z5.d, p0/m, z1.d, z0.d
movprfx z4.d, p0/z, z4.d
mad z4.d, p0/m, z1.d, z0.d
movprfx z3.d, p0/z, z3.d
mad z3.d, p0/m, z1.d, z0.d
movprfx z2.d, p0/z, z2.d
mad z2.d, p0/m, z1.d, z0.d
cmp w1, w0
bne .L3

It's obvious that we should be able to directly use z24 - z27 to perform mad
oberation and remove the redundant moves in the prologue.

I tried to implement register coalescing in IRA to fix it, but I am not sure
whether it's a good idea to fix it?

[Bug tree-optimization/107412] Miss to fold LEN_{LOAD,STORE} when the specified length equal to vector length

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
Make sure we only use "plain" accesses on machines that allow all unaligned
accesses?  p8 and later I think.  The load-with-length insns are even later,
but a builtin does not necessarily translate to those newer insns, so some
care is required :-)

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #9 from Steve Kargl  ---
On Thu, Oct 27, 2022 at 09:11:08PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
> 
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> (In reply to anlauf from comment #7)
> > However, while working on variations of the testcase, I hit an ICE for:
> > 
> > subroutine test3 (w)
> >   character, intent(in), value, optional :: w
> >   print*, 'present(w) is ', present(w)
> > end subroutine test3
> > 
> > It is not new, though.
> 
> This is now tracked in PR107444.
> 

If no other issues pop up and if this is an old issue,
you can probably commit your fix for current issue
as you've opened a new bug report.

Thanks for pecking away at gfortran bugs.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> However, while working on variations of the testcase, I hit an ICE for:
> 
> subroutine test3 (w)
>   character, intent(in), value, optional :: w
>   print*, 'present(w) is ', present(w)
> end subroutine test3
> 
> It is not new, though.

This is now tracked in PR107444.

[Bug fortran/107444] New: ICE on character, value, optional dummy argument

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

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

Bug ID: 107444
   Summary: ICE on character, value, optional dummy argument
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

The following ICE was found while working on PR107441:

subroutine test (w)
  character, value, optional :: w
  print *, present (w)
end


pr107441-yy.f90:3:22:

3 |   print *, present (w)
  |  1
internal compiler error: in fold_convert_loc, at fold-const.cc:2592
0xf10c3d fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-trunk/gcc/fold-const.cc:2592
0xc2be3a gfc_conv_expr_present(gfc_symbol*, bool)
../../gcc-trunk/gcc/fortran/trans-expr.cc:2023
0xc5d01f gfc_conv_intrinsic_present
../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:3669
0xc73567 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:10882
0xc4264b gfc_conv_function_expr
../../gcc-trunk/gcc/fortran/trans-expr.cc:8312
0xc4651f gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:9452
0xc46a14 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:9588
0xc81f47 gfc_trans_transfer(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-io.cc:2607
0xbd9a31 trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2170
0xbd9ba3 gfc_trans_code_cond(gfc_code*, tree_node*)
../../gcc-trunk/gcc/fortran/trans.cc:2295
0xc80889 build_dt
../../gcc-trunk/gcc/fortran/trans-io.cc:2051
0xc80961 gfc_trans_write(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-io.cc:2090
0xbd99a7 trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2142
0xbd9bc2 gfc_trans_code(gfc_code*)
../../gcc-trunk/gcc/fortran/trans.cc:2303
0xc224d1 gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:7666
0xbd9c06 gfc_generate_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.cc:2320
0xb600b4 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:6696
0xb609b6 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7002
0xbc0e87 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:229

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> Created attachment 53782 [details]
> Patch
> 
> Regtesting the attached patch.

Looks good for the reported issue.

However, while working on variations of the testcase, I hit an ICE for:

subroutine test3 (w)
  character, intent(in), value, optional :: w
  print*, 'present(w) is ', present(w)
end subroutine test3

It is not new, though.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 53782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53782=edit
Patch

Regtesting the attached patch.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Is there a public documentation what the ordering should be?

It is actually documented for gfortran:

https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html

The arguments are passed in the following order

* Result variable, when the function result is passed by reference
* Character length of the function result, if it is a of type CHARACTER and no
C binding is used
* The arguments in the order in which they appear in the Fortran declaration
* The present status for optional arguments with value attribute, which are
internally passed by value
* The character length and/or coarray token and offset for the first argument
which is a CHARACTER or a nonallocatable coarray dummy argument, followed by
the hidden arguments of the next dummy argument of such a type 

So it is create_function_arglist which is broken.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> We now need the corresponding part on the procedure side.

That might be create_function_arglist (trans-decl.cc).
There's currently a single hidden_arglist, which needs
to be aligned to the caller's side.

Is there a public documentation what the ordering should be?

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> so the hidden charlen is tacked on last whereas I think the hidden presence
> argument is also expected to be last.  Likely a counting error in generating
> the interface.

I've found the code generating the function call in gfc_conv_procedure_call
(trans-expr.cc:7680)

  /* Add the return arguments.  */
  vec_safe_splice (retargs, arglist);

  /* Add the hidden present status for optional+value to the arguments.  */
  vec_safe_splice (retargs, optionalargs);

  /* Add the hidden string length parameters to the arguments.  */
  vec_safe_splice (retargs, stringargs);

  /* We may want to append extra arguments here.  This is used e.g. for
 calls to libgfortran_matmul_??, which need extra information.  */
  vec_safe_splice (retargs, append_args);


We now need the corresponding part on the procedure side.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Confirmed.
> 
> There is an inconsistency either in the generated code for the caller or
> the callee:
> 
> integer(kind=4) testoptional (character(kind=1)[1:1] & restrict w,
> integer(kind=4) x, integer(kind=8) _w, logical(kind=1) _x)
> 
> vs.
> 
>   t = testoptional (, 0, 0, 1);
> 
> How does the ABI define the ordering of character length and presence flag?

Yep, there's an API issue.  If you use

   character(len=13) :: s

the produced code is

 t = testoptional (, 0, 0, 13);

so the hidden charlen is tacked on last whereas I think the hidden presence
argument is also expected to be last.  Likely a counting error in generating
the interface.

[Bug middle-end/107443] New: Switch conversion removing code

[amacleod at redhat dot com via Gcc-bugs]

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

Bug ID: 107443
   Summary: Switch conversion removing code
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amacleod at redhat dot com
  Target Milestone: ---

Compile the following with -O2 -fdump-tree-all -fdisable-tree-evrp

void dead (unsigned n);
void foo (unsigned n);

void func (unsigned n)
{
  if (n == 0)
__builtin_unreachable();
  if (n == 1)
__builtin_unreachable();
  if (n == 2)
__builtin_unreachable();
  if (n == 3)
__builtin_unreachable();
  if (n == 4)
__builtin_unreachable();
  if (n == 5)
__builtin_unreachable();
  if (n == 6)
__builtin_unreachable();
  if (n == 7)
__builtin_unreachable();
  foo (n);
  if (n < 8)
dead (n);
}

iftoswitch converts the series of if's into a switch:

   :
  switch (n_2(D))  [INV], case 0:  [INV], case 1: 
[INV], case 2:  [INV], case 3:  [INV], case 4:  [INV], case 5:
 [INV], case 6:  [INV], case 7:  [INV]>
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  __builtin_unreachable ();
   :
:
  foo (n_2(D));
  if (n_2(D) <= 7)
goto ; [INV]
  else
goto ; [INV]

   :
  dead (n_2(D));


 switch conversion then runs, eliminates all the blocks, then bails on the
conversion, leaving the IL without any of the __builtin_unreachable calls:

Beginning to process the following SWITCH statement ((null):0) : ---
switch (n_2(D))  [INV], case 0:  [INV], case 1: 
[INV], case 2:  [INV], case 3:  [INV], case 4:  [INV], case 5:
 [INV], case 6:  [INV], case 7:  [INV]>

Removing basic block 3
Removing basic block 4
Removing basic block 5
Removing basic block 6
Removing basic block 7
Removing basic block 8
Removing basic block 9
Removing basic block 10
Bailing out - switch is a degenerate case

Merging blocks 2 and 11
void func (unsigned int n)
{
   :
  foo (n_2(D));
  if (n_2(D) <= 7)
goto ; [INV]
  else
goto ; [INV]

   :
  dead (n_2(D));

   :
  return;

}

And now the optimizers cannot remove the call to dead() because we lose all the
range information inferred from the __builtin_unreachable calls.

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

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

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

--- Comment #46 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:0e36a9c6915c713d30016cbade97a4b31dcc1350

commit r13-3530-g0e36a9c6915c713d30016cbade97a4b31dcc1350
Author: H.J. Lu 
Date:   Thu Oct 20 11:55:19 2022 -0700

x86: Replace ne:CCC/ne:CCO with UNSPEC_CC_NE in neg patterns

In i386.md, neg patterns which set MODE_CC register like

(set (reg:CCC FLAGS_REG)
 (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))

can lead to errors when operand 1 is a constant value.  If FLAGS_REG in

(set (reg:CCC FLAGS_REG)
 (ne:CCC (const_int 2) (const_int 0)))

is set to 1, RTX simplifiers may simplify

(set (reg:SI 93)
 (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]

as

(set (reg:SI 93)
 (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]

which leads to incorrect results since LTU on MODE_CC register isn't the
same as "unsigned less than" in x86 backend.  To prevent RTL optimizers
from setting MODE_CC register to a constant, use UNSPEC_CC_NE to replace
ne:CCC/ne:CCO when setting FLAGS_REG in neg patterns.

gcc/

PR target/107172
* config/i386/i386.md (UNSPEC_CC_NE): New.
Replace ne:CCC/ne:CCO with UNSPEC_CC_NE in neg patterns.

gcc/testsuite/

PR target/107172
* gcc.target/i386/pr107172.c: New test.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

There is an inconsistency either in the generated code for the caller or
the callee:

integer(kind=4) testoptional (character(kind=1)[1:1] & restrict w,
integer(kind=4) x, integer(kind=8) _w, logical(kind=1) _x)

vs.

  t = testoptional (, 0, 0, 1);

How does the ABI define the ordering of character length and presence flag?

[Bug c++/107442] New: Concept and Template Var mangling

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

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

Bug ID: 107442
   Summary: Concept and Template Var mangling
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

>From a discussion re clang's mangling
(https://github.com/llvm/llvm-project/issues/58197), I find some GCC cases

namespace Concept { template concept True = true; }
namespace Struct_ { template struct True {}; }
namespace Var { template constexpr bool True = true; }
namespace Functio { template void True (); }

template  struct ImplExpr { template  using Type = T; };
template  struct ImplType { template  using Type = T; };
template  struct ImplFunc { template  using Type = T; };

template  using IfExpr
  = typename ImplExpr::template Type;
template  using IfType
  = typename ImplType::template Type;
template  using IfFunc
  = typename ImplFunc::template Type;

template using TypeConcept = IfExpr, T>;
template using TypeStruct_ = IfType, T>;
template using TypeVar = IfExpr, T>;
template using TypeFunctio = IfFunc, T>;

template TypeConcept fConcept () {return {};}
template TypeStruct_ fStruct_ () {return {};}
template TypeVar fVar () {return {};}
template TypeFunctio fFunctio () {return {};}

int main ()
{
  fConcept ();
  fStruct_ ();
  fVar ();
  fFunctio ();
}

neroon:270>./cc1plus -quiet -std=c++20 conc2.cc -o - | grep '^_Z'
_Z8fConceptIiEN8ImplExprIX4TrueIT_EEE4TypeIS1_EEv:
_Z8fStruct_IiEN8ImplTypeIN7Struct_4TrueIT_EEE4TypeIS3_EEv:
_Z8fVarIiEN8ImplExprIX4TrueIT_EEE4TypeIS1_EEv:
_Z8fFunctioIiEN8ImplFuncIX4TrueIT_EEE4TypeIS1_EEv:
_ZN7Var4TrueIiEE:

neroon:270>clang++ -S -std=c++20 conc2.cc -o - | grep '^_Z'  
_Z8fConceptIiEN8ImplExprIL_ZN7Concept4TrueIT_4TypeIS3_EEv: #
@_Z8fConceptIiEN8ImplExprIL_ZN7Concept4TrueIT_4TypeIS3_EEv
_Z8fStruct_IiEN8ImplTypeIN7Struct_4TrueIT_EEE4TypeIS3_EEv: #
@_Z8fStruct_IiEN8ImplTypeIN7Struct_4TrueIT_EEE4TypeIS3_EEv
_Z8fVarIiEN8ImplExprIXsr7VarE4TrueIT_EEE4TypeIS1_EEv: #
@_Z8fVarIiEN8ImplExprIXsr7VarE4TrueIT_EEE4TypeIS1_EEv
_Z8fFunctioIiEN8ImplFuncIXsr7FunctioE4TrueIT_EEE4TypeIS1_EEv: #
@_Z8fFunctioIiEN8ImplFuncIXsr7FunctioE4TrueIT_EEE4TypeIS1_EEv

We're dropping the scoping off Concept::True and Var::True &
Functio::True (we're representing these as TEMPLATE_ID_EXPRs, and the
mangler only expects an unqualified function there).  Should we represent these
using ScopeRef, like clang does for the variable case (the clang issue is what
should it do for the concept case).  Or should we mangle both concept and var
as a template instantiation like the class case?

[Bug c++/107379] [13 regression] g++.dg/modules/adl-3_c.C and adl-4_b.C break as of r13-2887-gb04208895fed34

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

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

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

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

commit r13-3528-ga33d623d2d3a78f5ef6f9e854946303e063eef63
Author: Jakub Jelinek 
Date:   Thu Oct 27 20:10:18 2022 +0200

c++: Fix ICE on g++.dg/modules/adl-3_c.C [PR107379]

As mentioned in the PR, apparently my r13-2887 P1467R9 changes
regressed these tests on powerpc64le-linux with IEEE quad by default.

I believe my changes just uncovered a latent bug.
The problem is that push_namespace calls find_namespace_slot,
which does:
  tree *slot = DECL_NAMESPACE_BINDINGS (ns)
->find_slot_with_hash (name, name ? IDENTIFIER_HASH_VALUE (name) : 0,
   create_p ? INSERT : NO_INSERT);
In the  ns case, slot is non-NULL
above with a binding_vector in it.
Then pushdecl is called and this does:
  slot = find_namespace_slot (ns, name, ns ==
current_namespace);
where ns == current_namespace (ns is :: and name is details) is true.
So this again calls
  tree *slot = DECL_NAMESPACE_BINDINGS (ns)
->find_slot_with_hash (name, name ? IDENTIFIER_HASH_VALUE
(name) : 0,
   create_p ? INSERT : NO_INSERT);
but this time with create_p and so INSERT.
At this point we reach
  if (insert == INSERT && m_size * 3 <= m_n_elements * 4)
expand ();
and when we are unlucky and the occupancy of the hash table just reached
3/4,
expand () is called and the hash table is reallocated.  But when that
happens,
it means the slot pointer in the pushdecl caller (push_namespace) points to
freed memory and so any accesses to it in make_namespace_finish will be UB.

The following patch fixes it by calling find_namespace_slot again even if
it
was non-NULL, just doesn't assert it is *slot == ns in that case (because
it often is not).

2022-10-27  Jakub Jelinek  

PR c++/107379
* name-lookup.cc (push_namespace): Call find_namespace_slot again
after pushdecl as the hash table might be expanded during pushdecl.

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

--- Comment #9 from Segher Boessenkool  ---
I read 
as approval to backport, fwiw :-)

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

--- Comment #8 from Segher Boessenkool  ---
Please do that together with the follow-up fix only?  PR107171.

[Bug fortran/107441] New: optional arguments are identified as "present" when missing

[kaiserkarl31 at yahoo dot com via Gcc-bugs]

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

Bug ID: 107441
   Summary: optional arguments are identified as "present" when
missing
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaiserkarl31 at yahoo dot com
  Target Milestone: ---

If the first argument to a function is of type "character" (of any length, from
what I can tell, including ":" and "*") and the second parameter is both passed
by value and optional, the second argument will be identified as "present" even
when absent. The following short program reproduces the problem with gfortran
12.2.1:

program bugdemo

   implicit none
   character :: s
   integer :: t

   s = 'a'
   t = testoptional(s)
   print*, 'testoptional: ', t

contains

   function testoptional(w, x) result(t)

  character, intent(in) :: w
  integer, intent(in), value, optional :: x
  integer :: t

  print*, 'present(x) is ', present(x)
  t = 0

   end function testoptional

end program bugdemo
!!

When compiled and run with gfortran 12.2.1, this gives the following output:
 present(x) is  T
 testoptional:0
[clearly, the first line should have "F" instead of "T"]

[Bug ada/107440] New: GCC error: in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:610

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

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

Bug ID: 107440
   Summary: GCC error: in gnat_to_gnu_entity, at
ada/gcc-interface/decl.cc:610
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krischik at users dot sourceforge.net
  Target Milestone: ---

Error Message:

cannot generate code for file adacl-eastrings-transcoding.ads (package spec)
+===GNAT BUG DETECTED==+
| 12.1.0 (x86_64-apple-darwin19.6.0) GCC error:|
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:610  |
| Error detected at adacl-eastrings.ads:728:9  |
| Compiling
/Users/Shared/Work/Projects/AdaCL/adacl_eastrings/src/adacl-eastrings.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Command line used:

error: Command ["gprbuild", "-s", "-j0", "-p", "-P",
"/Users/Shared/Work/Projects/AdaCL/adacl_eastrings/adacl_eastrings.gpr"] exited
with code 4

Source code:

https://sourceforge.net/p/adacl/git/ci/feature/alire/~/tree/adacl_eastrings/

[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186

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

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

--- Comment #25 from Mark Wielaard  ---
Note that elfutils-0.187 builds fine for me on fedora x86_64 with either:
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)

So this might have been fixed since 12.2.0?

[Bug c++/107439] New: use of static member function in requires-expression depends on declaration order

[jwjagersma at gmail dot com via Gcc-bugs]

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

Bug ID: 107439
   Summary: use of static member function in requires-expression
depends on declaration order
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

The following example fails to compile, as g++ complains that a declaration of
'check' is not available.  Reordering it so that 'check' is declared before
its use in the requires-expression makes it work.  This seems inconsistent, as
member functions are normally expected to be usable anywhere within the class
definition.

  $ cat requires-memfn.cpp
  struct A
  {
template requires (check())
auto func(T) { }

template
static consteval bool check() { return true; }
  };

  $ g++ -std=c++20 requires-memfn.cpp
  requires-memfn.cpp:3:34: error: there are no arguments to ‘check’ that depend
on a template parameter, so a declaration of ‘check’
   must be available [-fpermissive]
  3 |   template requires (check())
|  ^~~~
  requires-memfn.cpp:3:34: note: (if you use ‘-fpermissive’, G++ will accept
your code, but allowing the use of an undeclared name is deprecated)

[Bug c++/107429] misdiagnosed "constraint depends on itself" in overloaded functions

[jwjagersma at gmail dot com via Gcc-bugs]

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

--- Comment #2 from jwjagersma at gmail dot com ---
Thanks, I thought I searched but somehow missed that PR.
>From a user perspective it seems very surprising that this workaround compiles,
but the obvious implementation doesn't.  I do hope it gets addressed someday.

[Bug target/107432] __builtin_convertvector generates inefficient code

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #2 from g.peterh...@t-online.de ---
Another example. I want to convert an array to array.
There are basically 3 options:
- Copy
- Test (b2f64_default)
- optimized version (b2f64_manually)

gcc12.2 + gcctrunc
convertSIZE_copy only generates scalar code (_mm_cvtsi64_sd)
convertSIZE_default always generates conditional jumps

convertSIZE_manually
gcctrunc always generates branch-free scalar code
gcc12.2
convert1024_manually generates vector code, but does not use HW conversion
int8->int64 (_mm(256)_cvtepi8_epi64) and converts int8->int16->int32->int64
manually
convert8_manually generates branch-free scalar code
convert4_manually generates vector code and uses HW conversion int8->int64


NONE of these conversions are transformed/optimized to the extent that always
- all available intrinsics are used
- no "normal" registers are used
- branch-free code is generated

https://godbolt.org/z/f74vK79of

thx
Gero

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Peter Bergner  ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Surya Kumari Jangala
> :
> 
> https://gcc.gnu.org/g:bec35caafae8db0278e1d037a7ba00c3e6899bbd
> 
> commit r13-2525-gbec35caafae8db0278e1d037a7ba00c3e6899bbd
> Author: Surya Kumari Jangala 
> Date:   Tue Aug 2 23:00:03 2022 -0500
> 
> sched1: Fix -fcompare-debug issue in schedule_region [PR105586]

Surya, I think this has baked on trunk long enough, so if you have approval to
backport, I think you can do that now.

[Bug target/107438] New: bpf:

[jose.marchesi at oracle dot com via Gcc-bugs]

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

Bug ID: 107438
   Summary: bpf:
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jose.marchesi at oracle dot com
  Target Milestone: ---

We noticed that recently LLVM changed the BPF ABI by allowing to pass small
record arguments by value.  Previously all records were passed by reference.

This is the LLVM change:

  https://reviews.llvm.org/D132144

The GCC backend should be adapted to follow the same ABI.

[Bug c++/107437] nested generic lambdas fail requiring unneded captures

[development at jordi dot vilar.cat via Gcc-bugs]

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

Jordi Vilar  changed:

   What|Removed |Added

 CC||development at jordi dot 
vilar.cat

--- Comment #1 from Jordi Vilar  ---
BTW, capturing (the unneded!) N in the nested lambda, raises a beautiful error:

error: integral expression '(std::integral_constant::value_type)N' is not constant.

Should I fill a new issue for this?

[Bug middle-end/107436] Is -fsignaling-nans still experimental?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57994,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67052,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77926,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88640,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97965,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52258,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=46993

--- Comment #1 from Andrew Pinski  ---
There seems like there are still known issues with signalling nans on different
targets still. There has been many fixes in recent years but not all might be
there.

Also it depends on the target you are targetting.

A third party library depending on signaling NaNs is slightly an issue in
general considering -fsignaling-nans is not on by default and some (many?)
targets fpu have issues with signaling NaNs in general ...

[Bug tree-optimization/107435] [13 Regression] ice in build_vector_from_val, at tree.cc:2125

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

struct qlist_head {
  struct qlist_head *next
} qlist_add(struct qlist_head *new, struct qlist_head *head) {
  struct qlist_head *prev = head;
  new->next = head->next;
  prev->next = new;
}
struct {
  struct qlist_head queue_link
} free_list, prealloc[];
dbpf_open_cache_initialize() {
  int i = 0;
  for (; i < 64; i++)
qlist_add([i], _list);
}

[Bug c++/107437] New: nested generic lambdas fail requiring unneded captures

[development at jordi dot vilar.cat via Gcc-bugs]

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

Bug ID: 107437
   Summary: nested generic lambdas fail requiring unneded captures
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: development at jordi dot vilar.cat
  Target Milestone: ---

This simple valid code fails to compile with all recent versions of gcc, but
compiles nicely with clang (and even msvc!)

(live demo on complier explorer: https://godbolt.org/z/eM1b9e6s9)

// compile with just -std=c++20
#include 
#include 
#include 

void test()
{
std::invoke([](auto N, std::type_identity)
{
using vector_type = std::array;
static_assert(N == std::tuple_size_v);
std::invoke([](std::index_sequence)
{
   
static_assert(std::conjunction_v, T>...>);
}, std::make_index_sequence{});
}, std::integral_constant{}, std::type_identity{});
}

It issues the diagnostics output:
: In instantiation of 'test()::)>
[with T = int; auto:3 = std::integral_constant]':
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/type_traits:2565:26:  
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
test()::)>; _Args =
{std::integral_constant, std::type_identity}]'
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/type_traits:2576:55:  
required from 'struct std::__result_of_impl)>, std::integral_constant, std::type_identity >'
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/type_traits:2581:12:  
required from 'struct std::__invoke_result)>, std::integral_constant,
std::type_identity >'
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/type_traits:3022:12:  
required from 'struct std::invoke_result)>, std::integral_constant,
std::type_identity >'
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/type_traits:3034:11:  
required by substitution of 'template using
invoke_result_t = typename std::invoke_result::type [with _Fn =
test()::)>; _Args =
{std::integral_constant, std::type_identity}]'
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/functional:107:5:  
required by substitution of 'template
constexpr std::invoke_result_t<_Fn, _Args ...> std::invoke(_Callable&&, _Args&&
...) [with _Callable = test()::)>; _Args =
{std::integral_constant, std::type_identity}]'
:7:16:   required from here
:13:32: error: 'N' is not captured
   13 |
static_assert(std::conjunction_v, T>...>);
  |  
~^~~
:11:21: note: the lambda has no capture-default
   11 | std::invoke([](std::index_sequence)
  | ^~~
   12 | {
  | ~
   13 |
static_assert(std::conjunction_v, T>...>);
  |

   14 | }, std::make_index_sequence{});
  | ~
:7:37: note: 'std::integral_constant N' declared
here
7 | std::invoke([](auto N, std::type_identity)
  |~^

[Bug web/107436] New: Is -fsignaling-nans still experimental?

[florian.schanda at bmw dot de via Gcc-bugs]

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

Bug ID: 107436
   Summary: Is -fsignaling-nans still experimental?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florian.schanda at bmw dot de
  Target Milestone: ---

Hi,

Is the following statement in the documentation on "-fsignaling-nans"
still correct?

> This option is experimental and does not currently guarantee to
> disable all GCC optimizations that affect signaling NaN behavior.

The context is that we have a safety mechanism in a third-party library
that relies signalling nans to work correctly; and if we cannot guarantee 
it with this option it would be a major headache indeed.

Any advice (or even better statement that the experimental note is outdated
and can be deleted) would be appreciated.

Many thanks in advance!

[Bug target/107432] __builtin_convertvector generates inefficient code

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

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

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

[Bug tree-optimization/107435] [13 Regression] ice in build_vector_from_val, at tree.cc:2125

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Keywords||ice-on-valid-code
Version|12.0|13.0
   Target Milestone|--- |13.0
Summary|ice in  |[13 Regression] ice in
   |build_vector_from_val, at   |build_vector_from_val, at
   |tree.cc:2125|tree.cc:2125
  Component|c   |tree-optimization

[Bug c/107435] New: ice in build_vector_from_val, at tree.cc:2125

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107435
   Summary: ice in build_vector_from_val, at tree.cc:2125
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 53780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53780=edit
C source code

For the attached code, compiled with 

-std=gnu89 -O3 -march=znver3 -c bug858.c

recent gcc does this:

during GIMPLE pass: vect
src/io/trove/trove-dbpf/dbpf-open-cache.c: In function
‘dbpf_open_cache_initiali
ze’:
src/io/trove/trove-dbpf/dbpf-open-cache.c:100:6: internal compiler error: in
bui
ld_vector_from_val, at tree.cc:2125
0x1072d8e build_vector_from_val(tree_node*, tree_node*)
../../trunk.git/gcc/tree.cc:2124
0x100a927 vectorizable_recurr(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_t
ree*, vec*)
../../trunk.git/gcc/tree-vect-loop.cc:8472

The bug first seems to occur sometime between git hash baeec7cc83b19b46
and 3bd5d9a28e1ce4d1, a day later.

I have a reduction running.

[Bug c++/107433] 510.parest_r, call of overloaded 'back_interpolate' is ambiguous

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #2 from Rama Malladi  ---
(In reply to Martin Liška from comment #1)
> As mentioned slightly here:
> https://www.spec.org/cpu2017/Docs/benchmarks/510.parest_r.html
> please use -std=c++98 or something < c++17.

Thank you. I had it for C compiler. Will add it to C++ compiler command-line
too.

[Bug c++/96868] C++20 designated initializer erroneous warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||chfast at gmail dot com

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

[Bug c++/107434] Wrong -Wmissing-field-initializers for C++ designated initializers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 96868.
C has an implicit constructor.

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

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

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

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

Bug 107433 Summary: 510.parest_r, call of overloaded 'back_interpolate' is 
ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107433

   What|Removed |Added

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

[Bug c++/107433] 510.parest_r, call of overloaded 'back_interpolate' is ambiguous

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

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

Martin Liška  changed:

   What|Removed |Added

 Blocks||26163
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Liška  ---
As mentioned slightly here:
https://www.spec.org/cpu2017/Docs/benchmarks/510.parest_r.html
please use -std=c++98 or something < c++17.


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 rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug rtl-optimization/98603] aarch64: ICE in extract_insn (ira) on asm goto with bad constraint

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double

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

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

--- Comment #8 from seurer at gcc dot gnu.org ---
Here is the list of the current failures for trunk (they all fail with gcc 12
too).  I did not include the xtreme-header ones as those are flakey and fail
elsewhere, too (there are several PRs open about them).


FAIL: g++.dg/modules/binding-1_a.H -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/binding-1_a.H -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/binding-1_a.H -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/binding-1_b.H -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/binding-1_b.H -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/binding-1_b.H -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/global-3_a.C -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/global-3_a.C -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/global-3_a.C -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/hello-1_a.C -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/hello-1_a.C -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/hello-1_a.C -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/iostream-1_a.H -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/iostream-1_a.H -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/iostream-1_a.H -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/pr99023_b.X -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99023_b.X -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99023_b.X -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/pr99166_a.X -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99166_a.X -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99166_a.X -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/pr99425-2_a.X -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99425-2_a.X -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99425-2_a.X -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99425-2_b.X -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/pr99425-2_b.X -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

FAIL: g++.dg/modules/string-1_a.H -std=c++17 (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/string-1_a.H -std=c++2a (internal compiler error: in
type_node, at cp/module.cc:8878)
FAIL: g++.dg/modules/string-1_a.H -std=c++2b (internal compiler error: in
type_node, at cp/module.cc:8878)

[Bug fortran/107406] lock_type

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-27
   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #0)
> gfortran 12.2 accepts the code below if the "allocatable" attribute is
> removed:
> 
> % cat gfortran-lock-issue.f90 
>   use iso_fortran_env
>   type foo
> type(lock_type), allocatable :: bar
>   end type
>   type(foo) foobar[*]
> end
> 
> % gfortran -fcoarray=single gfortran-lock-issue.f90 
> gfortran-lock-issue.f90:3:39:
> 
> 3 | type(lock_type), allocatable :: bar
>   |   1
> Error: Allocatable component bar at (1) of type LOCK_TYPE must have a
> codimension
> 
> The NAG compiler accepts the above code and I believe constraint C1608 in
> the Fortran 2018 standard makes the above code valid.
> 
> Is this related to PR 92122?

Yes, it is likely related.

The code that gives rise to the error is trying to check F2008:C1302.

C1302 A named variable of type LOCK_TYPE shall be a coarray.
A named variable with a noncoarray sub-component of type
LOCK_TYPE shall be a coarray.

I think the 2nd sentence has been misinterpreted.  The named variable is foobar
and it is a coarray.  bar is a component of derived type and is not a named
variable.  In the parlance of Fortran, bar is a subobject and is referred to as
an object designator.

The same applies to PR92122.

The following patch allows your example to compile with 'gfortran
-fcoarray=single a.f90'.

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index f04fd13cc69..8440f58ef23 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3339,7 +3339,7 @@ check_component (gfc_symbol *sym, gfc_component *c,
gfc_component **lockp,
"of type LOCK_TYPE, which must have a codimension or be a "
"subcomponent of a coarray", c->name, >loc);

-  if (lock_type && allocatable && !coarray)
+  if (lock_type && allocatable && !coarray && !lock_comp)
 gfc_error ("Allocatable component %s at %L of type LOCK_TYPE must have "
"a codimension", c->name, >loc);
   else if (lock_type && allocatable && c->ts.type == BT_DERIVED

Note, the section of code is prefaced with the following comment

  /* Check for F2008, C1302 - and recall that pointers may not be coarrays
 (5.3.14) and that subobjects of coarray are coarray themselves (2.4.7),
 unless there are nondirect [allocatable or pointer] components
 involved (cf. 1.3.33.1 and 1.3.33.3).  */

Someone who knows coarrays needs to verify the veracity of the comment.

[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jwjagersma at gmail dot com

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

[Bug c++/107429] misdiagnosed "constraint depends on itself" in overloaded functions

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Thanks for the bug report.  This is a consequence of CWG2369, and the
constraint recursion diagnosis is strictly speaking correct correct.  I think
other compilers accept it because they don't fully implement
https://wg21.link/cwg2369 which moved the constraint satisfaction check during
template argument deduction to _before_ the checking non-dependent conversions.

A workaround (that should be valid pre- and post-CWG2369) is to encode the
non-dependent conversion in the constrained overload of f as an additional
constraint that's checked before the fooable constraint:

  template U, typename... T> requires
(fooable)
  auto f(U, T... x)

see PR99599 and its dups for more info

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

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #8 from Rama Malladi  ---
(In reply to Mark Wielaard from comment #7)
> The content of attachment 53773 [details] has been deleted for the following
> reason:
> 
> https://sourceware.org/pipermail/overseers/2022q4/019048.html

Thank you.

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark

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

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

--- Comment #4 from Mark Wielaard  ---
The content of attachment 53775 has been deleted for the following reason:

https://sourceware.org/pipermail/overseers/2022q4/019048.html

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

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

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

--- Comment #7 from Mark Wielaard  ---
The content of attachment 53773 has been deleted for the following reason:

https://sourceware.org/pipermail/overseers/2022q4/019048.html

[Bug c++/107434] New: Wrong -Wmissing-field-initializers for C++ designated initializers

[chfast at gmail dot com via Gcc-bugs]

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

Bug ID: 107434
   Summary: Wrong -Wmissing-field-initializers for C++ designated
initializers
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

If a struct S has a field c of type C having user constructor the
"missing-field-initializers" is reported for this field even though designated
initializers are used.

struct C
{
int x = 0;
};

struct S
{
C c;
bool flag = false;

};

S test()
{
return {.flag = true};
}

: In function 'S test()':
:15:25: warning: missing initializer for member 'S::c'
[-Wmissing-field-initializers]
   15 | return {.flag = true};
  | ^

https://godbolt.org/z/sxc8PP7Pq

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #6 from Rama Malladi  ---
(In reply to Martin Liška from comment #5)
> Please try writing here: overse...@sourceware.org

I have asked for deletion. Thanks

[Bug c/107433] New: 510.parest_r, call of overloaded 'back_interpolate' is ambiguous

[rvmallad at amazon dot com via Gcc-bugs]

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

Bug ID: 107433
   Summary: 510.parest_r, call of overloaded 'back_interpolate' is
ambiguous
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rvmallad at amazon dot com
  Target Milestone: ---

$ g++ -mabi=lp64 -c -o source/fe/fe_tools.o -DSPEC -DNDEBUG -Iinclude -I.
-DSPEC_AUTO_SUPPRESS_OPENMP -g -O3 -mcpu=native -fpermissive  -DSPEC_LP64
source/fe/fe_tools.cc

source/fe/fe_tools.cc:1301:21: error: call of overloaded
'back_interpolate(const dealii::DoFHandler<3, 3>&, const
dealii::BlockVector&, const dealii::FiniteElement<3, 3>&,
dealii::BlockVector&)' is ambiguous
 1301 | back_interpolate(dof1, u1, dof2.get_fe(), u1_interpolated);
  | ^~

$ /home/ubuntu/gccmainline/bin/g++  -v
Using built-in specs.
COLLECT_GCC=/home/ubuntu/gccmainline/bin/g++
COLLECT_LTO_WRAPPER=/home/ubuntu/gccmainline/libexec/gcc/aarch64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/ubuntu/gccmainline
--enable-languages=c,fortran
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221026 (experimental) (GCC)

[Bug c++/102773] Show fix-its for mispelled keywords like "templat" and "clas" and "typname"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Another example:

long i = reintepret_cast((void*)0);


cast.C:1:10: error: ‘reintepret_cast’ was not declared in this scope
1 | long i = reintepret_cast((void*)0);
  |  ^~~
cast.C:1:26: error: expected primary-expression before ‘long’
1 | long i = reintepret_cast((void*)0);
  |  ^~~~



And this one with -std=c++20:

template
void
f(const void* v)
{
  auto u = reintepret_cast(v);
}

cast.C: In function 'void f(const void*)':
cast.C:5:12: error: there are no arguments to 'reintepret_cast' that depend on
a template parameter, so a declaration of 'reintepret_cast' must be available
[-fpermissive]
5 |   auto u = reintepret_cast(v);
  |^
cast.C:5:12: note: (if you use '-fpermissive', G++ will accept your code, but
allowing the use of an undeclared name is deprecated)

[Bug c++/107432] New: __builtin_convertvector generates inefficient code

[g.peterhoff--- via Gcc-bugs]

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

Bug ID: 107432
   Summary: __builtin_convertvector generates inefficient code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.peterh...@t-online.de
  Target Milestone: ---

Example: conversion int64_t -> int32_t

avx512f + avx512vl
HW conversions are available.

avx2
There is a correctly working 32-bit-permutation
(_mm256_permutevar8x32_epi32/vpermd) that can be used.

I have not (yet) evaluated whether other conversions (larger int -> smaller
int) are also affected.
PS: On x86 it's already hell to optimize all cases depending on the instruction
set.
PPS: What about -march=znver4 ?

https://godbolt.org/z/3s79bnh7v

thx
Gero

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #5 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

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

https://gcc.gnu.org/g:2b1fb720818a85d5c893ce65d140add40debf2ff

commit r13-3525-g2b1fb720818a85d5c893ce65d140add40debf2ff
Author: Aldy Hernandez 
Date:   Tue Oct 25 22:44:51 2022 +0200

[PR tree-optimization/107394] Canonicalize global franges as they are read
back.

The problem here is that we're inlining a global range with NANs into
a function that has been tagged with __attribute__((optimize
("-ffinite-math-only"))).  As the global range is copied from
SSA_NAME_RANGE_INFO, its NAN bits are copied, which then cause
frange::verify_range() to fail a sanity check making sure no NANs
creep in when !HONOR_NANS.

I think what we should do is nuke the NAN bits as we're restoring the
global range.  For that matter, if we use the frange constructor,
everything except that NAN sign will be done automatically, including
dropping INFs to the min/max representable range when appropriate.

PR tree-optimization/107394

gcc/ChangeLog:

* value-range-storage.cc (frange_storage_slot::get_frange): Use
frange constructor.

gcc/testsuite/ChangeLog:

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

[Bug tree-optimization/107427] ICE Segmentation fault when -O1 -fdisable-tree-lower -fdisable-tree-eh is given

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Doctor it hurts. Then don't do it!

[Bug sanitizer/107431] UBSan has inconsistent behaviors in certain code snippet

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

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

--- Comment #2 from Li Shaohua  ---
Thanks a lot for the prompt reply!

[Bug c++/107422] [12/13 Regression] ICE in lvalue_kind, at cp/tree.cc:293 since r12-298-g58a92b789a77cdad

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[12/13 Regression] ICE in   |[12/13 Regression] ICE in
   |lvalue_kind, at |lvalue_kind, at
   |cp/tree.cc:293  |cp/tree.cc:293 since
   ||r12-298-g58a92b789a77cdad

--- Comment #2 from Martin Liška  ---
Started with r12-298-g58a92b789a77cdad.

[Bug fortran/107425] [12/13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3060 since r12-6780-gd2ad748eeef0dd26

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||sandra at codesourcery dot com
Summary|[12/13 Regression] ICE in   |[12/13 Regression] ICE in
   |gimplify_var_or_parm_decl,  |gimplify_var_or_parm_decl,
   |at gimplify.cc:3060 |at gimplify.cc:3060 since
   ||r12-6780-gd2ad748eeef0dd26
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-27

--- Comment #1 from Martin Liška  ---
Started with r12-6780-gd2ad748eeef0dd26.

[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-27
 CC||marxin at gcc dot gnu.org,
   ||sandra at codesourcery dot com

--- Comment #1 from Martin Liška  ---
Started with r13-142-g705bcedf6eae2d7c.

[Bug sanitizer/107431] UBSan has inconsistent behaviors in certain code snippet

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
> % cat example2.c
> int main() {
> int a=2;
> int b=1;
> long *c = 
> long d = *c;
> 
> }

Well, in this case you are lucky and 'b' is aligned to 8-bytes:
__builtin_printf ("=%p\n", );

$ gcc-12 example2.c -fsanitize=undefined -w && ./a.out
=0x7fffd438

$ gcc-12 -O1 example2.c -fsanitize=undefined -w && ./a.out
=0x7fffd44c
example2.c:6:10: runtime error: load of misaligned address 0x7fffd44c for
type 'long int', which requires 8 byte alignment
0x7fffd44c: note: pointer points here
  67 6c 69 62 01 00 00 00  68 d5 ff ff ff 7f 00 00  b0 c5 62 f7 ff 7f 00 00  50
d5 ff ff ff 7f 00 00
  ^ 
example2.c:6:10: runtime error: load of address 0x7fffd44c with
insufficient space for an object of type 'int'
0x7fffd44c: note: pointer points here
  67 6c 69 62 01 00 00 00  68 d5 ff ff ff 7f 00 00  b0 c5 62 f7 ff 7f 00 00  50
d5 ff ff ff 7f 00 00
  ^ 

So nothing we can do about it.

[Bug sanitizer/107431] New: UBSan has inconsistent behaviors in certain code snippet

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

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

Bug ID: 107431
   Summary: UBSan has inconsistent behaviors in certain code
snippet
   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: ---

Hi, for the following code, there is a misaligned load at line 5 `long d = *c`.
UBSan detected it successfully. However, if you change the definition of `a`
from `long a` to `int a`, UBSan would report nothing.

% cat example1.c
int main() {
long a=2;
int b=1;
long *c = 
long d = *c;

}
% gcc -O0 -fsanitize=undefined example1.c && ./a.out
example1.c:5:10: runtime error: load of misaligned address 0x7fffd97a993c for
type 'long int', which requires 8 byte alignment
0x7fffd97a993c: note: pointer points here
  f0 71 77 cc 01 00 00 00  02 00 00 00 00 00 00 00  3c 99 7a d9 ff 7f 00 00  50
9a 7a d9 ff 7f 00 00
%
% cat example2.c
int main() {
int a=2;
int b=1;
long *c = 
long d = *c;

}
% gcc -O0 -fsanitize=undefined example1.c && ./a.out
%

Compiler explorer: https://godbolt.org/z/4oKaMjbee

[Bug lto/107418] lto-dump -gimple-stats ICE Segmentation Fault

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Liska
:

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

commit r12-8872-gca0220d42e075194ca1341c98a0a9a9f3fd1c719
Author: Martin Liska 
Date:   Thu Oct 27 10:29:17 2022 +0200

lto: do not load LTO stream for aliases [PR107418]

PR lto/107418

gcc/lto/ChangeLog:

* lto-dump.cc (lto_main): Do not load LTO stream for aliases.

(cherry picked from commit be6c75547385c69706370f4e792b04295f708a5a)

--- Comment #5 from Martin Liška  ---
Fixed for GCC 12/13 releases.

[Bug lto/107418] lto-dump -gimple-stats ICE Segmentation Fault

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Liska
:

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

commit r12-8872-gca0220d42e075194ca1341c98a0a9a9f3fd1c719
Author: Martin Liska 
Date:   Thu Oct 27 10:29:17 2022 +0200

lto: do not load LTO stream for aliases [PR107418]

PR lto/107418

gcc/lto/ChangeLog:

* lto-dump.cc (lto_main): Do not load LTO stream for aliases.

(cherry picked from commit be6c75547385c69706370f4e792b04295f708a5a)

--- Comment #5 from Martin Liška  ---
Fixed for GCC 12/13 releases.

[Bug lto/107418] lto-dump -gimple-stats ICE Segmentation Fault

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-3523-gbe6c75547385c69706370f4e792b04295f708a5a
Author: Martin Liska 
Date:   Thu Oct 27 10:29:17 2022 +0200

lto: do not load LTO stream for aliases [PR107418]

PR lto/107418

gcc/lto/ChangeLog:

* lto-dump.cc (lto_main): Do not load LTO stream for aliases.

[Bug c++/107383] [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

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

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

--- Comment #5 from Martin Liška  ---
Please try writing here: overse...@sourceware.org

[Bug c++/107383] [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181

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

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

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

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

commit r13-3522-gbfb7994a9fb0b10767d12b8d670c081014ad8b01
Author: Jakub Jelinek 
Date:   Thu Oct 27 10:24:45 2022 +0200

c++: Fix excess precision related ICE on invalid binop [PR107382, PR107383]

The following tests ICE in the gcc_assert (common); in cp_build_binary_op.
I've missed that while for * common is set always, while for +, - and /
it is in some cases not.
If it is not, then
  if (!result_type
  && arithmetic_types_p
  && (shorten || common || short_compare))
condition is false, then the following
  if (may_need_excess_precision
  && (orig_type0 != type0 || orig_type1 != type1)
  && build_type == NULL_TREE)
would fail the assertion there and if there wouldn't be excess precision,
  if (code == SPACESHIP_EXPR)
would be false (for SPACESHIP_EXPR we always have build_type set like for
other comparisons) and then trigger
  if (!result_type)
{
  if (complain & tf_error)
{
  binary_op_rich_location richloc (location,
   orig_op0, orig_op1, true);
  error_at (,
"invalid operands of types %qT and %qT to binary %qO",
TREE_TYPE (orig_op0), TREE_TYPE (orig_op1), code);
}
  return error_mark_node;
}
So, if result_type is NULL, we don't really need to compute
semantic_result_type because nothing will use it anyway and can get
fall through into the error/return error_mark_node; case.

2022-10-27  Jakub Jelinek  

PR c++/107382
PR c++/107383
* typeck.cc (cp_build_binary_op): Don't compute
semantic_result_type
if result_type is NULL.

* g++.dg/diagnostic/bad-binary-ops2.C: New test.

[Bug c++/107382] [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436

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

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

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

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

commit r13-3522-gbfb7994a9fb0b10767d12b8d670c081014ad8b01
Author: Jakub Jelinek 
Date:   Thu Oct 27 10:24:45 2022 +0200

c++: Fix excess precision related ICE on invalid binop [PR107382, PR107383]

The following tests ICE in the gcc_assert (common); in cp_build_binary_op.
I've missed that while for * common is set always, while for +, - and /
it is in some cases not.
If it is not, then
  if (!result_type
  && arithmetic_types_p
  && (shorten || common || short_compare))
condition is false, then the following
  if (may_need_excess_precision
  && (orig_type0 != type0 || orig_type1 != type1)
  && build_type == NULL_TREE)
would fail the assertion there and if there wouldn't be excess precision,
  if (code == SPACESHIP_EXPR)
would be false (for SPACESHIP_EXPR we always have build_type set like for
other comparisons) and then trigger
  if (!result_type)
{
  if (complain & tf_error)
{
  binary_op_rich_location richloc (location,
   orig_op0, orig_op1, true);
  error_at (,
"invalid operands of types %qT and %qT to binary %qO",
TREE_TYPE (orig_op0), TREE_TYPE (orig_op1), code);
}
  return error_mark_node;
}
So, if result_type is NULL, we don't really need to compute
semantic_result_type because nothing will use it anyway and can get
fall through into the error/return error_mark_node; case.

2022-10-27  Jakub Jelinek  

PR c++/107382
PR c++/107383
* typeck.cc (cp_build_binary_op): Don't compute
semantic_result_type
if result_type is NULL.

* g++.dg/diagnostic/bad-binary-ops2.C: New test.

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #4 from Rama Malladi  ---
Hi Martin,
Thanks for the guidance. Can we delete the attachment from this bug report?

Regards,
Rama

[Bug lto/107418] lto-dump -gimple-stats ICE Segmentation Fault

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Mine, thanks for the bug report.

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

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

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

--- Comment #3 from Martin Liška  ---
Can you please share perf-profile before and after the revision?

Note I can't see it for Altra aarch64 CPU:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=633.477.0=683.477.0=664.477.0=648.477.0=618.477.0=605.477.0=759.477.0=584.477.0;

However, there are huge changes in between GCC 6/7 and a newer releases. Note
the benchmark is pretty small and very sensitive to instruction caches.

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Blocks||26163

--- Comment #2 from Martin Liška  ---
(In reply to Rama Malladi from comment #0)
> Created attachment 53773 [details]
> Input and source files.
> 

Note you should not share publicly source files of the entire SPEC benchmark.
That very likely violates their license rules!


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++/105644] ICE in a fold expression with a requires expression: in iterative_hash_template_arg, at cp/pt.cc:1805

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

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

--- Comment #1 from Martin Liška  ---
The original code is valid (accepted) by clang. But it's hard to reduce it as
clang++ does not accept's gcc's -E output and vice versa :/

[Bug rtl-optimization/98603] aarch64: ICE in extract_insn (ira) on asm goto with bad constraint

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #5 from Kewen Lin  ---
*** Bug 97940 has been marked as a duplicate of this bug. ***

[Bug target/97940] [11/12/13 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #6 from Kewen Lin  ---
The bisection shows the extra ICE dump was gone since r11-6562 (for fixing
PR98603), by checking the bug description of PR98603, I believed this is one
dup of that one.

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

[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
Aha! I've just managed to reproduce it even w/ the current gcc 13 snapshot by
adding -fstack-protector-all to the list of command line arguments:

% powerpc-e300c3-linux-gnu-g++-13 -m32 -O1 -ffloat-store -fgcse
-fnon-call-exceptions -fno-forward-propagate -fno-omit-frame-pointer -c
svj3x11t.cc -fstack-protector-all
svj3x11t.cc: In static member function 'static ar p::as(const
int&, j ...) [with ar = void; i = q::r; j = {o}]':
svj3x11t.cc:30:65: error: missing REG_EH_REGION note at the end of bb 6
   30 |   static ar as(const int , j...) { (*ao::ap(p1))(j()...); }
  | ^
during RTL pass: cprop_hardreg
svj3x11t.cc:30:65: internal compiler error: verify_flow_info failed
0xc77f7e verify_flow_info()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cfghooks.cc:284
0x10731e3 execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2103
0x10736fe execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2145

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

[Bug c/105581] new warning about boolean types and relational operators

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement