-
-
Notifications
You must be signed in to change notification settings - Fork 267
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
Upgrade frontend & libs to v2.110 #4707
Conversation
…ements without error
fix issue24534 : goto can skip declarations in labeled statements without error Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com> Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Part of the effort to extract semantic analysis code from the AST code. Co-authored-by: Alex Muscar <alex@muscar.eu>
Get rid of obsolete OMF support Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com> Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Get rid of obsolete `{C,Cpp}Runtime_DigitalMars` special cases Signed-off-by: Dennis <dkorpel@users.noreply.github.com> Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com> Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
The 22 integration tests came with a mix of removing only ROOT (generated/OS/BUILD/MODEL) or GENERATED (generated) subdirs as part of their `make clean`. And running `make clean` in the druntime dir only cleaned up the default BUILD=release variant, while running `make unittest` without explicit BUILD type includes running the integration tests in both debug and release variants. Streamline/fix this to always cleaning up ROOT, and running `make clean` in both variants when running druntime's `make clean`.
…dlang/dmd!16531) Co-authored-by: Alex Muscar <alex@muscar.eu>
…ll candidates (dlang/dmd!15572)
Co-authored-by: Alex Muscar <alex@muscar.eu>
Great, just one problem for new |
Interesting, another bit fields problem remaining, on Linux AArch64 only, working with Apple-clang on arm64 though; probably a frontend problem, needing more special cases:
|
Oh WTF: struct S16 { int :32; };
struct S18 { char a; long long :0; char b; };
static_assert(alignof(S16) == 1); // 4 on non-Apple AArch64
static_assert(alignof(S18) == 1); // 8 on non-Apple AArch64 It works fine for This appears to be handled in https://github.com/dlang/dmd/blob/6c826179ad5eec50b0bc40411acce8f7053e333f/compiler/src/dmd/dsymbolsem.d#L7176-L7193, possibly requiring a new |
Okay, spec is here: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#1018bit-fields
|
The layout for Linux armv7 is currently also wrong. Interestingly Apple seems to behave the same as Linux for armv7 and only aarch64 is different:
|
…ng (dlang/dmd!16729)
Required for 32-bit ARM, and non-Apple 64-bit ARM targets. The only difference to `Gcc_Clang` is that anonymous and 0-length bit-fields do contribute to the aggregate alignment. Caught by existing proper C interop tests in runnable_cxx/testbitfields.d on such targets. The hardcoded bad tests in runnable/{bitfieldsposix64.c,dbitfieldsposix64.d} however now fail after the fix, on such targets again.
…elect overload anymore
No description provided.