Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[devkitPPC] ::aligned_alloc is available, but not std::aligned_alloc #4

Open
dkosmari opened this issue Oct 23, 2023 · 3 comments
Open

Comments

@dkosmari
Copy link

I'm reporting this here, since the gcc repo doesn't allow submitting issues.

In devkitPPC/powerpc-eabi/include/c++/13.2.0/powerpc-eabi/bits/c++config.h, the _GLIBCXX_HAVE_ALIGNED_ALLOC macro is not defined, and that prevents the C function aligned_alloc() to be imported into the std namespace for C++ (in cstdlib).

This code compiles:

#include <stdlib.h>
// ...
buffer = ::aligned_alloc(256, size);

but this doesn't:

#include <cstdlib>
// ...
buffer = std::aligned_alloc(256, size);
@dkosmari dkosmari changed the title ::aligned_alloc is available, but not std::aligned_alloc [devkitPPC] ::aligned_alloc is available, but not std::aligned_alloc Oct 23, 2023
@WinterMute
Copy link
Member

WinterMute commented Apr 28, 2024

The same error occurs for me on linux, mingw64 and macOS with both g++ and clang suggesting this usage isn't portable. Where is this a problem?

@WinterMute WinterMute transferred this issue from devkitPro/newlib Apr 28, 2024
@WinterMute
Copy link
Member

Further investigation shows -std=c++17 is necessary for my linux & macOS compilers to compile this test code

#include <cstdlib>
#include <cstdio>

int main(int argc, char **argv) {

	printf("alloc is %p\n", std::aligned_alloc(256, 1024));
	return 0;
}

Still won't work with mingw64 and, from what I can see here, won't work with other newlib based toolchains without patching. I do have a fix for this though which I'll apply for next release.

@dkosmari
Copy link
Author

dkosmari commented Apr 28, 2024

From inspecting the libstdc++v3 configuration scripts, I think it's simply missing a AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc), or the corresponding AC_DEFINE, in the non-native path. A lot of these function checks are hardcoded in crossconfig.m4 for each target, so it's expected for features to be missing until somebody manually patches them in.

iSasuke7 pushed a commit to devkitNoob-mirrors/gcc that referenced this issue Nov 5, 2024
Here during overload resolution we have two strictly viable ambiguous
candidates devkitPro#1 and devkitPro#2, and two non-strictly viable candidates gcc-mirror#3 and devkitPro#4
which we hold on to ever since r14-6522.  These latter candidates have
an empty second arg conversion since the first arg conversion was deemed
bad, and this trips up joust when called on gcc-mirror#3 and devkitPro#4 which assumes all
arg conversions are there.

We can fix this by making joust robust to empty arg conversions, but in
this situation we shouldn't need to compare gcc-mirror#3 and devkitPro#4 at all given that
we have a strictly viable candidate.  To that end, this patch makes
tourney shortcut considering non-strictly viable candidates upon
encountering ambiguity between two strictly viable candidates (taking
advantage of the fact that the candidates list is sorted according to
viability via splice_viable).

	PR c++/115239

gcc/cp/ChangeLog:

	* call.cc (tourney): Don't consider a non-strictly viable
	candidate as the champ if there was ambiguity between two
	strictly viable candidates.

gcc/testsuite/ChangeLog:

	* g++.dg/overload/error7.C: New test.

Reviewed-by: Jason Merrill <[email protected]>
(cherry picked from commit 7fed7e9)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants