Skip to content
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

Jump to bottom

operand: printing floating point literals without decimal causes invalid interpretation #387

Closed
dmgard opened this issue Apr 18, 2023 · 1 comment · Fixed by #393
Closed

operand: printing floating point literals without decimal causes invalid interpretation #387

dmgard opened this issue Apr 18, 2023 · 1 comment · Fixed by #393
Labels
bug Something isn't working

Comments

@dmgard
Copy link

dmgard commented Apr 18, 2023

DATA someF32<>+0(SB)/4, $(1.0) will be interpreted correctly as 1.0f
DATA someF32<>+0(SB)/4, $(1) will seemingly be loaded as 0.0f

If a DATA section is specified using, for example, F32(1.0), avo renders it as $(1), which the Go assembler seems to interpret as an integer.

Manually changing the assembly to $(1.0) works.
dmgard added a commit to dmgard/avo that referenced this issue Apr 18, 2023
@dmgard
Update make_const.go floating point format verb
1611d77 
Change floating point format verb to `%#f` from `%#v` to ensure floating point constants are always printed with a decimal, ensuring they will be correctly interpreted by the Go assembler. Closes mmcloughlin#387.
@dmgard dmgard mentioned this issue Apr 18, 2023
Closed
mmcloughlin added a commit that referenced this issue Jun 11, 2023
@mmcloughlin
repro for issue #387
b0a97b0
@mmcloughlin mmcloughlin mentioned this issue Jun 11, 2023
Merged
mmcloughlin added a commit that referenced this issue Jun 11, 2023
@mmcloughlin
operand: fix integer float data (#393)
0d789c8 
Issue #387 pointed out that integer float data is printed incorrectly, such
that it is not parsed correctly by the Go assembler. Specifically, integer
values need the decimal point, otherwise they will be treated as integers. For
example, 1 must be represented as `$(1.)` or `$(1.0)` to be parsed correctly.

This PR fixes that problem and adds a regression test.  The root of the
problem was that the formatting verb `%#v` does not have the right behavior
for integers. We fix it by deferring to custom `String()` function for the
float operand types.

Fixes #387
Closes #388
@mmcloughlin mmcloughlin added the bug Something isn't working label Jun 11, 2023
@mmcloughlin mmcloughlin changed the title Assembly generation printing floating point literals without decimal causes invalid interpretation operand: printing floating point literals without decimal causes invalid interpretation Jun 11, 2023
@mmcloughlin
Copy link
Owner

I think this should be fixed with #393. Let me know if there's any other issues! Sorry for the slow response. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
2 participants
@mmcloughlin @dmgard