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 (Updated) (JIRA)" <ji...@apache.org> on 2012/03/22 23:16:22 UTC

[lucy-issues] [jira] [Updated] (LUCY-216) t/152-inversion.t failure

     [ 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