[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

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

https://gcc.gnu.org/g:62ec780ac0b4d109f2a3c8c4597cb19a82f6188d

commit r13-3147-g62ec780ac0b4d109f2a3c8c4597cb19a82f6188d
Author: Jakub Jelinek 
Date:   Fri Oct 7 08:56:04 2022 +0200

fixincludes: Fix up powerpc floatn.h tweaks [PR107059]

On Wed, Sep 28, 2022 at 12:23:31AM +, Joseph Myers wrote:
> In general the changes match those made by fixincludes, though I think
> the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
> __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
> fixincludes patterns.

You're right, missed that.
The header has:
 /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1.  */
 # if __HAVE_FLOAT128
 #  if __LDBL_MANT_DIG__ == 113 && defined __cplusplus
 typedef long double _Float128;
 #   define __CFLOAT128 _Complex long double
 #  elif !__GNUC_PREREQ (7, 0) || defined __cplusplus
 /* The type _Float128 exist for powerpc only since GCC 7.0.  */
 typedef __float128 _Float128;
 /* Add a typedef for older GCC and C++ compilers which don't natively
support
_Complex _Float128.  */
 typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
 #   define __CFLOAT128 __cfloat128
 #  else
 #   define __CFLOAT128 _Complex _Float128
 #  endif
 # endif
and my current rules don't do anything about that.

The following patch fixes that.
I've run additionally
MACRO_LIST=`pwd`/../gcc/macro_list TARGET_MACHINE=x86_64-pc-linux-gnu \
  ../fixincludes/fixinc.sh /tmp/include-fixed \
`echo /usr/src/libc | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
in the builddir/fixincludes directory where /usr/src/libc is latest glibc
trunk checkout and seems the remaining defined __cplusplus cases in the
floatn.h
and floatn-common.h headers are ok or acceptable.
The remaining cases are:
 #if __GNUC_PREREQ (7, 0) && !defined __cplusplus
 # define __HAVE_FLOATN_NOT_TYPEDEF 1
 #else
 # define __HAVE_FLOATN_NOT_TYPEDEF 0
 #endif
which is IMHO ok because this is only used in tgmath.h or tgmath-like
math.h
stuff which is C only, as C++ doesn't have _Generic.
Another case are the following 3 snippets:
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128X supported but no constant suffix"
 #  else
 #   define __f128x(x) x##f128x
 #  endif
...
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128X supported but no complex type"
 #  else
 #   define __CFLOAT128X _Complex _Float128x
 #  endif
...
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128x supported but no type"
 #  endif
but as no target has _Float128x right now and don't see it
coming soon, it isn't a big deal (on the glibc side it is of
course ok to adjust those).
OT, besides floatn.h and floatn-common.h headers, the only
one remaining in /tmp/include-fixed is sysdeps/arm/unwind.h, perhaps
-#if defined(linux) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__NetBSD__)
should be done in that header (and libgcc/config/arm/unwind-arm.h
too).

2022-10-07  Jakub Jelinek  

PR bootstrap/107059
* inclhack.def (glibc_cxx_floatn_2): Handle #elif the same as #if.
(glibc_cxx_floatn_4): New.
* fixincl.x: Regenerated.
* tests/base/bits/floatn.h: Regenerated.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

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

https://gcc.gnu.org/g:348e46fa8cba960c23170673bfc0c1b4fb384975

commit r13-3148-g348e46fa8cba960c23170673bfc0c1b4fb384975
Author: Jakub Jelinek 
Date:   Fri Oct 7 08:59:05 2022 +0200

fixincludes: Deal also with the _Float128x cases [PR107059]

On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches
wrote:
> Another case are the following 3 snippets:
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128X supported but no constant suffix"
> #  else
> #   define __f128x(x) x##f128x
> #  endif
> ...
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128X supported but no complex type"
> #  else
> #   define __CFLOAT128X _Complex _Float128x
> #  endif
> ...
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128x supported but no type"
> #  endif
> but as no target has _Float128x right now and don't see it
> coming soon, it isn't a big deal (on the glibc side it is of
> course ok to adjust those).

This incremental patch deals handles the above 3 cases, so we
fixinclude what glibc itself changed too.

2022-10-07  Jakub Jelinek  

PR bootstrap/107059
* inclhack.def (glibc_cxx_floatn_5): New.
* fixincl.x: Regenerated.
* tests/base/bits/floatn.h: Regenerated.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #34 from Jakub Jelinek  ---
Should be fixed now.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu

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

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

--- Comment #2 from Richard Biener  ---
final value replacement:
  b_lsm.8_26 = PHI 
 with expr: 1
 final stmt:
  b_lsm.8_26 = 1;

where

(get_scalar_evolution
  (scalar = b_lsm.8_15)
  (scalar_evolution = {0, +, 1}_1))
(chrec_apply
  (varying_loop = 1)
  (chrec = {0, +, 1}_1)
  (x = 1)
  (res = 1))

and

   [local count: 955630225]:
  _1 = (unsigned int) b_lsm.8_15;
  _2 = _1 + 4294967206;
  # RANGE [irange] long int [0, 4294967295] NONZERO 0x
  _12 = (long int) _2;
  # RANGE [irange] long int [91, 4294967386] NONZERO 0x1
  _3 = _12 + 91;

   [local count: 1073741824]:
  # b_lsm.8_15 = PHI <0(2), _3(3)>

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

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

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

--- Comment #10 from Richard Biener  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Alexander Monakov from comment #8) 
> > We need a solution that works for combine too — is it possible to invent a
> > representation for a no-op in-place MEM "move" that only changes its alias
> > set?
> 
> That is the same as my comment here:
> > I don't know what is the best way to represent an aliasing set change
> > even though the value didn't change on the RTL level.
> 
> Clobber might work though I don't know if that is 100% correct as the value
> didn't change so maybe a new RTL code for this? But that would require many
> changes in the backend ...

We need something similar on GIMPLE but I have not yet made up my mind
for something "nice" either ... I'm leaning towards something similar
to a CLOBBER on GIMPLE since that allows us to simply preserve the LHS,
so ...

 MEM[(long int *)_11] = {NOOP};

but we have to make sure this isn't perceived as KILL for DSE purposes
though it does have KILL semantics otherwise (it needs to be a barrier
for load motion).  DSE could of course replace the RHS when eliding an
earlier store.

On RTL a CLOBBER would have the same problem (with DSE), so maybe it
should be a

(parallel
  [(use (MEM ...))]
  [(clobber (MEM ...))])

?  That's also the alternative on GIMPLE - have it be

 MEM[(long int *)_11] = MEM[...];

with the caveat (same as above) of breaking the register typed temporary
rule.

On RTL other unwanted side-effects would be that register allocation
and scheduling have to handle the address compute of the MEM unless
we cobble up everything not allocated into a complex expression and
not require those MEMs to be recognized ...

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> If we don't want to treat such copies as noop moves, then either we need to
> change rtx_equal_p such that it will say MEMs aren't equal if the the alias
> sets are different

But in other context we can treat them as equal ...

> or should tweak in the same spirit the i386.md peephole2
> and set_noop_p (and perhaps some other spot).

Yep, we've been playing whack-a-mole already, so we should just continue
and fix places that pop up with this issue.

> But if we do either of that,
> it would be nice to get rid of the for assembly actually noop move later on
> shortly before expansion or emit it as nothing, because assembler then
> doesn't care about alias sets.

We eventually could do a flag_strict_aliasing = 0 at some point?  Similar
to the idea of doing flag_wrapv = 1 to allow more association.

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> GCC diagonstic seems reasonable.

Only from the most mechanical perspective.

> because GCC assumes you started to define a bitfield which is reasonable
> assumention really.

Not really, because the chances of somebody typing ':' instead of ';' is quite
high (they're on the same key on many keyboard layouts) and the chances of
somebody trying to define a bit-field with a function type is practically zero.

Although the parser just sees "bit-field with function type" we can apply some
intelligence and say that's probably not what the user was trying to do. A
simple typo is more likely.

> At least GCC points out the colon and even suggest you started a bitfield
> which is what a colon normally does here 

But not with a function type.

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > At least GCC points out the colon and even suggest you started a bitfield
> > which is what a colon normally does here 
> 
> But not with a function type.

My point is that it's invalid however we parse it. It's not a valid bit-field,
because of the type. It's not a valid constructor, because it has a return type
and the name doesn't match the class. It's not a valid member function, because
the colon shouldn't be there.

So instead of the most naive parse (an extremely unlikely attempt to define a
bit-field with function type) we should consider whether one of the other
parses was the most likely, because describing it in those terms will help the
highest number of users (as long as the diagnostic we choose doesn't make it
*too* difficult to understand for the other, less likely causes).

And to look at it another way, the "hamming distance" from "colon instead of
semi-colon" to valid code is a single character. The "hamming distance" from
"bit-field of function type" to valid code is huge. You'd need to change "T
foo():" to "int foo:N" i.e. change the type, remove the parens, and add a
constant for the size. It's nowhere near being a valid bit-field!

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jonathan Wakely from comment #3)You'd need to change "T
> foo():" to "int foo:N" i.e. change the type, remove the parens, and add a
> constant for the size.

*and* add a semi-colon!

[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

--- Comment #2 from Richard Biener  ---
OK, so the main issue is that when we parallelize a loop without stores we
insert stores and thus would require a loop PHI for the virtual operand plus
LC SSA updates.

We eventually end up in gen_parallel_loop at

  /* We assume that the loop usually iterates a lot.  */
  loop_version (loop, many_iterations_cond, NULL,
profile_probability::likely (),
profile_probability::unlikely (),
profile_probability::likely (),
profile_probability::unlikely (), true);
  update_ssa (TODO_update_ssa_no_phi);

which performs the update but doesn't insert PHIs - the above assumed
that we'd have no SSA update pending before the call to loop_version.

separate_decls_in_region is what creates the stores (with no virtual
operands, thus triggering renaming and the need for a LC PHI).

I'm going to work around.

[Bug rtl-optimization/107094] [13 Regression] ICE in require, at machmode.h:297 since r13-2916-gd0b00b63a39108

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Yes, I can confirm that.

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

--- Comment #23 from Andrew Haley  ---
This bug has pernicious effects in many more places:

https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html

Florian is right: at least, GCC should not automatically link crtfastmath.o
with -shared. Better, separate fiddling with the FP control register from
-ffast-math entirely.

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

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #4 from vfdff  ---
(In reply to Andrew Pinski from comment #1)
> A few issues.
> First is:
> 
>   if (_26 != 0)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 536870913]:
>   ht_15 = ht_13 + 4294967296;
> 
>[local count: 1073741824]:
>   # ht_2 = PHI 
> 

For the 1st issue, I see the gcc works well before gcc8 with if-conversion,
https://godbolt.org/z/99a9e59Ge

[Bug c++/107179] New: requires-expression gives hard error for inaccessible constructor

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

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

Bug ID: 107179
   Summary: requires-expression gives hard error for inaccessible
constructor
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

template struct bool_constant { static constexpr bool value = B; };

template
  struct is_implicitly_default_constructible
  : bool_constant
  { };

class X {
  X();
public:
  X(int);
};

static_assert( !is_implicitly_default_constructible::value );


This should compile with -std=c++20 but doesn't:

conv.cc: In instantiation of 'struct is_implicitly_default_constructible':
conv.cc:14:55:   required from here
conv.cc:5:53: error: 'X::X()' is private within this context
5 |   : bool_constant
  |~^~~~
conv.cc:9:3: note: declared private here
9 |   X();
  |   ^
conv.cc:14:16: error: static assertion failed
   14 | static_assert( !is_implicitly_default_constructible::value );
  |^~

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

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

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

--- Comment #3 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #2)
> Started with r13-1268-g8c99e307b20c502e.

Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not
this patch that caused the problem.  Furthermore, the IL at the *.optimized
dump looks fine, so this may be an RTL problem.  I also disabled VRP's
exporting of global ranges to make sure it's not RTL-land making decisions
based on global SSA ranges.

Also, the revision before r13-1268-g8c99e307b20c502e also fails with
-fno-tree-dominator-opts -O1 -ftree-vrp.

I tried bisecting this further with -fno-tree-dominator-opts -O1 -ftree-vrp,
and ran into:

commit f1652e3343b1ec47035370801d9b9aca1f8b613f
Author: Roger Sayle 
Date:   Mon May 30 21:26:37 2022 +0100

PR rtl-optimization/101617: Use neg/sbb in ix86_expand_int_movcc.

This patch resolves PR rtl-optimization/101617 where we should generate
the exact same code for (X ? -1 : 1) as we do for ((X ? -1 : 0) | 1).
The cause of the current difference on x86_64 is actually in
ix86_expand_int_movcc that doesn't know that negl;sbbl can be used
to create a -1/0 result depending on whether the input is zero/nonzero.

[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

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

https://gcc.gnu.org/g:89228e3985c5cdf6be58a3b5b1afcad91e9e3422

commit r13-3161-g89228e3985c5cdf6be58a3b5b1afcad91e9e3422
Author: Richard Biener 
Date:   Fri Oct 7 10:28:56 2022 +0200

tree-optimization/107153 - autopar SSA update issue

autopar performs insertion of stores, eventually requiring a
virtual loop PHI and assorted LC PHI adjustments which we intend
to do once after the pass finishes.  But we also perform intermediate
update_ssa after loop duplication which can lose this fact.  The
following forces renaming of the virtual operand before the final
SSA update to fix that.  It also removes the explicit update_ssa
call from the gimple_duplicate_sese_tail utility as has been done
for all other such utilities and instead performs the SSA update
from autopar.

PR tree-optimization/107153
* tree-cfg.cc (gimple_duplicate_sese_tail): Do not update
SSA form here.
* tree-parloops.cc (gen_parallel_loop): Update SSA form
after to-exit-first transform, no PHI insertion is necessary.
(pass_parallelize_loops::execute): Force re-write of the
virtual operand SSA web.

* gcc.dg/autopar/pr107153.c: New testcase.

[Bug tree-optimization/107153] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

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

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

--- Comment #12 from Alexander Monakov  ---
For reference, the previous whacked mole appears to be PR 106187 (where
mems_same_for_tbaa_p comes from).

[Bug c++/107179] [11/12/13 Regression] requires-expression gives hard error for inaccessible constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2022-10-07
 CC||ppalka at gcc dot gnu.org
Summary|requires-expression gives   |[11/12/13 Regression]
   |hard error for inaccessible |requires-expression gives
   |constructor |hard error for inaccessible
   ||constructor
  Known to fail||11.3.0, 12.2.0
 Ever confirmed|0   |1
   Target Milestone|--- |11.4
  Known to work||10.3.0

--- Comment #1 from Patrick Palka  ---
Started with r11-6815-g79e1251b642db0

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

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

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

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

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

commit r13-3163-gedbb2551d156d69a2e337dcd8daa69f2680d57ea
Author: Patrick Palka 
Date:   Fri Oct 7 09:32:45 2022 -0400

c++ modules: static var in inline function [PR104433]

The below testcase fails to link with the error

  undefined reference to `f()::y'

ultimately because during stream out for the static VAR_DECL y we
override DECL_EXTERNAL to true, which later during IPA confuses
symbol_table::remove_unreachable_nodes into thinking it's safe
to not emit the symbol.

The streaming code here already avoids overriding DECL_EXTERNAL for
inline vars and functions, so it seems natural to extend this to
static vars from an inline function.

PR c++/104433

gcc/cp/ChangeLog:

* module.cc (trees_out::core_bools): Don't override
DECL_EXTERNAL to true for static variables from an inline
function.

gcc/testsuite/ChangeLog:

* g++.dg/modules/static-2_a.H: New test.
* g++.dg/modules/static-2_b.C: New test.

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

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

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

Bug 104433 Summary: [modules] Importing  and using std::make_shared 
causes linker errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104433

   What|Removed |Added

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

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

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Should be fixed on trunk after the above commit and r13-3134, thanks for the
bug report and testcases.

[Bug libstdc++/107180] New: Itanium ABI says to block in the emergency EH buffer if memory cannot be acquired

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

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

Bug ID: 107180
   Summary: Itanium ABI says to block in the emergency EH buffer
if memory cannot be acquired
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#imp-emergency says:

"Additional threads are blocked until one of the 16 de-allocates its emergency
buffer storage."

Ignoring the fact that we don't limit the number of threads that can use the
buffer concurrently, our __cxa_allocate_exception first tries malloc, then
tries the emergency pool, then terminates. We should add a condition_variable
to the pool and block when it's full.

This needs to be optional though. For some users blocking indefinitely is worse
than terminating. Maybe use a tunable.

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

[jeff.science at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jeff Hammond  ---
Is this ever going to be fixed?  I observe that a similar MCVE (below) is
compiled without complaint by Intel, Cray and NAG Fortran, so it's almost
certainly a lack of support for the standard in GCC.

As best I can, it is impossible to overload an interface when one of the
specific interfaces involves type(*), dimension(..), which makes it impossible
for me to implement MPI-3 F08 support.

My MCVE:

module f
implicit none

interface test
module procedure test_f08
module procedure test_f08ts
end interface test

contains

subroutine test_f08(buf)
integer :: buf
end subroutine test_f08

subroutine test_f08ts(buffer)
type(*), dimension(..), intent(inout) :: buffer
end subroutine test_f08ts

end module f

[Bug c++/106654] [C++23] P1774 - Portable assumptions

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

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 53675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53675&action=edit
gcc13-pr106654-gimple-wip.patch

My current WIP patch for the handling of more complex assumptions.

My current testcase is for -O2:
int
foo (int x)
{
  [[assume (x == 42)]];
  return x;
}

int
bar (int x)
{
  [[assume (++x == 43)]];
  return x;
}

int
baz (int x)
{
  [[assume (({ int z = ++x; if (z == 51) return -1; if (z == 53) goto lab1; z
== 43; }))]];
lab1:
  return x;
}

Before IPA, that is roughly how I'd like it to look like.

What still needs to be done is:
1) mark the assumption functions somehow and arrange for not being
   actually expanded into RTL, just the bodies kept around for optimization
   of other functions
2) for LTO ideally ensure they are duplicated in every partition that
   refers to them
3) teach ranger to get something useful ouf ot it
4) perhaps for later, decide what to do e.g. for SRA, so that passing an
   argument by value to .ASSUME doesn't prevent its SRA optimization
5) guess see if one can somehow bypass fab pass (-fdisable-tree-fab doesn't
seem
   to work) and if yes, don't ICE if .ASSUME call makes it down to expansion,
   instead fold it away right before or during expansion such that args
   don't need to be evaluated)

Anyway, I must be doing something wrong, because on the above testcase I get
ICE in:
during RTL pass: expand
a.C: In function ‘_Z3bari._assume.0’:
a.C:11:3: internal compiler error: in adjust_one_expanded_partition_var, at
cfgexpand.cc:1577
   11 |   [[assume (++x == 43)]];
  |   ^~
0x99d1ba adjust_one_expanded_partition_var
../../gcc/cfgexpand.cc:1577
0x9af44c execute
../../gcc/cfgexpand.cc:6737
where the name in question is default def for the argument - x_1(D):
bool _Z3bari._assume.0 (int x)
{
  bool _2;

   [local count: 1073741824]:
  _2 = x_1(D) == 42;
  return _2;

}

[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
   |Wrong code at -Os on|Wrong code at -Os on
   |x86_64-pc-linux-gnu |x86_64-pc-linux-gnu since
   ||r7-2012-g43aabfcfd4139e4c
   Keywords|needs-bisection |
 CC||amker at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r7-2012-g43aabfcfd4139e4c.

[Bug testsuite/107181] New: new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90

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

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

Bug ID: 107181
   Summary: new test case gcc.dg/pr25521.c  fails in
r13-2952-ga0aafbc324aa90
   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:a0aafbc324aa90421f0ce99c6f5bbf64ed163da6, r13-2952-ga0aafbc324aa90

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg.exp=gcc.dg/pr25521.c"
FAIL: gcc.dg/pr25521.c scan-assembler \\.rodata

Ecommit a0aafbc324aa90421f0ce99c6f5bbf64ed163da6
Author: Jose E. Marchesi 
Date:   Thu Aug 4 21:16:10 2022 +0200

place `const volatile' objects in read-only sections

[Bug testsuite/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

   Host||powerpc64-linux-gnu
 CC||jemarch at gnu dot org
 Target||powerpc64-linux-gnu
  Build||powerpc64-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
Note: seeing this on BE machines.

[Bug bootstrap/107182] New: Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

Bug ID: 107182
   Summary: Commit
r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4
breaks profiledbootstrap
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

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

Hi,

since r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 I get this
profiledbootstrap fail:

make[3]: Entering directory
'/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/gcc'
/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/./prev-gcc/
-B/usr/x86_64-suse-linux/
bin/ -nostdinc++
-B/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64
-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs 
-I/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linu
x 
-I/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include
 -I/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/libstdc++-v3/libsupc++ -L
/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/prev-x8
6_64-suse-linux/libstdc++-v3/libsupc++/.libs  -fno-PIE -c   -O2 -g
-fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE -fprofile-use -fprofile-reprod
ucible=parallel-runs -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libcody 
 -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o cgraph.o -MT cgraph.o -MMD -MP -MF
./.deps/cgraph.TPo ../../gcc/cgraph.cc
../../gcc/cgraph.cc: In member function 'cgraph_edge*
cgraph_edge::first_speculative_call_target()':
../../gcc/cgraph.cc:1166:1: error: EDGE_CROSSING incorrectly set across same
section
 1166 | }
  | ^
../../gcc/cgraph.cc:1166:1: error: No region crossing jump at section boundary
in bb 19
during RTL pass: bbro
../../gcc/cgraph.cc:1166:1: internal compiler error: verify_flow_info failed
0xa7116e verify_flow_info()
../../gcc/cfghooks.cc:284
0x1c64958 execute
../../gcc/bb-reorder.cc:2663
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:1146: cgraph.o] Error 1
make[3]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-13.0.0+gitr13+2871/obj-x86_64-suse-linux/gcc'
make[2]: *** [Makefile:5182: all-stagefeedback-gcc] Error 2
make[1]: *** [Makefile:30079: stagefeedback-bubble] Error 2
make: *** [Makefile:30099: profiledbootstrap] Error 2

[Bug bootstrap/107182] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

--- Comment #1 from Franz Sirl  ---
Created attachment 53677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53677&action=edit
Related GCDA file

[Bug testsuite/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jose.marchesi at oracle dot com

--- Comment #2 from Jose E. Marchesi  ---
Looking at it...

[Bug c++/107173] ICE: unspellable token PRAGMA_EOL on type_traits:1446:26

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I couldn't reproduce this.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

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

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

--- Comment #20 from Jonathan Wakely  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603073.html

[Bug c++/107173] ICE: unspellable token PRAGMA_EOL on type_traits:1446:26

[esa.pulkkinen at iki dot fi via Gcc-bugs]

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

--- Comment #2 from Esa Pulkkinen  ---
Not sure if this info helps reproducing it, but trying to collect info about
the environment. I built gcc-13 from version
basepoints/gcc-13-2397-g20d30e737ad.

% LC_MESSAGES=C /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220904 (experimental) (GCC)

[Bug analyzer/105783] -Wanalyzer-null-dereference false positive with union and functions

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-3168-gf09b99550a3c6cd16f5e9150ebd4b1d87033dcbd
Author: David Malcolm 
Date:   Fri Oct 7 12:41:59 2022 -0400

analyzer: extract bits from integer constants [PR105783]

Fix a false positive from -Wanalyzer-null-dereference due to -fanalyzer
failing to grok the value of a particular boolean field initialized to a
constant.

gcc/analyzer/ChangeLog:
PR analyzer/105783
* region-model.cc (selftest::get_bit): New function.
(selftest::test_bits_within_svalue_folding): New.
(selfftest::analyzer_region_model_cc_tests): Call it.
* svalue.cc (constant_svalue::maybe_fold_bits_within): Handle the
case of extracting a single bit.

gcc/testsuite/ChangeLog:
PR analyzer/105783
* gcc.dg/analyzer/pr105783.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105783] -Wanalyzer-null-dereference false positive with union and functions

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed on trunk for GCC 13 by the above patch.

[Bug demangler/97091] Demangling the name of the type of a lambda accepting variadic auto parameters fails

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||hasse.christoph at cern dot ch

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

[Bug demangler/102851] Failure to demangle c++ symbol

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
dup of PR97091 I think, which is about demangling a variadic auto lambda

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

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 102851 Summary: Failure to demangle c++ symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851

   What|Removed |Added

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

[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared

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

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

--- Comment #24 from H.J. Lu  ---
Dropping crtfastmath.o with -shared makes sense.

[Bug rtl-optimization/107182] [13 Regression] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |rtl-optimization
Summary|Commit  |[13 Regression] Commit
   |r13-2871-g1b74b5cb4e9d7191f |r13-2871-g1b74b5cb4e9d7191f
   |298245063a8f9c3a1bbeff4 |298245063a8f9c3a1bbeff4
   |breaks profiledbootstrap|breaks profiledbootstrap
   Keywords||build, ice-on-valid-code
   Target Milestone|--- |13.0

[Bug target/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|testsuite   |target

--- Comment #3 from Andrew Pinski  ---
>(default_select_section): Likewise.

Jose didn't update all targets that define their own select section ...

[Bug demangler/97091] Demangling the name of the type of a lambda accepting variadic auto parameters fails

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0
 CC||nathan at acm dot org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
After r13-3167-geb491ea5c10955, trunk outputs:

13.0.0 20221007
Z4mainEUlDpT_E_
-> main::{lambda((auto:1)...)#1}

So I suppose this can be resolved as fixed for GCC 13.

[Bug c++/107173] ICE: unspellable token PRAGMA_EOL on type_traits:1446:26

[esa.pulkkinen at iki dot fi via Gcc-bugs]

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

--- Comment #3 from Esa Pulkkinen  ---
I realize also -E option is necessary for the problem. I tried various flags to
enable/disable modules support (e.g. -fmodules-ts), but those seem not to
impact the problem, though they impact what happens if I do more than just the
preprocessing step.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #42 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

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

commit r13-3171-gb9ad850e86b863c24f6f4f5acf08d49944cc7bbe
Author: Qing Zhao 
Date:   Fri Oct 7 14:59:01 2022 +

Use array_at_struct_end_p in __builtin_object_size [PR101836]

Use array_at_struct_end_p to determine whether the trailing array
of a structure is flexible array member in __builtin_object_size.

gcc/ChangeLog:

PR tree-optimization/101836
* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
to determine a flexible array member reference.

gcc/testsuite/ChangeLog:

PR tree-optimization/101836
* gcc.dg/pr101836.c: New test.
* gcc.dg/pr101836_1.c: New test.
* gcc.dg/pr101836_2.c: New test.
* gcc.dg/pr101836_3.c: New test.
* gcc.dg/pr101836_4.c: New test.
* gcc.dg/pr101836_5.c: New test.
* gcc.dg/strict-flex-array-2.c: New test.
* gcc.dg/strict-flex-array-3.c: New test.

[Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107183
   Summary: -fcompare-debug failure (length) with
-fsanitize=float-cast-overflow
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fsanitize=float-cast-overflow -fcompare-debug
testcase.c
x86_64-pc-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure (length)
$ diff -u *gkd
--- a-testcase.c.gkd2022-10-07 20:13:29.246165247 +0200
+++ a-testcase.gk.c.gkd 2022-10-07 20:13:29.299498288 +0200
@@ -79,12 +79,19 @@
 (const_double:SF 0.0 [0x0.0p+0])) "testcase.c":6:18 discrim 2#
{*movsf_internal}
  (expr_list:REG_EQUIV (const_double:SF 0.0 [0x0.0p+0])
 (nil)))
+(insn # 0 0 4 (parallel [
+(set (reg:XF 9 st(1))
+(reg:XF 8 st))
+(set (reg:XF 8 st)
+(reg:XF 9 st(1)))
+]) "testcase.c":6:18 discrim 2# {*swapxf}
+ (nil))
 (insn # 0 0 4 (set (reg:CCFP 17 flags)
 (unspec:CCFP [
 (compare:CCFP (reg:XF 8 st)
 (reg:XF 9 st(1)))
 ] UNSPEC_NOTRAP)) "testcase.c":6:18 discrim 2# {*cmpiuxf_i387}
- (expr_list:REG_DEAD (reg:XF 8 st)
+ (expr_list:REG_DEAD (reg:XF 8 st [107])
 (nil)))
 (insn # 0 0 4 (set (reg:XF 8 st)
 (reg:XF 8 st)) "testcase.c":6:18 discrim 2# {*movxf_internal}


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

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Jeff Hammond from comment #2)
> Is this ever going to be fixed?  I observe that a similar MCVE (below) is
> compiled without complaint by Intel, Cray and NAG Fortran, so it's almost
> certainly a lack of support for the standard in GCC.
> 
> As best I can, it is impossible to overload an interface when one of the
> specific interfaces involves type(*), dimension(..), which makes it
> impossible for me to implement MPI-3 F08 support.
> 
> My MCVE:
> 
> module f
> implicit none
> 
> interface test
> module procedure test_f08
> module procedure test_f08ts
> end interface test
> 
> contains
> 
> subroutine test_f08(buf)
> integer :: buf
> end subroutine test_f08
> 
> subroutine test_f08ts(buffer)
> type(*), dimension(..), intent(inout) :: buffer
> end subroutine test_f08ts
> 
> end module f

program foo
   use f
   integer i
   call test(i)
end program

which specific subroutine is called based on TKR?

[Bug tree-optimization/107038] Bogus -Wstringop-overflow in dead code

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

Summary|[13 Regression] Bogus   |Bogus -Wstringop-overflow
   |-Wstringop-overflow= since  |in dead code
   |r13-2789-gb40b3035879cf695  |

--- Comment #7 from Siddhesh Poyarekar  ---
[Removing the commit ref and regression since this has been known to fail for
elfutils with __bdos]

OK so here's a reduced reproducer that ought to avoid undefined behaviour.  It
is in fact a case of warning on unreachable code:

typedef long int off_t;
typedef long int ssize_t;
typedef long unsigned int size_t;

extern ssize_t foo_chk (void *buf, size_t nbytes, off_t offset, size_t sz)
__attribute__((__access__(__write_only__, 1, 2)));

extern ssize_t foo_alias (void *buf, size_t nbytes, off_t offset)
__attribute__((__access__(__write_only__, 1, 2)));

struct ar_hdr
{
  int buf;
  char ar_size[10];
};

int
elf_begin_rand(void)
{
  struct ar_hdr h = {.ar_size = {0}};
  size_t len = sizeof(h.ar_size);
  ssize_t recvd = 0;

  do
{
  ssize_t ret;
  do
{
  char *buf = h.ar_size + recvd;
  size_t nbytes = len - recvd;
  off_t offset = recvd + __builtin_offsetof (struct ar_hdr, ar_size);
  size_t bdos = __builtin_dynamic_object_size (buf, 0);

  if (__builtin_constant_p (bdos) && bdos == (size_t) -1)
ret = foo_alias (buf, nbytes, offset);
  else
ret = foo_chk (buf, nbytes, offset, bdos);
}
  while (ret < 0);
  recvd += ret;
}
  while ((size_t) recvd < len);
  return recvd;
}

So what's happening here is that ranger tries to infer the ranges backwards
from the possibly taken branch foo_alias to start from the fact that bdos ==
-1.  Here's the IR snippet:


 [local count: 1073741824]: 
# recvd_6 = PHI 
recvd.0_1 = (sizetype) recvd_6;   
_25 = recvd.0_1 + 4;  
_26 = MAX_EXPR <_25, 16>; 
_27 = _26 - recvd.0_1;
_24 = _27 + 18446744073709551612; 
buf_13 = &h.ar_size + recvd.0_1;  
nbytes_14 = 10 - recvd.0_1;   
_3 = recvd.0_1 + 4;   
offset_15 = (off_t) _3;   
bdos_16 = _24;

Working backwards, _24 is seen to be +INF like bdos_16, which gives _27 the
range of [3,3].

Given that _26 has range of [16, +INF], recvd.0_1 ends up with a range of [13,
18446744073709551612], leaving nbytes with a range of [14,
18446744073709551613].

Ideally somewhere in that chain there ought to have been some hint to indicate
that one of those ranges is impossible, but there isn't.  The nbytes range for
example ought to be limited to [1-10].  Initializing ret in the above program
allows ranger to see that correct range.

[Bug tree-optimization/107038] Bogus -Wstringop-overflow in dead code

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

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

--- Comment #8 from Siddhesh Poyarekar  ---
I forgot to mention that I've been building with:

gcc/cc1 -o /dev/null ../bogus-stringop-overflow.i -O2 -Werror=stringop-overflow
-quiet

to reproduce the warning:

../bogus-stringop-overflow.i: In function ‘elf_begin_rand’:
../bogus-stringop-overflow.i:35:19: error: ‘foo_alias’ writing 14 or more bytes
into a region of size 10 overflows the destination [-Werror=stringop-overflow=]
   35 | ret = foo_alias (buf, nbytes, offset);
  |   ^~~
../bogus-stringop-overflow.i:14:8: note: destination object ‘ar_size’ of size
10
   14 |   char ar_size[10];
  |^~~
../bogus-stringop-overflow.i:8:16: note: in a call to function ‘foo_alias’
declared with attribute ‘access (write_only, 1, 2)’
8 | extern ssize_t foo_alias (void *buf, size_t nbytes, off_t offset)
  |^
cc1: some warnings being treated as errors

[Bug tree-optimization/107038] Bogus -Wstringop-overflow in dead code

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-07
Version|13.0|12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-07
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org

--- Comment #7 from Patrick Palka  ---
Adding 'namespace std { }' alongside the exported entity seems to be a
workaround, e.g.

export module mod;
import "std.hpp";
namespace std { }
export std::X v;

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
IIRC type(*), dimension(..) is beyond F2008, this is F2018.
At least the NAG compiler says so.  The Cray compiler 14.0 fails for me,
as well as Nvidia.

Tobias recently updated support for type(*), dimension(*) according to the
F2018 standard.

Assumed rank still has some unfixed issues, and I think we are happy for
all contributions to make progress here.

> Is this ever going to be fixed?

This is not a contribution to that end.

Note that the complaint from comment#2 has little to do with the original
PR, comment#0, which is accepted by current mainline.  Even with my 7.5.0
installation.

Should we rather close this PR as WORKSFORME and open a new one about
the F2018 stuff?  Once we clarifies that the complaint is valid?

@Steve: I thought there is something in the standard that says how the
resolution (specific then generic) works, but cannot find it now...

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

--- Comment #5 from Steve Kargl  ---
On Fri, Oct 07, 2022 at 07:15:59PM +, anlauf at gcc dot gnu.org wrote:
> 
> @Steve: I thought there is something in the standard that says how the
> resolution (specific then generic) works, but cannot find it now...
> 

type(*) = match any type and its type kind parameters
dimension(..) = match any rank, which includes rank 0.

function foo(i)
   integer i
end foo

function bar(i)
   type(*), dimension(..) :: i
end bar

Both match type "integer", kind "4", rank "0".

AFAIK, there is no other consideration than TKR to discern which function
to call.

Perhaps, someone, who cares about this bug, can point at the language in
the Fortran standard.

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> Both match type "integer", kind "4", rank "0".
> 
> AFAIK, there is no other consideration than TKR to discern which function
> to call.

Yes, assuming that there is no prioritization (as for non-elemental vs.
elemental).

> Perhaps, someone, who cares about this bug, can point at the language in
> the Fortran standard.

I looked again at F2018 and couldn't find anything.

BTW: Crayftn 13.0.1 says:

module f
   ^ 
ftn-855 crayftn: ERROR F, File = pr66409.f90, Line = 1, Column = 8 
  The compiler has detected errors in module "F".  No module information file
will be created for this module.

 module procedure test_f08ts
  ^  
ftn-487 crayftn: ERROR F, File = pr66409.f90, Line = 6, Column = 23 
  The specific interfaces for "TEST_F08TS" and "TEST_F08" make the GENERIC
interface "TEST" ambiguous.

[Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|debug   |target
Summary|-fcompare-debug failure |[10/11/12/13 Regression]
   |(length) with   |-fcompare-debug failure
   |-fsanitize=float-cast-overf |(length) with
   |low |-fsanitize=float-cast-overf
   ||low
   Target Milestone|--- |10.5

--- Comment #1 from Andrew Pinski  ---
I am 99% sure it is a bug in reg-stack.cc which makes this a target issue as
x86_64 is one of two targets which use reg-stack for their FP (m68k being the
other).

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin  ---
(In reply to anlauf from comment #6)
> (In reply to Steve Kargl from comment #5)
> 
> > Perhaps, someone, who cares about this bug, can point at the language in
> > the Fortran standard.
> 
> I looked again at F2018 and couldn't find anything.
> 

I think it's in 15.4.3.4.5 Restrictions on generic declarations.
But it's too late for me to decipher what's written there.

[Bug rtl-optimization/107182] [13 Regression] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
I've managed to reproduce this failure.

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

--- Comment #8 from Steve Kargl  ---
On Fri, Oct 07, 2022 at 08:42:51PM +, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
> 
> Mikael Morin  changed:
> 
>What|Removed |Added
> 
>  CC||mikael at gcc dot gnu.org
> 
> --- Comment #7 from Mikael Morin  ---
> (In reply to anlauf from comment #6)
> > (In reply to Steve Kargl from comment #5)
> > 
> > > Perhaps, someone, who cares about this bug, can point at the language in
> > > the Fortran standard.
> > 
> > I looked again at F2018 and couldn't find anything.
> > 
> 
> I think it's in 15.4.3.4.5 Restrictions on generic declarations.
> But it's too late for me to decipher what's written there.
> 

   Two dummy arguments are distinguishable if

   · one is a procedure and the other is a data object,
   · they are both data objects or known to be functions,
 and neither is TKR compatible with the other,
   · one has the ALLOCATABLE attribute and the other has
 the POINTER attribute and not the INTENT (IN) attribute, or
   · one is a function with nonzero rank and the other is not
 known to be a function.

Bullet 2 is the TKR restriction.  Admittedly, 21-007.pdf:C1514 is
somewhat difficult to parse with the non-passed-object dummy data
object vs passed-object dummy data object language.

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

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||ubizjak at gmail dot com

--- Comment #4 from H.J. Lu  ---
There are:

(insn 6 5 17 2 (set (reg:SI 87 [ a_lsm.8 ])
(const_int 2 [0x2])) "x.c":7:7 83 {*movsi_internal}
 (nil))
...
(insn 62 59 63 2 (parallel [
(set (reg:CCC 17 flags)
(ne:CCC (reg:SI 87 [ a_lsm.8 ])
(const_int 0 [0])))
(set (reg:SI 96) 
(neg:SI (reg:SI 87 [ a_lsm.8 ])))
]) "x.c":4:7 680 {*negsi_ccc_1}
 (expr_list:REG_DEAD (reg:SI 87 [ a_lsm.8 ])
(expr_list:REG_UNUSED (reg:SI 96) 
(nil
(insn 63 62 64 2 (parallel [
(set (reg:SI 97) 
(neg:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]
(clobber (reg:CC 17 flags))
]) "x.c":4:7 1258 {*x86_movsicc_0_m1_neg}
 (expr_list:REG_DEAD (reg:CCC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

Since r87 == 2, combine knows (reg:CCC 17 flags) == 1 and optimizes

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

as

(ltu:SI (const_int 1 [1])
(const_int 0 [0]))

to 0.

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

--- Comment #9 from Mikael Morin  ---
(In reply to Jeff Hammond from comment #2)
> 
> My MCVE:
> 
> module f
> implicit none
> 
> interface test
> module procedure test_f08
> module procedure test_f08ts
> end interface test
> 
> contains
> 
> subroutine test_f08(buf)
> integer :: buf
> end subroutine test_f08
> 
> subroutine test_f08ts(buffer)
> type(*), dimension(..), intent(inout) :: buffer
> end subroutine test_f08ts
> 
> end module f

The following variant is not pretty, and I don't know if it does the job.
But at least it is accepted by the compiler.


module f
implicit none

interface test
module procedure test_f08ts
end interface test

contains

subroutine test_f08(buf)
integer :: buf
end subroutine test_f08

subroutine test_f08ts(buffer)
class(*), dimension(..), intent(inout) :: buffer
select rank(a => buffer)
  rank(0)
select type(b => a)
  type is(integer)
call test_f08(b)
end select
end select
end subroutine test_f08ts

end module f

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #7)
> I think it's in 15.4.3.4.5 Restrictions on generic declarations.
> But it's too late for me to decipher what's written there.

Tomorrow you'll discover:

C.10.6 Rules ensuring unambiguous generics (15.4.3.4.5)

There is talk about "limited type mismatch", and some examples about
polymorphic variables, but you need a clear head to understand it.

Unfortunately there is no mentioning of TYPE(*) in that context;
this is only explained in 7.3.3.2:

"An entity that is declared using the TYPE(*) type specifier is assumed-type
and is an unlimited polymorphic entity. It is not declared to have a type,
and is not considered to have the same declared type as any other entity,
including another unlimited polymorphic entity."

So what does it mean in the present context?

[Bug rtl-optimization/107182] [13 Regression] Commit r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4 breaks profiledbootstrap

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

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

--- Comment #3 from Jeffrey A. Law  ---
Testing a trivial patch now.

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

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

https://gcc.gnu.org/g:895dd027d5dda51a95d242aec8a49a6dfa5db58d

commit r13-3173-g895dd027d5dda51a95d242aec8a49a6dfa5db58d
Author: Marek Polacek 
Date:   Wed Oct 5 15:51:30 2022 -0400

c++: fixes for derived-to-base reference binding [PR107085]

This PR reports that

  struct Base {};
  struct Derived : Base {};
  static_assert(__reference_constructs_from_temporary(Base const&,
Derived));

doesn't pass, which it should: it's just like

  const Base& b(Derived{});

where we bind 'b' to the Base subobject of a temporary object of type
Derived.  The ck_base conversion didn't have ->need_temporary_p set because
we didn't need to create a temporary object just for the base, but the
whole
object is a temporary so we're still binding to a temporary.  Since the
Base subobject is an xvalue, a new function is introduced.

PR c++/107085

gcc/cp/ChangeLog:

* call.cc (conv_binds_ref_to_temporary): New.
(ref_conv_binds_directly): Rename to...
(ref_conv_binds_to_temporary): ...this.  Use
conv_binds_ref_to_temporary.
* cp-tree.h (ref_conv_binds_directly): Rename to...
(ref_conv_binds_to_temporary): ...this.
* method.cc (ref_xes_from_temporary): Use
ref_conv_binds_to_temporary.
* parser.cc (warn_for_range_copy): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/reference_constructs_from_temporary1.C: Adjust
expected
result.
* g++.dg/ext/reference_converts_from_temporary1.C: Likewise.
* g++.dg/cpp0x/elision4.C: New test.

[Bug c++/107085] __reference_constructs_from_temporary does not detect static up-cast

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed.

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

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

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

--- Comment #5 from H.J. Lu  ---
i386 needs to change

(ltu:SI (const_int 1 [1])
(const_int 0 [0]))

to

(ne:SI (const_int 1 [1])
(const_int 0 [0]))

when checking the carry flag.  But the mode info isn't passed to
TARGET_CANONICALIZE_COMPARISON.

[Bug target/100603] csky: config/csky/csky.h:402:13: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]

[jbglaw--- via Gcc-bugs]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

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

--- Comment #1 from Jan-Benedict Glaw  ---
Fixed in c8e93a08693cdd8e18f129f3a1918ed3d32eeebe.

[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #11 from Kees Cook  ---
(In reply to Richard Biener from comment #10)
> I sofar refrained from doing this because of the large amount of fallout and
> followup changes and I think those are not warranted on the GCC 12 branch.

Totally understandable! Thanks for considering it; I didn't know if it was
"easy" or not, so I thought I'd ask. :)

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

[jeff.science at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Jeff Hammond  ---
> program foo
>use f
>integer i
>call test(i)
> end program
> 
> which specific subroutine is called based on TKR?

I understand there is an ambiguity here, but what if I never make this call? 
Is the module code incorrect?

Anyways, there was a lot of discussion of this on a few channels and it seems
to not be required to work, although it's ambiguous whether compilers need to
catch it, and it seems that at least some compilers defer detection of the
issue until the ambiguous overload is actually used.