Re: Link tests after GCC_NO_EXECUTABLES
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> On Fri, Nov 30, 2007 at 10:25:34AM -0800, Mark Mitchell wrote:
>> Rask Ingemann Lambertsen wrote:
>>
>> >>>I have a feeling it would be more robust to simulate the link tests
>> >>> inside the autoconf/libtool macros themselves as opposed to explicitly
>> >>> avoiding them in each and every configure.{ac,in}. Supply an option
>> >>> --simulate-link-tests=file_with_results with the default being no and be
>> >>> happy.
>
>> The advantage to the current setup is that you get a
>> loud failure, and have to go actually work out the right answer.
>
>That's the --cache-file option, except for clobbering the file. I'll see
> if I can arrange for the toplevel Makefile to copy a pre-made config.cache
> into target library build directories just before running configure. That
> ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
> and AC_LIBTOOL_DLOPEN, which is manageble.
I've lost track of whether we're still talking about what to do for 4.3,
or whether we're talking about future directions. So: are we considering
this for 4.3, or for 4.4+?
Richard
Re: Link tests after GCC_NO_EXECUTABLES
Mark Mitchell <[EMAIL PROTECTED]> writes: > Richard Sandiford wrote: >> 2006-04-18 DJ Delorie <[EMAIL PROTECTED]> >> >> * configure.in (m32c): Build libstdc++-v3. Pass flags to >> reference libgloss so that libssp can be built in a combined >> tree. >> * configure: Regenerate. > >> Mark, DJ? Do you agree it's OK to drop that hunk? > > I'm not quite sure if you're asking for agreement to leave it in our > sourcebase, or to remove it therefrom, so, unambiguously: Yeah, sorry about that. And... > I would prefer to revert DJ's change, for the same reason as the other > changes under discussion, so that we're consistent across architectures. ...I was indeed asking whether I could remove that hunk from the source, rather than restoring it to its original position. Anyway, given that there have been objections to the patch generally, I realise that the pre-approval is void. Richard
Re: problems compiling a program with -m32
On Dec 1, 2007 6:54 AM, darvish <[EMAIL PROTECTED]> wrote: > > Hey, I'm running openSUSE 2.6.22.12-0.1-default with x86_64. > I have several files: pizza.asm, driver.c and asm_io.o > What I'm trying to do is to compile all these files to a single executable > file pizza, I use the following command: > > nasm -g -f elf -d ELF_TYPE pizza.asm > gcc -m32 -o pizza -g driver.c pizza.o asm_io.o > > and I get this whenever I execute the gcc line: > /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld: > skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.2.1/libgcc.a when > searching for -lgcc > /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld: > cannot find -lgcc > collect2: ld returned 1 exit status > > I tried to compile it again without the -m32 parameter and I get: > > /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld: > i386 architecture of input file `pizza.o' is incompatible with i386:x86-64 > output > /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld: > i386 architecture of input file `asm_io.o' is incompatible with i386:x86-64 > output > collect2: ld returned 1 exit status > > I don't understand...what am I doing wrong and how can I get pizza.o and > asm_io.o file to link with my 64bit architecture. I'd appreciate any help, > thanks. First, this is off-topic for this list, use gcc-help for this kind of questions. Second, you probably miss the gcc-32bit package. Richard.
Re: Link tests after GCC_NO_EXECUTABLES
On Sat, Dec 01, 2007 at 09:48:20AM +, Richard Sandiford wrote: > Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > > > >That's the --cache-file option, except for clobbering the file. I'll see > > if I can arrange for the toplevel Makefile to copy a pre-made config.cache > > into target library build directories just before running configure. That > > ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning > > and AC_LIBTOOL_DLOPEN, which is manageble. > > I've lost track of whether we're still talking about what to do for 4.3, > or whether we're talking about future directions. So: are we considering > this for 4.3, or for 4.4+? I'll post a patch to implement the --cache-file trick just as soon as I figure out why the $with_newlib variable is lost sometime before configuring libgfortran, because it seems to basicly work apart from that. Then we can decide for 4.3 or 4.4. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: Link tests after GCC_NO_EXECUTABLES
On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote: > >I'll post a patch to implement the --cache-file trick just as soon as I > figure out why the $with_newlib variable is lost sometime before configuring > libgfortran, because it seems to basicly work apart from that. Then we can > decide for 4.3 or 4.4. Correction: $with_newlib seems to be completely unavailable in the toplevel Makefile(.tpl). Any ideas? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: GNAT SVN trunk on PowerPC and SPARC
> Unfortunately I am nearly 100% sure that > it did break the run-time. Attached is a very > simple Ada program that works correctly > when the run-time is compiled at -O2 and > breaks when the run-time is at -O0. I cannot reproduce on x86/Linux, runtime compiled with -g. The ACATS and GNAT testsuites are also clean. Maybe occurs only on non-DWARF2 platforms too. -- Eric Botcazou
Re: Link tests after GCC_NO_EXECUTABLES
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote: >> >>I'll post a patch to implement the --cache-file trick just as soon as I >> figure out why the $with_newlib variable is lost sometime before configuring >> libgfortran, because it seems to basicly work apart from that. Then we can >> decide for 4.3 or 4.4. > >Correction: $with_newlib seems to be completely unavailable in the toplevel > Makefile(.tpl). Any ideas? Only variables subject to AC_SUBST are available in the generated Makefile. There is extra_host_args which includes --with-newlib, but this is only passed to configure scripts in host directories (via host_configargs), not target directories. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Link tests after GCC_NO_EXECUTABLES
On Sat, Dec 01, 2007 at 02:37:38PM +0100, Andreas Schwab wrote:
>
> Only variables subject to AC_SUBST are available in the generated
> Makefile. There is extra_host_args which includes --with-newlib, but
> this is only passed to configure scripts in host directories (via
> host_configargs), not target directories.
Thanks. I frequently configure using --with-newlib --without-newlib and
configure gets it right, so I won't just grep the configure args for
--with-newlib. Instead I use AC_SUBST to export with_newlib to the
Makefile.
So, here is the patch to implement the config.cache file trick: Create a
config.cache file with all the right link test answers for newlib just
before running configure, in both Makefile.tpl and config-ml.in. This allows
sparc-unknown-elf to build libstdc++-v3 with unmodified
libstdc++-v3/configure.ac. Libgfortran's configure.ac needs just the symbol
versioning patch ported from libssp. And that's it!
The file config-newlib-linktests.cache is just an extract of the
config.cache files I had lying around, except for the last four entries that
I had to extract manually from libgfortran's config.log because they're not
saved to config.cache. It's reasonably straight-forward to add entries as
needed.
Index: configure.ac
===
--- configure.ac(revision 130442)
+++ configure.ac(working copy)
AC_SUBST(CONFIGURE_GDB_TK)
AC_SUBST(GDB_TK)
AC_SUBST(INSTALL_GDB_TK)
+AC_SUBST(with_newlib)
# Build module lists & subconfigure args.
AC_SUBST(build_configargs)
Index: Makefile.tpl
===
--- Makefile.tpl(revision 130442)
+++ Makefile.tpl(working copy)
@@ -394,6 +394,7 @@
#
# Miscellaneous targets and flag lists
#
+with_newlib = @with_newlib@
# The first rule in the file had better be this one. Don't put any above it.
# This lives here to allow makefile fragments to contain dependencies.
@@ -814,7 +815,12 @@
*) topdir=`echo [+subdir+]/[+module+]/ | \
sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
esac; \
- srcdiroption="--srcdir=$${topdir}/[+module+]"; \
+ [+ IF check_multilibs
+ +]if test ! -f config.cache -a "x$(with_newlib)" = "xyes"; then \
+ echo "Using link test cache $${s}/config-newlib-linktests.cache."; \
+ cp $${s}/config-newlib-linktests.cache config.cache; \
+ fi; \
+ [+ ENDIF check_multilibs
+]srcdiroption="--srcdir=$${topdir}/[+module+]"; \
libsrcdir="$$s/[+module+]"; \
[+ IF no-config-site +]rm -f no-such-file || : ; \
CONFIG_SITE=no-such-file [+ ENDIF +]$(SHELL) $${libsrcdir}/configure \
Index: config-ml.in
===
--- config-ml.in(revision 130442)
+++ config-ml.in(working copy)
@@ -893,6 +893,10 @@
fi
fi
+if test ! -f config.cache -a "x${with_newlib}" = "xyes"; then
+ echo "Using link test cache ${s}/config-newlib-linktests.cache."
+ cp ${s}/config-newlib-linktests.cache config.cache
+fi
if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
${ac_configure_args} ${ml_config_env} ${ml_srcdiroption} ; then
Index: libgfortran/configure.ac
===
--- libgfortran/configure.ac(revision 130442)
+++ libgfortran/configure.ac(working copy)
@@ -144,7 +144,13 @@
EOF
save_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
-AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+if test x$gcc_no_link = xyes; then
+ # If we cannot link, we cannot build shared libraries, so do not use
+ # symbol versioning.
+ gfortran_use_symver=no
+else
+ AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+fi
LDFLAGS="$save_LDFLAGS"
AC_MSG_RESULT($gfortran_use_symver)
AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
--- /dev/null 2007-11-25 19:34:41.836000250 +0100
+++ config-newlib-linktests.cache 2007-12-01 20:48:47.0 +0100
@@ -0,0 +1,298 @@
+ac_cv_func_accept=${ac_cv_func_accept=no}
+ac_cv_func_access=${ac_cv_func_access=no}
+ac_cv_func_alarm=${ac_cv_func_alarm=no}
+ac_cv_func_alloca_works=${ac_cv_func_alloca_works=yes}
+ac_cv_func_argz_append=${ac_cv_func_argz_append=yes}
+ac_cv_func_argz_create_sep=${ac_cv_func_argz_create_sep=yes}
+ac_cv_func_argz_insert=${ac_cv_func_argz_insert=yes}
+ac_cv_func_argz_next=${ac_cv_func_argz_next=yes}
+ac_cv_func_argz_stringify=${ac_cv_func_argz_stringify=yes}
+ac_cv_func_backtrace=${ac_cv_func_backtrace=no}
+ac_cv_func_backtrace_symbols=${ac_cv_func_backtrace_symbols=no}
+ac_cv_func_bind=${ac_cv_func_bind=no}
+ac_c
Re: volatile and R/M/W operations
Samuel Tardieu wrote:
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y, %eax
orb $16, x
orl $32, %eax
movb%al, y
ret
I cannot see a reason not to use "orb $32,y" here instead of a three
steps read/modify/write operation. Is this only a missed optimization?
(in which case I will open a PR)
Are you sure it is an optimization, the timing on these things is
very subtle. What evidence do you have that there is a missed
optimization here?
ADOPT A PUP OR KITTEN THIS XMAS.
This Xmas season Pet breeders world currently has English bulldog pups and Exotic show kittens available for free adoption. Contact us for pictures, availability and more details. All cats and dogs have all vet shots till date. Pets make the perfect gifts for this season email us back for more details. Regards, John Lewis Pet breeder.
