GCC #80
Loading…
Reference in a new issue
No description provided.
Delete branch "gcc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Now compiles on GCC and Clang.
Can confirm using gcc also fixes the final linking error
Weird but it no longer compiles on clang(clang 12)
Oops as expected. Won't compile on Windows too. (Checked in actions on my repo)
It will work fine in clang14(libstdc++12)
Thanks for working on this! I've left a few comments below.
@ -418,3 +418,3 @@
throw std::invalid_argument(fmt::format("persistent id {:#x} is invalid", persistent_id));
return CemuApp::GetMLCPath(fmt::format(L"usr\\save\\system\\act\\{:08x}\\account.dat", persistent_id)).ToStdWstring();
return CemuApp::GetMLCPath(fmt::format(L"usr/save/system/act/{:08x}/account.dat", persistent_id)).ToStdWstring();
Maybe this have to be
ifdef
d, it might create issues on Windows, no?Use
STREQUAL
instead ofMATCHES
. The latter is for regular expressions.@ -5,13 +5,6 @@
#include "util/helpers/fspinlock.h"
#include "util/highresolutiontimer/HighResolutionTimer.h"
Is
uint64
standard? Why notuint64_t
?C++20 has
std::rotl
andstd::rotr
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
thread_local
is standard since C++11, you can drop this macroStackoverflow suggests a solution, I don't know how affective it is.
I've never used break points in code (my code editor allows me to insert them at a specific line without altering the source), so the best I can do is link this SO page
Clang defines
__GNUC__
already?
It causes UB when used with 64 bit values. (Need to investigate further)
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
I added it in a separate PR
@ -5,13 +5,6 @@
#include "util/helpers/fspinlock.h"
#include "util/highresolutiontimer/HighResolutionTimer.h"
I think it's for consistency. (Since uint64 is used throughout the code)
@ -418,3 +418,3 @@
throw std::invalid_argument(fmt::format("persistent id {:#x} is invalid", persistent_id));
return CemuApp::GetMLCPath(fmt::format(L"usr\\save\\system\\act\\{:08x}\\account.dat", persistent_id)).ToStdWstring();
return CemuApp::GetMLCPath(fmt::format(L"usr/save/system/act/{:08x}/account.dat", persistent_id)).ToStdWstring();
It won't. See https://github.com/cemu-project/Cemu/pull/70
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
https://stackoverflow.com/questions/13106049/what-is-the-performance-penalty-of-c11-thread-local-variables-in-gcc-4-8
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
I have added it in a separate PR
Fixes the need for -fdelayed-template-parsing flag in clang and make it work on gcc
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
Oh, wow, didn't know that. But it also says:
@ -5,13 +5,6 @@
#include "util/helpers/fspinlock.h"
#include "util/highresolutiontimer/HighResolutionTimer.h"
I would personally replace all instances of
uint64
withuint64_t
, but it's not a big deal obviously :)What UB does it cause? The C++ standard says that the implementation should behave basically as if it was implemented like these two functions, see https://timsong-cpp.github.io/cppwp/n4868/bit.rotate
I don't know why but yesterday, when I used it, I got an UB. Might be related to the code I was testing
What kind of UB did you encounter?
--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
Can't recollect. But I think it will be fine. (As long as it receives uint64_t as a param)
Maybe the issue was that the parameter type was uint64 instead of uint64_t, and
numeric_limits<uint64>::digits
doesn't work on some platforms?after hours of testing and compiling on Fedora 36/37 and Arch and testing games ive not had any issues or crashing that isn't normal for the main linux build great work LGTM
Yep, thanks. Fixed.
I only wrote these wrappers because _rotl64 and _rotr64 were used in the code and I wanted to get it compiling asap. Since then I've added
<bit>
toprecompiled.h
so maybe it's a good idea to just go through and replace all occurrences with the std functions. Thoughts?@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
See
73a8e6faac
@ -5,13 +5,6 @@
#include "util/helpers/fspinlock.h"
#include "util/highresolutiontimer/HighResolutionTimer.h"
Yep, that was my reasoning.
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
I would use
thread_local
if I knew it had no overhead on all compilers but I don't know that for sure so... macros :(@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
I've realised
__debugbreak
was only used inprecompiled.h
so now I'm thinking it may be tidier to conditionally replace the cemu_assert_... functions.Seems like the PR kinda got stacked with changes meant for Linux. Nice work!
Also, you've got empty line changes in many (unrelated) files that can probably be cleaned up as well. And if you could follow @Tachi107 suggestions.
This is a remnant of Cemuhook requiring this function to be not inlined, but that's no longer necessary with #73.
Is this code change necessary for GCC support or is there another reason?
Seems like a workaround, if this is needed then dependencies aren't matching or the cmakelists need to be adjusted.
Is this change necessary?
noinline can be removed entirely, see other comment.
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
Only having DLLEXPORT is fine, I don't think there's really a need for DLLIMPORT.
NOINLINE can be removed, see other comment.
Is this include necessary for compilation on GCC?
I believe doing offsetof where the member is a dynamic expression like in
spr.UGQR[sprIndex-SPR_UGQR0]
is not very portable. So this change is fine.Since we are on C++20, it is safe to use rotr or rotl rather than a custom implementation. And also, I found rotr and rotl to be more optimized in godbolt
I ran into this same issue with GCC 11.3.0.
I think it is for unix/platform which is included in Common/platform. Will double check.
Noted. Will remove NOINLINE.
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
Done.
Thanks, done.
Sorry, didn't see this one. That was blatant hacking, I'll undo this.
I think the actual solution was to have the spirv-headers package installed.I suppose
__clang__
or__GNUC__
is somewhat redundant. Changed to just__GNUC__
in71af6e54f4
It was causing problems for some people. I was following advice in this comment: https://github.com/cemu-project/Cemu/issues/1#issuecomment-1225289477.
RendererShaderVk.cpp:134:18: error: excess elements in scalar initializer
was the error.Looks okay w/out. Removed here
3d28b5e014
I've gone ahead replaced _rotl64, _rotr64. Slightly different semantics since std::rot on type T also returns T but there's only one place where that matters:
6408cfdd4b/src/Cafe/HW/Latte/Core/LatteShader.cpp (L228)
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
Thanks. Removed DLLIMPORT here
3b5eb49469
Works w/out on gcc-12.2.0 and clang-14.0.6 (debug) so I've undone this change (see
056ae1f882
). Is it possible the trailing comma was causing the error?Pretty sure this is cuz the struct has too many values if you don't have maxDualSourceDrawBuffersEXT in the header. Or a fix might be that we need to make sure that spirv-headers are also used as a dependency.
Maybe all compilers would be happier if this was just a separate struct that we use for limits or we could actually solve the issue and use a designated initializer list to make the code easier to check since we use C++20 now.
That sounds quite likely. C++20 designated initialisers may be useful here?
Maybe, but I think we can do that separately.
LGTM
I'm facing the same error in https://github.com/cemu-project/Cemu/pull/75#issuecomment-1229451547 - do you have any suggestions?
@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
As mentioned in the previous comment using
thread_local
the way it is currently used has no performance impact on GCC, while MSVC's documentation explicitly states that:See this for details: https://docs.microsoft.com/en-us/cpp/cpp/storage-classes-cpp?view=msvc-170#thread_local
So we could get rid of the macro.
The addition of the
-mavx2
flag is causing issues on pre-Haswell CPUs #144@ -206,0 +216,4 @@
#define UNREACHABLE __builtin_unreachable()
#else
#define UNREACHABLE
#endif
Thanks. https://github.com/cemu-project/Cemu/pull/101
-mavx2
is required for all the_mm256_...
functions.-mssse3
is for_mm_shuffle_epi8
Other instructions used in Cemu:
_mm_prefetch
,_mm_pause
,_mm_setcsr
_mm_mfence
,_mm_set_epi8
,_mm_set_epi16
,_mm_loadu_si128
,_mm_store_si128
_mm_min_epu16
,_mm_max_epu16
So it may actually be a good idea to add additional flags.
What about adding
-march=x86-64-v2
and trying to stick to the x86_64-v2 psABI?Edit: nevermind, AVX2 is part of v3
Both clang and gcc have a way to selectively enable CPU extensions for individual functions. Here is an example. It's better to do it this way than to set
-mavx2
or similar globally as Cemu doesn't have a hard requirement on any of the optional CPU extensions.I agree, I can make a pr changing this if you wish but I don't think it would help insofar as compiling Cemu for pre-haswell CPUs on GCC.
From https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
It would be appreciated.
Why not? As it says in your quote from the spec, you have to manually make sure the CPU extensions are supported at runtime before running the function with the intrinsics. This is something we already do. Optionally running the hand-optimized functions if the CPU extensions are supported and otherwise falling back to a generic implementation that can run on any CPU. The code for handling GPU drawcall indices is a good example. On Windows this is all pretty well tested and people run Cemu with the most ancient of CPUs.
Alright, I didn't realise you already checked this, thanks.
Here you go https://github.com/cemu-project/Cemu/pull/152
I must have missed these clang specific pragmas when I made #80. Sorry about that.
68fa5b32a1/src/Cafe/HW/Latte/Core/LatteIndices.cpp (L288)