Handling of builtins
Hello, When handling builtin functions there's the fold_builtin and the expand_builtin that can be defined. They seem to do their work at different times but I am not exactly sure if they are alternatives or complementary. Can't find anywhere explaining their use besides what's found in the internals document. Can anyone have a go at explaining when one or the other should be used? Cheers, -- PMatos
Re: GUPC: A GCC frontend for UPC
Hello Gary, Gary Funck writes: > A GCC front-end (and runtime) for UPC (Unified Parallel C) is available > via the following GCC branch: svn://svn/gcc/branches/gupc. Good to hear! ;-) > The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html. This URL is 404. Thanks, Ludo’.
Re: Handling of builtins
On Wed, Mar 3, 2010 at 10:28 AM, Paulo J. Matos wrote: > Hello, > > When handling builtin functions there's the fold_builtin and the > expand_builtin that can be defined. They seem to do their work at > different times but I am not exactly sure if they are alternatives or > complementary. > > Can't find anywhere explaining their use besides what's found in the > internals document. Can anyone have a go at explaining when one or the > other should be used? They are complementary. The fold_ variants are for simplifications throughout tree passes while the expand_ variant translates builtin calls to target-specific RTL (with falling back to libcalls). Richard. > Cheers, > > -- > PMatos >
Re: GUPC: A GCC frontend for UPC
l...@gnu.org (Ludovic Courtès) writes: >> The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html. > > This URL is 404. Hey Ludovic, it works well here. Can the trailing dot be the problem? Cheers, Giuseppe
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote: > I am highly interestd in implementing C compiler for EFI Byte Code in > gcc and participate in Google Summer Code. > > EFI is a much larger, more complex,OS-like replacement for the older BIOS > firmware interface present in all IBM PC-compatible personal computers. > and the EFI specification provides for a processor-independent device > driver environment(like virtualmachine), called EFI Byte Code or EBC. > > Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI > Byte Code > (http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx) > is not open source, and also a pay software. > > So i am wondering whether this kind of idea is valuable to the gcc > community? or are there any other related ideas is more valuable? There is no reason in principle this shouldn't be part of gcc. I think no-one has responded yet because they don't know what it would be for, and how much work it would involve. Is there an EFI interpreter that is free software? Is this in any way related to plans for a free BIOS? Who would maintain this EFI back-end? ... etc. Andrew.
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
On Mar 3, 2010, at 11:36 AM, Andrew Haley wrote: > On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote: > >> I am highly interestd in implementing C compiler for EFI Byte Code in >> gcc and participate in Google Summer Code. >> >> EFI is a much larger, more complex,OS-like replacement for the older BIOS >> firmware interface present in all IBM PC-compatible personal computers. >> and the EFI specification provides for a processor-independent device >> driver environment(like virtualmachine), called EFI Byte Code or EBC. >> >> Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI >> Byte Code >> (http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx) >> is not open source, and also a pay software. >> >> So i am wondering whether this kind of idea is valuable to the gcc >> community? or are there any other related ideas is more valuable? > > There is no reason in principle this shouldn't be part of gcc. I think the main issue is that EFI C dialect is not ANSI-C compliant: the size of pointer is determined at the run-time and therefore the layout of the structure is not static. Gcc doesn't support this model. Tristan.
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
On 03/03/2010 10:53 AM, Tristan Gingold wrote: > > On Mar 3, 2010, at 11:36 AM, Andrew Haley wrote: > >> On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote: >> >>> I am highly interestd in implementing C compiler for EFI Byte Code in >>> gcc and participate in Google Summer Code. >>> >>> EFI is a much larger, more complex,OS-like replacement for the older BIOS >>> firmware interface present in all IBM PC-compatible personal computers. >>> and the EFI specification provides for a processor-independent device >>> driver environment(like virtualmachine), called EFI Byte Code or EBC. >>> >>> Intel(R) C Compiler for EFI Byte Code, the only one C compiler for EFI >>> Byte Code >>> (http://sx.intel.com/p-553-intel-c-compiler-for-efi-byte-code.aspx) >>> is not open source, and also a pay software. >>> >>> So i am wondering whether this kind of idea is valuable to the gcc >>> community? or are there any other related ideas is more valuable? >> >> There is no reason in principle this shouldn't be part of gcc. > > I think the main issue is that EFI C dialect is not ANSI-C compliant: the > size of pointer is determined > at the run-time and therefore the layout of the structure is not static. Gcc > doesn't support this model. Ouch. That does sound difficult. Andrew.
Re: Bootstraping i686-linux gcc on x86_64-linux fails during libgcc stage1 on trunk
On Tue, 2010-03-02 at 16:34 -0800, H.J. Lu wrote: > On Tue, Mar 2, 2010 at 4:18 PM, Laurent GUERBY wrote: > > Hi, > > > > I'm trying to build a fully 32 bits GCC on a x86_64-linux 64 bits debian > > system which has all the 32 bits libraries installed (this is for the > > GCC compile farm testers). > > > > I've played with various things including --with-ld= and putting a fake > > "ld" script in PATH but something is hardcoding "/usr/bin/ld" and at the > > end of stage1 it always fails to link libgcc, after having successfully > > built a 32 bits cc1 & friends. > > > > crti.o & friends in 32 bits are in /usr/lib32 on this system. > > > > What am I doing wrong? Is there a way to tell libgcc build to > > use ld the right way? > > > > I don't know about Debian. I can bootstap ia32 gcc trunk on Fedora/x86-64 > with > > # CC="gcc -m32" CXX="g++ -m32" ../src-trunk/configure \ > --enable-clocale=gnu --with-system-zlib --enable-shared --with-d > emangler-in-ld --with-fpmath=sse i686-linux > > CC="gcc -m32" CXX="g++ -m32" is the key. After investigation Fedora x86_64 has 32bits libs in /lib and 64bits in /lib64 whereas Debian has 32 bits libs in /lib32 and 64bits in /lib that explains the difference we see. Laurent
Re: Bootstraping i686-linux gcc on x86_64-linux fails during libgcc stage1 on trunk
On Wed, 2010-03-03 at 00:33 +, Joseph S. Myers wrote:
> On Wed, 3 Mar 2010, Laurent GUERBY wrote:
>
> > $ ../trunk/configure --prefix=/n/100/guerby/install-trunk
> > --enable-languages=c --enable-__cxa_atexit --disable-nls
> > --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.2-32
> > --with-gmp=/opt/cfarm/gmp-4.2.4-32 --with-mpc=/opt/cfarm/mpc-0.8-32
> > --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
> > --disable-multilib
>
> The logic to use lib32 on Debian/Ubuntu is only in t-linux64, so you need
> to build --enable-targets=all for this to work. (I don't know whether
> --enable-targets=all --disable-multilib works; it doesn't really make
> logical sense, but might in fact cause the MULTILIB_OSDIRNAMES
> configuration to take effect with none of the rest of the multilib
> configuration.)
Thanks! --enable-targets=all --disable-multilib did the trick on debian:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00241.html
And the installed compiler works as expected, now trying
with more languages. I checked the generated multilib.h
and it has all the definitions plus DISABLE_MULTILIB
defined, see below.
I don't know if configure could do better here.
Sincerely,
Laurent
gue...@debian:~/build1$ cat ./gcc/multilib.h
static const char *const multilib_raw[] = {
". !m64 !m32;",
".:../lib64 m64 !m32;",
".:../lib32 !m64 m32;",
NULL
};
static const char *const multilib_matches_raw[] = {
"m64 m64;",
"m32 m32;",
NULL
};
static const char *multilib_extra = "";
static const char *const multilib_exclusions_raw[] = {
NULL
};
static const char *multilib_options = "m64/m32";
#define DISABLE_MULTILIB 1
Re: GUPC: A GCC frontend for UPC
Hi, Giuseppe Scrivano writes: > l...@gnu.org (Ludovic Courtès) writes: > >>> The GUPC project is described here: http://gcc.gnu.org/projects/gupc.html. >> >> This URL is 404. > > Hey Ludovic, it works well here. Works for me now, don’t know what happened. Thanks, Ludo’.
