Defect 6612732

[rgougol at email.sjsu.edu]

Very nice. I am more interested in defect 6478991. I can not though access the
attachment class which is supposed to illustrate the problem. How to get to the
attached files in the database? 

Sincerely,

Rouhollah Gougol

Quoting Tom Rodriguez <Thomas.Rodriguez at Sun.COM>:

> 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
> > 
> > 
>