-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Uncommenting unused variable assignment (or other various things) gives different results #29983
Labels
bug
Indicates an unexpected problem or unintended behavior
Comments
KristofferC
changed the title
Uncommenting unused variable assignment gives different results
Uncommenting unused variable assignment (or other various things) gives different results
Nov 9, 2018
Bump, anything I can do here to help? |
@Keno, I speculatively assigned this to you, assuming this was an optimizer bug. |
Looks like an SROA bug that then gives LLVM license to do the wrong thing |
Keno
added a commit
that referenced
this issue
Jan 5, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing udefined data to be introduced on that bath (generally the 1.0 that happened to already be in register).
Keno
added a commit
that referenced
this issue
Jan 5, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
Keno
added a commit
that referenced
this issue
Jan 5, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register).
Keno
added a commit
that referenced
this issue
Jan 5, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
Keno
added a commit
that referenced
this issue
Jan 7, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
Keno
added a commit
that referenced
this issue
Jan 7, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
Keno
added a commit
that referenced
this issue
Jan 7, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Jan 9, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983 (cherry picked from commit da0179c)
KristofferC
pushed a commit
that referenced
this issue
Jan 9, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it. (cherry picked from commit 34f7a4a)
KristofferC
pushed a commit
that referenced
this issue
Jan 11, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983 (cherry picked from commit da0179c)
KristofferC
pushed a commit
that referenced
this issue
Jan 11, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it. (cherry picked from commit 34f7a4a)
KristofferC
pushed a commit
that referenced
this issue
Feb 4, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 4, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Feb 4, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 4, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 11, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Apr 20, 2019
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Apr 20, 2019
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
KristofferC
pushed a commit
that referenced
this issue
Feb 20, 2020
SROA was accidentally treating a pending node as old and thus getting the wrong type when querying the predecessor. As a result it thought one of the paths was unreachable causing undefined data to be introduced on that path (generally the `1.0` that happened to already be in register). Fix #29983
KristofferC
pushed a commit
that referenced
this issue
Feb 20, 2020
I don't have concrete tests for these, but it looks like they all need the `is_old` predicate for what they're doing, so switch those over also while we're at it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the code
gives the erroneous output:
Now, we comment out the line
x1 = SVector((x[1],))
and get the correct result.
Executing the original code in the REPL also gives the correct result
If we initialize
f1
to be of typeT
we also get correct result.My guess it is something with the type instability in combination with broadcasting in combination with optimization but not sure...
The text was updated successfully, but these errors were encountered: