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-upgrade can fail on names with unspecified or defaulted type #1454

Closed
llvmbot opened this issue Jan 6, 2007 · 4 comments
Closed

llvm-upgrade can fail on names with unspecified or defaulted type #1454

llvmbot opened this issue Jan 6, 2007 · 4 comments
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm-tools All llvm tools that do not have corresponding tag

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Jan 6, 2007

Bugzilla Link 1082
Resolution FIXED
Resolved on Feb 22, 2010 12:55
Version trunk
OS All
Reporter LLVM Bugzilla Contributor

Extended Description

Unfortunately, the current algorithm in llvm-upgrade depends on each value being
preceded by its type. However, with signedness elimination, the following is
quite possible:

%tmp7360 = bitcast ubyte %tmp7354 to sbyte
%tmp7361 = sub ubyte 0, %tmp7360

llvm-upgrade current translates this to:

%tmp7360.s = bitcast i8 %x.u to i8
%tmp7361.u = sub i8 0, %tmp7360.u

%tmp7360.u in the sub instruction should be %tmp7360.s, the intended value.
However, since the first argument to sub is ubyte, it gets the .u suffix.

llvm-as rightly declares that %tmp7360.u is undefined in the i8 type plane.
@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 6, 2007

Test case for this and related things:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/042122.html

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 6, 2007

Mine

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 13, 2007

This is related to bug 645. They both require that llvm-upgrade get smarter
about what its parsing, possibly deferring output until everything is resolved.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jan 26, 2007

With the llvm-upgrade, this is now fixed.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070122/043254.html

The XFAIL from the test case has been removed and it passes.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
@hakama2
Merge branch 'feature/1467' into 'swpl-2'
1e03094 
llvm#1454 既存のtest/MTをlit対応する（ファイル比較4）

See merge request a64fx-swpl/llvm-project!59
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 compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm-tools All llvm tools that do not have corresponding tag
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@llvmbot