You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucy.apache.org by "Logan Bell (Created) (JIRA)" <ji...@apache.org> on 2012/03/22 23:14:23 UTC
[lucy-issues] [jira] [Created] (LUCY-216) t/152-inversion.t failure
t/152-inversion.t failure
-------------------------
Key: LUCY-216
URL: https://issues.apache.org/jira/browse/LUCY-216
Project: Lucy
Issue Type: Bug
Reporter: Logan Bell
Devs,
Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
not ok 2 - catch overflow in token position calculation
# Failed test 'catch overflow in token position calculation'
# at t/152-inversion.t line 70.
# ''
# doesn't match '(?^:position)'
After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
Cheers,
Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Commented] (LUCY-216) t/152-inversion.t failure
Posted by "Nick Wellnhofer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236507#comment-13236507 ]
Nick Wellnhofer commented on LUCY-216:
--------------------------------------
I filed a bug report with LLVM:
http://llvm.org/bugs/show_bug.cgi?id=12335
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Issue Comment Edited] (LUCY-216) t/152-inversion.t failure
Posted by "Nick Wellnhofer (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236487#comment-13236487 ]
Nick Wellnhofer edited comment on LUCY-216 at 3/23/12 10:11 AM:
----------------------------------------------------------------
I could reproduce this bug on 32-bit Linux with clang 2.9:
{noformat}
$ clang -v
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix
{noformat}
So this isn't restricted to 64-bit systems.
was (Author: nwellnhof):
I could reproduce this bug on Linux with clang 2.9:
{noformat}
$ clang -v
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix
{noformat}
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure
Posted by "Logan Bell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Logan Bell updated LUCY-216:
----------------------------
Attachment: Inversion.s-O0
With optimization set to -O0
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Commented] (LUCY-216) t/152-inversion.t failure
Posted by "Anton Korobeynikov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236514#comment-13236514 ]
Anton Korobeynikov commented on LUCY-216:
-----------------------------------------
The code in question has undefined behavior. More information can be found in http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Commented] (LUCY-216) t/152-inversion.t failure
Posted by "Nick Wellnhofer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236487#comment-13236487 ]
Nick Wellnhofer commented on LUCY-216:
--------------------------------------
I could reproduce this bug on Linux with clang 2.9:
{noformat}
$ clang -v
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix
{noformat}
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure
Posted by "Logan Bell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Logan Bell updated LUCY-216:
----------------------------
Attachment: Inversion.s-O1
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure
Posted by "Logan Bell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Logan Bell updated LUCY-216:
----------------------------
Attachment: Inversion.s-O0
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0, Inversion.s-O0O1.diff
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure
Posted by "Logan Bell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Logan Bell updated LUCY-216:
----------------------------
Attachment: (was: Inversion.s-O0)
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0, Inversion.s-O0O1.diff, Inversion.s-O1
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure
Posted by "Logan Bell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Logan Bell updated LUCY-216:
----------------------------
Attachment: Inversion.s-O0O1.diff
> t/152-inversion.t failure
> -------------------------
>
> Key: LUCY-216
> URL: https://issues.apache.org/jira/browse/LUCY-216
> Project: Lucy
> Issue Type: Bug
> Reporter: Logan Bell
> Attachments: Inversion.s-O0O1.diff
>
>
> Devs,
> Today Marvin helped me track down what we believe is a compiler optimization bug associated with the latest version of xcode and Mac OS 10.7.3 (Lion), compiler clan version 3.1. To summarize, I was getting the following unit test failure when after compiling Lucy with Perl 5.14.2 (perl brew install):
> not ok 2 - catch overflow in token position calculation
> # Failed test 'catch overflow in token position calculation'
> # at t/152-inversion.t line 70.
> # ''
> # doesn't match '(?^:position)'
> After dropping in various debug statements the unit test would magically begin to pass. At this point I turned off optimization and the test would always pass. Based on this evidence it would be safe to surmise that the optimizer is making a mistake somewhere. After further discussions on IRC with Marvin, we speculated that 32 bit integers that are being accumulated into 64 bit registers are *not* being truncated back to 32 bit prior to a comparison operation. Apparently during these stages we're speculating that the optimizer is running afoul.
> One idea that was floated on IRC was to convert the associated integers in question to int64_t, since support for 64 bit integers is required anyways for Lucy. However, we wanted to throw this issue up to the list and see if anyone else can maybe a) replicate this and b) has any other thoughtful solutions.
> Cheers,
> Logan
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira