Cross-compiler for Alpha architecture
Dear all, I am trying to build a cross-compiler for an alphaev56-unknown-linux-gnu system, using crosstool-ng. The host is a i686-unknown-linux-gnu. After applying several patches (look in [1]), I managed to build a tool-chain using binutils 2.18/gcc 4.2.3/linux kernel 2.6.24.7 and glibc 2.3.6 (with linuxthreads). However, I would like to use newer versions of gcc (4.3.x) and glibc(>=2.6). Trying to build these, however, yields some errors (initially in glibc and now in gcc). I managed to get as far as described here: http://sourceware.org/ml/libc-help/2008-06/msg00061.html [1] http://sourceware.org/ml/libc-help/2008-06/msg00062.html The errors in [1] are coming from glibc. Ryan Arnold replied with this message: http://sourceware.org/ml/libc-help/2008-06/msg00063.html which solved the first problem described in [1]. However, I now get an error further down in the build procedure, while trying to build gcc 4.3.1 for the target architecture: source='/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c' object='decimal128.o' libtool=no i686-pc-linux-gnu-gcc -I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber -I. -pipe -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -I/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber -I. -c /root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/src/gcc-4.3.1/libdecnumber/dpd/decimal128.c [ALL ]rm -f libdecnumber.a [ALL ]ar cru libdecnumber.a decNumber.o decContext.o decimal32.o decimal64.o decimal128.o [ALL ]i686-pc-linux-gnu-ranlib libdecnumber.a [ALL ]make[1]: Leaving directory `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/libdecnumber' [ALL ]make[1]: Entering directory `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc' [ERROR]make[1]: *** No rule to make target `libgcc.mk'. Stop. [ALL ]make[1]: Leaving directory `/root/Temp/crosstool-ng/crosstool-ng-2008-06-19/targets/alphaev56-unknown-linux-gnu/build/build-cc-core-shared/gcc' [ERROR]Build failed in step 'Installing shared core C compiler' I couldn't find any references to this problem in the mailing list archives and the Web. Any ideas? Thanks for your help! Ioannis
Re: Cross-compiler for Alpha architecture
Hello again, Does no one have any idea about the problem I described in my previous message? Do you need more information to check it? If so, let me know. Thanks! Ioannis
Minor documentation problem
Hello, I downloaded gcc 4.0.1 and created the manual with 'make dvi'. While browsing through it, I noticed the option -ftree-dse, which is mentioned in paragraph 3.1 (Options summary) and in paragraph 3.10 (Options That Control Optimization) under -O1. However, this option is not documented in the manual. What does it do? Thank you, Ioannis
Re: Minor documentation problem
Hello again, Sorry for the late response. Before creating the bug report I though I should search the bugs database and I found that a comment for bug 13756 mentions the missing documentation for -ftree-dse (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13756#c8). Should I still create a new bug report? Thanks, Ioannis Ian Lance Taylor wrote: "Ioannis E. Venetis" <[EMAIL PROTECTED]> writes: I downloaded gcc 4.0.1 and created the manual with 'make dvi'. While browsing through it, I noticed the option -ftree-dse, which is mentioned in paragraph 3.1 (Options summary) and in paragraph 3.10 (Options That Control Optimization) under -O1. However, this option is not documented in the manual. What does it do? It does dead store elimination. To quote from tree-ssa-dce.c: A dead store is a store into a memory location which will later be overwritten by another store without any intervening loads. In this case the earlier store can be deleted. Not describing this option is a documentation bug. If you feel like it, please submit a patch or a bug report (http://gcc.gnu.org/bugzilla/). Thanks. Ian
[gfortran] Problem parsing hexadecimal constants?
Dear all, Firstly, let me say that I don't know that much about Fortran, but I use a source-code transformation tool that creates Fortran 77 code, which I feed to gfortran. During this last stage, gfortran seems to have some problems to parse hexadecimal constants. I managed to reduce the problem to this very simple code: TEST.f: PROGRAM HEX_TEST INTEGER(4) MASK MASK = 'c0'X END ~ $ gfortran -c TEST.f In file TEST.f:5 MASK = 'c0'X 1 Error: Unclassifiable statement at (1) If, however, I make the following change: MASK = X'c0' the program compiles correctly. I remember that I used this tool with g77 too and that I had no problem. Either form of a hexadecimal constant was accepted. The same holds for the Intel compiler. Is this a bug of gfortran or some kind of extension that is not supported? ~ $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.2/configure --prefix=/home/iev/apps/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --disable-nls Thread model: posix gcc version 4.0.2 Best regards, Ioannis
[gfortran] Second try: Problem parsing hexadecimal constants?
I sent this message about a week ago, but didn't get any response. So, I try again. My question is whether this is a bug of gfortran and if I should open a bug report about it. I haven't found this in Bugzilla. Thank you! Dear all, Firstly, let me say that I don't know that much about Fortran, but I use a source-code transformation tool that creates Fortran 77 code, which I feed to gfortran. During this last stage, gfortran seems to have some problems to parse hexadecimal constants. I managed to reduce the problem to this very simple code: TEST.f: PROGRAM HEX_TEST INTEGER(4) MASK MASK = 'c0'X END ~ $ gfortran -c TEST.f In file TEST.f:5 MASK = 'c0'X 1 Error: Unclassifiable statement at (1) If, however, I make the following change: MASK = X'c0' the program compiles correctly. I remember that I used this tool with g77 too and that I had no problem. Either form of a hexadecimal constant was accepted. The same holds for the Intel compiler. Is this a bug of gfortran or some kind of extension that is not supported? ~ $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.2/configure --prefix=/home/iev/apps/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --disable-nls Thread model: posix gcc version 4.0.2 Best regards, Ioannis
Re: Status of -fstack-usage?
Hello, Having followed this thread and searched a little bit more, I understand that -fstack-usage will dump information into a file at compile time. However, I was wondering whether something similar would be possible at run-time. I am working on multithreaded libraries and I know that many multithreaded languages have compilers that calculate the required stack size and pass this information on to the associated library. This way, they can handle efficiently memory. However, this is a problem in standalone libraries. If we could have something like: stack_size = __builtin_stack_size() that returns the maximum required stack size for , multithreaded libraries could take advantage of it at run-time, in order to allocate only the amount of required memory. This is of course not a complete proposal for something, just asking if something like that would be possible at all. Ioannis
Re: Status of -fstack-usage?
I sent the following to Olivier, but forgot to CC this list. Ioannis Hello, Well, it depends :) Would __builtin_stack_size (F) retrieve information about F's stack frame only, or would it also recursively account for every other function that F may call ? Implementing the former is probably possible, though I'm not sure exactly how useful it would be. I agree that the former is probably not very useful. If a function is set to run as a thread and it calls other functions, the stack required for those functions should be accounted for. Probably the second option is much more useful. I had a look here: http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html I think that the best would be __builtin_stack_size(F) to return what is described as "dynamic" and "bounded" in the above link. Maybe a return value of -1 could be used to mean that it was not possible to retrieve this information. A library could then use a default, bigger stack for that thread. Except from recursive functions, what are the other cases where the above size cannot be computed statically? Ioannis
