I think we should to enable it in the core without leaking into
individual configuration scripts. In that case, we should be able to
test it by updating the ref stats, applying the patch, and running the
regressions. If there are no stat changes, we should be OK.

For custom scripts, we could enable the Python's built in warning for
classic division of integers. I think it might be possible to do that
from the C++ side by setting Py_DivisionWarningFlag (the normal way is
to pass -Qwarn on the command line). PEP-238 [1] also mentions a script
that parses Python scripts and lists all of the division, which would be
helpful to weed out the existing cases.

Cheers,
Andreas

[1] https://www.python.org/dev/peps/pep-0238/

On 26/02/2019 00:12, Gabe Black wrote:
> I'd be ok with that too, my only concern being if that changes behavior in
> a config script somewhere unintentionally and silently. With something like
> the print function vs. print statement the interpreter will at least choke
> and let you know something is going on.
>
> Gabe
>
> On Mon, Feb 25, 2019 at 9:00 AM Jason Lowe-Power <[email protected]>
> wrote:
>
>> Hey Andreas,
>>
>> I'd be happy to use the future version and switch the uses of "/" to "//"
>> when floordiv was intended. It should be pretty obvious when floordiv was
>> intended, and I imagine that it's every case of "/" in the current
>> codebase.
>>
>> I *do* hope that Python 3 returns 1.5 for 3/2 and not 1.4, though. ;)
>>
>> Cheers,
>> Jason
>>
>> On Mon, Feb 25, 2019 at 6:41 AM Andreas Sandberg <[email protected]
>> wrote:
>>
>>> Hi Everyone,
>>>
>>> TL;DR; Python 3 changes the default behaviour of division. Should we
>>> enable the same behaviour in Python 2.7?
>>>
>>> Most of you have probably been hit by my Python 3 spam recently. Sorry
>>> about that. :( The good news is that there are only a handful of changes
>>> left to merge before gem5 works in Python 3. Once that happens, we'll
>>> probably start running (some of) our internal regressions using Python 3
>>> instead of (or in addition to) Python 2.7.
>>>
>>> There is still one potential gotcha when using Python 3 in gem5, integer
>>> divisions. Unlike Python 2.7, the default behaviour when dividing two
>>> integers in Python 3 is to promote to floating point if necessary. I.e.,
>>> if you were to evaluate 3/2 in you'd get the following results:
>>>
>>> Python 3: 1.4
>>> Python 2.x: 1
>>>
>>> The operator above is known as "true division" (__truediv__) in Python
>>> 3. To get the old behaviour, there is a new operator (// or
>>> __floordiv__) called floor division that is supported since Python 2.2.
>>> For example, evaluating 3//2 would result in 1 in both Python 2.7 and
>>> Python 3.
>>>
>>> The new behaviour can be enabled by default in Python 2.7 by importing
>>> division from __future__. Should we enable this by default to get
>>> consistent behaviour of division across Python 2 and 3?
>>>
>>> Cheers,
>>> Andreas
>>>
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy
>> the
>>> information in any medium. Thank you.
>>> _______________________________________________
>>> gem5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to