Re: Porting GCC to RDOS and C++ issues
Mike Stump: > make will build libgcc for the target, specifically, you should be > able to cd gcc && make libgcc.a to build it. It did when I added --host=rdos to the configuration script and changed a couple of other files. My only current problem is that since RDOS uses the .exe suffix for executables, the xgcc cross-compiler is named xgcc.exe, even though it is a Linux executable. This problem is fixed by copying this file to xgcc (no extension), and re-starting the make process. I don't know if this is a bug in some scripts, or it is some misconfiguration on my part. The system should know that Linux executables never have an .exe extension. After this build is complete, there is a gcclib.a file in the rdos-host directory. When I install it, however, the gcclib.a file isn't copied to /usr/local/rdos/lib, like the other libraries from the build without --host=rdos, but in another directory. I fixed this by copying the file to the correct location. I then linked a fairly large C++ executable that works in BC 4.52 format, and it works as an ELF-executable. However, I wonder why I had to explicitly include crt0.o, libc.a and some other files that ld finds automatically for C-executables. Maybe I shouldn't use g++ as a compiler but gcc? > If your port doesn't use dwarf for EH, then it won't build that file, > but then again, there will be (should be) no unresolved references to > _Unwind_Resume if that were the case. It works, but I haven't tested the exception-handling code yet. Leif Ekblad
Installing GCC 4.1-20051223 on FreeBSD 6 failed
I'm trying to install the GCC 4.1 snapshot from Dec 23, 2005 on my FreeBSD box. I'm trying to try out gcj. The installation fails, complaining about not enough virtual memory. I just added another 2GB swap file on this box. I now have 1GB of physical RAM and 4GBs of swap. And that's not enough?! What do I need to do to get gcj and libjava to install? Is this a problem with GNU make or GCC? Thanks! Jon Brisbin Webmaster NPC International, Inc.
Re: Installing GCC 4.1-20051223 on FreeBSD 6 failed
Update: Just tarred everything up and stuck it on one of my servers, which has 4GBs of physical RAM and 2GBs of swap. Same problem: "virtual memory exhausted". If 6GBs isn't enough, then I'm out of ideas. I tried patching make with a patch I found on the make ML archives. No dice. Checked out make from CVS but the build is horribly broken (missing .po files and other such garbage). What do I do now? Thanks! Jon Brisbin Webmaster NPC International, Inc. Jon Brisbin wrote: I'm trying to install the GCC 4.1 snapshot from Dec 23, 2005 on my FreeBSD box. I'm trying to try out gcj. The installation fails, complaining about not enough virtual memory. I just added another 2GB swap file on this box. I now have 1GB of physical RAM and 4GBs of swap. And that's not enough?! What do I need to do to get gcj and libjava to install? Is this a problem with GNU make or GCC? Thanks! Jon Brisbin Webmaster NPC International, Inc.
Re: Installing GCC 4.1-20051223 on FreeBSD 6 failed
On Fri, Dec 30, 2005 at 10:53:43AM -0600, Jon Brisbin wrote: > Update: > > Just tarred everything up and stuck it on one of my servers, which has > 4GBs of physical RAM and 2GBs of swap. Same problem: "virtual memory > exhausted". If 6GBs isn't enough, then I'm out of ideas. > > I tried patching make with a patch I found on the make ML archives. No > dice. Checked out make from CVS but the build is horribly broken I am assuming that you have applied my make patch. Even with my make patch applied, make still uses lots of memory. Please make sure your memory limit is big enough. I have bash-3.00$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 16372 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 16372 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited H.J.
Re: Installing GCC 4.1-20051223 on FreeBSD 6 failed
A bug in FreeBSD's malloc? http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-December/005125.html On Fri, Dec 30, 2005 at 10:53:43AM -0600, Jon Brisbin wrote: > Update: > > Just tarred everything up and stuck it on one of my servers, which has > 4GBs of physical RAM and 2GBs of swap. Same problem: "virtual memory > exhausted". If 6GBs isn't enough, then I'm out of ideas. > > I tried patching make with a patch I found on the make ML archives. No > dice. Checked out make from CVS but the build is horribly broken __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
Re: Installing GCC 4.1-20051223 on FreeBSD 6 failed
What parameter do I put into loader.conf to do that? I did some googling and the kern.maxdsiz parameter I found a reference to didn't work. Where do I find that information? If I were going to compile it with the Doug Lea malloc, would I need to recompile GCC? Thanks! Jon Brisbin Webmaster NPC International, Inc. H. J. Lu wrote: On Fri, Dec 30, 2005 at 10:53:43AM -0600, Jon Brisbin wrote: Update: Just tarred everything up and stuck it on one of my servers, which has 4GBs of physical RAM and 2GBs of swap. Same problem: "virtual memory exhausted". If 6GBs isn't enough, then I'm out of ideas. I tried patching make with a patch I found on the make ML archives. No dice. Checked out make from CVS but the build is horribly broken I am assuming that you have applied my make patch. Even with my make patch applied, make still uses lots of memory. Please make sure your memory limit is big enough. I have bash-3.00$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 16372 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 16372 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited H.J.
RFC: An option to link against static gcc libraries
Gcc build executable linking against dynamic libraries by default. "-static" will link against all static libraries. For run-time portability, we may want to link against static gcc libraries, like libstdc++.a, libgfortran.a, libgcj.a, , but against dynamic system libraries, when we building executables. Currently, there is no easy way to do it. We have -static-libgcc for libgcc.a. It will be nice to have -static-gcclibs or something like that, to link against static gcc libraries. H.J.
Re: RFC: An option to link against static gcc libraries
On Dec 30, 2005, at 1:53 PM, H. J. Lu wrote: Gcc build executable linking against dynamic libraries by default. "-static" will link against all static libraries. For run-time portability, we may want to link against static gcc libraries, like libstdc++.a, libgfortran.a, libgcj.a, , but against dynamic system libraries, when we building executables. Currently, there is no easy way to do it. We have -static-libgcc for libgcc.a. It will be nice to have -static-gcclibs or something like that, to link against static gcc libraries. One, this will not work at all libobjc or libgcj since they require lookups at runtime. -- Pinski
Re: RFC: An option to link against static gcc libraries
On Fri, Dec 30, 2005 at 01:56:16PM -0500, Andrew Pinski wrote: > > On Dec 30, 2005, at 1:53 PM, H. J. Lu wrote: > > >Gcc build executable linking against dynamic libraries by default. > >"-static" will link against all static libraries. For run-time > >portability, we may want to link against static gcc libraries, like > >libstdc++.a, libgfortran.a, libgcj.a, , but against dynamic system > >libraries, when we building executables. Currently, there is no easy > >way to do it. We have -static-libgcc for libgcc.a. It will be nice to > >have -static-gcclibs or something like that, to link against static > >gcc libraries. > > One, this will not work at all libobjc or libgcj since they > require lookups at runtime. Are you saying "gcc -static" doesn't work with libobjc and libgcj? H.J.
Re: RFC: An option to link against static gcc libraries
On Dec 30, 2005, at 1:58 PM, H. J. Lu wrote: Are you saying "gcc -static" doesn't work with libobjc and libgcj? Yes, they have never really worked. You need to cause to import all of the .a file instead of just letting the linker link in the parts that it says it needs. -- Pinski
Re: RFC: An option to link against static gcc libraries
On Fri, Dec 30, 2005 at 10:58:16AM -0800, H. J. Lu wrote: > > One, this will not work at all libobjc or libgcj since they > > require lookups at runtime. > > Are you saying "gcc -static" doesn't work with libobjc and libgcj? It certainly doesn't work with libgcj (well, you can link in libgcj.a, but it will almost certainly never work right, for some programs --whole-archive helps a bit, but for most programs doesn't). That's why Fedora stopped including any Java .a libraries many months ago. Jakub
Re: RFC: An option to link against static gcc libraries
H. J. Lu wrote: On Fri, Dec 30, 2005 at 01:56:16PM -0500, Andrew Pinski wrote: On Dec 30, 2005, at 1:53 PM, H. J. Lu wrote: Gcc build executable linking against dynamic libraries by default. "-static" will link against all static libraries. For run-time portability, we may want to link against static gcc libraries, like libstdc++.a, libgfortran.a, libgcj.a, , but against dynamic system libraries, when we building executables. Currently, there is no easy way to do it. We have -static-libgcc for libgcc.a. It will be nice to have -static-gcclibs or something like that, to link against static gcc libraries. One, this will not work at all libobjc or libgcj since they require lookups at runtime. Are you saying "gcc -static" doesn't work with libobjc and libgcj? I think that is what he is saying. For the general case it is true. However that does not mean that it is not a useful option. For the libgcj case, if you know what you are doing and you do not need all the features of libgcj, static linking can be advantageous. I would much rather do 'gcj -static-gcclibs' flag than do this: 'gcc -shared-libgcc -Wl,-non_shared -lgcj -Wl,-call_shared \ -lsupc++ -Wl,--as-needed -lz -lgcc_s -lpthread -lc -lm -ldl \ -Wl,--no-as-needed' Note that this is not a hypothetical case. That is my actual linker command line. David Daney.
Re: RFC: An option to link against static gcc libraries
On Fri, Dec 30, 2005 at 08:05:13PM +0100, Jakub Jelinek wrote: > On Fri, Dec 30, 2005 at 10:58:16AM -0800, H. J. Lu wrote: > > > One, this will not work at all libobjc or libgcj since they > > > require lookups at runtime. > > > > Are you saying "gcc -static" doesn't work with libobjc and libgcj? > > It certainly doesn't work with libgcj (well, you can link in libgcj.a, > but it will almost certainly never work right, for some programs > --whole-archive helps a bit, but for most programs doesn't). > That's why Fedora stopped including any Java .a libraries many > months ago. > Then, "gcc -static-gcclibs" will work the same as "gcc -static", except for not linking against static system libraries. It is still useful for C++ and FORTRAN. H.J.
Re: Hack in gcc/c-decl.c?
On Dec 29, 2005, at 2:20 PM, Domagoj D wrote:
In the case anybody cares about code verifiability... It's
exteremely hard
to automatically prove the correctness of the code that uses pointer
arithmetic and casts as in the example above.
It is but a couple of trivial rules that one should have anyway...
Proving more interesting properties like
enum ftype tx;
float fx;
... (assign to tx and fx)
assert(get_coef(set_coef(tx, fx)) == fx);
would be even harder.
Trivial enough for the compiler. The only stumbling block might be
caused by the failure to inline the indirect call to offset. Seems
trivial enough to fix up:
static inline int zero() { return 0; }
int bar() {
int (*func)() = zero;
return func();
}
currently gives:
_zero:
li r3,0
blr
_bar:
b _zero
which, as I read it, is trivial. Notice that in:
enum ftype {T1, T2, T3};
static struct coefs {
float c[3];
int (*offset_callback)(enum ftype t);
} filter_s;
static inline int offset(enum ftype t) __attribute__((pure,const));
inline int offset(enum ftype t) {
int off = 0;
switch (t) {
case T1: return off;
case T2: return off + sizeof(float);
case T3: return off + 2*sizeof(float);
}
}
static inline void init(void) {
filter_s.offset_callback = offset;
}
static inline float get_coef(enum ftype t) {
return *(float *)((char *)&filter_s + filter_s.offset_callback(t));
}
static inline enum ftype set_coef(enum ftype t, float val) {
*(float *)((char *)&filter_s + filter_s.offset_callback(t)) = val;
return t;
}
void foo();
void boo() {
enum ftype tx;
float fx;
fx = 1.0;
tx = T1;
init();
if (filter_s.offset_callback != offset)
if (get_coef(set_coef(tx, fx)) != fx)
foo();
}
there is no call to foo. If one removes the != offset conditional
and works around the lack of the inlining I pointed out by calling
offset directly, there still is no call to foo. If the compiler can
prove something, I'd expect and hope that a system built to prove
things would not be worse. What the compiler doesn't do, is prove
the general property, rather, given a specific value for tx, it can
prove equality, but it doesn't need a specific value of fx to do this.
[gnu.org #247501] Submitting to the Gnu Project
Hello, This email is to follow up on your communication with the Free Software Foundation. Previously, you had expressed interest in contributing to the GNU Project. If this is still the case please respond so that we can move the process along. If you did not receive the assignment please let us know and we will cheerfully mail out another. If you need an employer disclaimer and did not receive one via email we will forward you a copy. I apologize if this email reached you in error, but please let me know so that I may remove you from the record. It too is possible that you have completed your assignment process with the FSF, but have yet to be removed from the list of outstanding assignments. If this is the case please let me know so that I can update the record. All the best, Jonas Jacobson Copyright Administrator Free Software Foundation 51 Franklin Street, Fifth Floor Boston, MA 02110 Phone +1-617-542-5942 Fax +1-617-542-2652
gcc-4.1-20051230 is now available
Snapshot gcc-4.1-20051230 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051230/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109181 You'll find: gcc-4.1-20051230.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051230.tar.bz2 C front end and core compiler gcc-ada-4.1-20051230.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051230.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051230.tar.bz2 C++ front end and runtime gcc-java-4.1-20051230.tar.bz2 Java front end and runtime gcc-objc-4.1-20051230.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051230.tar.bz2The GCC testsuite Diffs from 4.1-20051223 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
tree-ssa alias constraints
I noticed that we add a constraint for each variable that is assigned
to the
return value of a function call even though that information is useless
for
non pointers? Is there a reason why we do this?
For the following C file:
int f(void);
int g(void)
{
int y = f();
int x = f();
return y+x;
}
We get in alias1:
Points-to analysis
Constraints:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
D.1515_1 = &ANYTHING
D.1516_3 = &ANYTHING
Points-to sets
NULL = { }
ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
D.1515_1 = { ANYTHING }
D.1516_3 = { ANYTHING }
g: Total number of aliased vops: 0
It seems like we are spending extra time to try to figure out the
constraints
on these variables than what we should be doing.
The reason for this processing is the following code in
tree-ssa-structalias.c:
/* Only care about operations with pointers, structures
containing pointers, dereferences, and call expressions.
*/
if (POINTER_TYPE_P (TREE_TYPE (lhsop))
|| AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
|| TREE_CODE (rhsop) == CALL_EXPR)
Or I am missing that a constraint that can happen?
Thanks,
Andrew Pinski
