Defect 6612732

[Tom Rodriguez]

The jdk starter bug list doesn't appear to be updated very frequently 
and we don't appear to provide access to keywords which is unfortunate. 
  Check out 6415680 or 6478991.  6415680 is basically the windows 
version of 4454115 which is linked in the bug report and provides more 
detail.

tom

rgougol at email.sjsu.edu wrote:
> It is nice to get guidelines. How can I look up the tagged defects. The search 
> engine does not find them... please give me more direction or their numbers.
> 
> Sincerely,
> 
> Nima Rouhollah Gougol
> 
> Quoting Tom Rodriguez <Thomas.Rodriguez at Sun.COM>:
> 
>> I thought that bug was closed.  The test is actually invalid since it 
>> isn't using the strict modifier so extra precision in the expression is 
>> allowed.  See 6579973.  Anyway, I've closed that bug so don't bother 
>> looking at it.  I tagged a couple bugs in compiler1 as openjdk-starter 
>> but I don't see very many in compiler2 that would be easy to pickup and 
>> fix quickly.
>>
>> tom
>>
>> rgougol at email.sjsu.edu wrote:
>>> Thanks for all the feadbacks in advance. So I switched to this defect, 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6612732 . The problem is
>>> basically that C1 computes Double.MAX_VALUE * Double.MAX_VALUE == 
>>> Double.POSITIVE_INFINITY incorrectably false which should be true. The
>> defect 
>>> is reproduced by invoking java -Xcomp -XX:UseSSE=1 . However this defect is
>> not 
>>> reproduced in mixed mode even if the problematic method contains a large
>> loop 
>>> and does get compiled?! Does it mean this defeat is extra complicated too?
>> I 
>>> thought I should catch the defect starting from the function 
>>> LIRGenerator::do_ArithmeticOp_FPU(ArithmeticOp*) . However this function is
>>> catched by GDB after the compilation of the problematic method?! Would it
>> be 
>>> the right method to start tracing from?
>>>
>>> Sincerely,
>>>
>>> Nima Rouhollah Gougol
> 
>