Bug#487547: libgcj9-0: Null Pointer Exception in Datum constructor
Package: libgcj9-0
Version: 4.3.1-2
Severity: normal
= cat DatumBug.java
// DatumBug.java20080622NHA
// Demonstrate bug in gij-4.3
final class DatumBug
{
public static void main (String args[])
{
Datum date = new Datum();
} //DatumBug.main()
} //DatumBug
= javac DatumBug.java
= /usr/bin/gij-4.3 DatumBug
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(libgcj.so.90)
at DatumBug.main(DatumBug.java:8)
Caused by: java.lang.NullPointerException
at java.util.TimeZone.setID(libgcj.so.90)
at java.util.SimpleTimeZone.(libgcj.so.90)
at Datum.(Datum.java:41)
at java.lang.Class.initializeClass(libgcj.so.90)
...1 more
-- System Information:
Debian Release: lenny/sid
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.21.3B
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgcj9-0 depends on:
ii gcj-4.3-base 4.3.1-2 The GNU Compiler Collection (gcj b
ii libasound2 1.0.16-2 ALSA library
ii libc6 2.7-10GNU C Library: Shared libraries
ii libgcc11:4.3.0-5 GCC support library
ii libgcj-common 1:4.3.0-7 Java runtime library (common files
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages libgcj9-0 recommends:
ii libgcj9-0-awt 4.3.0-3AWT peer runtime libraries for use
ii libgcj9-jar 4.3.0-3Java runtime library for use with
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #114 from pepalogik at seznam dot cz 2008-06-22 16:59 --- (In reply to comment #113) > It is available when storing a result to memory. Yes, but this requires quite a complicated workaround (solution (4) in my comment #109). So you could say that the IEEE754 double precision type is available even on a processor without any FPU because this can be emulated using integers. Moreover, if we assess things pedantically, the workaround (4) still doesn't fully obey the IEEE single/double precision type(s), because there remains the problem of double rounding of denormals. > The IEEE754-1985 allows this. Section 4.3: "Normally, a result is rounded to > the precision of its destination. However, some systems deliver results only > to > double or extended destinations. On such a system the user, which may be a > high-level language compiler, shall be able to specify that a result be > rounded > instead to single precision, though it may be stored in the double or extended > format with its wider exponent range. [...]" > [...] > AFAIK, the IEEE754-1985 standard was designed from the x87 > implementation, so it would have been very surprising that x87 didn't conform > to IEEE754-1985. So it seems I was wrong but the IEEE754-1985 standard is also quite "wrong". > > Do you mean that on Windows, long double has (by default) no more precision > > than double? I don't think so (it's confirmed by my experience). > I don't remember my original reference, but here's a new one: > http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx > In fact, this depends on the architecture. I quote: "x86. Intermediate > expressions are computed at the default 53-bit precision with an extended > range > [...]" I quote, too: "Applies To Microsoft® Visual C++®" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#487564: gnat-4.3: FTBFS with gnat-4.3 but not gnat installed
Package: gnat-4.3 Version: 4.3.1-1 Severity: important According to the Build-Depends, having gnat-4.3 installed but not gnat should be sufficient. However, when I tried that, I got: ... checking for x86_64-linux-gnu-gcc... gnatgcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [stamps/04-configure-stamp] Error 77 make[1]: Leaving directory `/tmp/gnat-4.3/gnat-4.3-4.3.1' make: *** [stamps/04-configure-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 The config.log file shows that it's detecting that gnatgcc doesn't exist. So it appears that gnat-4.3 by itself is insufficient to build the package. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 --- That ® should be (R). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 --- (In reply to comment #114) > Yes, but this requires quite a complicated workaround (solution (4) in my > comment #109). The problem is on the compiler side, which could store every result of a cast or an assignment to memory (this is inefficient, but that's what you get with the x87, and the ISO C language could be blamed too for *requiring* something like that instead of being more flexible). > So you could say that the IEEE754 double precision type is available even on > a processor without any FPU because this can be emulated using integers. Yes, but a conforming implementation would be the processor + a library, not just the processor with its instruction set. > Moreover, if we assess things pedantically, the workaround (4) still doesn't > fully obey the IEEE single/double precision type(s), because there remains the > problem of double rounding of denormals. As I said, in this particular case (underflow/overflow), double rounding is allowed by the IEEE standard. It may not be allowed by some languages (e.g. XPath, and Java in some mode) for good or bad reasons, but this is another problem. > I quote, too: > "Applies To >Microsoft® Visual C++®" Now I assume that it follows the MS-Windows API (though nothing is certain with Microsoft). And the other compilers under MS-Windows could (or should) do the same thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #26 from russiane39 at gmail dot com 2008-06-23 04:34 --- This bug also affects OpenSolaris. # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.2.4/configure --prefix=/usr/gnu --libdir=/usr/gnu/lib --libexecdir=/usr/gnu/lib --mandir=/usr/gnu/share/man --infodir=/usr/share/info --with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/gnu/bin/ld --with-gnu-ld --enable-languages=c,c++,fortran,objc --enable-shared --disable-static --enable-decimal-float -disable-nls Thread model: posix gcc version 4.2.4 - g++ -I/usr/include -I/usr/local/include -Wall -D_REENTRANT -pthreads -I/usr/local/include/openssl -DHAVE_SSL -I/opt/mysql/mysql/include -m64 -mtune=k8 -DMY_ATOMIC_MODE_RWLOCKS -m64 -O2 -mtune=k8 -static-libgcc -o ascent-logonserver AccountCache.o AuthSocket.o LogonCommServer.o LogonConsole.o LogonOpcodes.o LogonStdAfx.o AutoPatcher.o Main.o -L/export/home/burlex/summit/src/ascent-shared -L/export/home/burlex/summit/dep/src/zlib -L/usr/lib/amd64 -L/usr/local/lib/amd64 -L/usr/gnu/lib/amd64 -L/usr/sfw/lib/amd64 -L/usr/gnu/lib -L/opt/mysql/mysql/lib -lmysqlclient -lposix4 -lresolv -lgen -lsocket -lnsl -lm -lshared -lzlib -lz -lssl -lcrypto /usr/gnu/lib/amd64/libstdc++.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
