[ 
https://issues.apache.org/jira/browse/LUCY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Logan Bell resolved LUCY-216.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 0.3.1 (incubating)

This should  now be resolved, thanks to Nick's commuinique with the LLVM group: 
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
>             Fix For: 0.3.1 (incubating)
>
>         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

        

Reply via email to