Re: libgcj/1615

Re: libgcj/1615

[bryce]

The following reply was made to PR libgcj/1615; it has been noted by GNATS.

From: bryce@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, mjr@statesmean.com, warrenl@gcc.gnu.org
Cc:  
Subject: Re: libgcj/1615
Date: 3 Mar 2001 07:28:28 -0000

 Synopsis: java.math.BigInteger.modPow produces bogus results w/ certain input data
 
 State-Changed-From-To: open->closed
 State-Changed-By: bryce
 State-Changed-When: Fri Mar  2 23:28:28 2001
 State-Changed-Why:
     Confirmed fixed, thanks to Per Bothner's recent patch.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1615&database=gcc

Re: libgcj/1615

[warrenl]

The following reply was made to PR libgcj/1615; it has been noted by GNATS.

From: warrenl@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, mjr@statesmean.com, nobody@gcc.gnu.org,
  warrenl@gcc.gnu.org
Cc:  
Subject: Re: libgcj/1615
Date: 11 Jan 2001 11:23:01 -0000

 Synopsis: java.math.BigInteger.modPow produces bogus results w/ certain input data
 
 Responsible-Changed-From-To: unassigned->warrenl
 Responsible-Changed-By: warrenl
 Responsible-Changed-When: Thu Jan 11 03:23:00 2001
 Responsible-Changed-Why:
     BigInteger author.
 
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=1615&database=gcc
>From daniel@unity.ncsu.edu Sun Apr 01 00:00:00 2001
From: Daniel Henninger <daniel@unity.ncsu.edu>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1688: Includes causing extern "C" not to behave correctly(?)
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010117211600.23946.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00427.html
Content-length: 1868

The following reply was made to PR c++/1688; it has been noted by GNATS.

From: Daniel Henninger <daniel@unity.ncsu.edu>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/1688: Includes causing extern "C" not to behave correctly
 (?)
Date: Wed, 17 Jan 2001 16:06:22 -0500 (EST)

 > > >Priority:       high
 >
 > Please note that this setting is restricted to GCC maintainers:
 > http://gcc.gnu.org/gnats.html
 
 My apologies.
 
 > > >How-To-Repeat:
 > > Just recompiling a program with X11/Xlib.h included will
 > > show it.  Lose the tcl:
 > > #include <X11/Xlib.h>
 > > int main() {}
 > > g++ -I/usr/openwin/include crap.C
 > > same deal.
 >
 > This is a bug in Solaris' X11 headers.  See
 > http://gcc.gnu.org/fom_serv/cache/25.html for a workaround.
 
 
 But...  without -I/usr/openwin/include it is including the =very same=
 header files, and it is not complaining.  In fact it is compiling and
 working without flaw.  I could include the preprocessor output from both
 the failing and working tries and you'll see what I mean.  (you =will= see
 the paths different because they show /usr/include/X11 instead of
 /usr/openwin/include, but they are the very same header files,
 /usr/include/X11 linked to /usr/openwin/include/X11)
 
 Any idea why that behavior would be occuring?  That's the main confusion
 point.  For now we've reverted to gcc 2.8.1 as the default.  Was causing
 headers for our students/users.
 
 Daniel
 
 -- 
 /\\\----------------------------------------------------------------------///\
 \ \\\      Daniel Henninger     http://genjuro.eos.ncsu.edu/daniel       /// /
  \_\\\      North Carolina State University - Systems Programmer        ///_/
     \\\                   Information Technology <IT>                  ///
      """--------------------------------------------------------------"""
 
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: preprocessor/2069
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010225084601.15817.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01705.html
Content-length: 525

The following reply was made to PR preprocessor/2069; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, rbt@mtlb.co.uk
Cc:  
Subject: Re: preprocessor/2069
Date: 25 Feb 2001 08:43:54 -0000

 Synopsis: Preprocessor defines machine-type=1
 
 State-Changed-From-To: open->closed
 State-Changed-By: neil
 State-Changed-When: Sun Feb 25 00:43:53 2001
 State-Changed-Why:
     Closed on request of submitter.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2069&database=gcc

Re: libgcj/1615

[Per Bothner]

The following reply was made to PR libgcj/1615; it has been noted by GNATS.

From: Per Bothner <per@bothner.com>
To: gcc-gnats@gcc.gnu.org, mjr@statesmean.com, warrenl@gcc.gnu.org
Cc: per@bothner.com
Subject: Re: libgcj/1615
Date: 11 Feb 2001 15:36:59 -0800

 I took a look at the code for BigInteger.modPow, and noticed something
 rather suspicious: The variable s is never used.  Perhaps
 double-checking the referenced algorithm would make sense.
 
 Another problem: if exponent.isNegative() then modInverse(m) is
 called.  That seems unlikely to be correct if exponent < -1.
 
 One trivial performance improvement that should be done: Replace
 u.and(ONE).isOne() by u.isOdd().  Even better would be to drop u
 entirely, and just use bitValue(exponent, i) (where i starts at 0 is
 is increment on each iteration), where:
 
   /** Return the value of a specified bit in an BigInteger. */
   public static boolean bitValue (BigInteger x, int bitno)
   {
     int i = x.ival;
     if (x.words == null)
       {
         return bitno >= 32 ? i < 0 : ((i >> bitno) & 1) != 0;
       }
     else
       {
         int wordno = bitno >> 5;
         return wordno >= i ? x.words[i-1] < 0
           : (((x.words[wordno]) >> bitno) & 1) != 0;
       }
   }
 
 /* This is cut-and-pasted from Kawa, so may need soem tweaking. */
 -- 
 	--Per Bothner
 per@bothner.com   http://www.bothner.com/~per/