[#BOO-468] ulong.MaxValue triggers internal compiler error in booish

Boo

ulong.MaxValue triggers internal compiler error in booish

Created: 31/Aug/05 08:24 PM Updated: 15/Sep/06 04:18 PM

Component/s:

Type System, Command line tools, Compiler

Affects Version/s:

None

Fix Version/s:

0.7.7

Time Tracking:

Not Specified

File Attachments:	1. BOO-468.patch (3 kb)
Environment:	Windows XP SP2 / .NET 1.1 SP1

Description

« Hide

Refer to the following screen dump from booish:

>>> long.MaxValue
9223372036854775807
>>> ulong.MaxValue
ERROR: Internal compiler error: Arithmetic operation resulted in an overflow..

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Max Bolingbroke - 13/Sep/06 12:47 AM

This is due to an explicit "checked" block being used in EmitLoadLiteralField. This is easy to fix. However, when trying to write some tests, I found this:

>>> c as uint = 0xF0000000
-268435456
>>> c.GetType()
System.OverflowException: Value was either too large or too small for a UInt32.
at System.Convert.ToUInt32(Int32 value)
at System.Int32.System.IConvertible.ToUInt32(IFormatProvider provider)
at Boo.Lang.Runtime.RuntimeServices.UnboxUInt32(Object value) in f:\Programmi
ng\Current\Boo\src\Boo.Lang\Runtime\RuntimeServices.cs:line 1738
at Input23Module.Main(String[] argv)
>>> d as ulong = 0xF000000000000000l
-1152921504606846976
>>> d.GetType()
System.OverflowException: Value was either too large or too small for a UInt64.
at System.Convert.ToUInt64(Int64 value)
at System.Int64.System.IConvertible.ToUInt64(IFormatProvider provider)
at Boo.Lang.Runtime.RuntimeServices.UnboxUInt64(Object value) in f:\Programmi
ng\Current\Boo\src\Boo.Lang\Runtime\RuntimeServices.cs:line 1756
at Input25Module.Main(String[] argv)

Clearly since those are unsigned they should never report negative values! I will investigate this further tonight.

[ Permlink | « Hide ]

Max Bolingbroke - 13/Sep/06 04:27 PM

Test case and patch. However, I believe there may be a deeper issue here. The whole EmitAssembly.EmitLoadLiteralField method seems to suffer from a fundamental flaw: it effectively inlines the values of literal fields in any assembly you reference into your Boo IL, probably on the basis that literals cannot change at runtime. However, this is a versioning issue: if the values of these literals change in the assembly you link against, your inlined values are no longer correct and weirdness results (if my understanding is correct).

So, I think we can actually remove the method and replace its one call site with an instruction to emit a normal load field instruction (i.e. literalness of fields will not be branched on in EmitLoadField).

[ Permlink | « Hide ]

Max Bolingbroke - 13/Sep/06 04:29 PM

By the way, I have opened a new issue (~~BOO-754~~) for the seperate bug that I found above in my first comment: it seems to be an unrelated change.

[ Permlink | « Hide ]

Rodrigo B. de Oliveira - 14/Sep/06 06:33 PM

Fixed in the repository. Thanks for the patch!!!

[ Permlink | « Hide ]

Arron Washington - 14/Sep/06 06:50 PM

The test-case associated with this patch doesn' t seem to pass the unit tests?

[ Permlink | « Hide ]

Max Bolingbroke - 15/Sep/06 04:18 PM

Arron, the test case works for me. However, I notice that someone has added the CultureInfo paramater to the float display code: this may have solved the issue you were having?