RE: gcc4.5.0/libiberty/pex-common.h missing pid_t on vms
> Use #ifdef HAVE_UNISTD_H instead. There are many examples in > libiberty. > > Ian Thanks Ian, that worked. --- /src/orig/gcc-4.5.0/libiberty/pex-common.h 2009-04-13 03:45:58.0 -0700 +++ /src/gcc-4.5.0/libiberty/pex-common.h 2010-05-04 06:43:24.0 -0700 @@ -31,6 +31,9 @@ #if !defined(pid_t) && defined(HAVE_SYS_TYPES_H) #include #endif +#ifdef HAVE_UNISTD_H +#include +#endif #define install_error_msg "installation problem, cannot exec `%s'" Perhaps someone can apply it.. Sorry, not me. - Jay
RE: gcc 4.5.0 libiberty .o vs. .obj confusion
> CC: gcc@ > From: iant@ > > Jay: >> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to >> $(OBJEXT). > > Yes. > > Ian Thanks. Specifically ".o" goes to "@objext@". There's no way I'm going to be able to get "the papers" in. I can try to squeak by via triviality of change. I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c, vms-crtl.h), but this did work for me, attached. It's many lines, but highly mechanical. There are a few places where ".o" occurs in comments, can be left alone. There is: .c.o: false > .c.obj: > false and < -rm -rf *.o pic core errs \#* *.E a.out > -rm -rf *.o *.obj pic core errs \#* *.E a.out and I wrapped the affected lines to one file per line, and spaces instead of tabs (consistent rendering) - Jay 119a120,122 > .c.obj: > false > 160,178c163,213 < REQUIRED_OFILES = \ < ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o\ < ./alloca.o ./argv.o \ < ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o \ < ./dyn-string.o \ < ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o\ < ./fnmatch.o ./fopen_unlocked.o \ < ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o\ < ./hashtab.o ./hex.o \ < ./lbasename.o ./lrealpath.o \ < ./make-relative-prefix.o ./make-temp-file.o \ < ./objalloc.o ./obstack.o\ < ./partition.o ./pexecute.o ./physmem.o \ < ./pex-common.o ./pex-one.o @pexecute@ \ < ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o \ <./strsignal.o \ < ./unlink-if-ordinary.o \ < ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o \ <./xstrerror.o ./xstrndup.o --- > REQUIRED_OFILES = \ > ./reg...@objext@\ > ./cplus-d...@objext@\ > ./cp-demang...@objext@ \ > ./m...@objext@ \ > ./sh...@objext@ \ > ./allo...@objext@ \ > ./ar...@objext@ \ > ./choose-te...@objext@ \ > ./conc...@objext@ \ > ./cp-demi...@objext@\ > ./crc...@objext@\ > ./dyn-stri...@objext@ \ > ./fdmat...@objext@ \ > ./fibhe...@objext@ \ > ./filename_c...@objext@ \ > ./floatform...@objext@ \ > ./fnmat...@objext@ \ > ./fopen_unlock...@objext@ \ > ./geto...@objext@ \ > ./getop...@objext@ \ > ./getp...@objext@ \ > ./getrunti...@objext@ \ > ./hasht...@objext@ \ > ./h...@objext@ \ > ./lbasena...@objext@\ > ./lrealpa...@objext@\ > ./make-relative-pref...@objext@ \ > ./make-temp-fi...@objext@ \ > ./objall...@objext@ \ > ./obsta...@objext@ \ > ./partiti...@objext@\ > ./pexecu...@objext@ \ > ./physm...@objext@ \ > ./pex-comm...@objext@ \ > ./pex-o...@objext@ \ > @pexecute@ \ > ./safe-cty...@objext@ \ > ./so...@objext@ \ > ./spac...@objext@ \ > ./splay-tr...@objext@ \ > ./strerr...@objext@ \ > ./strsign...@objext@\ > ./unlink-if-ordina...@objext@ \ > ./xatex...@objext@ \ > ./xex...@objext@\ > ./xmall...@objext@ \ > ./xmemd...@objext@ \ > ./xstrd...@objext@ \ > ./xstrerr...@objext@\ > ./xstrnd...@objext@ 183,203c218,276 < CONFIGURED_OFILES = ./asprintf.o ./atexit.o \ < ./basename.o ./bcmp.o ./bcopy.o ./bsearch.o ./bzero.o \ < ./calloc.o ./clock.o ./copysign.o \ < ./_doprnt.o \ < ./ffs.o \ < ./getcwd.o ./getpagesize.o ./gettimeofday.o \ < ./index.o ./insque.o\ < ./memchr.o ./memcmp.o ./memcpy.o ./memmem.o ./memmove.o \ <./mempcpy.o ./memset.o ./mkstemps.o\ < ./pex-djgpp.o ./pex-msdos.o \ <./pex-unix.o ./pex-win32.o \ <./putenv.o \ < ./random.o ./rename.o ./rindex.o\ < ./setenv.o ./sigsetmask.o ./snprintf.o ./stpcpy.o ./stpncpy.o \ <./strcasecm
RE: gcc 4.5.0 libiberty .o vs. .obj confusion
oops, also need like:
--- /src/orig/gcc-4.5.0/libiberty/configure 2010-01-04 15:46:56.0
-0800
+++ /src/gcc-4.5.0/libiberty/configure 2010-05-05 05:40:52.0 -0700
@@ -6533,10 +6533,10 @@
# Figure out which version of pexecute to use.
case "${host}" in
- *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.o ;;
- *-*-msdosdjgpp*) pexecute=./pex-djgpp.o ;;
- *-*-msdos*) pexecute=./pex-msdos.o ;;
- *) pexecute=./pex-unix.o ;;
+ *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.$ac_objext ;;
+ *-*-msdosdjgpp*) pexecute=./pex-djgpp.$ac_objext ;;
+ *-*-msdos*) pexecute=./pex-msdos.$ac_objext ;;
+ *) pexecute=./pex-unix.$ac_objext ;;
esac
--- /src/orig/gcc-4.5.0/libiberty/configure.ac 2010-01-04 15:46:56.0
-0800
+++ /src/gcc-4.5.0/libiberty/configure.ac 2010-05-05 05:45:47.0 -0700
@@ -671,10 +671,10 @@
# Figure out which version of pexecute to use.
case "${host}" in
- *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.o ;;
- *-*-msdosdjgpp*) pexecute=./pex-djgpp.o ;;
- *-*-msdos*) pexecute=./pex-msdos.o ;;
- *) pexecute=./pex-unix.o ;;
+ *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.$ac_objext ;;
+ *-*-msdosdjgpp*) pexecute=./pex-djgpp.$ac_objext ;;
+ *-*-msdos*) pexecute=./pex-msdos.$ac_objext ;;
+ *) pexecute=./pex-unix.$ac_objext ;;
esac
AC_SUBST(pexecute)
I manually edited configure.
I don't know how to keep multiple versions of autoconf installed/working, other
than to use Cygwin and its special packages dedicated to this problem.
configure.ac:3: error: Autoconf version 2.64 or higher is required
configure.ac:3: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
jbook2:libiberty jay$
- Jay
> From: jay.krell@
> To: i...@m
> CC: g...@g
> Subject: RE: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Wed, 5 May 2010 10:10:15 +
>
>
>> CC: gcc@
>> From: iant@
>>
>> Jay:
>>> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
>>> $(OBJEXT).
>>
>> Yes.
>>
>> Ian
>
> Thanks.
>
> Specifically ".o" goes to "@objext@".
>
> There's no way I'm going to be able to get "the papers" in.
> I can try to squeak by via triviality of change.
> I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c,
> vms-crtl.h), but this did work for me, attached.
> It's many lines, but highly mechanical.
> There are a few places where ".o" occurs in comments, can be left alone.
> There is:
>
> .c.o:
> false
>
>> .c.obj:
>>false
>
>
> and
> <-rm -rf *.o pic core errs \#* *.E a.out
>
>>-rm -rf *.o *.obj pic core errs \#* *.E a.out
>
>
> and I wrapped the affected lines to one file per line, and spaces instead of
> tabs (consistent rendering)
>
>
> - Jay
>
more .o vs. .obj targeting VMS
Here's the next one: alpha-dec-vms-ar cru libdecnumber.a decNumber.o decContext.o decimal32.o decimal64.o decimal128.o alpha-dec-vms-ar: decNumber.o: No such file or directory make[2]: *** [libdecnumber.a] Error 1 make[1]: *** [all-libdecnumber] Error 2 make: *** [all] Error 2 jbook2:vms jay$ ls libdecnumber/ Makefile config.log decNumber.obj decimal64.obj config.cache config.status decimal128.obj gstdint.h config.h decContext.obj decimal32.obj stamp-h1 - Jay
Adding function calls before and after a CALL_EXPR
Hi
I am trying to add two function calls before and after a CALL_EXPR
To do this I use bsi_insert_before and bsi_insert_after
But I am having an issue having both of these working in the same pass.
I can make bsi_insert_before or bsi_insert_after work independently.
To make them work together I use
if (fndecl)
{
bsi_insert_before (&block_iterator1, fndecl, BSI_SAME_STMT);
}
if (fndecl2)
{
bsi_insert_after (&block_iterator1, fndecl2, BSI_NEW_STMT);
}
in the basic block iterator loop
Can someone suggest what may be going wrong?
--
Regards,
Saleel Kudchadker
Graduate Student
School of Computing , Informatics and Decision Systems
Arizona State University
Building GCC & CFLAGS settings
I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS) setting that causes GCC to generate code that is not compatibile with the default GCC output. Basically, I am building GCC on ia64-hp-hpux11.31 where I set CFLAGS and CXXFLAGS to "-mlp64" to generate 64 bit code instead of the default 32 bit code. During the build libiberty is built in 64 bit mode but then the object files that go into genmodes (genmodes.o, errors.o, etc) are compiled without using CFLAGS and the link of genmodes fails because genmodes.o and errors.o are in 32 bit mode and libiberty is in 64 bit mode. I have tried setting CFLAGS_FOR_BUILD and ALL_CFLAGS but these didn't have any affect. Is there a flag that I am missing or is this a bug in the build process? This problem only seems to occur when I am doing a bootstrap build, if I use --disable-bootstrap and build all-gcc then I don't have this problem. Steve Ellcey s...@cup.hp.com
Re: more .o vs. .obj targeting VMS
Hello Jay, * Jay K wrote on Wed, May 05, 2010 at 06:11:29PM CEST: > Here's the next one: > > alpha-dec-vms-ar cru libdecnumber.a decNumber.o decContext.o decimal32.o > decimal64.o decimal128.o > alpha-dec-vms-ar: decNumber.o: No such file or directory > make[2]: *** [libdecnumber.a] Error 1 > make[1]: *** [all-libdecnumber] Error 2 > make: *** [all] Error 2 I don't think a build system maintainer is likely to look at a stream of messages about unconfirmed build system errors on this list, for two reasons: people are too busy to follow them, and a week later, collecting messages is tiresome. Since you cannot provide patches yourself, I suggest you collect the issues (or at least all of those that you have found already), open one bugzilla report and list them all there. Feel free to Cc: me in the bugzilla, but I can't promise whether and when I have time to look at it. Thanks, Ralf
Re: Building GCC & CFLAGS settings
On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote: > > I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS) setting > that causes GCC to generate code that is not compatibile with the default > GCC output. Basically, I am building GCC on ia64-hp-hpux11.31 where I set > CFLAGS and CXXFLAGS to "-mlp64" to generate 64 bit code instead of the > default 32 bit code. During the build libiberty is built in 64 bit mode but > then the object files that go into genmodes (genmodes.o, errors.o, etc) are > compiled without using CFLAGS and the link of genmodes fails because > genmodes.o and errors.o are in 32 bit mode and libiberty is in 64 bit mode. > I am using # CC="gcc -m32" CXX="g++ -m32" ./configure to bootstrap 32bit gcc on 64bit Linux. -- H.J.
Re: Building GCC & CFLAGS settings
On 05/05/2010 07:42 PM, H.J. Lu wrote:
On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote:
I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS) setting
that causes GCC to generate code that is not compatibile with the default
GCC output.
I am using
# CC="gcc -m32" CXX="g++ -m32" ./configure
to bootstrap 32bit gcc on 64bit Linux.
Out of curiosity, H.J.Lu, is it for performance reasons (like eg.
bootstrapping in 32 bits mode is faster) or is it for testing reasons
(like you are working on x86 32 bits backend)?
I was imagining that bootstrapping in 64 bits mode would be faster (more
registers at run time of the compiler and less pressure on the register
allocator at compile time of the compiler)
When I was bootstrapping a 32 bits GCC, I used to do that in a chroot-ed
environment (containing a minimal debian x86 32bits distro).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Building GCC & CFLAGS settings
On Wed, May 5, 2010 at 12:41 PM, Basile Starynkevitch wrote: > On 05/05/2010 07:42 PM, H.J. Lu wrote: >> >> On Wed, May 5, 2010 at 10:18 AM, Steve Ellcey wrote: >>> >>> I was wondering if anyone has built GCC using a CFLAGS (and CXXFLAGS) >>> setting >>> that causes GCC to generate code that is not compatibile with the default >>> GCC output. >> >> I am using >> >> # CC="gcc -m32" CXX="g++ -m32" ./configure >> >> to bootstrap 32bit gcc on 64bit Linux. >> > > Out of curiosity, H.J.Lu, is it for performance reasons (like eg. > bootstrapping in 32 bits mode is faster) or is it for testing reasons (like > you are working on x86 32 bits backend)? > This is to test 32bit host wide integer on 64bit host. -- H.J.
Re: Building GCC & CFLAGS settings
On 05/05/2010 18:18, Steve Ellcey wrote: > During the build libiberty is built in 64 bit mode But *which* libiberty? Host, build, or target? > if I use --disable-bootstrap and build all-gcc then I don't have this problem. This could be an interaction with the cross-compile mechanism, maybe? cheers, DaveK
where are caller-save addresses legitimized?
reload() > setup_save_areas() > assign_stack_local_1() creates a mem address whose offset too large to fit into the machine insn's offset operand. Later, reload() > save_call_clobbered_regs() > insert_save() > adjust_address_1() > change_address_1() asserts because the address is not legitimate. My port defines all the address legitimizing target hooks, but none are called with the address in question. Where/how is the address supposed to be fixed-up in this case? Or, where/how does gcc avoid producing an illegitimate address in the first place? G
Re: Building GCC & CFLAGS settings
On Thu, 2010-05-06 at 00:36 +0100, Dave Korn wrote: > On 05/05/2010 18:18, Steve Ellcey wrote: > > > During the build libiberty is built in 64 bit mode > > But *which* libiberty? Host, build, or target? That is a good question. I am building in obj and I have: obj/libiberty/libiberty.a - ELF-32 obj/build-ia64-hp-hpux11.31/libiberty/libiberty.a - ELF-64 It looks like I am using the correct one, the one from build-ia64-hp-hpux11.31, and that is 64 bit ELF which I would expect since I set CFLAGS and CXXFLAGS to -mlp64. I think the problem is that the rest of the build objects are not 64 bits. $ file obj/gcc/build/*.o obj/gcc/build/errors.o: ELF-32 relocatable object file - IA64 obj/gcc/build/genmodes.o: ELF-32 relocatable object file - IA64 If I am building with CFLAGS and CXXFLAGS set to generate 64 bit code, why are these objects 32 bits? HJ seems to have the way to make it work, set CC to 'gcc -mlp64' instead of setting CC to 'gcc' and CFLAGS to '-mlp64' but that seems a bit counter-intuitive to the meaning of the flags. Steve Ellcey s...@cup.hp.com
Re: where are caller-save addresses legitimized?
On 05/05/10 17:45, Greg McGary wrote: reload() > setup_save_areas() > assign_stack_local_1() creates a mem address whose offset too large to fit into the machine insn's offset operand. Later, reload() > save_call_clobbered_regs() > insert_save() > adjust_address_1() > change_address_1() asserts because the address is not legitimate. My port defines all the address legitimizing target hooks, but none are called with the address in question. Where/how is the address supposed to be fixed-up in this case? Or, where/how does gcc avoid producing an illegitimate address in the first place? I'm not sure they are ever legitimized -- IIRC caller-save tries to only generate addressing modes which are safe for precisely this reason. Jeff
Re: where are caller-save addresses legitimized?
On 05/05/10 20:21, Jeff Law wrote: On 05/05/10 17:45, Greg McGary wrote: reload()> setup_save_areas()> assign_stack_local_1() creates a mem address whose offset too large to fit into the machine insn's offset operand. Later, reload()> save_call_clobbered_regs()> insert_save() adjust_address_1()> change_address_1() asserts because the address is not legitimate. My port defines all the address legitimizing target hooks, but none are called with the address in question. Where/how is the address supposed to be fixed-up in this case? Or, where/how does gcc avoid producing an illegitimate address in the first place? I'm not sure they are ever legitimized -- IIRC caller-save tries to only generate addressing modes which are safe for precisely this reason. Apparently not so: caller save is quite capable of producing invalid offsets. Perhaps my port needs some hook to help GCC produce good addresses? I've been looking, but haven't found it yet... G
Re: where are caller-save addresses legitimized?
On 05/05/10 21:34, Greg McGary wrote: On 05/05/10 20:21, Jeff Law wrote: I'm not sure they are ever legitimized -- IIRC caller-save tries to only generate addressing modes which are safe for precisely this reason. Apparently not so: caller save is quite capable of producing invalid offsets. Perhaps my port needs some hook to help GCC produce good addresses? I've been looking, but haven't found it yet... Try != successful :( You might want to look at his code in init_caller_save: /* The following code tries to approximate the conditions under which we can easily save and restore a register without scratch registers or other complexities. It will usually work, except under conditions where the validity of an insn operand is dependent on the address offset. No such cases are currently known. We first find a typical offset from some BASE_REG_CLASS register. This address is chosen by finding the first register in the class and by finding the smallest power of two that is a valid offset from that register in every mode we will use to save registers. */
