Skip to content

Conversation

@rascani
Copy link
Contributor

@rascani rascani commented Jan 9, 2026

Summary

GCC exhibits inconsistent behavior where it applies array-to-pointer decay when calling through function pointers, but not for direct function calls, even though both should invoke the same conversion to the parameter type.

Minimal reproduction:

template <int N>
struct S { S(int (&)[N]) {} };

void f(S<3>) {}

int main() {
    int a[3];
    f(a);       // OK on both GCC and Clang
    (&f)(a);    // OK on Clang, ERROR on GCC
}

A similar issue is tracked at: GCC Bugzilla 114812

In ExecuTorch, OpFunction is defined as:

using OpFunction = void (*)(KernelRuntimeContext&, Span<EValue*>);

When tests call (*func)(context, stack) where stack is an EValue*[] array, GCC decays it to EValue** before considering Span's array constructor template<size_t N> Span(T (&)[N]), causing compilation to fail.

This PR updates call sites to work around this issue by explicitly constructing the Span. An alternative option would be to convert the C arrays to std::arrays, which would not be subject to array to pointer decay.

Test plan

# Using GCC 11.5
./test/run_oss_cpp_tests.sh

GCC exhibits inconsistent behavior where it applies array-to-pointer
decay when calling through function pointers, but not for direct
function calls, even though both should invoke the same conversion
to the parameter type.

Minimal reproduction:

    template <int N>
    struct S { S(int (&)[N]) {} };

    void f(S<3>) {}

    int main() {
        int a[3];
        f(a);       // OK on both GCC and Clang
        (&f)(a);    // OK on Clang, ERROR on GCC
    }

A similar issue is tracked at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114812

In ExecuTorch, OpFunction is defined as:

    using OpFunction = void (*)(KernelRuntimeContext&, Span<EValue*>);

When tests call `(*func)(context, stack)` where `stack` is an
`EValue*[]` array, GCC decays it to `EValue**` before considering
Span's array constructor `template<size_t N> Span(T (&)[N])`, causing
compilation to fail.

This PR updates call sites to work around this issue by explicitly
constructing the Span. An alternative option would be to convert the C
arrays to std::arrays, which would not be subject to array to pointer
decay.
@pytorch-bot
Copy link

pytorch-bot bot commented Jan 9, 2026

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/16520

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Cancelled Job, 1 Unrelated Failure

As of commit 1cee1dc with merge base 7fa1aaa (image):

CANCELLED JOB - The following job was cancelled. Please retry:

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@meta-cla meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 9, 2026
@rascani rascani added ciflow/trunk release notes: none Do not include this in the release notes and removed CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. labels Jan 9, 2026
@meta-cla meta-cla bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ciflow/trunk CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. release notes: none Do not include this in the release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant