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
NegativeArraySizeException during code gen compiling a large project #6547
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6547?orig=1 |
@paulp said: trait ConfigurableDefault[@specialized V] {
def fillArray(arr: Array[V], v: V) = (arr: Any) match {
case x: Array[Int] => null
case x: Array[Long] => v.asInstanceOf[Long]
}
} |
@paulp said: |
@retronym said: |
@dlwh said: |
@retronym said:
|
@paulp said: |
@retronym said (edited on Oct 20, 2012 7:18:04 AM UTC):
|
@paulp said: |
@magarciaEPFL said:
Leaving out Let's compare the bytecode emitted with and without "closelim", and all other optimization phases on. (BTW, the ASM crash results from computing stack-map frames to emit 1.6 classfiles, that's skipped with -target:1.5-asm but then one also skips noticing non-wellformed bytecode). The ASM crash occurs for:
The problematic snippet is "v.asInstanceOf[Long]". In both cases below the method signature is:
ie local 1 is a boolean[] and local 2 a boolean. Without "closelim" it looks like:
With "closelim" it looks like:
The last snippet is problematic because a |
@magarciaEPFL said: One reason
plus the snippet
are accepted by the verifier. When specialized to something other than In detail (when specialized to something other than
The combination
(ie specialization on) might pass the verifier, but the code described above is unreachable all the same. With "closelim" it's additionally non-well-formed. |
@paulp said: We only know this by applying information the compiler does not have. I don't see how asm can know it either. The match is this: (unknown: Any) match { case _: Array[Int] => ; case _: Array[Long] => } You can't say statically whether those cases will match. Here is a version without Arrays, to further illuminate the problem. trait C[@specialized(Boolean) V] {
def f(v: V) = (null: Any) match {
case _: Int =>
case _: Long => v.asInstanceOf[Long]
}
} It looks like erasure will be the winner here. Man, the boxing code really sucks the air out of the room. |
@magarciaEPFL said:
it can't be determined statically that "after unboxing the 2nd arg, the element type of that array matches the third arg's unboxed type". I was thinking about the specialization I was examining,
for which a bytecode-level type-flow analysis (detailed enough to track array component and element types) could be used to rule out success for:
Anyway, that was a comment "just for completeness". Fixing the bug most likely involves patching ClosureElim some more :) |
@retronym said (edited on Oct 20, 2012 11:02:31 AM UTC):
|
@paulp said: |
@paulp said: |
@retronym said (edited on Oct 20, 2012 11:16:14 AM UTC): |
@paulp said: |
@paulp said: |
@paulp said: < 17587#class Annotation
---
> 17587#trait Annotation
5700c5988
< 58#trait Function1$mcDF$sp
---
> 58#class Function1$mcDF$sp
14937c15229
< 3024#class FractionalProxy
---
> 3024#trait FractionalProxy
16122c16414
< 3483#trait BufferedIterator
---
> 3483#class BufferedIterator |
@adriaanm said: |
@magarciaEPFL said:
from the snippet in [#comment-60509] . That's the least risky fix I can think of. |
@magarciaEPFL said: |
@magarciaEPFL said: |
@adriaanm said (edited on Oct 29, 2012 9:49:21 PM UTC): |
@retronym said: |
@adriaanm said: |
(actually RC1, but that's not an option in jira yet.)
The breeze-math code base crashes when compiling against 2.10.0-RC1.
(Branch here: https://github.com/dlwh/breeze/tree/scala-2.10.0RC1, sbt clean compile should do it.)
The error is:
It claims it's in the file math/src/main/scala/breeze/util/Terminal.scala, but that file compiles fine on its own in its own project. Also, significant changes to the file don't seem to matter.
NB, with specialization disabled breeze-math compiles fine. There are other miscellaneous compile errors if you get passed this project, but nothing that generates compiler stack traces.
The text was updated successfully, but these errors were encountered: