Toolchain: GCC 15 #25920
Toolchain: GCC 15 #25920
Conversation
| @@ -16,18 +16,16 @@ void* memcpy(void* dest_ptr, void const* src_ptr, size_t n) | |||
| // FIXME: Support starting at an unaligned address. | |||
| if (!(dest & 0x3) && !(src & 0x3) && n >= 12) { | |||
| size_t size_ts = n / sizeof(size_t); | |||
| n -= size_ts * sizeof(size_t); | |||
| asm volatile( | |||
| "rep movsq\n" | |||
There was a problem hiding this comment.
And why did you move the n -= size_ts * sizeof(size_t);?
There was a problem hiding this comment.
Not sure about the cld/iff we can make assumptions about DF
as for the code move, if I understand the + clobber correctly it means, in-out so it would clobber size_ts, make it 0, making the subtraction not work as intedet
There was a problem hiding this comment.
Oh yes, you are right about the inline assembly overriding size_ts.
The cc clobber should be unnecessary: https://stackoverflow.com/questions/75198561/how-to-let-gcc-know-that-the-direction-flag-df-in-the-eflags-register-has-change#answer-75203424
The x86-64 psABI only requires DF to be clear on function entry/exit, so I think it can technically be set when control flow reaches the inline asm.
Every example online seems to do a cld before instructions respecting the flag, but they never restore it to the previous state. But shouldn't that be wrong? Or does GCC expect DF to be zero after inline asm statements?
I could swear it didn't work without the cld, but it seems to work with your code.
| @@ -11,6 +11,8 @@ | |||
|
|
|||
| namespace GUI { | |||
|
|
|||
| JsonArrayModel::~JsonArrayModel() = default; | |||
There was a problem hiding this comment.
looking at this, the destructor was not the key function before, data(ModelIndex const&, ModelRole) was. So if the destructor is not emitted into libgui-serenity.so with gcc 15, that's a boog in the compiler and/or linker.
There was a problem hiding this comment.
That being said. the patch as-is is fine and benign and doesn't actually change any behavior -- explicitly defaulting a destructor at the declaration site has no effect if the thing is actually virtual.
There was a problem hiding this comment.
Does the symbol not exist at all, or is it just hidden?
Hendiadyoin1
force-pushed
the
gcc-15
branch
3 times, most recently
from
64a384c to
0c2a413
Compare
github-actions
bot
added
the
👀 pr-needs-review
Hendiadyoin1
force-pushed
the
gcc-15
branch
2 times, most recently
from
06ac87a to
113afe2
Compare
GCC 15 seems to raise a false positive here in some cases
Co-Authored-By: Sönke Holz <[email protected]> Co-Authored-By: Daniel Bertalan <[email protected]> F: Clobbers
GCC 15.1.0 has a code-gen bug which causes some odd bit fiddling otherwise, so lets use the multiplication compilers usually emit instead
Seems like GCC 15 now also has this warning
Otherwise newer GCC versions will complain about uninitialized memory accesses
Not sure why this is needed but otherwise SystemMonitor can't find the symbol...
This makes it actually build on compilers assuming C20 (like GCC 15)
There was a problem hiding this comment.
Just one small commit message nit: You're no longer changing the asm clobbers, only other kinds of asm operands. Also, the last line contains a stray "F: Clobbers."
And you should remove the "LibC+" part from the category.
@ADKaster I think you know abit about key-functions and the like, any clue why the LibGUI change is needed?
Missing things: