From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25379 invoked by alias); 28 Feb 2006 03:25:48 -0000 Received: (qmail 25358 invoked by uid 48); 28 Feb 2006 03:25:47 -0000 Date: Tue, 28 Feb 2006 03:25:00 -0000 Message-ID: <20060228032547.25357.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/26483] Wrong parsing of doubles when interpreted In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "wilson at gcc dot gnu dot org" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2006-q1/txt/msg00247.txt.bz2 List-Id: ------- Comment #4 from wilson at gcc dot gnu dot org 2006-02-28 03:25 ------- The number 5e-324 exceeds the range of the (C language) double type. So the result you get will depend on how overflow is handled. If I use a number within the range of double, it works fine. I don't know what Java is supposed to do in the presence of overflow here. Compile this with -E #include DBL_MIN_10_EXP and we get a result of -307. So 5e-324 is an out-of-range number. The number is within range of an IA-64/x86 80-bit FP long double number. LDBL_MIN_10_EXP is -4931. So if long doubles are being used, intentionally or accidentally, this could work. On an x86_64 system, I get an answer of 0.0 for both the compiled and interpreted tests. If I use -m32 when compiling, I get the answer "5E-324". I don't have a 32-bit compiled interpreter, so I can't check that. Without access to a copy of the Java standard, it isn't clear to me what the correct answer is here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483