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).