Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c

[deadshort]

BPO	12701
Nosy	@ronaldoussoren, @mdickinson, @ned-deily
Superseder	bpo-12973: int_pow() implementation is incorrect
Files	seqpoint.c

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-01-25.20:09:25.113>
created_at = <Date 2011-08-06.02:46:58.647>
labels = ['interpreter-core']
title = "Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c"
updated_at = <Date 2013-01-25.20:09:25.112>
user = 'https://bugs.python.org/deadshort'

bugs.python.org fields:

activity = <Date 2013-01-25.20:09:25.112>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2013-01-25.20:09:25.113>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2011-08-06.02:46:58.647>
creator = 'deadshort'
dependencies = []
files = ['22845']
hgrepos = []
issue_num = 12701
keywords = []
message_count = 9.0
messages = ['141701', '141702', '141804', '141809', '141900', '141902', '180610', '180618', '180619']
nosy_count = 4.0
nosy_names = ['ronaldoussoren', 'mark.dickinson', 'ned.deily', 'deadshort']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '12973'
type = None
url = 'https://bugs.python.org/issue12701'
versions = ['Python 2.7']

[deadshort]

Apple Radar ticket 9908625 has been filed. The clang 2.1 optimizer causes overflows in Object/intobject.c:int_pow() to be missed, so 2**63 turns into a negative integer. The attached test program narrows it down. llvm-gcc is fine, so this ticket is mostly an FYI.

idiotbox:Python-2.7.2 cloomis$ ./seqpoint-OK 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=-611686018
overflow detected: 1

to turn into:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4294967296 4200000000
a=4294967296, b=4200000000, c(a*b)=-407881430509551616, c/b=4294967296
overflow detected: 0

[deadshort]

Blecch: cut-o.
The bad case should have been the matching:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=4000000000
overflow detected: 0

[ronaldoussoren]

Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile?

There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard.

[deadshort]

Yup, that was it. Something new learnt. Thanks.

Not sure how to have configure spot that clang needs the flag. OK, the configure stanza for gcc is hardly general; maybe trying $(CC) -fwrapv and keeping the flag if that does not blow up on the pad? But I guess that other ticket takes care of that.

[mdickinson]

If there's dependence on undefined behaviour (from overflow of signed integer operations) in intobject.c, I'd call that a bug. I've been trying to remove similar overflow checks from the Python source when I've encountered them, but there are still a good few left.

[ronaldoussoren]

Clang has an option "-fcatch-undefined-behavior" that might help in locating other locations where we use undefined behavior.

[brettcannon]

Is this still a problem in clang 3.2?

[mdickinson]

I believe the int_pow issue has been resolved, so this bug shouldn't show up in any of the current branches, regardless of which version of Clang is used.

[mdickinson]

Issue bpo-12973 is the one that led to the eventual fix. Closing this as a duplicate.