Error "body of ‘constexpr’ function is not return statement" on build

[GiovaGa]

Building with gcc 11.4. 0 on current develop the following error arises:

[...]
ALP/include/graphblas/base/distribution.hpp:140:33: error: body of ‘constexpr’ function ‘static constexpr size_t grb::internal::Distribution<backend>::local_offset(size_t, size_t, size_t) [with grb::Backend backend = grb::reference; size_t = long unsigned int]’ not a return-statement

Indeed the C++-11 standard dictates that the body of a constexpr function must contain only a return statement (see here ).

The function that triggers the error is the following:

https://github.com/Algebraic-Programming/ALP/blob/2bd1a9ee8b53853199255b26283179d30578f2f3/include/graphblas/base/distribution.hpp#L132C1-L140C6

I see two possible solutions:

1. Removing the (void) ... statements, but this results in warnings about unused parameters, which is the reason I introduced those lines in the first place.
   Of course we could suppress such warnings, but that's definitely something I would avoid if possible.
2. Somehow telling the compiler to use a newer C++ standard when compiling this file, as newer versions allow such constexpr functions
   Furthermore the fact that testing passed on the CI and previous testing means that we are likely not explicitly telling the compiler to use a fixed C++ standard version.

I think we should consider this to avoid this kind of unexpected compile errors.

[GiovaGa]

This issue is definitely related to #373 , and in my opinion supports the bump to C++17

[anyzelman]

Ah I see what you mean! What is strange is that GCC13 accepts it. Could you check whether bumping the C++ standard to 17 "solves" the issue for GCC11? From:Giovanni Gaio ***@***.******@***.***>> To:Algebraic-Programming/ALP ***@***.******@***.***>> Cc:Subscribed ***@***.******@***.***>> Date:2026-02-17 11:12:00 Subject:Re: [Algebraic-Programming/ALP] Error "body of ‘constexpr’ function is not return statement" on build (Issue #410) [https://avatars.githubusercontent.com/u/48856010?s=20&v=4]GiovaGa left a comment(Algebraic-Programming/ALP#410)<#410 (comment)> This issue is definitely related to #373<#373> , and in my opinion supports the bump to C++17 —

[anyzelman]

I read some specs -- it seems to me that the related lines are null statements, and the spec in C++11 actually allows for null statements in the body of a constexpr function. Hence I believe GCC13's behaviour is correct. It may be good to check if GCC 11.5 still has this issue, and otherwise report it there?

[GiovaGa]

I am now able to test using gcc 11.5.0, and this seems to still be an issue
I will now try also bumping to c++17 and seeing what happens

[anyzelman]

Thanks Giovanni. Given error still persists with GCC 11.5, we can / should also raise a bug report on GCC. We can also check my reading of the spec that way. That doesn't solve the issue for anyone who wants to compile ALP with GCC 11 though, so the check with -std=c++17 is still very useful

[anyzelman]

(Also other workarounds are of course possible)

[GiovaGa]

Adding -std=c++17 successfully compiles with both gcc 11.5.0 and gcc 13.3.0
Some warnings appear with gcc-13

[GiovaGa]

In a minimal example the error is raised with both versions of gcc (specifying -std=c++11, that maybe is implicit in the building infrastructure of ALP).
Interestingly clang 18.1.3 shows this as a warning (and not an error)

I will check the specification once again to understand if this is indeed the intended behavior.

[anyzelman]

GCC 14.3.1 is the one that accepts it, apologies (it's the CentOS Stream 10's default)

[GiovaGa]

The specification seems pretty clear that null statements are allowed inside constexpr functions in c++11

My minimal example:

constexpr int foo(int x, int y){
	(void) x;
	(void) y;
	return 42;
}

int bar(int x, int y){
	return foo(x,y);
}

Also throws an error when compiling as g++-14 x.cpp -std=c++11 -Wall -Wextra -c, but this is gcc 14.2.0

[anyzelman]

So we have that the code we think is correct in ANSI C++11 does not compile with -std=c++11 on GCC 14.2.0 (not latest -> 14.3), GCC 13.3.0 (not latest -> 13.4), and GCC 11.5 (latest). It means we can / should raise it as a bug in GCC 11?

On the other hand, it works as it should on LLVM /Clang 18.1.13 and GCC 14.3.1.

[anyzelman]

For fixing it on our side we have that bumping to ANSI C++17 avoids this issue as well. @djelovina @p-anastas do you have strong opinions on this? I myself am a bit hesitant doing this just before releasing v0.8, it seems more wise to make such a bump after the release

[GiovaGa]

It means we can / should raise it as a bug in GCC 11?

I reported it to GCC (see here), we'll see what happens there