https://github.com/hvdijk closed https://github.com/llvm/llvm-project/pull/81175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
> I would really like to avoid Clang 18 being released in this broken state, if
> possible, and I see no way short of a revert to realistically achieve that.
It's too late for that now, it's out there, and it's now everybody else's
problem regardless of what Clang does in the fut
hvdijk wrote:
That would be nice, but that will take time, and I did wait months already
before creating this PR. Leaving Clang in its current state until someone steps
up to fix it, in my opinion, does a massive disservice to users.
If code is written to use `_BitInt`, and it correctly uses c
rjmccall wrote:
There's no such thing as "this is impossible to do". Clang, as the frontend,
is responsible for emitting IR that has gets the effect we want. If that means
contorting the IR we generate to do ugly things like memcpying into a
temporary, that's our life.
I am not surprised th
hvdijk wrote:
> At least that shouldn't be a problem: LLVM has separate concepts of "store
> size" and "alloc size" where only the latter rounds up to alignment. So `load
> i129` is specified to access only 9 bytes, not 16 bytes.
Sure, but when it appears inside a struct, the memory reserved i
nikic wrote:
> > It should be technically possible for Clang to give _BitInt(N) an alignment
> > that is independent from LLVM's alignment
>
> I'm not sure it's even technically possible: if loading a `_BitInt(129)` from
> memory should load 3 bytes, but it is translated to an LLVM IR load of
hvdijk wrote:
> It should be technically possible for Clang to give _BitInt(N) an alignment
> that is independent from LLVM's alignment
I'm not sure it's even technically possible: if loading a `_BitInt(129)` from
memory should load 3 bytes, but it is translated to an LLVM IR load of `i129`
t
nikic wrote:
Thanks for providing proper context. The second issue does look pretty serious
to me. It's a regression from the i128 alignment changes in LLVM 18.
It should be technically possible for Clang to give `_BitInt(N)` an alignment
that is independent from LLVM's alignment, but clearly
https://github.com/nikic dismissed
https://github.com/llvm/llvm-project/pull/81175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
hvdijk wrote:
> I find your PR description very vague. Please be more specific about which
> ICEs and miscompilations you are concerned about (godbolt please). Is this
> _just_ about the open alignment question, or also something else?
I linked to where one major example had already been provi
https://github.com/nikic requested changes to this pull request.
I don't think that this makes sense, given that this has already been allowed
in previous stable clang releases. That's not a step you can really take back.
> but internal compiler errors and seriously wrong code
I find your PR d
AaronBallman wrote:
CC @phoebewang as well
https://github.com/llvm/llvm-project/pull/81175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
I'm not in favor of this revert at the moment, but I'd like to hear more from
our ABI folks (@rjmccall @hjl-tools specifically). It does not seem reasonable
to me that we basically have no path forward to support `_BitInt` with larger
sizes, which is one of the key points t
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Harald van Dijk (hvdijk)
Changes
This reverts commit def720726b73e0d7ab139376ab3ea955f25f4d89.
As noted in #60925 and in D86310, with the current implementation of
`_BitInt` in Clang, we can have either a correct `__int128` implementation
https://github.com/hvdijk created
https://github.com/llvm/llvm-project/pull/81175
This reverts commit def720726b73e0d7ab139376ab3ea955f25f4d89.
As noted in #60925 and in D86310, with the current implementation of `_BitInt`
in Clang, we can have either a correct `__int128` implementation, or a
15 matches
Mail list logo
