Regression with -optimise: "Illegal index: 0 overlaps List((variable par1,LONG))"

[scabug]

Fails as below since at least r23034, up to and including r23144. Compiles with 2.8.0 and the 2.8.1 RCs.

% scalac29 -d /tmp -optimise src/library/scala/collection/immutable/LongMap.scala
error: Illegal index: 0 overlaps List((variable par1,LONG))
error: Illegal index: 0 overlaps List((variable par1,LONG))
two errors found

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-3882?orig=1
Reporter: @paulp
Attachments:

• SI-3882.tar.gz (created on Oct 23, 2011 10:45:38 AM UTC, 3023 bytes)

[scabug]

Christoph Radig (cradig) said:
I get a similar error message when compiling with -optimise:

[ERROR] error: Illegal index: 0 overlaps List((variable par1,DOUBLE))
[INFO] locals: Map(1 -> List((variable par1,DOUBLE)))

The offending line is:

@inline def ≈ (that: Double) = this almost_== that

Curiously, the following compiles:

@inline def nounicodeplease (that: Double) = this almost_== that

Dropping the "@inline" also compiles.

So it seems like inlining and non-ASCII(?) method names don't like each other...?

Strange enough, but I hope this helps.

[scabug]

@paulp said:
Boy, that sounded really promising. Unfortunately I can't reproduce it based on what you've given. A full reproduction would be appreciated.

[scabug]

Commit Message Bot (anonymous) said:
(extempore in r25880) Debugging note.

Pinpointed line which gave us #3882. In case a remedy
suggest itself to you, review by dragos.

[scabug]

Christoph Radig (cradig) said:
I cannot further sustain the "Unicode hypothesis" - probably I made a mistake during compilation drawing false conclusions. I was able though to isolate the offending code so you can compile it yourself and hopefully have a better chance of finding that bug.

Note that the error occurs compiling the ScalaTest file PimpedDouble.scala. I tried to reproduce the conditions in the regular code in the (misnamed) OffendingCode.scala, but without luck.

If you need any further information, please let me know.

[scabug]

@paulp said:
Since fisheye seems to be fairly dead, updating reference: r25880 is scala/scala@81fda51 .

[scabug]

@paulp said:
Also, and I don't know if it's symptomatic or meaningful, this stopped happening with LongMap in 3320a35298 .

[scabug]

@VladUreche said:
I fixed this in the trait inlining branch -- https://github.com/VladUreche/scala/tree/issue/4767-clean
IIRC, it's caused by the iCodeReader reading javac-generated bytecode where locals are recycled, but I might be wrong as I fixed a handful of icode reader errors in that branch.

Now, regarding the bug itself, which is legitimate, I suggest we revisit it once we have GenBCode running - my feeling is that working with bytecode instead of icode should improve the stability. But I won't close it until I see the message gone.

[scabug]

@VladUreche said:
Actually, the bug is not too legitimate, it's just the fact that it prints those scary error messages -- ICodeReader won't ever be capable of handling recycled locals, so it won't load the bytecode for the method and it won't inline it. Not harmful in any way.

See also:
VladUreche/scala@f2e2273#L6R969
VladUreche/scala@f2e2273#L6L939

[scabug]

@adriaanm said:
Un-assigning to foster work stealing, as announced in https://groups.google.com/forum/?fromgroups=#!topic/scala-internals/o8WG4plpNkw

[scabug]

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.

[scabug]

@magarciaEPFL said:
The new optimizer http://magarciaepfl.github.io/scala/ isn't prone to ICodeReader bugs (because it doesn't use it anymore).