Skip to content

Documentation: Remove warning that nonstandard primitive type sizes may reveal LLVM bugs #58262

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
May 13, 2025
+1 −1
Merged

Documentation: Remove warning that nonstandard primitive type sizes may reveal LLVM bugs #58262

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion doc/src/manual/types.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -301,7 +301,7 @@ a name. A primitive type can optionally be declared to be a subtype of some supe
is omitted, then the type defaults to having `Any` as its immediate supertype. The declaration
of [`Bool`](@ref) above therefore means that a boolean value takes eight bits to store, and has
[`Integer`](@ref) as its immediate supertype. Currently, only sizes that are multiples of
8 bits are supported and you are likely to experience LLVM bugs with sizes other than those used above.
8 bits are supported.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @LilithHafner already pointed out, the removed sentence did not refer to the "multiples of 8 bits" but rather to "sizes [...] used above", i.e. "8, 16, 32, 64, 128"

So the question then is: we sure that e.g. 24 or 48 work fine now and there are no LLVM bugs to be encountered? Then removing this sentence makes sense -- but I'd feel better about that if there were some actual tests in the test suite exercising that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BitIntegers.jl's test suite covers 24, 200, 256, 512 and 1024 bits with more than 500 lines of test files.

We are also using non-power-of-two byte sizes in the company I work for and do not have observed a single LLVM bug.

C, Rust and Zig should use the same LLVM code paths.

Proving the absence of bugs is hard. I have the feeling that we treat this differently compared to what we normally do: Normally we assume that LLVM works correctly and we normally do not mention bugs in other software we use. Shouldn't we have proof of bugs if we say so?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the feeling that we treat this differently compared to what we normally do

I think this is just an instance of once bitten, twice shy. We know LLVM used to have a bunch of bugs here. That said, given BitIntegers tests, I think this is good to go.

Therefore, boolean values, although they really need just a single bit, cannot be declared to be any
smaller than eight bits.

Expand Down