GMP on IA64-HPUX
Hi all, Below is the answer I got from the developer of GMP when I asked about support for ia64-hpux. So, in short, my questions are: is gmp-4.1.4 supposed to work on ia64-hpux? No, it is not. It might be possible to get either the LP64 or the ILP32 ABI to work, but even that requires the workaround you mention. Don't expect any HP compiler to compile GMP correctly though, unless you switch off optimization. Will it be working in the next version (and when?)? I cannot tell for sure. We are currently determining what will go into GMP 4.2 and what will have to wait for 5.0. I must confess that ia64-hpux is a low-priority platform. If it already works in the devel sources (not generally available), would it be possible to have a snapshot of these devel sources? There is some support for ia64-hpux, but it was broken last time I tried it. (Presumably this is yet another HP compiler bug; the problem apparently started when we got a compiler update. I don't have any plans to isolate it and work around it.) We don't make development snapshots public. Sorry. So, it looks like we will not have gfortran on ia64-hpux before a long time, unless someone who cares about it enough patches the GMP sources. Steve, how did you hack gmp to get it run? In the short term, that also means that we don't have to care about supporting __float80 in gfortran ;-) FX PS: I'm amazed that a "GNU project" can have exactly two developers, release source snapshots every two years, adopt the too common attitude of "every non-i686-linux platform is not mainstream", and so on.
Re: GMP on IA64-HPUX
On 12/4/05, FX Coudert <[EMAIL PROTECTED]> wrote: > Hi all, > > Below is the answer I got from the developer of GMP when I asked about > support for ia64-hpux. > > > So, in short, my questions are: is gmp-4.1.4 supposed to work on > > ia64-hpux? > > > > No, it is not. It might be possible to get either the LP64 or > > the ILP32 ABI to work, but even that requires the workaround you > > mention. Don't expect any HP compiler to compile GMP correctly > > though, unless you switch off optimization. > > If it's really compiler problems, this is one more reason for pulling gmp to the toplevel gcc, so it can be built with a sane compiler. Richard.
Re: Installing libgcj consumes huge amounts of memory
Hi Gerald, On Sun, 2005-12-04 at 00:35 +0100, Gerald Pfeifer wrote: > Is anyone seeing this? With current 4.1 sources, on a machine with "only" > 1GB of main memory + 1GB swap, the following part of `make install` > > Adding java source files from srcdir '/cvs/gcc/trunk/libjava/classpath'. > Adding java source files from VM directory /cvs/gcc/trunk/libjava > /tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava > Adding generated files in builddir '..'. > make -f /cvs/gcc/trunk/libjava/classpath/lib/Makefile.gcj \ > GCJ='/tmp/OBJ-1203-1719/gcc/gcj \ > -B/tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava/ \ > -B/tmp/OBJ-1203-1719/gcc/' \ > > compile_classpath='..:/cvs/gcc/trunk/libjava:/tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava:/cvs/gcc/trunk/libjava/classpath:/cvs/gcc/trunk/libjava/classpath/external/w3c_dom:/cvs/gcc/trunk/libjava/classpath/external/sax:.:' > > \ > top_srcdir=/cvs/gcc/trunk/libjava/classpath > > spawns a recursive make (GNU make 3.80) that consumes some 450MB of > memory and triggers a system load of 12+, basically rendering the > machine dead for about a minute. > > Any ideas how I could nail this down? Anyone else seeing this? Yes, I notice the same thing on smaller (limited memory) machines. The problem is that we really have a lot of dependencies between .java source files, and there are really a lot of these in the core library. We are pushing make a bit too hard it seems. This might be caused by my patch to reduce compile time in classpath. I know I tested memory use back then, but this might have only been with respect to the gcj invocations. I'll try reversing this patch and retest later today or tomorrow. But if someone has time earlier then please let me know if reverting this helps or not. 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]> * lib/split-for-gcj.sh: Cut list to 3 package levels deep. http://lists.gnu.org/archive/html/classpath-patches/2005-09/msg00171.html Andrew Haley also had a suggestion for the step just before this one in the build process, rewriting split-for-gcj in awk. But I believe that would still result in the same memory use for make. http://lists.gnu.org/archive/html/classpath-patches/2005-08/msg00145.html Other suggestions welcome. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Installing libgcj consumes huge amounts of memory
Alan Modra writes: > On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote: > > spawns a recursive make (GNU make 3.80) that consumes some 450MB of memory > > and triggers a system load of 12+, basically rendering the machine dead > > for about a minute. > > > > On a different machine with only 512MB + 1GB swap, this time running > > FreeBSD 5.3, I cannot install GCC any longer. > > I noticed something similar on a Linux machine with 512M + 1G swap when > remaking libjava after editing some files. Thrashing for around 15 > minutes before finally proceeding. This might be make or the disastrously slow split-for-gcj shell script. However, I was a little reluctant to check in my patch at http://lists.gnu.org/archive/html/classpath-patches/2005-08/msg00145.html that replaces a shell script with an Awk program, because at lest shell scripts are portable everywhere. Even on a fast machine (Athlon64 3200+) this patch shaves a minute from the build time. Andrew.
Re: Installing libgcj consumes huge amounts of memory
On Sun, Dec 04, 2005 at 11:45:21AM +, Andrew Haley wrote: > Alan Modra writes: > > On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote: > > > spawns a recursive make (GNU make 3.80) that consumes some 450MB of > memory > > > and triggers a system load of 12+, basically rendering the machine dead > > > for about a minute. > > > > > > On a different machine with only 512MB + 1GB swap, this time running > > > FreeBSD 5.3, I cannot install GCC any longer. > > > > I noticed something similar on a Linux machine with 512M + 1G swap when > > remaking libjava after editing some files. Thrashing for around 15 > > minutes before finally proceeding. > > This might be make or the disastrously slow split-for-gcj shell It was "make". I forget the exact figures, but I saw approx the same mem usage as Gerald. -- Alan Modra IBM OzLabs - Linux Technology Centre
GNU Classpath development and gcc integration
Hi all, Probably bad timing just after possibly haven broken the build on small memory machines but I thought it would be good to explain the GNU Classpath development plan and how we integrate with gcc. (BTW I can reproduce the problem now by artificially limiting the virtual memory size with ulimit -v45. Trying to find a solution now.) For a very high level overview of were we are with respect to providing a Free Software alternative to the proprietary java platform and a kind of road map see: http://developer.classpath.org/support/ Escaping the Java Trap A practical road map to the Free Software and Open Source alternatives The GNU Classpath core libraries are used by a large number of runtimes and alternative execution environments (like the traditional kaffe interpreter/jit, but also by integration in mono through ikvm byte code transformation). But it is clear that the most important, in terms of users and in terms of stability/production quality, is the combination with gcc/gcj. Lots of GNU/Linux distributions now rely on the stable gcc/gcj releases with integrated GNU Classpath to package various (large) programs written in the java programming langauge (see the support document above). We noticed that most of our bug reports (50% at least) came through gcj. So we have, with the help of Daniel Berlin, merged our old savannah bug database with the gcc bugzilla. This also allowed us to get similar cvs/svn-commit messages automagically inserted whenever a fix hit the classpath/gcc repositories. This has been a very big help. On the library development front we have tried to separate most of the development from the main gcc tree. Most development is now done directly "upstream" on savannah with occasional merges back into the libjava/classpath tree in gcc. Thanks again to Daniel Berlin for subversion help and to Tom Tromey for making this split possible. Merging has become a lot easier with subversion. We now import new GNU Classpath snapshots into a special branch: svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath and then merge that into the trunk libjava/classpath tree. This has worked very smoothly for us. The traditional design of the java compiler and core libraries means that there is still a tight integration between the two. But we hope that the current arrangement allows us to do rapid development of the core libraries without disrupting the normal gcc development flow. More details about the setup can be found in the libjava/HACKING file in svn. We try really hard not to disrupt the normal flow of GCC development. For any large build/integration changes we contact Mark Mitchell as release manager, but should probably also more often post a note to the main gcc list in the future. If we somehow fail and we cause any trouble, please do let us know on the [EMAIL PROTECTED] list. We try very hard to solve any issues asap. I am mainly one of the library guys, maybe some of the frontend people can tell more about future gcj plans. The current status of the gcjx frontend is described at http://gcc.gnu.org/wiki/GCJX%20status Thanks for all the cooperation. The GCC community has been very helpful and supportive of our efforts. Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Installing libgcj consumes huge amounts of memory
On Sun, 2005-12-04 at 11:48 +0100, Mark Wielaard wrote:
> This might be caused by my patch to reduce compile time in classpath. I
> know I tested memory use back then, but this might have only been with
> respect to the gcj invocations. I'll try reversing this patch and retest
> later today or tomorrow. But if someone has time earlier then please let
> me know if reverting this helps or not.
>
> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]>
>
> * lib/split-for-gcj.sh: Cut list to 3 package levels deep.
I reversed this (patch attached) and now my build with ulimit -v45
passes. But the total virtual memory usage didn't drop that much. It was
around 454MB top usage, to 438MB top usage. Build time increased with
several minutes. Maybe this was just the tipping point for your setup?
Still looking for some other explanation why this seems to show up just
now.
Cheers,
Mark
Index: libjava/classpath/lib/split-for-gcj.sh
===
--- libjava/classpath/lib/split-for-gcj.sh (revision 108010)
+++ libjava/classpath/lib/split-for-gcj.sh (working copy)
@@ -31,7 +31,7 @@
for dir in java javax gnu org; do
fgrep /$dir/ classes | while read file; do
pkg=`echo "$file " | sed -n -e "s,^.*/\($dir/.*\)/[^/]*$,\1,p"`
- list=lists/`echo $pkg | sed -e 's,/,-,g' | cut -f1-3 -d-`
+ list=lists/`echo $pkg | sed -e 's,/,-,g'`
echo "$file" >> ${list}.list.1
f2=`echo "$file" | sed -n -e "s,^.*/\($dir/.*\)$,\1,p"`
f2=`echo "$f2" | sed -e 's/.java$//'`.class
signature.asc
Description: This is a digitally signed message part
Is libgfortran in 4.1 compatible with 4.2?
SPEC CPU 2K FP compiled with gcc 4.2 failed to run with libgfortran from gcc 4.1. Is this expected? If yes, I think we should bump up libgfortran version in 4.2. H.J.
Re: Is libgfortran in 4.1 compatible with 4.2?
On Sunday 04 December 2005 17:48, H. J. Lu wrote: > SPEC CPU 2K FP compiled with gcc 4.2 failed to run with libgfortran > from gcc 4.1. Is this expected? Yes.
Re: Installing libgcj consumes huge amounts of memory
Gerald Pfeifer <[EMAIL PROTECTED]> writes: > Is anyone seeing this? With current 4.1 sources, on a machine with "only" > 1GB of main memory + 1GB swap, the following part of `make install` > > Adding java source files from srcdir '/cvs/gcc/trunk/libjava/classpath'. > Adding java source files from VM directory /cvs/gcc/trunk/libjava > /tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava > Adding generated files in builddir '..'. > make -f /cvs/gcc/trunk/libjava/classpath/lib/Makefile.gcj \ > GCJ='/tmp/OBJ-1203-1719/gcc/gcj \ > -B/tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava/ \ > -B/tmp/OBJ-1203-1719/gcc/' \ > > compile_classpath='..:/cvs/gcc/trunk/libjava:/tmp/OBJ-1203-1719/i686-pc-linux-gnu/libjava:/cvs/gcc/trunk/libjava/classpath:/cvs/gcc/trunk/libjava/classpath/external/w3c_dom:/cvs/gcc/trunk/libjava/classpath/external/sax:.:' > > \ > top_srcdir=/cvs/gcc/trunk/libjava/classpath > > spawns a recursive make (GNU make 3.80) that consumes some 450MB of memory > and triggers a system load of 12+, basically rendering the machine dead > for about a minute. At first glance looks like a variant of PR 24154. Ian
Re: GMP on IA64-HPUX
On Sun, 4 Dec 2005, FX Coudert wrote: > PS: I'm amazed that a "GNU project" can have exactly two developers, > release source snapshots every two years, adopt the too common attitude > of "every non-i686-linux platform is not mainstream", and so on. There is a difference in focus between the Free Software and Open Source movements. GCC itselfs used to be an example with a closed development process, back in the 90s. On Sun, 4 Dec 2005, Richard Guenther wrote: > If it's really compiler problems, this is one more reason for pulling > gmp to the toplevel gcc, so it can be built with a sane compiler. Indeed. Gerald
identifying c++ aliasing violations
In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran) I discovered one of its c++ source files causes segfaults at optimization levels higher than -O1 unless I add -fno-strict-aliasing to the compile flags. In that case, there program passes all of its testsuite without any segfaults. Unfortunately, the offending source file, dint-node.cc, doesn't result in any warnings with -Wstrict-aliasing. Is there any documentation on how to debug aliasing rule violations in such cases where g++ is unable to produce any warnings? Are there any tutorials or documentation on how to debug such situations? Thanks in advance for any advice. Jack
Re: identifying c++ aliasing violations
On 12/4/05, Jack Howarth <[EMAIL PROTECTED]> wrote: > In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran) > I discovered one of its c++ source files causes segfaults at optimization > levels higher than -O1 unless I add -fno-strict-aliasing to the compile > flags. In that case, there program passes all of its testsuite without > any segfaults. Unfortunately, the offending source file, dint-node.cc, > doesn't result in any warnings with -Wstrict-aliasing. > Is there any documentation on how to debug aliasing rule violations > in such cases where g++ is unable to produce any warnings? Are there any > tutorials or documentation on how to debug such situations? Thanks in > advance for any advice. 4.1 and previous releases do not warn for aliasing issues in C++. Try recent 4.2 snapshots, which have this capability. Maybe we can backport the warning to 4.1. Richard.
c++ speed 3.3/4.0/4.1
In benchmarking a build of xplor-nih (which is a mix of c++,c, and fortran) built entirely under gcc 4.1 or built using gcc 4.1's gfortran and either Apple's gcc 4.0.1 or gcc 3.3, I have noticed that there was a significant speed regression in the c++ code generation between gcc 3.3 and gcc 4.0.x. The 4.0 binaries execute 15% slower (which is why the xplor-nih developer still builds his distributions against g++-3.3 instead of g++-4.0). I was happy to see some recovery in the c++ code generation with gcc 4.1. Now xplor-nih only exhibits a 7% speed loss using g++-4.1 compared to g++-3.3. I assume this is due to the total rewrite of the optimizers in gcc > 4.0. Is there any tricks on can use to coax the c++ performance from the g++ 4.1 to be equivalent to that seen in g++-3.3 or will we have to wait for later versions of gcc for that? Jack
problem with gcc 3.2.2
Dear Sir, I am a student at the American University in Cairo, and I am facing some problems with the gcc version 3.2.2. When installing a package on linux, it tries to compile some files but outputs the following error: /usr/include/c++/3.2.2/bits/fpos.h:60: 'streamoff' is used as a type, but is not defined as a type. This error is followed by many other errors (but I found the same combination of errors a lot when trying to search for a solution on google). I was wondering what the problem was and if there was a known solution to it? Any help would be greatly appreciated. Thank you for your time, Mohamed Ghorab
Re: identifying c++ aliasing violations
Richard, I built current gcc 4.2 branch under MacOS X 10.4.3 and unfortunately while -Wstrict-aliasing does catch the error from PR 14024, it doesn't catch whatever strict aliasing error exists in dint-node.cc of xplor-nih. Is there a list somewhere of all those strict aliasing violations which aren't checked for yet in gcc 4.2? Jack
Re: GNU Classpath development and gcc integration
On Sun, 4 Dec 2005, Mark Wielaard wrote: > We try really hard not to disrupt the normal flow of GCC development. > For any large build/integration changes we contact Mark Mitchell as > release manager, but should probably also more often post a note to the > main gcc list in the future. That would be nice. And we could add the occasional accountment to the gcc.gnu.org frontpage, for example. (I saw that you(?) already raised the issue of adding material to the release notes; that's good PR as well.) > If we somehow fail and we cause any trouble, please do let us know on > the [EMAIL PROTECTED] list. We try very hard to solve any issues asap. Indeed, I'm positively surprised by the quick responses I've been getting! Gerald
Re: identifying c++ aliasing violations
Richard, Actually, while the currently offending file, dint-node.cc which must be built with -fno-strict-aliasing, doesn't report any strict aliasing violations in gcc 4.2, I do find that the rest of xplor-nih is filled with them. I will report these upstream. They seem to all be of the form.. swigpy.cc: In function 'int SWIGPY_Python_ConvertPtr(PyObject*, void**, swig_typ e_info*, int)': swigpy.cc:620: warning: dereferencing type-punned pointer will break strict-alia sing rules swigpy.cc: In function 'PyObject* SWIGPY_Python_NewPointerObj(void*, swig_type_i nfo*, int)': swigpy.cc:707: warning: dereferencing type-punned pointer will break strict-alia sing rules What exactly is the implication of having a hundred or more of this in an application being built with gcc/g++ 4.x at -O3? Does it only risk random crashes in the generated code or does it also impact the quality of the generated code in terms of execution speed? Jack
Re: Documentation for 4.0.2
Hi. > Any chances that the GCC Internals documentation will be updated any > time soon? http://gcc.gnu.org/onlinedocs/gccint/ It looks pretty current to me. > There have been a lot of changes in GCC and it's hard to figure out > the code by reading the old documentation and the new incomplete > 4.0.2 draft. Are you talking about 4.2 or 4.0.2? There is 4.0.2 user documentation online and internals documentation for the current version under development. The GCC project doesn't normally keep internals documentation for older versions online (but it's easy to build it yourself). Ben
Re: c++ speed 3.3/4.0/4.1
On Sun, Dec 04, 2005 at 06:09:54PM -0500, Jack Howarth wrote: > I was happy to see some recovery in the c++ code generation with > gcc 4.1. Now xplor-nih only exhibits a 7% speed loss using g++-4.1 > compared to g++-3.3. I assume this is due to the total rewrite of > the optimizers in gcc > 4.0. Is there any tricks on can use to coax > the c++ performance from the g++ 4.1 to be equivalent to that seen in > g++-3.3 or will we have to wait for later versions of gcc for that? You could try to isolate some inner loops that are slower for 4.1 than 3.3, and submit them as bug reports.
MIPS: comparison modes in conditional branches
Hi,
I am trying to understand why the MIPS backend's handling of
comparison modes seems to be different from what rtl.texi says:
The mode of the comparison operation is independent of the mode
of the data being compared. If the comparison operation is being tested
(e.g., the first operand of an @code{if_then_else}), the mode must be
@code{VOIDmode}.
In the MIPS backend conditional branches based on integer comparisons
are valid only if the mode of the comparison matches the mode of the
operands, e.g. in 64-bit mode (if_then_else (eq:DI (reg:DI 1)
(const_int 0)) ...).
This is relevant because combine could optimize this:
(set (reg:DI 2) (and:DI (reg:DI 1) (const_int 1)))
(set (reg:SI 3) (truncate:SI (reg:DI 2)))
(set (pc) (if_then_else (eq:SI (reg:SI 3) (const_int 0)) ...))
into this:
(set (reg:DI 2) (and:DI (regDI 1) (const_int 1)))
(set (pc) (if_then_else (eq:SI (reg:DI 2) (const_int 0)) ...))
I think this is a valid transformation on MIPS64 too. In fact I
believe that as long as we compare valid SImode or DImode values the
64-bit comparison should work fine.
If I remove the comparison modes from the conditional branch patterns
regression testing on mips64-elf does not show any problem (diff is
attached for reference). When I however compare the assembly output
it is clear that some of the changes are incorrect. This is
a simplified testcase illustrating the problem:
f (long long a)
{
if ((a & 0x) != 0)
abort ();
}
long long a = 0x12345678LL;
main ()
{
f (a);
}
What happens is that combine.c:simplify_comparison noticing the
zero-extension transforms this:
(ne:DI (and:DI (reg:DI 4) (const_int 0x)) (const_int 0))
into this:
(ne:DI (reg:SI 4) (const_int 0))
And now we do allow comparison like this in conditional branches.
On targets where DI->SI mode-switch is not a nop I think the
transformation in simplify_comparison is incorrect. We need an
explicit truncate here to enforce valid SI values:
(ne:DI (truncate:SI (reg:DI 4)) (const_int 0)).
Now if I am correct and this last thing is really a bug then the
obvious question is whether it has anything to do with the more
restrictive form for conditional branches on MIPS64? And of course if
I fix it then whether it would be OK to lift the mode restrictions in
the conditional branch patterns.
Thanks,
Adam
Index: mips.md
===
--- mips.md (revision 107758)
+++ mips.md (working copy)
@@ -4291,7 +4291,7 @@
(define_insn "*branch_zero"
[(set (pc)
(if_then_else
-(match_operator:GPR 0 "comparison_operator"
+(match_operator 0 "comparison_operator"
[(match_operand:GPR 2 "register_operand" "d")
(const_int 0)])
(label_ref (match_operand 1 "" ""))
@@ -4311,7 +4311,7 @@
(define_insn "*branch_zero_inverted"
[(set (pc)
(if_then_else
-(match_operator:GPR 0 "comparison_operator"
+(match_operator 0 "comparison_operator"
[(match_operand:GPR 2 "register_operand" "d")
(const_int 0)])
(pc)
@@ -4333,7 +4333,7 @@
(define_insn "*branch_equality"
[(set (pc)
(if_then_else
-(match_operator:GPR 0 "equality_operator"
+(match_operator 0 "equality_operator"
[(match_operand:GPR 2 "register_operand" "d")
(match_operand:GPR 3 "register_operand" "d")])
(label_ref (match_operand 1 "" ""))
@@ -4353,7 +4353,7 @@
(define_insn "*branch_equality_inverted"
[(set (pc)
(if_then_else
-(match_operator:GPR 0 "equality_operator"
+(match_operator 0 "equality_operator"
[(match_operand:GPR 2 "register_operand" "d")
(match_operand:GPR 3 "register_operand" "d")])
(pc)
