Navigation Menu

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.

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

llvm-as mis-reads some negative integers #1617

Closed
asl opened this issue Mar 9, 2007 · 7 comments
Closed

llvm-as mis-reads some negative integers #1617

asl opened this issue Mar 9, 2007 · 7 comments
Labels
bugzilla Issues migrated from bugzilla miscompilation tools:llvm-as

Comments

@asl
Copy link
Collaborator

asl commented Mar 9, 2007

Bugzilla Link 1245
Resolution FIXED
Resolved on Feb 22, 2010 12:46
Version trunk
OS Linux
Blocks llvm/llvm-bugzilla-archive#1246
Attachments failed .ll

Extended Description

Consider the attached .ll file.

Do:
llvm-as foo.ll -o - | ./llvm-dif -o foo-cmp.ll

I have (x86-linux):

....

  •   %ov35 = add i32 %ov16, -29              ; <i32> [#uses=1]

  •   %ov35 = add i32 %ov16, -93              ; <i32> [#uses=1]
  store i32 %ov35, i32* %state
  %pcc8 = add i32 %pcv7, 1                ; <i32> [#uses=1]
  store i32 %tmp20, i32* %tmp20_c

@@ -321,7 +321,7 @@
%ov7 = xor i32 %ov18_cc, 251 ; [#uses=3]
%ov41 = xor i32 %ov7, 116 ; [#uses=1]
%ov63 = sub i32 139, %ov7 ; [#uses=2]

  •   %hvar68 = add i32 %ov63, -1             ; <i32> [#uses=1]

  •   %hvar68 = add i32 %ov63, -9             ; <i32> [#uses=1]

and so on. Valgrind is quite. It's definitely an assembler bug, since output
binary code is broken.
@asl
Copy link
Collaborator Author

asl commented Mar 9, 2007

Note, that -93 is 0xFFF...FE3 and -29 is 0xFFFF...FA3. APInt issues?

@asl
Copy link
Collaborator Author

asl commented Mar 9, 2007

Err. Vice-versa. A3 and E3

@asl
Copy link
Collaborator Author

asl commented Mar 9, 2007

Well. The problem is definitely APInt issue. Let's look into {NInteger} rule in
the Lexer.l file. It correctly receives "-93" as yytext. But we have minBits = 6
and numBits = 7. After trunc we have "-29" as a value...

@asl
Copy link
Collaborator Author

asl commented Mar 9, 2007

One more addition. In any of such bad cases executing getSExtValue() before
trunc will result positive number. E.g.: +35 for "-93", "7 for "-9", +58 for
"-70". Funny, eh? :)

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 9, 2007

This is definitely a bug in APInt::getMinSignedBits(). For some values it is
off-by-one. I will fix this shortly.

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 9, 2007

This problem only affected negative integers whose "next to last" significant
bit was set. In such cases the number of bits computed as needed by the value
was off-by-one as it did not account for the sign bit. Consequently, the number
was parsed correctly by the "fromString" constructor but truncated to the wrong
length which changed the value.

This simple patch fixes it:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070305/045759.html

@asl
Copy link
Collaborator Author

asl commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#1246

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
@adrian-prantl
Merge pull request llvm#1617 from adrian-prantl/66024437-bastille
ca9418c 
Unify the code that updates the ArchSpec after finding a fat binary
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla miscompilation tools:llvm-as
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@asl @llvmbot