[Bug fortran/39087] New: Performance using COMPLEX data type
I have noticed that in some cases - especially calculating Mandelbrot Fractals there is a severe performance penalty if the COMPLEX data type is used instead of plain variables. It's nothing wrong with the calculation, but it shall be noted that it can mean a severe performance penalty if the COMPLEX data type is used. Result of test cases I have created: --- [r...@cvs2 frac]# time ./m6 real0m5.806s user0m1.705s sys 0m0.032s [r...@cvs2 frac]# time ./m7 real0m18.598s user0m12.469s sys 0m0.036s --- -- Summary: Performance using COMPLEX data type Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m4341 at abc dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #2 from m4341 at abc dot se 2009-02-03 15:50 --- Notice that the test cases have been executed on a Pentium III computer with dual 866MHz processors. The 'depth' variable in the example code has been set to produce comfortable execution times for the forementioned computer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #1 from m4341 at abc dot se 2009-02-03 15:46 --- Created an attachment (id=17234) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17234action=view) Test cases for demonstrating performance impact. The attached file contains code that is in it's current state requiring Xwindows, but it's completely optional for the test case and is only used to display the result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug libgcj/24834] PersistentByteMap close() method is not catching Exception
--- Comment #2 from m4341 at abc dot se 2005-11-14 18:42 --- This was detected by opening the whole set of Java files in Eclipse (and not having any standard Java library at all selected). The close method stood out as an error. since it was declared to throw an exception in the classes AbstractInterruptibleChannel and FileChannel, but when used in PersistentByteMap it was not caught. I did this as an effort to try to strip out the parts I didn't need like AWT and then I encountered this. I hope that this is sufficient as an explanation to the bug. It doesn't seem to be critical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
[Bug libgcj/24832] Modularization of Java libraries
--- Comment #2 from m4341 at abc dot se 2005-11-14 19:18 --- Created an attachment (id=10237) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10237action=view) Proposal for the initial split. This is the initial split I did, and I must admit that it isn't thoroughly tested. There are one text file for each module I created. The text file contains an initial dependency description and a list of files incorporated in that module. In addition to this there is one Java-file with code modified to dynamically load the DefaultContentHandlerFactory that now resides in the AWT package from the URLConnection class. This wasn't necessary earlier. Beware that this is completely untested and I see it as a proposed modification. I REALLY wanted to break out the security classes too, since they have a significant size and aren't really needed on an embedded system. This is my minimal effort breakup - it could have been even better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug libgcj/24832] New: Modularization of Java libraries
I would like to see a modularization of the Java libraries. This will allow for use of Java/gcj in an embedded or semi-embedded environment with the benefits of a full java. However - it shall still be possible to build a single module too for those environments that doesn't need modularization. I understand that this is no easy task due to cross-depenencies. -- Summary: Modularization of Java libraries Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m4341 at abc dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24832
[Bug java/20977] Invalid long to int promotion permitted in array initializer
--- Comment #2 from m4341 at abc dot se 2005-11-13 11:32 --- This is actually in use in the class gnu.gcj.tools.gcj_dbtool.Main.java, line 382. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20977
[Bug libgcj/24833] New: Variable declared as 'final' can be assigned in conflict with Java standard
Example is found in file java.lang.VMCompiler, by code:
private static final MessageDigest md5Digest;
static
{
try
{
md5Digest = MessageDigest.getInstance(MD5);
}
catch (NoSuchAlgorithmException _)
{
md5Digest = null;
}
}
The second assignment in the catch is in conflict with Java standard. (checked
against jdk 1.5.0.)
From a logical point of view this is not really an error, but from a
conformance point ov view it is.
--
Summary: Variable declared as 'final' can be assigned in conflict
with Java standard
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m4341 at abc dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24833
[Bug libgcj/24834] New: PersistentByteMap close() method is not catching Exception
the close() method from java.nio.channels.FileChannel (through java.nio.channels.spi.AbstractInterruptibleChannel) is throwing an exception inside the close() method in gnu.gcj.runtime.PersistentByteMap. This can be resolved in two ways: 1. Catch the Exception in the close() method and just drop the Exception. (since it's a close that fails it shouldn't cause too much trouble). 2. Let the close() method throw it further up in the hirearchy. (formally right, but is it needed?) -- Summary: PersistentByteMap close() method is not catching Exception Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m4341 at abc dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
