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

llvm::Module::getDataLayout() returns an incorrect layout. #1578

Closed
llvmbot opened this issue Feb 17, 2007 · 1 comment
Closed

llvm::Module::getDataLayout() returns an incorrect layout. #1578

llvmbot opened this issue Feb 17, 2007 · 1 comment
Labels
bugzilla Issues migrated from bugzilla

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 17, 2007

Bugzilla Link 1206
Resolution FIXED
Resolved on Mar 06, 2010 14:00
Version 1.9
OS All
Reporter LLVM Bugzilla Contributor

Extended Description

I'm using the LLVM 1.9 API. I have an LLVM IR file (in ASCII) that contains
the following header:

; ModuleID = 'hello.c'
target datalayout = "e-p:32:32"
target endian = little
target pointersize = 32
target triple = "i686-pc-linux-gnu"

I then have some code that reads in the IR file and queries for the data layout:

llvm::Module* mod = llvm::ParseAssemblyFile("file.ll");
std::string layout = llvm::Module::getDataLayout();
std::cout << layout;

The value I get back from getDataLayout() is "e-p:32:32-e-p:32:32". I think it
should return "e-p:32:32" instead.

@lattner
Copy link
Collaborator

lattner commented Feb 18, 2007

This is fixed in CVS (2.0).

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit to clementval/llvm-project that referenced this issue Apr 11, 2022
…_VARIABLE (llvm#1578)

Handle dynamic optional argument in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE (previously compiled but caused segfaults).

Simplify the runtime call lowering to simply lower the runtime call without dealing with optionality there. This keeps the optional handling logic in IntrinsicCall.cpp.

Note that the new code will generate some extra "if (not null addr )/then/else" when the actual arguments are always there at runtime. That makes the implementation a lot simpler/safer, and I think it is OK for now (I do not expect these runtime function to be called in hot loop nests, besides).
kitano-metro pushed a commit to RIKEN-RCCS/llvm-project that referenced this issue Feb 14, 2023
refs llvm#1567 llvm#1578 レジスタ割り付けバグ修正

See merge request a64fx-swpl/llvm-project!51
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

2 participants