Improve c2nim support for C #801
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
new expression parser based on Top Down Operator Procedence supports ',' by making it a statement list supports '\x00' character literals supports do while supports function pointers in function arguments improved floating point number tokenization
|
Could you add your |
|
Sure. I will include what i used to test specific issues, but I have been using the Quake 2 source for the bulk of testing and verifying. My next update will be large as well, or would you like smaller commits, one per improvement. |
|
Smaller commits are appreciated and please ensure the tests continue to work and that C++ "new" and "delete" are kept being supported. |
|
why was this closed? :O |
Clyybber
pushed a commit
to Clyybber/Nim
that referenced
this pull request
Sep 16, 2023
## Summary Fix either the compiler crashing or the VM failing at run-time with an over- or underflow defect for `incl`, `contains`, and construction operations for `set`s where the element range crossed the `int64` upper boundary. The fixed bugs only affected VM bytecode generation and code running in the VM. ## Details There were two related problems: - the relevant `vmgen` logic performed all math with signed integer values - preparing (i.e., offsetting) a run-time value for a `set` operation always happened via `SubInt` (subtract signed integer), ignoring the signed-ness of the operands When the lower bound of the elements' range was beyond the `int64` upper bound, this didn't cause problems: reinterpreting the integer bits always yields negative values there. For example, for a `set[Low..High]` where `Low == high(uint64)-3` and `High = high(uint)`, subtracting the lower inclusive-bound (-4) from the upper inclusive-bound (-1) both didn't cause and overflow and also resulted in the correct value (3). However, when `Low == uint64 high(int64)` and `High == Low + 4`, this doesn't work. When the operand to an operation involving such sets was a literal integer outside the `int64` range, the compiler crashed - when it was a run-time value, the VM erroneously reported an overflow. The logic for generating the code for loading set elements now uses `Int128` to get around over- and underflow problems, and the `Subu` operation is emitted for offsetting unsigned run-time values. In addition, generating the bytecode for loading literal unsigned integers now happens via `loadInt`, meaning that the values are now loaded via `LdImmInt` if they're less than 2^23. Previously, literal unsigned integers were always loaded via the slightly less efficient `LdConst` operation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
new expression parser based on Top Down Operator Procedence
supports ',' by making it a statement list
supports '\x00' character literals
supports do while
supports function pointers in function arguments
improved floating point number tokenization