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

[instcombine] assertion error (Invalid structure index) with empty struct #1277

Closed
llvmbot opened this issue Sep 11, 2006 · 3 comments
Closed
Assignees
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Sep 11, 2006

Bugzilla Link 905
Resolution FIXED
Resolved on Nov 07, 2018 00:17
Version 1.0
OS All
Attachments bugpoint reduced bytecode
Reporter LLVM Bugzilla Contributor

Extended Description

While working on emplementing some new feature in PyPy's LLVM backend (garbage collection
framework) we encountered a blocker. I've ran bugpoint on it and it came with a rather small reduced
case, which I have attached. The traceback I get is this:....

opt: Type.cpp:375: virtual const llvm::Type* llvm::StructType::getTypeAtIndex(const llvm::Value*) const:
Assertion `indexValid(V) && "Invalid structure index!"' failed.
/home/ericvrp/projects/llvm/Release/bin/opt((anonymous
namespace)::PrintStackTrace()+0x1f)[0x83c7e0f]/lib/libc.so.6(abort+0xeb)[0xb7dc30f3]
/lib/libc.so.6(__assert_fail+0xeb)[0xb7dbb4af]
/home/ericvrp/projects/llvm/Release/bin/opt(llvm::StructType::getTypeAtIndex(llvm::Value const*)
const+0x6a)[0x837b1fa]
./crash.sh: line 1: 21353 Aborted ~/projects/llvm/Release/bin/opt bugpoint-reduced-
simplified.bc -instcombine

@llvmbot
Copy link
Collaborator Author

llvmbot commented Sep 11, 2006

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Sep 11, 2006

Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060911/037721.html

Testcase here:
Transforms/InstCombine/2006-09-11-EmptyStructCrash.ll

-Chris

@llvmbot
Copy link
Collaborator Author

llvmbot commented Sep 11, 2006

great job! very fast response! thank you

@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 Jan 18, 2022
As per issue llvm#1196, the loop induction variable, which is an argument
in the omp.wsloop operation, does not have a memory location, so when
passed to a function or subroutine, the reference to the value is not
a memory location, but the value of the induction variable. The callee
function/subroutine is then trying to dereference memory at address 1
or some other "not a good memory location".

This is fixed by creating a temporary memory location and storing the
value of the induction variable in that.

Test fixes as a consequence of the changed code generated.

Add checking for some of the omp-unstructured.f90 to check for alloca,
store and load operations, to ensure the correct flow. Add a test
for CYCLE inside a omp-do loop.

Fix trivial typo (LLVMIR instead of LLVMIR:) in some tests.
Remove two lines of unused checks in one test.
Leporacanthicus added a commit that referenced this issue Jun 1, 2022
As per issue #1196, the loop induction variable, which is an argument
in the omp.wsloop operation, does not have a memory location, so when
passed to a function or subroutine, the reference to the value is not
a memory location, but the value of the induction variable. The callee
function/subroutine is then trying to dereference memory at address 1
or some other "not a good memory location".

This is fixed by creating a temporary memory location and storing the
value of the induction variable in that.

Test fixes as a consequence of the changed code generated.

Add checking for some of the omp-unstructured.f90 to check for alloca,
store and load operations, to ensure the correct flow. Add a test
for CYCLE inside a omp-do loop.

Also convert to use -emit-fir in the omp-unstructrued, and make
the symbol matching consistent in the omp-wsloop-variable test.

Reviewed By: peixin

Differential Revision: https://reviews.llvm.org/D126711
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 compile-fail Use [accepts-invalid] and [rejects-valid] instead
Projects
None yet
Development

No branches or pull requests

2 participants