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.

Sign up for GitHub

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

Incorrect nothrow modeling for intrinsics #34482

Closed
Keno opened this issue Jan 22, 2020 · 1 comment
Closed

Incorrect nothrow modeling for intrinsics #34482

Keno opened this issue Jan 22, 2020 · 1 comment
Labels
compiler:inference Type inference kind:bug Indicates an unexpected problem or unintended behavior

Comments

@Keno
Copy link
Member

Keno commented Jan 22, 2020 

julia> function foo()
           Base.not_int("ABC")
           1
       end
foo (generic function with 1 method)

julia> foo()
1

julia> Base.not_int("ABC")
ERROR: not_int: value is not a primitive type
Stacktrace:
 [1] top-level scope at REPL[42]:1

foo should have thrown, but didn't.
@Keno Keno added compiler:inference Type inference kind:bug Indicates an unexpected problem or unintended behavior labels Jan 22, 2020
@Keno
Copy link
Member Author

Keno commented Jan 22, 2020

Now that I think about it, that might also be a codegen issue, but either way it should be fixed.

Keno added a commit that referenced this issue Jan 27, 2020
@Keno
Fix nothrow behavior for intrinsics
891fada 
This fixes the case in #34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
@Keno Keno mentioned this issue Jan 27, 2020
Merged
Keno added a commit that referenced this issue Feb 16, 2020
@Keno
Fix nothrow behavior for intrinsics
79ce8b9 
This fixes the case in #34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
@vtjnash vtjnash mentioned this issue Feb 25, 2020
Closed
Keno added a commit that referenced this issue Feb 26, 2020
@Keno
Fix nothrow behavior for intrinsics
2857b83 
This fixes the case in #34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
Keno added a commit that referenced this issue Feb 28, 2020
@Keno
Fix nothrow behavior for intrinsics (#34539)
3f05b0d 
This fixes the case in #34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
@Keno Keno closed this as completed Feb 28, 2020
ravibitsgoa pushed a commit to ravibitsgoa/julia that referenced this issue Apr 9, 2020
@Keno @ravibitsgoa
Fix nothrow behavior for intrinsics (JuliaLang#34539)
60a35fd 
This fixes the case in JuliaLang#34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
KristofferC pushed a commit that referenced this issue Apr 11, 2020
@Keno @KristofferC
Fix nothrow behavior for intrinsics (#34539)
466df5a 
This fixes the case in #34482 and adds some more robustness for similar
cases, though I wouldn't be surprised if there were more dragons hiding
here. Intrinsics are a bit special and from the start, we sort of expected
them to only ever be called correctly under pain of segfaults or other
undefined behavior. We've been gradually making these more robust,
but fundamentally, they were never intended to be used by users directly,
only through the type-validating wrappers in Base. What has changed
to cause the recent influx of issues in this area is that people now
like to do compiler transforms that happily recurse through these wrappers
and perform transforms that are not always legal on Intrinsics. This should
help catch a number of them, but this interface is still not very thoroughly
validated, and I would be surprised to see crashes or other errors stemming
from incorrect usage here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler:inference Type inference kind:bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Keno