public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen
@ 2023-03-21 13:15 rs2740 at gmail dot com
2023-03-21 13:26 ` [Bug c++/109232] " rguenth at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: rs2740 at gmail dot com @ 2023-03-21 13:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Bug ID: 109232
Summary: Using deduced return type in an unevaluated context
leads to codegen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
auto begin(auto&& r) {
return r.begin();
}
namespace {
struct R {
int* begin();
};
}
static_assert(__is_same(decltype(begin(R())), int*));
int main() {}
Even though ::begin is only used in an unevaluated context, GCC at -O0
generates code for begin<R>, leading to a warning and a failure to link
(https://gcc.godbolt.org/z/cdajoP7f3):
<source>:10:14: warning: 'int* {anonymous}::R::begin()' used but never defined
10 | int* begin();
| ^~~~~
/opt/compiler-explorer/gcc-trunk-20230320/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc7gqEhh.o: in function `auto begin<(anonymous namespace)::R&>((anonymous
namespace)::R&)':
<source>:2: undefined reference to `(anonymous namespace)::R::begin()'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
@ 2023-03-21 13:26 ` rguenth at gcc dot gnu.org
2023-03-21 14:39 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-21 13:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |link-failure
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
maybe it's implementation defined or unspecified whether instantiation happens?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
2023-03-21 13:26 ` [Bug c++/109232] " rguenth at gcc dot gnu.org
@ 2023-03-21 14:39 ` pinskia at gcc dot gnu.org
2023-03-22 14:13 ` ppalka at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-03-21 14:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang does not emit the function but does emit the warning ...
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
2023-03-21 13:26 ` [Bug c++/109232] " rguenth at gcc dot gnu.org
2023-03-21 14:39 ` pinskia at gcc dot gnu.org
@ 2023-03-22 14:13 ` ppalka at gcc dot gnu.org
2023-03-22 14:16 ` ppalka at gcc dot gnu.org
2023-03-22 14:21 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ppalka at gcc dot gnu.org @ 2023-03-22 14:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
What seems to be happening is determine_visibility correctly notices that
begin<R> should have internal linkage due to R having internal linkage, so it
proceeds to clear TREE_PUBLIC, DECL_COMDAT, DECL_EXTERN, etc for begin<R>.
Later in cgraph_node::finalize for begin<R>, we force its definition to be
outputted due to
/* When not optimizing, also output the static functions. (see
PR24561), but don't do so for always_inline functions, functions
declared inline and nested functions. These were optimized out
in the original implementation and it is unclear whether we want
to change the behavior here. */
if (((!opt_for_fn (decl, optimize) || flag_keep_static_functions
|| node->no_reorder)
&& !node->cpp_implicit_alias
&& !DECL_DISREGARD_INLINE_LIMITS (decl)
&& !DECL_DECLARED_INLINE_P (decl)
&& !(DECL_CONTEXT (decl)
&& TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL))
&& !DECL_COMDAT (decl) && !DECL_EXTERNAL (decl))
node->force_output = 1;
I guess we need to somehow refine the above test to exclude implicit
instantiations with internal linkage?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
` (2 preceding siblings ...)
2023-03-22 14:13 ` ppalka at gcc dot gnu.org
@ 2023-03-22 14:16 ` ppalka at gcc dot gnu.org
2023-03-22 14:21 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ppalka at gcc dot gnu.org @ 2023-03-22 14:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Here's another perhaps simpler version that explicitly gives begin<R> internal
linkage, which also fails to link:
namespace {
template<class T>
auto begin(T&& r) {
return r.begin();
}
}
struct R {
int* begin();
};
static_assert(__is_same(decltype(begin(R())), int*));
int main() { }
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
` (3 preceding siblings ...)
2023-03-22 14:16 ` ppalka at gcc dot gnu.org
@ 2023-03-22 14:21 ` ppalka at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: ppalka at gcc dot gnu.org @ 2023-03-22 14:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
So one workaround is to explicitly declare begin inline, which works because
the problematic test in cgraph_node::finalize_function excludes
DECL_DECLARED_INLINE_P functions.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-03-22 14:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-21 13:15 [Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen rs2740 at gmail dot com
2023-03-21 13:26 ` [Bug c++/109232] " rguenth at gcc dot gnu.org
2023-03-21 14:39 ` pinskia at gcc dot gnu.org
2023-03-22 14:13 ` ppalka at gcc dot gnu.org
2023-03-22 14:16 ` ppalka at gcc dot gnu.org
2023-03-22 14:21 ` ppalka at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).