Re: wiki topics wish (configuration related)

[Ralf Wildenhues]

Hello Basile,

* Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET:
> 
> http://gcc.gnu.org/wiki/AboutGCCConfiguration
> 
> I borrowed a few sentences elsewhere, in particular from the autobook
> http://sources.redhat.com/autobook/ by Gary V. Vaughan, Ben Elliston,
> Tom Tromey and Ian Lance Taylor (I sent a small email to Gary about this).

If you need a verbose introductionary tutorial to Autoconf and Automake
that is not more or less outdated:
http://www-src.lip6.fr/~Alexandre.Duret-Lutz/autotools.html

The first chapter of the Automake 1.10 manual contains an abbreviated
overview:
http://sources.redhat.com/automake/automake.html#Autotools-Introduction

The Autobook and the tutorial page
http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html
that is referred to in above wiki page refer to older versions of
Autoconf and Automake, and thus omit newer constructs.

Hope that helps.

Cheers,
Ralf

Re: wiki topics wish (configuration related)

['Ralf Wildenhues']

* Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET:
> >> http://gcc.gnu.org/wiki/AboutGCCConfiguration
[...]
>   You don't really "get" wiki, do you?  ;-)

Oh, I didn't know this wiki was editable by anybody.
I mistakenly inferred from notices on other wiki pages
that there are restrictions and rules.

Cheers,
Ralf

Re: configuration options policy (at toplevel or only inside gcc/)?

[Ralf Wildenhues]

Hello,

* Ian Lance Taylor wrote on Thu, Dec 14, 2006 at 04:29:19PM CET:
> 
> I agree that new options should only be added at the appropriate
> level, but there is one disadvantage: top level configure --help will
> not display them.

Autoconf 2.5x implements --help=recursive.

> But then configure --help is kind of useless anyhow since it has so
> much boilerplate, so this is not a significant problem.

If I want to find something in a long list, I can pipe it to less and
search for it.  That's trivial, but it's a good enough reason to have
something listed.

You may find this discussion currently on the Autoconf list helpful:
http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/8755

Cheers,
Ralf

GCC optimizes integer overflow: bug or feature? (was: avoid integer overflow in mktime.m4)

[Ralf Wildenhues]

[ Please see http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/8152
  http://www.ginac.de/pipermail/cln-list/2006-December/000259.html ]

Hello Paul, all,

Let's forward your comments and questions to the GCC list, I wasn't
aware of this topic being so disruptive:

* Paul Eggert wrote on Tue, Dec 19, 2006 at 03:06:52AM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > the newer GCC exploits at -O2 the fact that integer overflow
> > produces undefined behavior
> 
> Wheeeoo!  That optimization is going to break a _lot_ of GNU
> software.  (Silently.  Oh my.)
> 
> This is a major change.  Where is it documented and discussed?  I
> don't see it listed at either
> <http://gcc.gnu.org/gcc-4.2/changes.html> or
> <http://gcc.gnu.org/gcc-4.3/changes.html>.
> 
> We tried to do that sort of optimization in the 1990s (back when I
> was a GCC contributor), but ran into too many problems in
> real-world software.  So the optimization got removed.  RMS
> decided it was too disruptive.
> 
> How about if we report the problem again, and get the optimization
> removed from -O2?  I don't mind having the optimization available
> on request for people who prefer speedy to reliable software, but
> it shouldn't be turned on with a mere -O2, as it breaks too much
> real-world code like mktime.c, which says:
> 
>/* The code also assumes that signed integer overflow silently wraps
>   around, but this assumption can't be stated without causing a
>   diagnostic on some hosts.  */
> 
> The optimization also breaks code that assumes LIA-1 (see Annex H
> of the C99 standard).  To conform to LIA-1, if signed integer
> arithmetic does not wrap around reliably, a signal must be
> generated.
> 
> Surely the GCC guys care about LIA-1.  After all, gcc has an
> -ftrapv option to enable reliable signal generation on signed
> overflow.  But I'd rather not go the -ftrapv route, since that
> will cause other problems.  I'd rather have signed integer
> overflow silently wrap around, as this is the traditional behavior
> and a lot of real-world code assumes this.  Is there an option to
> the new GCC to specify this?

Maybe it's also just an unintended bug I happened to observe
(and take for given behavior)?  Should I open a bugzilla entry?

The testing was done with
  gcc (GCC) 4.3.0 20061215

and I haven't tested GCC in several months before, so I have no idea
when this was introduced.

> If not, is there any way to tell the new GCC to disable this
> harmful optimization?  Maybe we can have 'configure' automatically
> generate the appropriate flag to do that.  For example, we can
> change Autoconf to default to -O1 instead of -O2.  I hope we don't
> have to be this drastic, though; I'd rather just disable the
> optimizations that cause GCC to depart from LIA-1 wraparound
> arithmetic.

> > This test hangs,
> 
> Does the test hang forever?

No, the timeout works.

Cheers,
Ralf

Re: gcc-4.1.2 RC1 build problem

[Ralf Wildenhues]

Hello Kate, all,

* Kate Minola wrote on Fri, Feb 02, 2007 at 03:37:05PM CET:
> 
> echo 'SYSTEM_HEADER_DIR="'"`echo /usr/include | sed -e :a -e 
> "s,[^/]*/\.\.\/,,"
> -e ta`"'"' \
>> 
>/home/kate/gcc-4.1.2-20070128/alpha-OSF1-V4/lib/gcc/alphaev56-
> dec-osf4.0f/4.1.2/install-tools/mkheaders.conf
> /bin/sh: : cannot execute
> /bin/sh: /]*/../,, -e ta: not found
> sed: Function s,[ cannot be parsed.
> make[2]: *** [install-mkheaders] Error 1
> make[2]: Leaving directory 
> `/home/kate/gcc-4.1.2-20070128/src/obj-alpha-OSF1-V4/
> gcc'

The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context,
leading to nonportable "...`..."..."...`...",  see
<http://www.gnu.org/software/autoconf/manual/html_node/Shell-Substitutions.html>.

Proposed untested patch.  (I also haven't checked whether there are
other instances of this issue in 'make install' code.)

Cheers,
Ralf

gcc/ChangeLog:
2007-02-03  Ralf Wildenhues  <[EMAIL PROTECTED]>

PR other/27843
* Makefile.in (SYSTEM_HEADER_DIR): Use single quotes to avoid
nested double- and backquotes.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 121494)
+++ gcc/Makefile.in (working copy)
@@ -386,7 +386,9 @@
 # Purge it of unneccessary internal relative paths
 # to directories that might not exist yet.
 # The sed idiom for this is to repeat the search-and-replace until it doesn't 
match, using :a ... ta.
-SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e 
"s,[^/]*/\.\.\/,," -e ta`
+# Use single quotes here to avoid nested double- and backquotes, this
+# macro is also used in a double-quoted context.
+SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e 
's,[^/]*/\.\.\/,,' -e ta`
 
 # Control whether to run fixproto and fixincludes.
 STMP_FIXPROTO = @STMP_FIXPROTO@

Re: gcc-4.1.2 RC1 build problem

[Ralf Wildenhues]

Hello Paolo, all,

* Paolo Bonzini wrote on Mon, Feb 05, 2007 at 10:30:41AM CET:
> 
> >The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context,
> >leading to nonportable "...`..."..."...`...", [...]

> >Proposed untested patch.  (I also haven't checked whether there are
> >other instances of this issue in 'make install' code.)
> 
> If you or anybody can test this (better on an affected system, but even 
> i686-pc-linux-gnu would be ok), ok for mainline and all affected release 
> branches.

With the patch, the gcc-4.1.2-20070128 tarball passes
  configure --enable-languages=c && gmake && gmake install

on alphaev67-dec-osf5.1, and fails without it.

Thanks for the review.  Please note I don't have write access.

Cheers,
Ralf

Re: updating libtool, etc.

[Ralf Wildenhues]

[ please Cc: me ]

Hi Geoff,

* Geoff Keating wrote on Fri, Jul 01, 2005 at 03:37:07AM CEST:
> On 30/06/2005, at 6:26 PM, David Edelsohn wrote:
> 
> >Geoff> Does anyone mind if I update libtool to the latest released version,
> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
> >
> >If everyone agrees to go forward with this
> 
> Oh, I should have said:  "and if you don't mind, how do you feel  
> about a GCC project fork of libtool?"

I would be very happy if we could fold back many of the differences
between pristine Libtool and GCC's version back into Libtool proper.

I realize Libtool's side has not been the easiest on GCC demands in
the past.  Personally, I am quite happy to re-think some of the
decisions made, but I am not alone.  Also, Libtool's pace of development
does not match that of GCC, unfortunately.

Regarding Fortran 90/95, there is a proposed patch for support, albeit
for branch-2-0/HEAD only.

Just to make you aware before they hit you: some of the patches GCC
Libtool incorporated were only put in branch-2-0 or HEAD of Libtool,
so they won't be present in 1.5.18.

(shameless plug: it would be really cool if PR 5291 could be fixed
eventually.  I wonder if the idea at the end of [1] could work, but I
really don't know enough about GCC yet to try it out.)

Regards,
Ralf

[1] 

Re: Running ranlib after installation - okay or not?

[Ralf Wildenhues]

Hi Peter,

* Peter O'Gorman wrote on Thu, Sep 01, 2005 at 07:09:35AM CEST:
> Peter O'Gorman wrote:
> | The problem is that libtool tries to run ranlib after install and that
> | ranlib can fail if the library is not writable?

Thanks for the pointer.

> When I look more closely at this, I see in libtool.m4:
> old_postinstall_cmds='chmod 644 $oldlib'
> 
> and a little later:
> old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
> 
> Should that be:
> old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
> ??

Yes, I believe so (both CVS HEAD and branch-1-5).
Unless there exists ranlib's that change file mode..

> > The problem is that libtool tries to run ranlib after install and
> > that ranlib can fail if the library is not writable? Note that on
> > darwin running ranlib on a 444 lib works and changes permissions to
> > 644, remind me to file a bug.

Hmm.  The change to 644 should be OK.  What happens to libraries with
other modes (say, not group- or world-readable)?  So how about changing
the order as you suggest above, and filing a bug with darwin ranlib?

Someone in this thread suggested saving and restoring the mode used for
installation; in a way, it would be a nice service to serve the user's
wish here (for example, for supposed-to-be private code); one danger
would be if we then found issues similar to with shared libraries (where
on some systems, weird permissions are necessary for them to work
right).  Not that I know of any such issues.

> > Another alternative would be to set RANLIB=: before configure if
> > your system does not need to ranlib anything.

Improving upon this situation has been on our TODO list anyway:
http://lists.gnu.org/archive/html/libtool-patches/2005-05/msg00092.html

Cheers,
Ralf

Re: Problem with commas in macro parameters

[Ralf Wildenhues]

* Dmitry Yu. Bolkhovityanov wrote on Sun, Nov 06, 2005 at 07:21:56AM CET:
> 
>   That's probably an old problem, but I haven't found any notion of 
> it in GCC docs. So...

It's one better discussed on the gcc-help mailing list.

>   #define V(value) = value

>   This works fine, until I try to pass it some complex value:
> 
> D int some_array[2] V({4,5})

If you can limit yourself to C99-aware preprocessors, use
  #define V(...) = __VA_ARGS__

Cheers,
Ralf

Re: FYI: [PATCH] RDOS support for libtool

[Ralf Wildenhues]

Leif,

* Leif Ekblad wrote on Fri, Jan 13, 2006 at 04:15:30PM CET:
> Peter:
> > Well, it is a daily checkout, please try again to ensure that you did not
> > miss the update on the 13th.. The Changelog for the version that is up

> OK, I saw it was just regenerated. (http://libtool.opendarwin.org/)
> 
> I downloaded this version and run ./configure, make and make install.
> Then I moved libtool.m4 into the root of the GCC tree, and run
> libtoolize.

Please use that development version of libtool *only* to run the libtool
test suite.  If you're going to use it for other packages, you're going
to have to read the documentation and/or the source.  1.5.x contents of
libtool.m4 have now been split into more than one macro file, for
example.

> I then run autoconf in the libstdc++-v3 directory, but unfortunately, the
> libtool.m4
> file doesn't work. It emits a series of errors:
*snip*
> Maybe I'm going about this in the wrong way? Maybe GCC requires branch 1.5.x
> of libtool and not MAIN?

GCC has its own in-house cranked-up version of 1.4.x libtool.

Cheers,
Ralf

Re: new libjava bootstrap failure

[Ralf Wildenhues]

Hello Dave,

* Dave Korn wrote on Wed, Mar 02, 2011 at 06:28:15AM CET:
>  http://mad-scientist.net/make/autodep.html
> 
> although note that where that recommends using "-include" (under
> "Avoiding ``No rule to make target ...'' Errors") to ignore would-be
> errors from trying to include non-existent files, we use an unprefixed
> include directive to read them in our Makefiles, and rely on
> config.status to generate empty ones first time round.  I'm not sure
> why we do that differently.

That's because non-GNU makes don't have facilities to include a file
only if it is present, and with the current machinery, a non-present
file always indicates a bug (or previous error) and having errors be
loud is a good thing for debugging.

Jack, the actual issue you're seeing might well be the result of some
missing dependency.  With parallel build failures, it is most important
to see output from make, back to at least the first error that happened.
That can be arbitrarily far back, and in GCC it is not uncommon to have
it happen a few thousand lines before the end of the log.  Please save
such logs for future reports.

Thanks,
Ralf

Re: new libjava bootstrap failure

[Ralf Wildenhues]

* Jack Howarth wrote on Wed, Mar 02, 2011 at 06:08:22PM CET:
> On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote:
> > Jack, the actual issue you're seeing might well be the result of some
> > missing dependency.  With parallel build failures, it is most important
> > to see output from make, back to at least the first error that happened.
> > That can be arbitrarily far back, and in GCC it is not uncommon to have
> > it happen a few thousand lines before the end of the log.  Please save
> > such logs for future reports.

> A second repetition of the original build with --enable-build-with-cxx
> completed without errors.

Race conditions can be very tricky to win; successful builds are never a
proof of their absence.  It might only happen again in a few months, or
only under a certain system load.

> FYI, I do all of my builds on darwin10 with
> lto-bootstrap and 'make -j 8'. This is the first time that I have seen this
> particular failure crop up.

Well, please keep logs for the case when it might happen again.

Thanks,
Ralf

Re: GCC_NO_EXECUTABLES vs. libtool

[Ralf Wildenhues]

Hello Ian,

* Ian Lance Taylor wrote on Tue, Mar 29, 2011 at 07:39:25AM CEST:
> We have several bug reports for 4.6.0 about failures of the form 
> 
> checking dynamic linker characteristics... configure: error: Link tests are 
> not allowed after GCC_NO_EXECUTABLES.

> Unfortunately, on a GNU/Linux host (recall that for a target library,
> the target is the host), libtool itself does a link test.

The general strategy I've been following with these is wrapping the link
test result with a cache variable, and trying to let the cache variable
be pre-set by configure.ac in the no-executables case (and adjusting
libtool/tests/no-executables.at).  Then, even if the cache variable is
not set, the user can work around it.

> From the top
> level libtool.m4 file, in _LT_SYS_DYNAMIC_LINKER, in the "linux* |
> k*bsd*-gnu | kopensolaris*-gnu" case:
> 
> AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
>   [AS_IF([ ($OBJDUMP -p conftest$ac_exeext) 2>/dev/null | grep 
> "RUNPATH.*$libdir" >/dev/null],
>[lt_cv_shlibpath_overrides_runpath=yes])])
> 
> That test fails when a link fails.  That test must not be run when
> linking fails.

There's a simple workaround for the time being: pass
  target_configargs='lt_cv_shlibpath_overrides_runpath=yes'

(or =no, depending on which is correct) to toplevel configure.

> Shortly after that code in libtool.m4, I see this:
> 
>   if test -f /etc/ld.so.conf; then
> lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 
> 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < 
> /etc/ld.so.conf | $SED -e 's/#.*//;/^[ ]*hwcap[]/d;s/[:,  
> ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
> sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
>   fi
> 
> Testing /etc/ld.so.conf is absolutely meaningless when building a target
> library for a non-native compilation.  That test must not be run when
> cross-compiling.

Right.  There are probably more such cases.  I'm not sure how to change
the code for best results here, apart from just using /lib /usr/lib.

> We should definitely fix this for gcc 4.6.1.  However, I don't know what
> the best way to fix this is.  Our gcc-specific target libraries check
> $with_cross_host to see if they are being built as a cross-compiled
> target library.  Presumably libtool doesn't want to check that.
> GCC_NO_EXECUTABLES sets a gcc-specific shell variable and overrides
> AC_LINK_IFELSE to test variable.  libtool doesn't know anything about
> that.  So what should we do here?

Well, we can introduce another variable that tells Libtool macros that
/ is not something to look at for system details.  I'm not sure if
$with_sysroot can be (ab)used for that.

Cheers,
Ralf

Re: GCC_NO_EXECUTABLES vs. libtool

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Mar 29, 2011 at 07:55:27AM CEST:
> * Ian Lance Taylor wrote on Tue, Mar 29, 2011 at 07:39:25AM CEST:
> > Shortly after that code in libtool.m4, I see this:
> > 
> >   if test -f /etc/ld.so.conf; then
> > lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 
> > 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < 
> > /etc/ld.so.conf | $SED -e 's/#.*//;/^[   ]*hwcap[]/d;s/[:,  
> > ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
> > sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
> >   fi

This code, too, is guarded by cache variables, but that's not easy to
see; lt_cv_sys_lib_search_path_spec and lt_cv_sys_lib_dlsearch_path_spec
are checked only several lines later, near the end of the macro.

So GCC (or the user) could override them too, if need be.

Cheers,
Ralf

Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite

[Ralf Wildenhues]

Hello,

* Jorge D'ELIA wrote on Wed, Apr 06, 2011 at 01:24:58AM CEST:
> Here there are few comments from my college Lisandro Dalcin,
> an external developer of PETSc, e.g. see

> - Mensaje original -
> > The current scheme is that the user somehow compiles 
> > the communication library (libcaf) [2] and then builds 
> > and links doing something like:
> >
> > mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
> >
> > or alternatively
> >
> > gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> > -I/usr/lib64/mpi/gcc/openmpi/include
> > -L/usr/lib64/mpi/gcc/openmpi/lib64
> > -lmpi
> >
> > with some -I, -L -l are added. 
> > (Cf. "mpif90 -show" of some MPI implementations.) 
> >
> > The resulting program is then run using, e.g.,
> >
> > mpiexec -n 3 ./a.out
> >
> > Alternatively, it could be just "-lcaf_single" 
> > which is run like normal ("./a.out").

I think one of the most important things is that you allow to override
both the running of mpif90 and the mpiexec commands, so as to allow
batch environments (qsub, llrun).  Although, parsing of output might
need to be more complex in that case, too.  But if only to allow for
different mpiexec.* incarnations this would be good.

> > (In any case, only static libraries should be created; 
> > the libraries could then be installed 
> > in $PREFIX/$lib/gcc/$target/$version/, where
> > already libgcc.a etc. are located.)
> 
> COMMENT: well, using shared libraries would certainly help 
> users to switch the underlying MPI implementation at runtime. 
> This is an feature should be considered.

The MPI implementations I know all have pairwise incompatible ABIs,
prohibiting any kind of switching at run time.  If anything, GCC
might consider making it easy to build and install in parallel the
library for multiple MPI implementations.

Cheers,
Ralf

Re: possible race condition in make install?

[Ralf Wildenhues]

* Jack Howarth wrote on Sat, Jul 16, 2011 at 10:40:22PM CEST:
>I have had a report of i386 darwin10 failing to build gcc 4.4.6 in fink 
> which I've reproduced
> myself. The failure looks quite odd...
> 
> /usr/bin/install -c -m 644 ./libiberty.a 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/xgcc
>  -B/sw/src/fink.build/gcc44-4.4.6-1001/darwin_objdir/./gcc/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/bin/ 
> -B/sw/lib/gcc4.4/i386-apple-darwin10.8.0/lib/ -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/include -isystem 
> /sw/lib/gcc4.4/i386-apple-darwin10.8.0/sys-include -g -O2   
> -print-multi-os-directory`/./libiberty.an
[...]

> ( cd /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/`gcc -g -O2 
> -print-multi-os-directory` ; chmod 644 ./libiberty.an ;ranlib ./libiberty.an )
> libtool: install: chmod 644 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> ranlib: file: ./libiberty.an is not an archive
> libtool: install: ranlib -c 
> /sw/src/fink.build/root-gcc44-4.4.6-1001/sw/lib/gcc4.4/lib/x86_64/libssp.a
> make[2]: *** [install_to_libdir] Error 1
> make[1]: *** [install-libiberty] Error 2
> make[1]: *** Waiting for unfinished jobs
> 
> and only occurs with parallel builds. Is it possible that the command...

This is one bit of the unfixed part of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980

Cheers,
Ralf

Re: updating autotools status

[Ralf Wildenhues]

Hello Benjamin,

sorry for the delay, I've been traveling.

* Benjamin Kosnik wrote on Tue, Jul 14, 2009 at 09:17:46PM CEST:
> 
> Hey Ralf! Saw your message about updating gcc/src to current auto
> tools, in favor. But, it looks like the autoconf 2.64 release is not
> out, last I see is 2.63b at the end of March. This and
> confirmation of --with-build-sysroot working seem to be the only open
> issues standing in the way of the conversion of the GCC source
> repository.

Yes, that is still the case.

> What's the eta for the 2.64 autoconf release? How is this to be timed
> with the end of GCC Stage 1? If autoconf 2.64 is not out by the end of
> July, does it make sense to use autoconf 2.63 instead?

Yes, definitely.  Let's ask Eric if there is any chance for 2.64 RSN.
Otherwise, I'll start going through the workarounds needed in GCC for
2.63.

Cheers,
Ralf

Re: Bootstrap failure configuring in-tree gmp in mainline

[Ralf Wildenhues]

* Bradley Lucier wrote on Wed, Jul 15, 2009 at 10:37:56PM CEST:
> After configuring
> 
> Target: x86_64-unknown-linux-gnu
> gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC) 
> 
> with
> 
> ../../mainline/configure --enable-checking=release 
> --prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c 
> --enable-gather-detailed-mem-stats
> 
> I get the bootstrap error:
> 
> Configuring stage 2 in ./gmp
> < stuff omitted>
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
> make[2]: *** [configure-stage2-gmp] Error 1
> make[2]: Leaving directory `/home/lucier/programs/gcc/objdirs/mainline'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/lucier/programs/gcc/objdirs/mainline'
> make: *** [bootstrap] Error 2
> 
> This is using an in-tree gmp 4.3.0, gmp/config.log reports:
> 
> configure:11030: checking how to run the C++ preprocessor
> configure:11061:  /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ 
> -B/home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/ 
> -B/pkgs/gcc-mainline-mem-stats/x86_64-unknown-linux-gnu/bin/ -nostdinc++ 
> -I/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
>  
> -I/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
>  
> -I/home/lucier/programs/gcc/objdirs/mainline/../../mainline/libstdc++-v3/libsupc++
>  
> -L/home/lucier/programs/gcc/objdirs/mainline/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
>  -E -DNO_ASM conftest.cc
> /home/lucier/programs/gcc/mainline/gmp/configure: line 11062: 
> /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++: No such file or 
> directory
> 
> configure:11061: /lib/cpp -DNO_ASM conftest.cc
> cpp: error trying to exec 'cc1plus': execvp: No such file or directory
> 
> Am i missing something? 

Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist,
and if yes, is it a functioning executable?

If it doesn't exist, that looks like the toplevel logic for which
languages to build still has a loop hole for --enable-languages=c,
either not properly enabling the C++ compiler for stage 1, or wrongly
overriding CXX, CXX_FOR_BUILD in toplevel Makefile.tpl to point to
nonexistent previous-stage C++ compiler.  I don't know which is the
desired one.

BTW, what's the last , and why does your /lib/cpp try to
spawn cc1plus?

Cheers,
Ralf

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Dave Korn wrote on Sun, Jul 26, 2009 at 02:26:05AM CEST:
> Angelo Graziosi wrote:
> >> make[4]: Nothing to be done for `install-exec-am'.
> >> test -z "/usr/local/gfortran/share/gcc-4.5.0/python" || mkdir -p --
> >> "/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python"
> >> /bin/sh: line 0: cd: /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0:
> >> No such file or directory
> 
>   Notice here how it tests for the real install dir, then if it doesn't exist
> it creates the DESTDIR-prefixed version, then it tries to cd into the real one
> and fails.  That's definitely a bug there.

Not really.  It tests whether the variable that contains the real
install dir has empty contents.  'test -z' is a simple string test.
This can happen in some situations automake has no control over, so
it needs a runtime test here.

One bug is that in libstdc++-v3/python/Makefile.am, in the
install-data-local rule, the code tries to cd to $(toolexeclibdir)
which is nonsensical.  It needs to use $(DESTDIR)$(toolexeclibdir).

The other bug (the one about libstdc++*) also seems within that rule,
but I don't see it yet.

Is there a PR for this issue?

Thanks,
Ralf

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

Adding gcc-patches and libstdc++; this is
<http://gcc.gnu.org/ml/gcc/2009-07/msg00464.html>.

* Ralf Wildenhues wrote on Sun, Jul 26, 2009 at 09:46:34AM CEST:
> 
> The other bug (the one about libstdc++*) also seems within that rule,
> but I don't see it yet.

Never mind.  The rest is just followup failure.

OK to install this trivial patch if it passes the build I'm running
right now, as well as a normal and a DESTDIR install I'll be doing
afterwards?

AFAICS the python directory is new in trunk, so no stable releases
affected.

Thanks,
Ralf

libstdc++-v3/ChangeLog:
2009-07-26  Ralf Wildenhues  

* python/Makefile.am (install-data-local): Use DESTDIR
correctly.

diff --git a/libstdc++-v3/python/Makefile.am b/libstdc++-v3/python/Makefile.am
index 50cc6d9..457e45b 100644
--- a/libstdc++-v3/python/Makefile.am
+++ b/libstdc++-v3/python/Makefile.am
@@ -44,7 +44,7 @@ install-data-local: gdb.py
 ## .la file, and any previous -gdb.py file.  This is inherently
 ## fragile, but there does not seem to be a better option, because
 ## libtool hides the real names from us.
-   @here=`pwd`; cd $(toolexeclibdir); \
+   @here=`pwd`; cd $(DESTDIR)$(toolexeclibdir); \
  for file in libstdc++*; do \
case $$file in \
  *-gdb.py) ;; \

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Angelo Graziosi wrote on Sun, Jul 26, 2009 at 09:59:35AM CEST:
> Dave Korn ha scritto:
> >Angelo Graziosi wrote:
> >
> >>...are the files with an '*' in their names, like libstdc++*-gdb.py,
> >>allowed on Cygwin?
> >
> >  No, it's a glob match, the makefile expects there to be something to match
> >that pattern but there isn't so the shell returns it verbatim instead of
> >expanding it.
> 
> Do you mean that the '*' there is a wild character? Hmm... on
> GNU/Linux the file installed is _exactly_ libstdc++*-gdb.py,

But only if you do a DESTDIR install, right?

That's the bug.

Cheers,
Ralf

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues  writes:
> 
> Ralf> OK to install this trivial patch if it passes the build I'm running
> Ralf> right now, as well as a normal and a DESTDIR install I'll be doing
> Ralf> afterwards?

> I think this patch qualifies as obvious.

Alright.  Installed.

Thanks,
Ralf

Re: Failure in a complete build of current gcc snapshot

[Ralf Wildenhues]

* Angelo Graziosi wrote on Tue, Jul 28, 2009 at 01:20:00AM CEST:
> Ralf Wildenhues ha scritto:
> >* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:
> >
> >>I think this patch qualifies as obvious.
> >
> >Alright.  Installed.
> 
> Shouldn't Makefile.in be rebuilt?

D'oh.  Fixed now.

Thanks,
Ralf

Re: MELT tutorial on the wiki

[Ralf Wildenhues]

* Basile STARYNKEVITCH wrote on Sat, Aug 01, 2009 at 08:10:24AM CEST:
> I don"t know really how to fix that quickly! I must confess that
> autoconf related files in GCC scares me a big lot. BTW, I really
> cannot imagine why GCC still required autoconf 2.59 specifically,
> and not 2.63. What is so specific about 2.59?

I will post patches to move to 2.64 and Automake 1.11; they are ready
(I only need to finish writing the emails) but I'm off-list for the
next week starting now.  :-)

Cheers,
Ralf

Re: What happens when you --enable libgomp but not --enable-languages=fortran?

[Ralf Wildenhues]

Hello Dave,

* Dave Korn wrote on Wed, Aug 05, 2009 at 11:58:31AM CEST:
> > libtool: link: /gnu/gcc/obj-patched-gnat2/./gcc/xgcc 
> > -B/gnu/gcc/obj-patched-gnat
> > 2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ 
> > -B/opt/gcc-tools/i686-pc-cygwin/li
> > b/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem 
> > /opt/gcc-tools/i686-p
> > c-cygwin/sys-include-shared  .libs/alloc.o .libs/barrier.o 
> > .libs/critical.o
[...]
> > o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o 
> >-
> > pthread -Wl,-O1   -o .libs/libgomp-1.dll -Wl,--enable-auto-image-base 
> > -Xlinker -
> > -out-implib -Xlinker .libs/libgomp-1.dll
> > xgcc: unrecognized option '-pthread'
> > Creating library file: .libs/libgomp-1.dll
> > libtool: link: (cd ".libs" && rm -f "libgomp.lib" && ln -s "libgomp-1.dll" 
> > "libg
> > omp.lib")
> > libtool: link: /opt/gcc-tools/i686-pc-cygwin/bin/ar rc .libs/libgomp.lib  
> > alloc.
> > o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o 
> > ordered
[...]
> > /opt/gcc-tools/i686-pc-cygwin/bin/ar: .libs/libgomp.lib: File format not 
> > recogni
> > zed
> > make[4]: *** [libgomp.la] Error 1
> > 
> > $ file i686-pc-cygwin/libgomp/.libs/libgomp.lib
> > i686-pc-cygwin/libgomp/.libs/libgomp.lib: symbolic link to `libgomp-1.dll'
> 
>   I configured the exact same sandbox yesterday with "--enable-libgomp
> --enable-languages=c,c++,ada,fortran" and it bootstrapped fine.  I tried it
> today with libgomp but without fortran, and this happens.  I noticed that this
> problem has been observed by someone on the MinGW users list, without much
> resolution.  Something must have gone wrong with the libtool configuration
> somehow; there's no such thing as a libgomp.lib (whether symlink to a DLL or
> otherwise) in my previous successful build.
> 
>   Should I not be surprised that libgomp can't be built without fortran 
> enabled,
> or should I open a PR?

Yes, and Cc: me in the PR, please; thanks.

Cheers,
Ralf

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Ralf Wildenhues]

Hello,

* Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> => gcc/testsuite/ada/acats/run_all.sh

> 3/ Here is the point I find surprising: the "ps fauxww" run in the
> second "if" show that even if the script is fully sequential
> at least one gnatmake subprocess (collect-ld) is still marked as running 
> *in parallel* with the ps command in the subsequent "if" of the script!

One thing I see in that script is there is a line
  rm -rf $dir/tests.$$ &

that will be run "in parallel" due to the stray "&".  However, I also
don't see at least parts of the rest of the script that you quote, so
maybe I'm looking at the wrong version (looking at trunk) or you have
added debug statements, so maybe yours has more such stray asynchronous
lists.

Hope that helps.

Cheers,
Ralf

Re: Need some Unix and /bin/sh expertise for GCC testsuite

[Ralf Wildenhues]

> > * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > > => gcc/testsuite/ada/acats/run_all.sh
> > 
> > > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > > second "if" show that even if the script is fully sequential
> > > at least one gnatmake subprocess (collect-ld) is still marked as running 
> > > *in parallel* with the ps command in the subsequent "if" of the script!

Sounds like http://thread.gmane.org/gmane.comp.shells.bash.bugs/11990
and the NEWS for bash-3.2 contains this entry:

l.  Several fixes to the code that manages the list of terminated jobs and
their exit statuses, and the list of active and recently-terminated jobs
to avoid pid aliasing/wraparound and allocation errors.

I'd try out a newer bash version.

Cheers,
Ralf

Re: bootstrap error with --enable-maintainer-mode

[Ralf Wildenhues]

Hello Thomas,

* Thomas Koenig wrote on Sat, Aug 15, 2009 at 04:00:13PM CEST:
> Does this ring any bells?  This is with a recent trunk.
> 
> $ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --enable-maintainer-mode && make && make install
> 
> make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber'
> make[3]: Entering directory `/var/work/gcc-bin/trunk/gcc'
> (cd ../../../gcc/trunk/gcc && aclocal -I ../config -I ..)
> (cd ../../../gcc/trunk/gcc && autoconf)
> configure:3123: error: possibly undefined macro: AC_REQUIRE_AUX_FILE
>   If this token and others are legitimate, please use
> m4_pattern_allow.
>   See the Autoconf documentation.
> make[3]: *** [../../../gcc/trunk/gcc/configure] Error 1

> $ autoconf --version
> autoconf (GNU Autoconf) 2.59

Which aclocal version do you have in PATH?  Looks like 1.10 or newer,
rather than 1.9.6.

Cheers,
Ralf

Re: libtool update?

[Ralf Wildenhues]

Hello Rainer,

* Rainer Emrich wrote on Tue, Aug 18, 2009 at 04:08:38PM CEST:
> Are there any plans to update libtool?

If anybody updates libtool before the Autoconf + Automake update,
I'm probably going to run screaming.

Afterwards you can go crazy all you like.

> There is at least one issue which is solved upstream, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972

There is at least one other issue solved upstream which you reported.

There is at least one other issue (-bindir) pending upstream which would
be nice to have solved in GCC.

Cheers,
Ralf

Re: Failure building current 4.5 snapshot on Cygwin

[Ralf Wildenhues]

Hello Eric,

* Eric Niebler wrote on Sun, Aug 23, 2009 at 01:41:38AM CEST:
> checking whether the C compiler works... configure: error: in
> `/home/ericne/objdir/i686-pc-cygwin/li
> biberty':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
> checking for egrep... grep -E
> checking for i686-pc-cygwin-gcc... /home/ericne/objdir/./gcc/xgcc
> -B/home/ericne/objdir/./gcc/ -B/us
> r/local/gcc-4.5-20090813//i686-pc-cygwin/bin/
> -B/usr/local/gcc-4.5-20090813//i686-pc-cygwin/lib/ -is
> ystem /usr/local/gcc-4.5-20090813//i686-pc-cygwin/include -isystem
> /usr/local/gcc-4.5-20090813//i686
> -pc-cygwin/sys-include
> make[1]: *** [configure-target-libiberty] Error 1
> make[1]: *** Waiting for unfinished jobs
> checking for C compiler default output file name... a.exe
> checking whether the C compiler works... configure: error: in
> `/home/ericne/objdir/i686-pc-cygwin/li
> bstdc++-v3':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/home/ericne/objdir'
> make: *** [all] Error 2

You need to look at the config.log file in the
/home/ericne/objdir/i686-pc-cygwin/libstdc++-v3 directory.

Cheers,
Ralf

Re: MELT tutorial on the wiki

[Ralf Wildenhues]

Hello,

* Dave Korn wrote on Sat, Aug 01, 2009 at 08:41:10AM CEST:
> Tom Tromey wrote:
> 
> > I looked into this a little.  It looks like the PPL checks don't work
> > properly in the case where PPL is a system library.  I guess I need
> > --with-ppl=/usr ... I will try that later.
> 
>   Were you using a --prefix?  The PPL checks (by design I think) only look for
> PPL in your prefix.

Just by the way, while it superficially sounds intuitive, I find this a
slightly problematic "feature".  For example when you're cross-compiling,
intending to do a DESTDIR install, and what you pass as --prefix is
inhabited by $build system files and libraries and so on.

My two cents.

Cheers,
Ralf

Re: darwin8 / ppc bootstrap is failing for me.

[Ralf Wildenhues]

Hello Iain,

* IainS wrote on Mon, Aug 24, 2009 at 07:16:05PM CEST:
>  uname -mrs
> Darwin 8.11.0 Power Macintosh

> configure: WARNING: decimal float is not supported for this target
> configure: WARNING: fixed-point is not supported for this target
> configure: error: in `/Volumes/ScratchCS/gcc-4-5-regbuild/gcc':
> Links are now set up to build a native compiler for powerpc-apple-darwin8.
> In file included from ../../gcc-4-5-regtest/libiberty/regex.c:638:0:
> ../../gcc-4-5-regtest/libiberty/regex.c: In function
> 'byte_re_match_2_internal':
> ../../gcc-4-5-regtest/libiberty/regex.c:7476:5: warning: jump skips
> variable initialization
> ../../gcc-4-5-regtest/libiberty/regex.c:5952:12: note: label
> 'restore_best_regs' defined here
> ../../gcc-4-5-regtest/libiberty/regex.c:5913:16: note: 'same_str_p'
> declared here
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
> make[2]: *** [configure-stage2-gmp] Error 1
> make[1]: *** [stage2-bubble] Error 2
> make: *** [bootstrap] Error 2

Please inspect and/or show the relevant parts of
  /Volumes/ScratchCS/gcc-4-5-regbuild/gcc/config.log

Thanks,
Ralf

Re: darwin8 / ppc bootstrap is failing for me.

[Ralf Wildenhues]

* IainS wrote on Mon, Aug 24, 2009 at 08:17:37PM CEST:
> 
> the configure that's failing is GMP rather than gcc...  maybe I've
> missed a requirement to update?

> configure:11139: /lib/cpp -DNO_ASM conftest.cc
> /Volumes/ScratchCS/gcc-4-5-regtest/gmp/configure: line 1: /lib/cpp:
> No such file or directory

> configure:11214: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.

Maybe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950 or similar?
Anyway, the error happens even earlier, probably when it's trying to
find an in-tree C++ compiler.

HTH.  Cheers,
Ralf

Re: darwin8 / ppc bootstrap is failing for me.

[Ralf Wildenhues]

* IainS wrote on Tue, Aug 25, 2009 at 12:28:58PM CEST:
> On 24 Aug 2009, at 19:52, Ralf Wildenhues wrote:
> >
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950

> That seems to be it, and the cure is to add --enable-stage1-languages=c,c++
> (as per the bugreport).
> 
> In fact, it seems to effect both Darwin8 & 9 when building in-tree
> GMP (so possibly others too).
> 
> The problem appeared between 148251 and 151057 (yeah, a big gap I
> know.. busy with other things).
> 
> Note that I haven't changed the GMP - so the fail *is* as a result
> of some aspect of the gcc build process changing.
> presumably, most likely the upgrade in auto* tools.

No.  The bug report is from before the autotools upgrade.  The issue
comes from the switch to use C++ as a bootstrap compiler.  I'd guess
r148889,

./:
* configure.ac: Add --enable-build-with-cxx.  When set, add c++ to
boot_languages.  [...]

Cheers,
Ralf

Re: r150960 changed ltmain.sh and broke the build

[Ralf Wildenhues]

* Dave Korn wrote on Wed, Aug 26, 2009 at 12:38:50PM CEST:
> Paolo Bonzini wrote:
> > $ sed -e 's,/\(\./\)\{1\,\},/,g;s,/\.$,/,'
> > ./foo/bar/./baz
> > ./foo/bar/baz
> > 
> > $ sed -e 's,/\(\./\)\{1,\},/,g;s,/\.$,/,'
> > sed: -e expression #1, char 18: unknown option to `s'
> > 
> > $
> 
>   Maybe the best thing would be to change it to use a different separator?
> Ralf, have we discovered a new item for the autoconf man page "portable shell"
> chapter?

Not really:

 Patterns should not include the separator (unless escaped), even
 as part of a character class.  In conformance with Posix, the Cray
 `sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
[...]
 Portable `sed' regular expressions should use `\' only to escape
 characters in the string `$()*.0123456789[\^n{}'.

Sorry for not catching this.

Cheers,
Ralf

Re: r150960 changed ltmain.sh and broke the build

[Ralf Wildenhues]

[ trimmed Cc:, added autoconf-patches; followups can remove gcc@ ]
[ http://thread.gmane.org/gmane.comp.gcc.devel/108348 ]

* Dave Korn wrote on Wed, Aug 26, 2009 at 08:16:11PM CEST:
> Ralf Wildenhues wrote:
> >  Patterns should not include the separator (unless escaped), even
> >  as part of a character class.  In conformance with Posix, the Cray
> >  `sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
> > [...]
> >  Portable `sed' regular expressions should use `\' only to escape
> >  characters in the string `$()*.0123456789[\^n{}'.
> 
>   Ah, I didn't read those two conditions as applying simultaneously.

I don't think they apply simultaneously in the way you interpreted that.
However, in the  s,x\{1\,\},y,  example, the comma is both a separator
and another metacharacter.  Hmm, maybe those sentences don't really
cover this case.

How about

 Patterns should not include the separator (unless escaped), even
 as part of a character class.  In conformance with Posix, the Cray
 `sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.  Even escaped,
 patterns should not include separators that are also used as
 metacharacters.  For example, GNU sed 3.02 rejects `s,x\{1\,\},,',
 and is used on MinGW.

?

Cheers,
Ralf

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Ralf Wildenhues]

* Jason Merrill wrote on Wed, Aug 26, 2009 at 10:32:05PM CEST:
> On 08/03/2009 04:09 PM, Pedro Lamarão wrote:
> >Current trunk (revision 150381) fails to bootstrap with the following
> >configuration:
> 
> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
> >‘char* basename(const char*)’
> >/usr/include/string.h:601: error: ambiguates old declaration ‘const
> >char* basename(const char*)’
> 
> The problem is that AC_CHECK_DECLS gets confused by overloaded
> functions, and glibc 2.10 has overloaded declarations of basename
> and some other string functions for const-correctness.

Could you show the config.log snippet that shows the failed test?
Is this a new error due to the autotools upgrade, or new due to
glibc 2.10?

Thanks,
Ralf

toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

While still working to prove Bob wrong on the fixincludes sed issues,
I found out that current toplevel config.status hits the program length
limit of HP-UX 11.11 sed:

$ ./config.status
config.status: creating Makefile
sed: There are too many commands for the 
s&@abs_builddir@&/home/rwild/gcc/build-hppa2.0w-hp-hpux11.11&;t t function.

This is due to the large number of commands added to $extrasub in
configure.ac (around 80 in this case); the limit is (autoconf.info):

|   HP-UX sed has a limit of 99
| commands (not counting `:' commands) and 48 labels, which can not
| be circumvented by using more than one script file.  [...]

It seems to be possible for now to work around it by hacking Autoconf's
status.m4 to omit the 't t' commands:

$ diff -C 2 config.status config.status1
*** config.status   Mon Aug 31 18:41:02 2009
--- config.status   Mon Aug 31 18:40:49 2009
***
*** 1079,1093 
  :t
  /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
! s|@configure_input@|$ac_sed_conf_input|;t t
! s&@top_builddir@&$ac_top_builddir_sub&;t t
! s&@top_build_prefix@&$ac_top_build_prefix&;t t
! s&@srcdir@&$ac_srcdir&;t t
! s&@abs_srcdir@&$ac_abs_srcdir&;t t
! s&@top_srcdir@&$ac_top_srcdir&;t t
! s&@abs_top_srcdir@&$ac_abs_top_srcdir&;t t
! s&@builddir@&$ac_builddir&;t t
! s&@abs_builddir@&$ac_abs_builddir&;t t
! s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
! s&@INSTALL@&$ac_INSTALL&;t t
  $ac_datarootdir_hack
  "
--- 1079,1093 
  :t
  /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
! s|@configure_input@|$ac_sed_conf_input|
! s&@top_builddir@&$ac_top_builddir_sub&
! s&@top_build_prefix@&$ac_top_build_prefix&
! s&@srcdir@&$ac_srcdir&
! s&@abs_srcdir@&$ac_abs_srcdir&
! s&@top_srcdir@&$ac_top_srcdir&
! s&@abs_top_srcdir@&$ac_abs_top_srcdir&
! s&@builddir@&$ac_builddir&
! s&@abs_builddir@&$ac_abs_builddir&
! s&@abs_top_builddir@&$ac_abs_top_builddir&
! s&@INSTALL@&$ac_INSTALL&
  $ac_datarootdir_hack
  "


but in the long run (or short, if you add another couple of directories)
we might have to either
- require a better sed,
- split the script in two inside Autoconf (if $extrasub is nonempty),
- allow for extra sed scripts here.

Should I write a patch for omitting the 't t'?

Cheers,
Ralf

--enable-languages=c --enable-build-with-cxx

[Ralf Wildenhues]

Currently, --enable-languages=c --enable-build-with-cxx fails because
neither the C++ compiler nor libstdc++-v3 are built in Stage 1, but in
Stage 2, CXX is set to .../prev-gcc/g++ and other variables are set
accordingly.  Is this combination supposed to work?

If yes, is it supposed to only build the C++ compiler and associated
library in Stage 1 but not in later stages?

If no (to the first question), then shouldn't configure fail early?

(This is related to PR bootstrap/40950, but only in that it causes a
similarly-looking failure, AFAICS.)

Thanks,
Ralf

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 09:06:20PM CEST:
> On 08/31/2009 08:54 PM, Ralf Wildenhues wrote:
> >While still working to prove Bob wrong on the fixincludes sed issues,
> 
> Bob?

Bruce; sorry about that, Bruce!

> >- require a better sed,
> >- split the script in two inside Autoconf (if $extrasub is nonempty),
> >- allow for extra sed scripts here.
> 
> Like a new variable $ac_presub, that is executed as
> 
>   sed "$ac_presub" | sed "$extrasub; other config.status substitutions"
> 
> ?  I think this is what I like the most.

Yes, but it is still not extensible.  What if GCC needs three or more
scripts in the future?  Autoconf cannot split scripts, they might be
intertwined, or they might come from different third-party macros.
Granted, this whole concept is a bit flawed, and too low-level.

In fact, I think this API shouldn't be even more encouraged.  It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).

> Does the following plan
> make sense to you as Autoconf maintainer? (CCing autoc...@gnu.org).

Well maybe, but I'm not sure whether we want another rush, nor why we
need to decide this alongside with the extrasub issue.  override.m4
is also about relaxing release order requirements, no?

Cheers,
Ralf

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

Hello Jeff,

* Jeff Law wrote on Mon, Aug 31, 2009 at 10:00:57PM CEST:
> On 08/31/09 12:54, Ralf Wildenhues wrote:
> >I found out that current toplevel config.status hits the program length
> >limit of HP-UX 11.11 sed:

> >This is due to the large number of commands added to $extrasub in
> >configure.ac (around 80 in this case); the limit is (autoconf.info):
> It's been the case for eons that various configury bits have blown
> out the hpux-sed.

Configury bits of GCC and src projects, or of Autoconf or other
Autoconf-using projects?

>  I vaguely recall hacks in Cygnus's trees to split
> big sed scripts into smaller pieces -- but with  my hpux machines
> gathering layers of dust, I haven't kept a copy of the script.

Autoconf used to use sed for the bulk of the substitutions (it uses awk
now, which allows for better complexity), and it used to split its sed
scripts into chunks fit for HP-UX sed.

Cheers,
Ralf

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST:
> >In fact, I think this API shouldn't be even more encouraged.  It doesn't
> >really fix things in an elegant way, and it doesn't help for other
> >pending issues in the GCC tree (such as the multilib fixups that aren't
> >applied in all cases; report coming up).
> 
> I agree.  However, I did not have any alternative idea when I
> started using extrasub, and do not have one now. :-(

Just use
  AC_CONFIG_COMMANDS([Makefile], [commands to fix up Makefile])

and do whatever $extrasub did yourself in those commands.

multilib and Makefile regeneration

[Ralf Wildenhues]

Hello,

the current multilibs support code is a bit racy, in a few ways.  The
following might be a bit technical, but I'm trying to gauge where to go
from here, even if this is not fixed right away.

gcc/config/multi.m4 provides AM_ENABLE_MULTILIB which allows to specify
the Makefile which is to be multilibbed.  The macro adds another config
command (through obsolete AC_CONFIG_COMMANDS) to config.status.
Autoconf names the command tag 'default-N' with N the index of
additional commands (that usually comes out as 1 or 2).  Now, that means

  ./config.status

or
  ./config.status some/Makefile default-N

run in some target library build directory, will update some/Makefile
properly (including the multilib adjustments), but
  ./config.status some/Makefile

will not (and that latter command can be triggered by 'make' when
$srcdir/some/Makefile.in is newer than some/Makefile).  There are a few
more interesting data points:

The AC_CONFIG_FILES API allows to associate with an output file
(some/Makefile) additional commands (e.g., precisely those multilib
commands).  However, it is not possible to amend to these commands, or
specify AC_CONFIG_FILES(some/file, , additional-commands) twice.  So
while we could make AM_ENABLE_MULTILIB call AC_CONFIG_FILES for the
top Makefile of the library directory, that would require the libraries
to all remove that Makefile from their own AC_CONFIG_FILES list
(and prevent them from using any other extra commands they might want
to use).

It would be nice to have an API that would either

1) allow us to add 'default-N' to the automake rule for regenerating the
Makefile (there's the am__depfiles_maybe hack already, but that's an
internal automake detail) (this would be an Automake task),

2) allow us to add additional commands to an AC_CONFIG_ instance
later (this would be an Autoconf task, and it could allow us to
eliminate am__depfiles_maybe in the future),

3) or simply add to multi.m4 an API to provide a macro that itself
instantiated
AC_CONFIG_FILES(some/Makefile,,
multi-lib-commands plus more-user-commands)

for example through
AM_MULTILIB_FILES(some/Makefile, [inputs], [more-user-commands])

The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2).  Something like
  AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
   [more-init-cmds])

but then the order of issuing this and the respective
  AC_CONFIG_FILES(some/Makefile)

would be significant.  I don't see any way to avoid this.

Cheers,
Ralf

Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place

[Ralf Wildenhues]

Hello Jakub,

* Jakub Jelinek wrote on Thu, Sep 03, 2009 at 10:51:42AM CEST:
> On Wed, Sep 02, 2009 at 11:08:19PM -0600, Ryan Hill wrote:
> > 
> > I was just wondering if there was any consensus among distros about where to
> > move these.  We cannot keep the .py files in the location they're currently
> > installed; ldconfig is far too noisy about it:
> > 
> >   /sbin/ldconfig: 
> > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/libstdc++.so.6.0.14-gdb.py
> >  is not an ELF file - it has the wrong magic bytes at the start.

> ldconfig by default certainly doesn't search gcc private directories, if you
> let ldconfig search there by adding it to its configuration, it would be
> admin error.

'libtool --mode=install' will invoke 'ldconfig -n' on the directory
it installs libraries in (e.g., in order to fix symlinks), which will
cause this complaint as well.

Cheers,
Ralf

Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx

[Ralf Wildenhues]

* Pedro Lamarão wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST:
> 2009/8/26 Ralf Wildenhues:
> 
> >> >.../../trunk/libcpp/../include/libiberty.h:106: error: new declaration
> >> >‘char* basename(const char*)’
> >> >/usr/include/string.h:601: error: ambiguates old declaration ‘const
> >> >char* basename(const char*)’
> >>
> >> The problem is that AC_CHECK_DECLS gets confused by overloaded
> >> functions, and glibc 2.10 has overloaded declarations of basename
> >> and some other string functions for const-correctness.
> >
> > Could you show the config.log snippet that shows the failed test?
> > Is this a new error due to the autotools upgrade, or new due to
> > glibc 2.10?
> 
> I think this is new in glibc 2.10, for the reasons given by Jason Merrill 
> above.
> I've discussed this problem with Jerry Quinn before, and he had a
> tentative patch that worked for me.
> As I understand things, this patch is on hold waiting for a solution
> to the bootstrap comparison problem being discussed in another thread.
> 
> I am waiting for a solution to these problems to continue work on the
> std::sort gcc-in-cxx subproject; keeping all these patches up to date
> with trunk is too difficult for me right now.
> Currently, I have a patch to an old revision of the trunk.

Well, can you post the patch, or did I somehow miss it on the list?
I'd be particularly interested if it tries to fix the Autoconf test
in some sensible way.

Thanks,
Ralf

Re: multilib and Makefile regeneration

[Ralf Wildenhues]

<http://thread.gmane.org/gmane.comp.gcc.devel/108469>

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 11:53:17PM CEST:
> On 08/31/2009 11:11 PM, Ralf Wildenhues wrote:
> >The easiest for now would be (3), the coolest, most difficult and
> >probably most dangerous one would be (2).  Something like
> >   AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
> >[more-init-cmds])
> >
> >but then the order of issuing this and the respective
> >   AC_CONFIG_FILES(some/Makefile)
> >
> >would be significant.  I don't see any way to avoid this.
> 
> You could specify that AC_CONFIG_FILES comes first, and *_COMMANDS
> occurrences come later in the order that appears in the source (and
> do nothing unless the corresponding AC_CONFIG_FILES exists).

Yes; but this would not solve the issue that, when interrupted, we could
end up with the wrong, intermediate Makefile.  I don't want to add a new
API that has known deficiencies.

Maybe going via an explicit intermediate file is better, a la
  AC_CONFIG_FILES([some/Makefile.ml:some/Makefile.in])
  AM_MULTILIB_FILES([some/Makefile:some/Makefile.ml])

but that requires that config.status is passed files in the right order
and rebuild dependencies in the Makefile are right.  Currently, however,
automake doesn't cope with something like the above at all ...

Cheers,
Ralf

combined enable-build-with-cxx bootstrap comparison failure

[Ralf Wildenhues]

If I combine GCC and binutils-gdb, bootstrap, enable gold, use
--enable-build-with-cxx:

configured by ../src/configure, generated by GNU Autoconf 2.64,
  with options " '-C' '--enable-maintainer-mode' '--enable-objc-gc' 
'--enable-libssp' '--enable-sim' '--enable-gold' '--enable-build-with-cxx' 
'CC=/home/ralf/recent/bin/gcc' 'CXX=/home/ralf/recent/bin/g++' 
'--enable-languages=c,c++,fortran,java,objc,obj-c++'"

and a very recent GCC as $build compiler:
| gcc (GCC) 4.5.0 20090916 (experimental)

GMP 4.2.1, MPFR 3.0.0.dev, then I get a bootstrap comparison failure:

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
gold/i386.o differs
gold/stringpool.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/guard.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/debug.o differs
make[2]: *** [compare] Error 1

Now, what do I do to (help) debug this?  Open a PR?  Attach some of the
object files (which)?  How do I know this is the same as (or different
from) ?

Note the comparison failure does not occur if I
- don't build from a combined tree (i.e., using binutils for Debian
  2.18.0.20080103), or
- turn off both of --enable-gold --enable-build-with-cxx (I cannot turn
  off the latter without turning off the former, see mail on gcc-patches.)

Thanks,
Ralf

Re: libtool update?

[Ralf Wildenhues]

Hello Rainer,

* Rainer Emrich wrote on Wed, Nov 11, 2009 at 05:47:13PM CET:
> Any news on libtool? Does anybody care to update?

Work in progress:


Since then, I found a couple of issues, one of which was a
bug in the sync and the other I'm not yet sure whether it
is a GCC configury or Libtool upstream bug.

I hope to get to it within the next couple of weekends,
but I'm swamped ATM (of course won't mind being beaten
to if someone feels so inclined).

Cheers,
Ralf

Re: i370 port - constructing compile script

[Ralf Wildenhues]

Hello Paul,

* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
> Well, I have good news to report.  The restructuring was a success.
> 
> That means with those 30-odd changes to the configure scripts, I
> was able to get an auto-host.h built that allowed me to take the
> generated source and compile it with my own scripts as per
> normal.

It would be a good idea if you took the extra mile and reported all
these changes to the bug-autoconf mailing list, so it could be fixed
for good there.

Furthermore, it would be really good if we could get Autoconf to build
and run on your system, so you could run its test suite there.  That
would provide much better coverage of all the issues that would need
fixing, and allow us to fix them once in the macros, instead of having
you do this repeatedly in every configure script.

However, Autoconf requires Perl and GNU M4 (and some shell environment
as well as a make program), so I'm not sure whether it is possible to
get to this point.

Thanks,
Ralf

Re: i370 port - constructing compile script

[Ralf Wildenhues]

* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
> >Well, the configure process should result in the variable LIBOBJS
> >in the generated libiberty Makefile to be set to list of objects
> >containing implementations of replacement system routines.
> >
> >So if you do not have HAVE_STRCASECMP in config.h, you should
> >have been getting strcasecmp.o in LIBOBJS ...
> 
> And indeed, I sort of am.
> 
> LIBOBJS includes a strcasecmp.s$U.s
> 
> That suffix is certainly strange-looking though.  I checked in
> config.log and I can see that it automatically detected that
> my "object code" has a ".s" extension, which is basically
> correct given that I forced the "-S" option.

Why do you pass -S in the compiler script?  configure sort of expects
that neither -S nor -c are passed automatically.

> In addition, there's another problem - it has included strncmp
> in the list.  I had a look and it appears that it attempts to
> actually run the program to see if strncmp works.  That's
> not going to work in a cross-compile environment though.
> So maybe it assumes the worst.

Yes.  The macro that does this is libiberty_AC_FUNC_STRNCMP in
libiberty/aclocal.m4.  In a cross-compile situation, the macro assumes
that strncmp does not work.  It uses the cache variable
ac_cv_func_strncmp_works, which you can set if you need to override the
decision, e.g.:
  ac_cv_func_strncmp_works=yes
  export ac_cv_func_strncmp_works
  ../gcc/configure ...

A more permanent solution would be to set this correctly based upon
$host in libiberty/configure.ac and regenerate libiberty/configure with
autoconf.

> And then I changed ac_libobjs to stop putting that $U in there as
> well, and I finally got my strcasecmp.

Why does that $U hurt you?  It should get expanded to nothing later on.
(It is a remainder from some ansi2knr scheme.)

> Note that I also seem to be getting strerror.  It's on the list
> of "required files", even though it isn't required or wanted.
> configure correctly detected that I already had strerror.
> I manually excluded that from my list of files and now things
> are looking good again - including strcasecmp being
> automatically selected in the build process.  :-)

Again, rather than hacking the generated configure script, I think you
should start modifying the input files, configure.ac in this case, for
permanent solutions to your build issues.  Even if you're only changing
a few lines, doing it each time you want to build a different GCC
version is an unnecessary burden.

Thanks,
Ralf

Re: MELT help: how to autoconf-igure makefile fragments?

[Ralf Wildenhues]

* Basile STARYNKEVITCH wrote on Fri, Nov 27, 2009 at 05:57:02PM CET:
> Does anyone have hints on what kind of stuff I should add to have a
> makefile fragment like [a future file] gcc/melt-module.mk.in
> expanded into a melt-module.mk thru autoconf tricks?

Add
  AC_CONFIG_FILES([melt-module.mk.in])

to gcc/configure.ac.  Run autoconf once in gcc/.

Cheers,
Ralf

Re: GCC 4.5 Status Report (2009-12-02)

[Ralf Wildenhues]

Hello Richard,

* Richard Guenther wrote on Wed, Dec 02, 2009 at 01:32:24PM CET:
> The trunk is in regression and documentation fixes only mode,
> Stage 3 has ended yesterday.  Release branch rules are now
> in effect for all changes to trunk that touch release critical
> parts of the compiler (primary and secondary targets, C and
> C++ and their runtimes).

> We seem to get more testing of GCC 4.5 in the field now, so
> bugs are more frequently reported now.  Please help in
> analyzing (and possibly finding duplicates) and fixing bugs.

The Libtool update would fix a couple of bugs, one of which is important
for MinGW at least.  Any chance this could still be considered?

Thanks, and sorry I didn't get it sent earlier,
Ralf

Re: GCC 4.5 Status Report (2009-12-02)

[Ralf Wildenhues]

* Jack Howarth wrote on Thu, Dec 03, 2009 at 03:22:56AM CET:
> On Wed, Dec 02, 2009 at 11:08:49PM +0100, Richard Guenther wrote:
> > On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
> > > 
> > > The Libtool update would fix a couple of bugs, one of which is important
> > > for mi...@least.  Any chance this could still be considered?
> > 
> > I think this is up to you - I can't asses the benefits or risks
> > of the change.

Well, the benefits are on the table: fixes important for MinGW, cross
compiles for HP-UX, shared libraries with binutils on AIX, less noise
and thus (hopefully) less conflicts with future merges of configure
scripts; the risks are build breakage on some systems or with some
setups (that are not exercised with the Libtool test suite), and some
developers rightly being angry at me for such a late change.

I can only offer to help with any breakage as resources permit
(latency < 24hrs for the next 8 days at least).  I expect any serious
breakage to show up within the following time GCC is bootstrapped on
the system in question.

> Actually, I would be very interested in testing the proposed libtool patch
> to verify that this new change works as advertised (coupled with the pending
> dsymutil fixes...http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00094.html
> and http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00096.html). This should 
> finally
> fix up darwin for properly debugging in libstdc++ and libjava which both
> use such libtool convenience archives.

Do you need anything to test the patch before it is applied, or did you
mean to test it when it has been applied?  (To test this patch that does
not include regenerated files, apply it, then
  find $srcdir -name configure | while read f; do
(cd $(dirname $f) && autoconf)
  done

then build.

Thanks,
Ralf

Re: GCC 4.5 Status Report (2009-12-02)

[Ralf Wildenhues]

* Jack Howarth wrote on Thu, Dec 03, 2009 at 10:15:59PM CET:
> On Thu, Dec 03, 2009 at 09:32:38PM +0100, Ralf Wildenhues wrote:
> > 
> > Do you need anything to test the patch before it is applied, or did you
> > mean to test it when it has been applied?  (To test this patch that does
> > not include regenerated files, apply it, then
> >   find $srcdir -name configure | while read f; do
> > (cd $(dirname $f) && autoconf)
> >   done

>Are you sure one doesn't have to do any magic with the autoconf files
> to make sure that the proper config directories are used. Ages ago when
> we regenerating configure in the fink gcc42 packages, we had to use...

Yeah, you're right that in general, more regeneration is needed.
I typically let --enable-maintainer-mode do that job, but a recheck
triggered by 'make' reuses the cache files from the first configure.
(That only regenerates the directories used during that build, of
course.)

With --enable-maintainer-mode, GCC trunk should have all rebuild rules
and dependencies in place.

Cheers,
Ralf

Re: Combined tree fails to build -- libtool version mismatch?

[Ralf Wildenhues]

* Paolo Bonzini wrote on Sat, Jan 09, 2010 at 03:26:33PM CET:
> 
> Binutils should adopt GCC's libtool.m4, ltmain.sh, lt~obsolete.m4,
> ltoptions.m4, ltsugar.m4, ltversion.m4 and src should rerun autoconf
> on all of its scripts (CCing gdb, newlib and cygwin mailing lists).

I just pinged that very change this morning.  I will commit it later
tonight.

Cheers,
Ralf

Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)

[Ralf Wildenhues]

[ trimming Cc: ]

Hello,

* Joern Rennecke wrote on Tue, Feb 09, 2010 at 11:46:15AM CET:
> However, I wonder if there is a better way to do the string processing -
> I only do autoconf hacking sporadically, and my code looks somewhat
> different from the original style.

I haven't had a chance to look at it in detail, but:

> 2010-02-09  Joern Rennecke  
> 
> libcpp:
>   * aclocal (_AC_CHECK_PROTO_BODY): New shell function.
>   (AC_CHECK_PROTO, _AC_CHECK_PROTOS, AC_CHECK_PROTOS): New macros.
>   * configure.ac: Use AC_CHECK_PROTOS instead of AC_CHECK_DECLS.
>   * configure: Regenerate.

> --- libcpp/aclocal.m4 (revision 156598)
> +++ libcpp/aclocal.m4 (working copy)
> @@ -22,3 +22,75 @@ m4_include([../config/lib-link.m4])
>  m4_include([../config/lib-prefix.m4])
>  m4_include([../config/override.m4])
>  m4_include([../config/warnings.m4])
> +
> +##  ##
> +## Checking for declared symbols.   ##
> +## This is like *AC_CHECK_DECL*, except that for c++, we may use a  ##
> +## prototype to check for a (possibly overloaded) function. ##
> +##  ##
> +
> +
> +# _AC_CHECK_PROTO_BODY
> +# ---
> +# Shell function body for AC_CHECK_PROTO.
> +m4_define([_AC_CHECK_PROTO_BODY],
> +[  AS_LINENO_PUSH([$[]1])
> +  [as_decl_name=`echo $][2|sed 's/(.*//'`]
> +  [as_decl_use=`echo $][2|sed -e 's/(/((/' -e 's/\()\|,\)/) 0&/'`]

sed alternation \| is not portable.

> +  AC_CACHE_CHECK([whether $as_decl_name is declared], [$[]3],
> +  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$[]4],
> +...@%:@ifndef $[]as_decl_name
> +...@%:@ifdef __cplusplus
> +  $[]as_decl_type

What is this variable?  It doesn't seem to be defined anywhere.

> +  (void) $[]as_decl_use;
> +...@%:@else
> +  (void) $[]as_decl_name;
> +...@%:@endif
> +...@%:@endif
> +])],
> +[AS_VAR_SET([$[]3], [yes])],
> +[AS_VAR_SET([$[]3], [no])])])
> +  AS_LINENO_POP
> +])# _AC_CHECK_PROTO_BODY
[...]

Cheers,
Ralf

Re: error: cannot compute suffix of object files: cannot compile

[Ralf Wildenhues]

Hi Bruce,

* Bruce Korb wrote on Fri, Mar 19, 2010 at 05:22:15PM CET:
> On Fri, Mar 19, 2010 at 9:12 AM, Richard Guenther wrote:
> > On Fri, Mar 19, 2010 at 5:02 PM, Bruce Korb wrote:
> >> What does this message really mean?
> >> i.e. What should I do about it?
> >
> > run ldconfig or use binaries from
> > http://download.opensuse.org/repositories/devel:/gcc/openSUSE_11.1
> 
> I'm building the binaries.  It seems some update or another caused
> the ld.so.cache to become out of date with respect to ld.so.conf.
> Not something I expected.  Thank you!

'make install' should cause libtool to invoke '/sbin/ldconfig -n
/usr/local/lib'.  When doing a DESTDIR install, libtool should
warn you that you may need to run 'libtool --finish /usr/local/lib'
after moving libraries to their final place (which then would run
ldconfig).  AFAIK mpc uses libtool.

Which piece was missing for you?

Thanks,
Ralf

Re: expected behavior for --with-cloog?

[Ralf Wildenhues]

Hello Jack,

* Jack Howarth wrote on Fri, Mar 26, 2010 at 01:13:16AM CET:
>While testing a patch to update the minimum version
> of cloog-ppl in gcc trunk...

> --- configure.ac(revision 157732)
> +++ configure.ac(working copy)
> @@ -1612,9 +1612,9 @@
>  if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
>saved_CFLAGS="$CFLAGS"
>CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
> -  AC_MSG_CHECKING([for version 0.15.5 (or later revision) of CLooG])
> +  AC_MSG_CHECKING([for version 0.15.9 (or later revision) of CLooG])
>AC_TRY_COMPILE([#include "cloog/cloog.h"],[
> -  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || 
> CLOOG_VERSION_REVISION < 5
> +  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || 
> CLOOG_VERSION_REVISION < 9
>choke me
>#endif
>], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
> 
> I noticed that this test only returns...
> 
> checking for version 0.15.9 (or later revision) of CLooG... no
> 
> for...
> 
>   ../gcc-4.5-20100325/configure --prefix=/sw  --prefix=/sw/lib/gcc4.5 
> --mandir=/sw/share/man --infodir=/sw/share/info 
> --enable-languages=c,c++,fortran,objc,obj-c++,java \
>  --with-gmp=/sw  --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw 
> --with-mpc=/sw --with-system-zlib \
>  --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib 
> --disable-libjava-multilib --enable-checking=release
> 
> ...when a cloog-ppl earlier than 0.15.9 is installed. Shouldn't configure fail
> outright in this case since the user obviously intended cloog to be used? 
> Currently
> configure proceeds to set up a build without graphite support.

Well, what does config.log tell you why it was not detected?

Cheers,
Ralf

Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

Hello gcc and libtool lists,

Summary: both Autoconf-generated configure tests as well as some Libtool
construct invoke undefined behavior.  Question is how to deal with it,
and whether GCC, as QoI, may want to define behavior in these cases.


1) Autoconf-generated configure tests often fake the prototype of some
function; e.g., AC_CHECK_FUNC([func]) uses
  char func();

and tries to link that.  Using this is undefined according to C99, if
func has a different actual prototype, and when all system libraries are
LTO'ed, gcc -flto may even detect this kind of inconsistency and could
act accordingly (nasal demons and such).


2) libtool has a feature that makes it extract symbol lists from
objects and turn them into fake declarations and function/object
pointers: fake static preloaded modules.

It currently works by running nm or a similar tool over the object, then
converting the output with a couple of sed script or so
(global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
synthesized extra source file that then contains code like this:

extern int func();
extern char variable;

typedef struct {
  const char *name;
  void *address;
} lt_dlsymlist;

extern const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[];
const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{  { "@PROGRAM@", (void *) 0 },
  {"func", (void *) &func},
  {"variable", (void *) &variable},
  {0, (void *) 0}
};

This is invoking undefined behavior in a couple of respects:

a) Pointers to functions are stored in pointer-to-void variables.
This could be fixed with an incompatible API change to using a union of
object and function pointer, I guess.

b) The symbols 'func' and 'variable' likely have the wrong prototypes,
i.e., elsewhere, they might be declared as

  void func(int, double);
  double variable[42];

instead.  I haven't come across any actual issues with this yet, except
now LTO may rightfully complain about it.


Question is, what can we do about this?  We could ensure to never pass
-flto or -fwhopr to the compilation of the libtool symfile object, and
remove it from some or all link tests done in configure.  That's ugly.
Would that even be sufficient though?  Conversely, would GCC developers
be willing to agree that, when GCC detects such inconsistencies, it
wouldn't take adverse advantage of it (e.g., by turning off LTO in this
case, or similar)?

Other possibilities for Autoconf would be to work toward a new set of
checking macros (or extensions of current one) where the configure.ac
author passes a full prototype for each function to check (Autoconf
could keep a list of known prototypes for often-checked functions).
I'm not sure how to fix the libtool symfile in a C99-conforming way.

Thanks for reading this far.

Cheers,
Ralf

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

* Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
> On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
> > 1) Autoconf-generated configure tests often fake the prototype of some
> > function; e.g., AC_CHECK_FUNC([func]) uses
> >  char func();
> >
> > and tries to link that.  Using this is undefined according to C99, if
> > func has a different actual prototype, and when all system libraries are
> > LTO'ed, gcc -flto may even detect this kind of inconsistency and could
> > act accordingly (nasal demons and such).
> 
> I suppose autoconf cannot do this for C++ functions then, because
> of mangling issues?

Correct.  For C++ libraries, it is more typical to just write a complete
test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.

FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
declarations given by the user (in order to support overloaded
basename, for example).

> Note that the only thing GCC with LTO might do here is to issue
> a diagnostic (which of course might confuse the configure script),
> but we cannot really reject such programs (as such errors are
> unfortunately very common) and thus defer any problems to
> link- and/or runtime.

That's almost exactly the kind of semantics I would like to see.
Can we get this documented in the manual?  Something like this.
Note that it would explicitly contradict one of the design goals
listed in lto.pdf, which is that conflicting declarations might
provoke an error; so really GCC developers should make a conscious
design decision here.


* doc/invoke.texi (Optimize Options): Document that LTO
won't remove object access purely due to incompatible
declarations.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2226cad..85f9c5f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -7294,6 +7294,12 @@ regular (non-LTO) compilation.  This means that if your 
build process
 was mixing languages before, all you need to add is @option{-flto} to
 all the compile and link commands.
 
+If LTO encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to ISO C99 6.2.7), it might produce a warning, but
+this fact alone will not cause an access to an object to be optimized
+away.
+
 If object files containing GIMPLE bytecode are stored in a library
 archive, say @file{libfoo.a}, it is possible to extract and use them
 in an LTO link if you are using @command{gold} as the linker (which,


(In practice, Autoconf does not support -Werror at configure time; this
issue only reinforces that.)

> > b) The symbols 'func' and 'variable' likely have the wrong prototypes,
> > i.e., elsewhere, they might be declared as
> >
> >  void func(int, double);
> >  double variable[42];
> >
> > instead.  I haven't come across any actual issues with this yet, except
> > now LTO may rightfully complain about it.
> 
> Same issue as above.  We try to handle it - there might be bugs
> in the current implementation of LTO though.

Bugs are no problem as long as they are acknowledged as such.  I desire
future compatibility, i.e., being fairly certain autotools don't regress
just because of a good improvement in some other tool.  Dealing with
existing cruft is abundant in autotools.

> > Question is, what can we do about this?  We could ensure to never pass
> > -flto or -fwhopr to the compilation of the libtool symfile object, and
> > remove it from some or all link tests done in configure.  That's ugly.
> > Would that even be sufficient though?  Conversely, would GCC developers
> > be willing to agree that, when GCC detects such inconsistencies, it
> > wouldn't take adverse advantage of it (e.g., by turning off LTO in this
> > case, or similar)?
> >
> > Other possibilities for Autoconf would be to work toward a new set of
> > checking macros (or extensions of current one) where the configure.ac
> > author passes a full prototype for each function to check (Autoconf
> > could keep a list of known prototypes for often-checked functions).
> > I'm not sure how to fix the libtool symfile in a C99-conforming way.
> 
> I'd say wait and see.  What would be nice to have is a few testcases
> that cover the autoconf cases in the GCC testsuite (feel free to
> just file them into bugzilla).

I have been doing just that for the failures I've found so far.  I'll
add some more for stuff that ought to work.

> We really do not want to break
> working setups with LTO - any fancy ODR violation diagnostics
> should IMHO be optional, only things that LTO does not get
> correct are currently diagnosed IIRC.

That's a good sentiment.  autotools shouldn't stand on slippery
slope more than it has to.

Thanks,
Ralf

Re: Bootstrap failures on i386-pc-solaris2.10

[Ralf Wildenhues]

* Rainer Orth wrote on Thu, Apr 01, 2010 at 04:24:40PM CEST:
> The --disable-multilib option has been broken by a recent patch.  This
> is a known bug and will hopefully be fixed soon.

Should be fixed now with r157916 which reverts the offending commit.
Apologies for the breakage.

Cheers,
Ralf

how to "parse" gcc -v output

[Ralf Wildenhues]

Hello gcc and libtool lists,

Both Autoconf and Libtool have macros which "parse" output of 'gcc -v'
for some link commands.  Yes, I know, almost by definition this is not
"parseable" text, but GCC does not provide a stable API that allows to
find out
- which libraries it needs to link shared modules against, or
- which libraries are needed to let g++ link mixed C++/Fortran code,
so in practice there is no other choice (unless the user provides this
information).

In some situations, esp. when -flto is used, -v output consists of many
parts.  Libtool needs to know which parts it can drop, or needs to look
at.  Can we be fairly confident that, iff there is a line matching
  '^ [^ ].*collect'

it will pick the one line that contains the verbose driver invocation
that lets us pick up init/fini objects as well as compiler libs to link
against?  I.e., can we assume the leading space to be stable, and the
'collect2' name to be fairly stable across GCC versions and systems?
It seems to work with all versions starting from 2.95 on those systems
where collect2 is used (the 2.7.2.3 I can still find here matches
'^ [^ ].*ld ').  If we don't find such a line, then picking the first
line with a single leading space seems prudent.  That would e.g. match
linking with ld on FreeBSD.

If not, can you suggest a different approach?  Should we be using -###
instead?  Looking for the first line with leading space and containing
' -L' (I think Alexandre Oliva suggested that a while ago)?

I'm willing to add API to a future GCC if that's the only viable way
(that way at least we have a fixed set of past and present versions to
match).

Thanks,
Ralf

Re: how to "parse" gcc -v output

[Ralf Wildenhues]

* Joseph S. Myers wrote on Sun, Apr 04, 2010 at 11:40:19AM CEST:
> On Sun, 4 Apr 2010, Ralf Wildenhues wrote:
> 
> > - which libraries it needs to link shared modules against, or
> > - which libraries are needed to let g++ link mixed C++/Fortran code,
> > so in practice there is no other choice (unless the user provides this
> > information).
> [...]
> > I'm willing to add API to a future GCC if that's the only viable way
> > (that way at least we have a fixed set of past and present versions to
> > match).
> 
> For both of the above, at least on ELF systems, the correct thing to do is 
> to make GCC (used by any of the drivers "gcc", "g++", etc.) do the right 
> thing by default: link with the libraries required by the objects being 
> linked in, using those appropriate for shared libraries if -shared is 
> passed, and respecting options such as -static-libstdc++.  That is, make 
> the driver/collect2 combination smart enough that libtool does not need to 
> query this information.

How would g++ know that part of the objects were from Fortran sources?
Maybe from a different (non-GCC) Fortran compiler, that needs a
different set of libraries at link time?  I don't see how this
information can fully be embedded in GCC.

Also, in order to actually be able to run programs, libtool needs to
also be able to ask for paths missing in the run paths, so they can be
added to the program *if the user so desires* and if they are not in the
default run path.

Until these are available, the other information are still useful to,
and needed for, Libtool and Autoconf.

Thanks,
Ralf

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

Hello Leif,

* Leif Ekblad wrote on Sun, Apr 25, 2010 at 12:56:21PM CEST:
> The primary issue I had was that some basic configuration was
> never updated to GCC (libtool). Because this was the place where the
> targets and stuff was defined, it was not even possible to submit specific
> patches in the first place, because they would fail without this refresh.

Wait, Libtool has a patch from you from 2006-01-12 in its tree,

Is that the one you're talking about?

Was it that GCC took long to merge the Libtool changes?  Did you ever
ping that?

Nowadays the Libtool sources in GCC track upstream more closely than
they used to do, and updating them should be fairly straightforward.

Thanks,
Ralf

Re: Why not contribute? (to GCC)

[Ralf Wildenhues]

I don't like self-advertising, but ...

* Steven Bosscher wrote on Sun, Apr 25, 2010 at 03:05:45PM CEST:
> Perhaps it is possible to create some kind of check-patch script for
> GCC too, e.g. one that checks the following things at least:
> * ChangeLog presence
> * ChangeLog format and completeness
> * formatting / coding style of the patch itself
> 
> We should perhaps make tools available in contrib/ that help people
> set up things properly for patch submission. For example Diego had a
> script that extracts a skeleton ChangeLog from a patch, perhaps it
> should be put in contrib/ and advertised somewhere (e.g. wiki).

FWIW, I wrote vc-chlog a while ago (ships together with vc-dwim[1]) which
IMVHO is fairly accurate at creating stub ChangeLog entries if you have
Exuberant Ctags installed.  Without it, updates to the GCC build system
would have been rather painful.

I would add blurb about it in the wiki if that is acceptable.

Cheers,
Ralf

[1] www.gnu.org/software/vc-dwim/

Re: gcc and autoconf 2.61

[Ralf Wildenhues]

Hi Jack,

* Jack Howarth wrote on Wed, Dec 03, 2008 at 06:13:20PM CET:
>  When will gcc switch from autoconf 2.59 to
> autoconf 2.61? Both darwin and the newer linux
> releases have migrated to the newer autoconf.
> Is that a change slated for gcc 4.5?

I have some patches to get the GCC tree more or less in shape
for git autotools, with the idea being that the most recent
stable version be used when merging these patches.  In some
way I can only hope that GCC 4.5 branching take a little longer
so Automake 1.11 can be released first ... ;-)
(and an Autoconf 2.64 release would be good as well, since that
would probably shave MB worth of size off the GCC tarball.)

But anyway, the idea was to cleanup and post patches sometime
soon after 4.4 branches.  And no, I don't think it's worth
switching to any version older than the latest stable one.

Cheers,
Ralf

Re: libjava and raw_cxx

[Ralf Wildenhues]

* Andreas Schwab wrote on Fri, Dec 12, 2008 at 06:43:45PM CET:
> Paolo Bonzini  writes:
> 
> > I think it's easiest to define a cache variable somewhere so that the
> > test is forced to pass.
> 
> There is no cache variable associated with this test.

That's an independent bug which needs to be fixed in Libtool anyway.
Thanks for the report.  I will fix it upstream.

I haven't understood the original bug yet, in the sense that I don't 
quite understand the requirements that GCC has for Libtool's macros.
Obviously, in this case link tests are not explicitly forbidden, but
implicitly.  How can Libtool know when they are supposed to work and
when not?  What can we assume to work?

If I see correctly, then this particular test tries to find out whether
-rpath sets DT_RUNPATH in addition to DT_RPATH.  Unfortunately, some
distributions patch binutils to add that, but at the same time made no
other change to ld which would make this behavior apparent to the
outside world.  So I don't see how to avoid a test here, and hard-coding
"yes" for gentoo and "no" for most other distros sounds pretty ugly.

Thanks,
Ralf

Re: libjava and raw_cxx

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Dec 12, 2008 at 10:14:15PM CET:
> > 
> > Yes, this is true.  But even though the test that sets
> > shlibpath_overrides_runpath is run for every compiler, only one result
> > is then used for all link commands, and that happens to be the result of
> > the C++ test.
> 
> That's the bug then I'd say... Ralf what do you think?

Yes, my intention was to use one cache variable for the test, as opposed
to one per compiler, which should fix this to take the result of the
first compiler (C if not disabled).

Strictly speaking, that is not precise enough: the user could be using
different linkers for different compilers.  I don't think we need to
support such a setup on GNU/Linux, though.

Cheers,
Ralf

gcj -v --help: ecj switches

[Ralf Wildenhues]

Hello,

I have a patch (accompanying those other ones on gcc-paches) to fix

--- a/gcc/java/lang.opt
+++ b/gcc/java/lang.opt
@@ -209,212 +209,213 @@ Java
 
 ;
 ; Warnings handled by ecj.
-; FIXME: document them
 ;
 

but I did start off with the help texts from

which AFAICS falls under the Eclipse Public License - v 1.0
.

Now my question, before I blindly post this to {gcc,java}-patches and
thus create potential legal hassles for whoever works on it: was it
OKed (by the SC or FSF) to integrate such material into GCC?
If not, would you think that it suffices if I reformulate the entries
sufficiently, or do we need to start playing the legal game, if the
situation is to be improved?

Thanks!
Ralf

Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)

[Ralf Wildenhues]

Hello Jan,

* Jan Hubicka wrote on Thu, Mar 05, 2009 at 11:54:31AM CET:
> *** dwarf2out.c   (revision 144621)
> --- dwarf2out.c   (working copy)
> *** along with GCC; see the file COPYING3.  
> *** 89,94 
> --- 89,95 
>   #include "hashtab.h"
>   #include "cgraph.h"
>   #include "input.h"
> + #include "gimple.h"

This needs Makefile.in adjustment.

Cheers,
Ralf

Re: GCC 4.3.X libgomp

[Ralf Wildenhues]

Hello Takis,

* Takis Psarogiannakopoulos wrote on Thu, Mar 05, 2009 at 07:28:53PM CET:
> Seems that libgomp is part of GCC and not a separate project right?
> So i am posting this here.
> I have a new target for this library that I want to add. Hence I am
> modifying configure.tgt, source files etc and also adding some new
> threads stuff on the configure.ac However when I recreate the configure
> with autoconf either the original version 2.59 or 2.63 and it runs
> during the bootstrap the resulting gcc-x.x.x/target-dir/libgomp/Makefile 
> fails.
> Seems like some macros are missing? (.m4 files)

If you are rerunning things manually, in libgomp you need to use
  aclocal -I .. -I ../config
  autoconf
  automake

and within the GCC tree, you currently *have* to use exactly Autoconf
2.59 and Automake 1.9.6.

> Personaly I think autoconf 2.63 is one of the most stable autoconfs after
> the 2.1x branch [...]

I have patches to update most of the GCC tree to current autotools,
but that is 4.5 material.

Hope that helps.

Cheers,
Ralf

Re: gcj -v --help: ecj switches

[Ralf Wildenhues]

Ping!

* Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
> I have a patch (accompanying those other ones on gcc-paches) to fix
> 
> --- a/gcc/java/lang.opt
> +++ b/gcc/java/lang.opt
> @@ -209,212 +209,213 @@ Java
>  
>  ;
>  ; Warnings handled by ecj.
> -; FIXME: document them
>  ;
>  
> 
> but I did start off with the help texts from
> <http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm>
> which AFAICS falls under the Eclipse Public License - v 1.0
> <http://www.eclipse.org/legal/epl-v10.html>.
> 
> Now my question, before I blindly post this to {gcc,java}-patches and
> thus create potential legal hassles for whoever works on it: was it
> OKed (by the SC or FSF) to integrate such material into GCC?
> If not, would you think that it suffices if I reformulate the entries
> sufficiently, or do we need to start playing the legal game, if the
> situation is to be improved?

Re: Call for MPC complex math library GCC testers on various platforms

[Ralf Wildenhues]

* Kaveh Ghazi wrote on Wed, Mar 18, 2009 at 06:17:46PM CET:
> If you would like to help out by testing MPC on your favorite platforms
> (especially those from the GCC primary/secondary platform list) then please
> download the latest MPC tarball from the above LORIA link and send your
> results to the MPC mailing list here:
> http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss

I tried to send the message below to the list, without subscribing.  It
was thus rejected.  I then tried to send it to you off-list, which your
mail server doesn't like either, due to unblock.secureserver.net.  Would
you please forward it for me?  I have no intention to subscribe to yet
another mailing list, nor to debug mail server issues from my provider,
if they want feedback then they should *please* setup gmane.org or
another gateway.

Thanks, and sorry everyone else for bothering you,
Ralf



Hello mpc maintainers,

The tarball referenced in 
builds on powerpc970-apple-darwin8.11.0.  Unlike the configure scripts
for gmp and mpfr, I had to use
  configure CC="gcc -m64" CXX="g++ -m64"

for mpc.  All checks passed.

Updating the tarball to a newer Libtool release will improve build time.

Is this mailing list already enlisted in gmane.org?  If not, it would be
nice if you did so, so that non-subscribers like me (Cc: me on replies,
please) can reply without breaking threads.

Cheers,
Ralf

Re: gcj -v --help: ecj switches

[Ralf Wildenhues]

* Andrew Haley wrote on Sat, Mar 14, 2009 at 11:05:03AM CET:
> Ralf Wildenhues wrote:
> > * Ralf Wildenhues wrote on Sun, Mar 01, 2009 at 08:20:35AM CET:
> >> I have a patch (accompanying those other ones on gcc-paches) to fix
> >>
> >>  ; Warnings handled by ecj.
> >> -; FIXME: document them

> >> but I did start off with the help texts from
> >> <http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm>

> >> If not, would you think that it suffices if I reformulate the entries
> >> sufficiently, or do we need to start playing the legal game, if the
> >> situation is to be improved?
> 
> All material in gcc must be assigned the the FSF by the copyright owner.
> A rewrite that didn't derive from the Eclipse work would be OK.

OK.  Hmm, well, the way I read this, it means that I can't write this
patch any more, nor can anyone do it easily who has looked at the above
link.  I mean, how many ways are there to express that some warning
complains about, say, an unused variable?

Sigh.

Thanks,
Ralf

Re: Proposed gfortran development branch

[Ralf Wildenhues]

* Toon Moene wrote on Thu, Mar 19, 2009 at 07:46:37PM CET:
> Richard Guenther wrote:
>>
>> Note that merging the branch will be painful (as in, please dissect
>> the branch into the individual patches again to make bisecting the
>> trunk SVN possible).

> I agree about the bisecting-in-case-of-bugs issue.

For what little the opinion of a mostly-lurker is worth here, but I
disagree on the bisecting-in-case-of-bugs issue.  Today, there exist
version control systems that can deal with bisecting over nonlinear
histories, as well as temporarily linearizing a history (in case the
merge point, rather than a single patch on a merged branch is at fault).
It even works, too.

That's only tangent to the real issue here, of course.

Cheers,
Ralf

Re: Call for testers: MPC-0.6 released

[Ralf Wildenhues]

* Kaveh R. Ghazi wrote on Tue, Apr 07, 2009 at 05:32:14PM CEST:
>
> I think we're just missing AIX5.2.  Ralf you did that last time for the 
> svn tarball.  Would you please repeat your testing with mpc-0.6?

Sorry for the delay.  Issues on AIX 5.2:

- This time, I had an old version of mpc installed.  This caused this
failure:

Error: header and library do not match
mpc_get_version: "0.6-dev"
MPC_VERSION_STRING: "0.6"
FAIL: tget_version

Hmm, I don't quite see yet how that could have happened (and I ran "make
install" before analyzing this, so the failure is gone now.


- I still needed to set OBJECT_MODE=64 before running make,
otherwise libmpc is not created.

- These lines in configure are not portable:

   GMP_CC="`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED -e
 's/MPC_OPTION //g' | $SED -e 's/"//g'`"

  GMP_CFLAGS="`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | 
$SED -e 's/MPC_OPTION //g'| $SED -e 's/"//g'`"

and cause these errors:
  sed: Function s/"//g"`" cannot be parsed.
  ../mpc-0.6/configure[4212]: //g| $SED -e s///g':  not found
  yes CC= CFLAGS=

  ../mpc-0.6/configure[4201]: syntax error at line 4258 : `(' unexpected

Please replace them with these lines, respectively:

  GMP_CC=`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED -e 
's/MPC_OPTION //g' | $SED -e 's/"//g'`

  GMP_CFLAGS=`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED 
-e 's/MPC_OPTION //g'| $SED -e 's/"//g'`

You never need to put the right hand side of a shell assignment in
double quotes; see here for a detailed explanation:


(I thought we've already fixed this before?)

Cheers,
Ralf

Re: Parma Polyhedra Library 0.10.1

[Ralf Wildenhues]

Hello,

* Roberto Bagnara wrote on Tue, Apr 14, 2009 at 06:58:01PM CEST:
> Richard Guenther wrote:
>> It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux
>> but I get
>>
>> PASS: nnc_writepolyhedron1
>> /bin/sh: line 4: 29952 Segmentation fault  ${dir}$tst
>> FAIL: memory1
>> ==
>> 1 of 191 tests failed
>> Please report to ppl-de...@cs.unipr.it
>> ==
>>
>> on s390x-linux.  Does the testsuite stop after the first error?

Are you saying that there were no 190 PASSes before that FAIL?  If yes,
that would be weird, and I'd be interested in the output of
  make check SHELL="/bin/sh -x"

and the make version used.

> The testsuite does not proceed after the first directory that gives
> an error.

Why not recommend
  make -k check

then?

Cheers,
Ralf

Re: [JAVA,libtool] Big libjava is biiiig.

[Ralf Wildenhues]

Hello Dave,

* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
> 
>   So I'm currently experimenting with a patch that adds a new option
> "--enable-libgcj-sublibs" in libjava/configure.ac.  I may need to add a
> dummy-link-and-relink stage to get the interdependencies working right, or I
> might have to hack something in libtool, but the basic approach of adding a
> bunch of extra libtool declarations based on $(filter)ing the full list of
> dependencies from the complete libgcj_la_LIBADD definition seemed a reasonable
> way to go:
> 
> +if BUILD_SUBLIBS
> +libgcj_gnu_la_LIBADD = $(filter gnu/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs
> libgcj.la
> +libgcj_java_la_LIBADD = $(filter java/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_javax_la_LIBADD = $(filter javax/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_misc_la_LIBADD = $(filter-out gnu/%.lo java/%.lo
> javax/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs libgcj.la
> +endif

I don't yet see why you would need any kind of libtool hacking.

I also don't see why the GCC tree *ever* uses -L$(something)/.libs in
directories where libtool is used.  Just specify in-tree library
dependencies as 'libgcj.la' and automake and libtool will do The Right
Thing.  You adding an explicit -L.libs can only lead to installed .la
files retaining paths to build tree locations.

> 1)  Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?

You are aware of the fact that it is part of the ABI in which of the
linked DLLs a given symbol was found, and any shuffling of that later
will break that ABI?

You also have to ensure that the sub libraries are self-contained, or at
least their interdependencies form a directed non-cyclic graph (or you
will need very ugly hacks on w32).

> 2)  Given that there's a bit of a logjam upstream, and not likely to be
> another libtool release betwen now and the end of stage1,

What makes you think so?  There is a backlog of some patches, but that
doesn't mean
- important patches won't go in,
- GCC can't update to a newer unreleased Libtool version; it has done
  this several times, and it does not require the GCC developers to
  upgrade their build tools.

> would it be
> acceptable (in general) to hack on our in-tree libtool first and send patches
> upstream second (thus still avoiding any potential future merge lossage)?

I don't see a reason for that in your message.  Do you have other
reasons for suggesting this?

Cheers,
Ralf

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Ralf Wildenhues]

* Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
> On arm-linux-gnueabi there are regressions of the form
> 
> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> 
> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ 
> with
> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.

In order to be able to anayze this (and either confirm or refute a
possible libtool bug), I would like to see the './libtool --mode=link'
command that fails, plus all of its output with --debug added as first
argument; further the output of
  ./libtool --tag=TAG --config

with TAG replaced by the tag used for the link.

Thanks,
Ralf

Re: [JAVA,libtool] Big libjava is biiiig.

[Ralf Wildenhues]

* Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST:
> Ralf Wildenhues wrote:
> > I don't yet see why you would need any kind of libtool hacking.
> 
>   Because of this:
> 
> > You also have to ensure that the sub libraries are self-contained, or at
> > least their interdependencies form a directed non-cyclic graph (or you
> > will need very ugly hacks on w32).
> 
>   I fully expect there to be cyclic interdependencies, which I could resolve
> by building import libs first with dlltool.  I'm not sure yet whether to do
> this in libtool, but it occurred to me as one possibility.

If you could show the commands that would be needed without libtool,
then it would be easier for me to understand how libtool could help.
Of course, the more generally usable the approach, the better.

> Another approach
> would have been to do it in the Makefile, by first building the sub-DLLs all
> linked against the monolithic libjava DLL, then rebuilding them all but this
> time linking against their own import libs generated in the previous step; it
> occurred to me that even this might need a little help from libtool.

I agree that this sounds a bit awkward.

> > I also don't see why the GCC tree *ever* uses -L$(something)/.libs in
> > directories where libtool is used.  Just specify in-tree library
> > dependencies as 'libgcj.la' and automake and libtool will do The Right
> > Thing.  You adding an explicit -L.libs can only lead to installed .la
> > files retaining paths to build tree locations.
> 
>   Right, I'll try it; I have no idea why it's like that, I just cut and pasted
> existing examples without fully understanding.  The comment on the bit I cut
> and pasted reads:
> 
> ## We don't explicitly link in the libraries we need; libgcj.la brings
> ## in all dependencies.  We need the -L so that gcj can find libgcj
> ## with `-lgcj', but it must come first, otherwise the -L flags
> ## brought in from libgcj.la would cause the install directories to be
> ## searched before the build-tree ones, and we'd get errors because of
> ## different libraries with the same SONAME from picky linkers such as
> ## Solaris'.  FIXME: should be _libs on some systems.
> jv_convert_LDADD = -L$(here)/.libs libgcj.la

I understand that one might need -L$(here)/.libs with non-libtool
linking, where without it, -lgcj will not be found.  But it makes
no sense to me when libtool _is_ used for linking.  And here, libtool
must be the only user, if only for the simple reason that passing
'libgcj.la' (as opposed to '-lgcj') to the compiler driver (rather than
to libtool) will cause an error.

> >> 2)  Given that there's a bit of a logjam upstream, and not likely to be
> >> another libtool release betwen now and the end of stage1,
> > 
> > What makes you think so?  There is a backlog of some patches, but that
> > doesn't mean
> > - important patches won't go in,
> 
>   Oh, great.  I didn't want to /rely/ on being able to draw on your time when
> you've already got a lot to deal with, but in combination with this ...

If this turns out to be a lot of work to even stabilize, we can still
decide to let GCC do its own stuff for a while and reintegrate later.

> > I don't see a reason for that in your message.  Do you have other
> > reasons for suggesting this?
> 
>   Nope, I was only planning ahead against the contingency of it either not
> being practicable or convenient upstream, or there being subtle problems that
> transpire with doing an entire libtool update/merge.

Oh, I was intending for a complete autotool update for the GCC tree,
but given the delay on the license exception thing for Autoconf, I'm
not sure how well that will align with GCC being in Stage 1 ...

Cheers,
Ralf

git mirror at infradead?

[Ralf Wildenhues]

Hello Bernardo,

sorry if this is not an official mirror of the GCC tree, but
 has not been updated since
June 1.  Any chance you (or whoever is responsible) could look into it?

Thanks!
Ralf

Re: git mirror at infradead?

[Ralf Wildenhues]

Hello Bernie,

* Bernie Innocenti wrote on Sun, Jun 07, 2009 at 12:17:44PM CEST:
> On 06/07/09 07:21, Ralf Wildenhues wrote:
> > sorry if this is not an official mirror of the GCC tree, but
> >  has not been updated since
> > June 1.  Any chance you (or whoever is responsible) could look into it?
> 
> The git-svn process was stuck on a read(), with the socket to
> gcc.gnu.org still open.  Killing the process and running the update
> script again fixed it.

Thanks!

> BTW, we also have another up-to-date git mirror, supposedly the
> "official" one:
> 
>http://gcc.gnu.org/git/?p=gcc.git

Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a full repo?  Or can I reuse
objects)?  

> I never got around to give it the necessary love, though, such as
> configuring a few more branches.

Oh.  Yes, at least the still-active release branches would be nice to
have.

> Also, sourceware still running git 1.5
> doesn't help (git-svn was greatly improved in git 1.6).

Does that mean you would like to redo the full export after updating
git-svn?  If yes, then I'd want to wait until after that before
switching.

Thanks,
Ralf

Re: Should -Wjump-misses-init be in -Wall?

[Ralf Wildenhues]

Hello Ian,

out of curiosity:

* Ian Lance Taylor wrote on Sat, Jun 20, 2009 at 07:12:50AM CEST:
> Any opinions on this?  Should I take the new warning out of -Wall?

Is the missing of an initialization detected elsewhere, or can it be
detected elsewhere, maybe only in cases where it actually leads to
undefined behavior (as defined by C)?

Thanks,
Ralf

Updating Autoconf and Automake versions used in GCC and src

[Ralf Wildenhues]

Hello GCC, binutils, gdb developers,

short summary: I'd like to, in roughly that order,

1) update GCC and src to Autoconf 2.64, Automake 1.11,
2) enable automake dependency tracking for the bfd, binutils, ld,
   opcodes, gprof, and gas directories,
3) bring some more build sanity for libstdc++-v3, including dependency
   tracking,
and maybe
4) update Libtool in GCC and src at some convenient point later.

I'd be grateful about feedback as to whether the general plan is
acceptable for everyone; thanks.


Automake 1.11 has been released a month ago, so far there has been only
one regression reported over previous releases and it is trivial to work
around.  This release provides more efficient "make install", and fixes
some long-standing issues in the libstdc++-v3 build system, and some
other things.  It requires Autoconf 2.62 or newer.

The latest stable Autoconf is 2.63 currently, with 2.64 hopefully
released soon.  2.64 brings shell functions to configure scripts which
can shrink the size of some of the scripts considerably, and some other
fixes; I have so far been testing with the current git tree.

Instead of updating to 2.64, we can also update to 2.63 only, if you
prefer.  It would require working around a number of known bugs that
have since been fixed in Autoconf, and it would not bring the shell
function improvements.  Of course, the switch to 2.64 should anyway be
done only a little while after it has been released, but still well
before the end of GCC Stage 1.  It should be noted that working around
Autoconf bugs should be relatively straightforward (see existing
instances in config/override.m4 and other files).

I understand that most distributions do not ship these versions by
default.  However, that is little different with the 2.59/1.9.6 versions
used by the current trees, so it should not matter much, and improve in
the near future.

(1) will require a flag day, at which developers will need to switch
the Autoconf and Automake they use for the tree if they modify any of
the autotools input files.

I have a number of patches for GCC and src, grown in the last few months
(tracking the infreadead gcc and binutils-gdb git repos of the trees).
I have done some testing, including parallel builds,
'--enable-targets=all --enable-64bit-bfd', but not much
cross-compilation and not on very many different systems.

I'd prefer to do the transition on the GCC trunk rather than in a
branch, unless there is opposition to this.  Keeping a branch in sync
with the src tree seems awkward.  BTW, should I keep any other trees in
sync with these two (archer, out-of-tree libffi)?  Also, I am not aware
of any branches to be merged in GCC which interact non-trivially with an
autotools update.

The transition will consist of a few preparatory patches which keep
using the currently used autotools, and only make the files fit for the
new tools, which I'll start off with.  The final couple of patches for
(1) then flip the Autoconf version bit in config/override.m4, add a few
trivial non-backward-compatible changes, and regenerate everything with
new tools.


There are a few incompatible changes that need addressing:

* changed per-target link flags handling in Automake:

  - Per-target flags are now correctly handled in link rules.

For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
preferred AM_CFLAGS over maude_CFLAGS while linking, and they
used both AM_LDFLAGS and maude_LDFLAGS on the same link command.

The fix for compiler flags (i.e., using maude_CFLAGS instead of
AM_CFLAGS) should not hurt any package since that is how _CFLAGS
is expected to work (and actually works during compilation).

However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
"in addition to" breaks backward compatibility with older versions.
If your package used both variables, as in

  AM_LDFLAGS = common flags
  bin_PROGRAMS = a b c
  a_LDFLAGS = more flags
  ...

and assumed *_LDFLAGS would sum up, you should rewrite it as

  AM_LDFLAGS = common flags
  bin_PROGRAMS = a b c
  a_LDFLAGS = $(AM_LDFLAGS) more flags
  ...

This new behavior of *_LDFLAGS is more coherent with other
per-target variables, and the way *_LDFLAGS variables were
considered internally.


* changed installation directory structure and names in Autoconf:

  - datarootdir

  - infodir, docdir, pdfdir, and other point to below ${datarootdir}
and some have changed defaults (e.g., /usr/local/share/info instead
if /usr/local/info through this change)


* both tools use awk now in configure and makefiles, but old awks with
  V7 feature set from 1978 should suffice.


More changes are listed in the NEWS files of Autoconf and Automake:




I have gone through the trees and tried to fix all i

Re: Updating Autoconf and Automake versions used in GCC and src

[Ralf Wildenhues]

Hi Tom,

* Tom Tromey wrote on Mon, Jun 29, 2009 at 07:05:26PM CEST:
> >>>>> "Ralf" == Ralf Wildenhues  writes:
> 
> Ralf> I'd be grateful about feedback as to whether the general plan is
> Ralf> acceptable for everyone; thanks.
> 
> Sounds good to me.  Please don't forget Classpath.

If you are talking about gcc/libjava/classpath, then yes, I have that on
my radar; or should I consider out-of-tree Classpath, too?

Thanks,
Ralf

Re: gtyp-input.list should contain absolute paths.

[Ralf Wildenhues]

Hello Basile,

* Basile STARYNKEVITCH wrote on Fri, Jul 03, 2009 at 12:10:17PM CEST:
> It would be much easier for plugins if gtyp-input.list contained
> only absolute paths. In my case, (AMD64/Debian/Sid), it contains
> only two relative filepaths: auto-host.h & options.h

Over here it contains only relative paths.  I build GCC using a relative
srcdir:
  ../gcc/configure

as opposed to
  /path/to/gcc/configure

> If gtyp-input.list contained only absolute path, plugins wanting
> gengtype could use that very list. Otherwise, they have to hack it
> to replace relative file paths (relative to the build directory) by
> absolute ones.

I cannot judge whether using absolute paths in this file is a problem or
not.  The s-gtyp-input rule definitely has problems when the absolute
paths to the files contain whitespace.  (I have no idea whether building
GCC works, or would be nice to work, when source or build directory
names contains whitespace, at least when relative $srcdir is used.)

> I tried to replace in gcc/Makefile.in near line 3437
> s-gtyp-input: Makefile
>@: $(call write_entries_to_file,$(GTFILES),tmp-gi.list)
>$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
>$(STAMP) s-gtyp-input
> with
> s-gtyp-input: Makefile
>@: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list)
>$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
>$(STAMP) s-gtyp-input
> but it does not work.

Please note that "it does not work" is never a good description of any
failure.  You can always do better than that, and be more precise, by
showing the command that failed and any error messages.

> However, I am unfamiliar with GNU make user
> functions and cannot understand how write_entries_to_file work.

Write out names in pieces that don't overflow command line length
limits.  The easiest way to debug such makefile constructs is to use
  make SHELL='/bin/sh -x'

or similar.

One issue with your change is that it drops the [ada] and other language
tags that $(GTFILES) contains.

Hope that helps.

Cheers,
Ralf

Re: gtyp-input.list should contain absolute paths.

[Ralf Wildenhues]

* Basile STARYNKEVITCH wrote on Fri, Jul 03, 2009 at 03:51:00PM CEST:
> 
> The patch below solves the issue, but the generated gtype-input.list
> contains too much empty blank lines. Any suggestions on how to solve
> this?

> +## compute the realpath of above GTFILES - keeping language tags as before
> +REALGTFILES = $(foreach f, $(GTFILES), $(if $(patsubst [%],,$f),
> $(realpath $f), $f))

In general please get your mailer to not mangle long lines in patches.
In this case, the mangling helped to provide the clue: you have too much
white space in this line, try using this instead:

REALGTFILES := $(foreach f, $(GTFILES),$(if $(patsubst [%],,$f),$(realpath 
$f),$f))

because those extra spaces show up in the output.

Cheers,
Ralf

Re: libiberty should be a shared library when cc1 has plugin enabled.

[Ralf Wildenhues]

* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 02:50:04PM CEST:
> On Thu, Jul 09, 2009 at 10:49:49AM +0200, Basile Starynkevitch wrote:
> > But it seems to me that a plugin can call a libliberty function only if that
> > function is already referenced (e.g. called) from cc1. This is not the case
> > of all libiberty functions.
> 
> So... link libiberty into your plugin and get make_temp_file that way.

Ahh, another opportunity for subtle bugs stemming from multiple entities
of static data, such as random numbers used in a plugin being
suspiciously correlated to random numbers used in cc1 proper,
setenv in cc1 segfaulting because a plugin used it too, invalidating
cc1's copy of the last_environ pointer ...

Cheers,
Ralf

Re: libiberty should be a shared library when cc1 has plugin enabled.

[Ralf Wildenhues]

* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
> While Ralf's point about static data is valid, the functions likely to
> be in libiberty on any platform supporting plugins should not suffer
> from this problem.

Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as missing
setenv, and of course they are tertiary platforms only.  However, I
wouldn't be surprised if plugins such as melt used setenv, esp. if they
spawn other processes, e.g., to compile code.

> If you're concerned about it, then build a subset.  I've considered a
> separation of libiberty into replacements and utilities, anyway.

Why would that help in this case?  Even if the static data issue
concerns one set of these functions only now (does it?), it won't
prevent anyone from adding problems to the other set tomorrow, unless
you also introduce a policy that libiberty functions be safe against
multiple entities.

Cheers,
Ralf

Re: more .o vs. .obj targeting VMS

[Ralf Wildenhues]

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: Help needed: banishing RTL from the front ends

[Ralf Wildenhues]

* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST:
> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote:
> > Target-specific variable values are applied to all dependencies, see
> > (make) Target-specific:
[...]
> That is the problem here. TM_H depends on insn-constants.h, which
> depends on   genconstants:
[...]
> 
> Lots of files validly depend on TM_H (directly, or via target.h).

What's more, the order-only prerequisite

  $(ALL_HOST_OBJS) : | $(generated_files)

may (eventually) bite you, too.  This GNU make semantic does not seem
very intuitive.

> So I guess this plan of mine is not going to work...
> Other ideas?

Well, you could override the overridden variable for the dependencies
yet again.

Cheers,
Ralf

Re: toplevel out of sync

[Ralf Wildenhues]

* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST:
> the toplevel configury of gcc/gdb/binutils is very much out of sync.

> Unfortunately I don't have much time to devote to bringing the trees
> back in shape, and not even to chase down committers of patches
> placed only on one side.  Can anybody help with this?

I can take a look.

> ... the last date when the tree was synchronized ...

It looked fairly good 3 months ago[1].

Do you prefer tracking down committers and letting them finish their
work, or should I just go ahead and sync sets of commits as I did last
time?

Thanks,
Ralf

[1]
$ L="git log --until=3.months.ago --pretty=format:%H"
$ diff <( cd gcc && git show $($L origin/trunk | head -n 1):configure.ac ) \
   <( cd src && git show $($L origin/master | head -n 1):configure.ac )

Re: toplevel out of sync

[Ralf Wildenhues]

* Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
> On 05/25/2010 07:09 PM, Ralf Wildenhues wrote:
> >>... the last date when the tree was synchronized ...
> >
> >It looked fairly good 3 months ago[1].

Toplevel and config/ went out of sync with commit 6c8aa2aa884d of the
GCC infradead git mirror, aka. r157945, on April 2.  Since then, there
have been no commits on src that were not synced to GCC.

> >Do you prefer tracking down committers and letting them finish their
> >work, or should I just go ahead and sync sets of commits as I did last
> >time?
> 
> As you prefer.  I'd rather see a list of commits before giving you
> green light though. :-)

commit id of infradead mirror, GCC SVN revision number:

17281d1ee17f204064cfcbcc82089aefa19e3779   159527
401f30d69e280e18a9581b819376d18786595d3b   159173
decab1d0d6db331f662d42679eb1a8d473f72920   159134
bcd70fb06d56d9316d49019f5c0a3109def08d39   158763
a9ed67d000f285282e61aa9b87cc8d992a8731df   158762
22c56f6f70e07d6d9991a294439613dbf8eb60e0   158550
8b6a3525690f368dc965cd1457dc128d1925c995   158459
7da77e3b5958bf72909a3d238b2be0aa0820cb41   158423
82cf45c792250d333911ae6d2719fea77b520f0d   158285
d1d17d418a5c66a792e9988a945ca25e89692632   157946
6c8aa2aa884de79314b9b16a374518f4fd6624aa   157945

There are no changes in intl, libiberty.  The sourceware git mirror
doesn't seem to carry libdecnumber.  Which files in include/ were
part of libiberty again?

Thanks,
Ralf

Re: toplevel out of sync

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, May 25, 2010 at 07:33:53PM CEST:
> * Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST:
> > As you prefer.  I'd rather see a list of commits before giving you
> > green light though. :-)
> 
> commit id of infradead mirror, GCC SVN revision number:

One more missing in config/:
f299d473920cb31abfc07842575b43bbf08383d6   155648

Re: [PATCH, committed] Re: toplevel out of sync

[Ralf Wildenhues]

* Dave Korn wrote on Wed, May 26, 2010 at 07:36:26AM CEST:
> >>> bcd70fb06d56d9316d49019f5c0a3109def08d39   158763
> >>> a9ed67d000f285282e61aa9b87cc8d992a8731df   158762
> >> 17281d1ee17f204064cfcbcc82089aefa19e3779   159527
> >> 401f30d69e280e18a9581b819376d18786595d3b   159173

>   I've synched across the above-mentioned GCC revisions to the top-level
> configure.ac script in /src, with the following ChangeLog:

Remainders, in reverse chronological order:

2010-05-05  Sebastian Pop  

   * configure.ac: Allow all the versions greater than 0.10 of PPL.
   * configure: Regenerated.


2010-04-16  Rainer Orth  

   * configure.ac: Check for elf_getshdrstrndx or elf_getshstrndx
   separately.
   * configure: Regenerate.


2010-04-13  Steve Ellcey  

   * configure: Regenerate after change to elf.m4.

config/
2010-04-13  Steve Ellcey  

   * elf.m4: Add hppa[12]*-*-hpux* to list of non-elf platforms.


2010-04-02  Sebastian Pop  

   * configure.ac: Add brackets around AC_TRY_COMPILE alternative.
   * configure: Regenerated.


2010-04-02  Sebastian Pop  

   * configure.ac: Print "buggy but acceptable" when CLooG
   revision is less than 9.
   * configure: Regenerated.


config/
2010-01-05  Rainer Orth  

   * stdint.m4 (GCC_HEADER_STDINT): Don't typedef uint8_t etc. if
   corresponding macros already exist.

Re: [RFC] Switching implementation language to C++

[Ralf Wildenhues]

* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST:
> 
>  In file included from ../../gcc/libcpp/system.h:341,
>  from ../../gcc/libcpp/expr.c:21:
> ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration
> ‘char* basename(const char*)’
> /usr/include/string.h:601: error: ambiguates old declaration ‘const
> char* basename(const char*)’

I'm working on that currently (the Autoconf patch).

Re: [RFC] Switching implementation language to C++

[Ralf Wildenhues]

* Joern Rennecke wrote on Tue, Jun 01, 2010 at 09:11:03PM CEST:
> Quoting Ralf Wildenhues:
> >* Toon Moene wrote on Tue, Jun 01, 2010 at 08:36:53PM CEST:
> >>
> >> In file included from ../../gcc/libcpp/system.h:341,
> >> from ../../gcc/libcpp/expr.c:21:
> >>../../gcc/libcpp/../include/libiberty.h:106: error: new declaration
> >>‘char* basename(const char*)’
> >>/usr/include/string.h:601: error: ambiguates old declaration ‘const
> >>char* basename(const char*)’
> >
> >I'm working on that currently (the Autoconf patch).
> 
> That's PR bootstrap/42798.
> The patch has been posted to the autoconf mailing list in Febuary:
> http://lists.gnu.org/archive/html/autoconf/2010-02/msg00057.html
> What we need is a patch review.

Yes.  I am working on test case, documentation update etc., based on
your patch.

Re: AC_CHECK_DECLS(basename) (Was: Re: Ping: patches required for --enable-build-with-cxx)

[Ralf Wildenhues]

[ moving from autoconf@ to -patches ]

* Richard Guenther wrote on Tue, Jun 01, 2010 at 01:52:07PM CEST:
> 
> Any progress here?  If we want to switch on --enable-build-with-cxx
> by default then this has to be addressed.

Proposed patches for Autoconf.  Tested with CC=g++ in TESTSUITEFLAGS and
without.

One remaining nit is that the configure cache variables carry the whole
signature, are quite long, and sensitive to white space in the
declaration.  Oh well.  Any other issues with it?

Thanks, and sorry for the long delay,
Ralf
>From dbfbf0d2e550d7d304f5fb8edfa5a340aebc4d21 Mon Sep 17 00:00:00 2001
From: Joern Rennecke 
Date: Tue, 1 Jun 2010 20:06:54 +0200
Subject: [PATCH 1/2] Generalize AC_CHECK_DECL for C++: allow optional arguments.

* general.m4 (_AC_CHECK_DECL_BODY): Process trailing function
argument types as arguments to use for C++.
(_AC_CHECK_DECLS): Filter out trailing function argument types
when henerating the HAVE_DECL_* macro.

Signed-off-by: Ralf Wildenhues 
---
 ChangeLog   |8 
 lib/autoconf/general.m4 |   15 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1452eb3..8041556 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-06-01  Joern Rennecke(tiny change)
+
+	Generalize AC_CHECK_DECL for C++: allow optional arguments.
+	* general.m4 (_AC_CHECK_DECL_BODY): Process trailing function
+	argument types as arguments to use for C++.
+	(_AC_CHECK_DECLS): Filter out trailing function argument types
+	when henerating the HAVE_DECL_* macro.
+
 2010-05-25  Stefano Lattarini  
 	Eric Blake  
 
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index b7ac62f..fecfb72 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -2792,10 +2792,16 @@ AC_DEFUN([AC_CHECK_FILES],
 # Shell function body for AC_CHECK_DECL.
 m4_define([_AC_CHECK_DECL_BODY],
 [  AS_LINENO_PUSH([$[]1])
-  AC_CACHE_CHECK([whether $[]2 is declared], [$[]3],
+  [as_decl_name=`echo $][2|sed 's/(.*//'`]
+  [as_decl_use=`echo $][2|sed -e 's/(/((/' -e 's/)/) 0&/' -e 's/,/) 0& (/g'`]
+  AC_CACHE_CHECK([whether $as_decl_name is declared], [$[]3],
   [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$[]4],
-...@%:@ifndef $[]2
-  (void) $[]2;
+...@%:@ifndef $[]as_decl_name
+...@%:@ifdef __cplusplus
+  (void) $[]as_decl_use;
+...@%:@else
+  (void) $[]as_decl_name;
+...@%:@endif
 @%:@endif
 ])],
 		   [AS_VAR_SET([$[]3], [yes])],
@@ -2831,7 +2837,8 @@ AS_VAR_POPDEF([ac_Symbol])dnl
 # ACTION-IF-FOUND or ACTION-IF-NOT-FOUND.
 m4_define([_AC_CHECK_DECLS],
 [AC_CHECK_DECL([$1], [ac_have_decl=1], [ac_have_decl=0], [$4])]dnl
-[AC_DEFINE_UNQUOTED(AS_TR_CPP([HAVE_DECL_$1]), [$ac_have_decl],
+[AC_DEFINE_UNQUOTED(AS_TR_CPP(m4_bpatsubst(HAVE_DECL_[$1],[(.*])),
+  [$ac_have_decl],
   [Define to 1 if you have the declaration of `$1',
and to 0 if you don't.])]dnl
 [m4_ifvaln([$2$3], [AS_IF([test $ac_have_decl = 1], [$2], [$3])])])
-- 
1.7.0.rc1.161.g90487

>From ef0cd33aa5bc626a4a0063062aaae5fd80bf185f Mon Sep 17 00:00:00 2001
From: Ralf Wildenhues 
Date: Tue, 1 Jun 2010 21:54:39 +0200
Subject: [PATCH 2/2] Documentation and tests for the AC_CHECK_DECL change.

* lib/autoconf/general.m4 (_AC_CHECK_DECL_BODY): Squash trailing
spaces in as_decl_name.
(_AC_CHECK_DECLS): Likewise for the define.
* tests/semantics.at (AC_CHECK_DECLS): Extend test.
* doc/autoconf.texi (Generic Declarations): Update.
* NEWS: Update.

Signed-off-by: Ralf Wildenhues 
---
 ChangeLog   |   10 ++
 NEWS|3 +++
 doc/autoconf.texi   |   14 +++---
 lib/autoconf/general.m4 |4 ++--
 tests/semantics.at  |   35 +--
 5 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 8041556..08bcde8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-06-01  Ralf Wildenhues  
+
+	Documentation and tests for the AC_CHECK_DECL change.
+	* lib/autoconf/general.m4 (_AC_CHECK_DECL_BODY): Squash trailing
+	spaces in as_decl_name.
+	(_AC_CHECK_DECLS): Likewise for the define.
+	* tests/semantics.at (AC_CHECK_DECLS): Extend test.
+	* doc/autoconf.texi (Generic Declarations): Update.
+	* NEWS: Update.
+
 2010-06-01  Joern Rennecke(tiny change)
 
 	Generalize AC_CHECK_DECL for C++: allow optional arguments.
diff --git a/NEWS b/NEWS
index afd8907..04cf8dd 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,9 @@ GNU Autoconf NEWS - User visible changes.
 
 ** Autoconf should work on EBCDIC hosts.
 
+** AC_CHECK_DECL and AC_CHECK_DECLS accept optional function argument types
+   for overloaded C++ functions.
+
 * Major changes in Autoconf 2.65 (2009-11-21) [stable]
   Released by Eric Blake, based on git versions 2.64.*.
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 3df0d3f..eab9ab2 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -6275,8 +6275,14 @@ Generic Declarations
 
 Thi

Re: Issue with LTO/-fwhole-program

[Ralf Wildenhues]

* Jan Hubicka wrote on Fri, Jun 11, 2010 at 03:26:12PM CEST:
> > Ah, so the problem is the missing -flto in the second compilation
> > step? I think this is a bug in the compiler for not reporting this
> > somehow. Is there are PR open for this?
> 
> Compiler can not report it because it does not see the other object files.
> It is really up to user to understand -fwhole-program and mark externally 
> visible
> symbols.  Your testcase is quite ugly in a way that it leads to miscopmilation
> rather than linktime error, but there is not much we can do about it I guess.
> Perhaps we can somehow poison the object names that are brought local with 
> -fwhole-program
> so linking explode, but I am not sure there is way to do so.

The requirement to compile with -flto needs to be documented in the
description of the -fwhole-program switch in invoke.texi.  The text of
the following -flto switch is long enough that the user will not by
see that by chance, and it isn't very specific on this either.

More generally, the description of -fwhole-program does not make it
clear to me whether it is required at compile time or link time only, or
both.  Likewise, it is unclear whether the combination of
-fwhole-program with -combine, -flto, or -fwhopr is to happen at compile
time, link time, both, or one switch at compile time and another at link
time, or one for some translation units at compile time, and another for
others.

The description refers to "the current compilation unit" but there may
be more than one unit, or none at all if only objects and libraries were
specified.

I'm willing to improve the documentation if somebody explains the
intended semantics to me.  :-)

Cheers,
Ralf

Re: transitioning cloog to ppl-0.11

[Ralf Wildenhues]

* Jack Howarth wrote on Fri, Aug 06, 2010 at 02:31:31AM CEST:
>I have been mulling over how to transition the
> current gcc4x and cloog packages in fink to the new
> ppl-0.11 release and believe we really need to have
> a soversion bump on cloog to safely do this on
> systems with pre-existing packages.

Not sure I understand, but why should ppl soversion bump require a cloog
soversion bump?  In which way is this different from any other library
dependency that undergoes such a bump, and why should it be handled
differently?

Thanks,
Ralf