Re: The return of the bootstrap comparison failure on i386
On Sat, 12 Sep 2009 13:29:35 +0200 (CEST) Gerald Pfeifer wrote: > On Sat, 12 Sep 2009, Ryan Hill wrote: > >> I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this > >> started. Latest attempt was with r151649. > >> Configured as: > > I was able to build using --enable-checking. Should I file a new PR? > > If you are still seeing this, I think that would be appropriate. PR41345. (sorry for hijacking your thread BTW) -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
Ralf Wildenhues wrote: > * Pedro LamarÃo wrote on Thu, Aug 27, 2009 at 12:24:07AM CEST: > > 2009/8/26 Ralf Wildenhues: > > > > >> 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. Here's the patch I sent Pedro: Index: gcc/configure === --- gcc/configure (revision 149964) +++ gcc/configure (working copy) @@ -10650,8 +10650,9 @@ + for ac_func in times clock kill getrlimit setrlimit atoll atoq \ - sysconf strsignal getrusage nl_langinfo \ + sysconf strsignal getrusage nl_langinfo basename \ gettimeofday mbstowcs wcswidth mmap mincore setlocale \ clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do @@ -12673,11 +12674,10 @@ - for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \ strsignal strstr strverscmp \ errno snprintf vsnprintf vasprintf malloc realloc calloc \ - free basename getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked + free getopt clock getpagesize clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked do ac_tr_decl=`echo "HAVE_DECL_$ac_func" | $as_tr_cpp` echo "$as_me:$LINENO: checking whether $ac_func is declared" >&5 Index: gcc/config.in === --- gcc/config.in (revision 149964) +++ gcc/config.in (working copy) @@ -321,6 +321,12 @@ #endif +/* Define if your assembler supports LWSYNC instructions. */ +#ifndef USED_FOR_TARGET +#undef HAVE_AS_LWSYNC +#endif + + /* Define if your assembler supports mfcr field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_MFCRF @@ -351,23 +357,18 @@ #endif -/* Define if your assembler supports popcntb instruction. */ +/* Define if your assembler supports popcntb field. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTB #endif -/* Define if your assembler supports popcntd instruction. */ +/* Define if your assembler supports POPCNTD instructions. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_POPCNTD #endif -/* Define if your assembler supports lwsync instruction. */ -#ifndef USED_FOR_TARGET -#undef HAVE_AS_LWSYNC -#endif - /* Define if your assembler supports .register. */ #ifndef USED_FOR_TARGET #undef HAVE_AS_REGISTER_PSEUDO_OP @@ -430,6 +431,12 @@ #endif +/* Define to 1 if you have the `basename' function. */ +#ifndef USED_FOR_TARGET +#undef HAVE_BASENAME +#endif + + /* Define to 1 if you have the `clearerr_unlocked' function. */ #ifndef USED_FOR_TARGET #undef HAVE_CLEARERR_UNLOCKED @@ -480,13 +487,6 @@ #endif -/* Define to 1 if we found a declaration for 'basename', otherwise define to - 0. */ -#ifndef USED_FOR_TARGET -#undef HAVE_DECL_BASENAME -#endif - - /* Define to 1 if we found a declaration for 'calloc', otherwise define to 0. */ #ifndef USED_FOR_TARGET Index: gcc/configure.ac === --- gcc/configure.ac(revision 149964) +++ gcc/configure.ac(working copy) @@ -1016,7 +1016,7 @@ fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked dnl putchar_unlocked putc_unlocked) AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoll atoq \ - sysconf strsignal getrusage nl_langinfo \ +
Re: Add my name to Write-after-Approval List
Hopefully the combined wisdom on this list can help getting this addressed (one way or the other). :-) I can see five cases: 1) Some of these have requested gcc.gnu.org access only to be "bugmasters", for example they have no commits. >dalecki (Marcin Dalecki )2006-12-29 13 >yechiel (Yechiel Kimchi ) >martin (Martin Schindewolf ) >setton (Nicolas Setton ) >liao(Shih-wei Liao ) (Marcin does not have copyright on file, and contribute with his personal email). They should add themselves at the end of MAINTAINERS, and Marcin should be sent the copyright form ASAP unless he was covered by his employer in 2005-2006. 2) some of these do not have anymore a copyright assignment since they were covered by their employer. >zlaski (Ziemowit Laski )2005-09-29 429 Based on LinkedIn info, Zem's current employer does not have a GCC copyright assignment. >rodimina(Olga Rodimina )2005-01-06 59 >aluchko (Aaron Luchko)2005-07-149 >kgallowa(Kyle Galloway )2007-05-17 38 These were at Red Hat, contributed only to libjava, and AFAIK neither of the two things is true anymore. 3) some of these are covered by their employer. even if they are only contributing to a "vendor" branch, they should anyway add themselves as WAA on trunk. >tglek (Taras Glek )2009-05-276 >victorlei (Victor Leikehman)2004-11-181 Taras is still active, Victor is still at IBM according to LinkedIn. 4) some might fall under 2 or 3. Actually just one; he used to be at QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him: >gp (Graeme Peterson )2003-08-063 5) some of these just forgot. Individual copyrights: >rkidd (Robert Kidd )2007-09-10 11 >sgilbertson (Scott Gilbertson)2006-02-23 13 >marekm (Marek Michalkiewicz )2005-03-20 57 >jfreeman(John Freeman)2009-08-29 118 Employer: >olga(Olga Golovanevsky )2008-03-19 37 >olegr (Oleg Ryjkov )2008-04-25 28 >jingyu (Jing Yu )2009-04-284 That's it. Paolo
Re: Updating gnu.org/software Fortran Page
Rob, On Thu, 23 Apr 2009, Rob Myers wrote: > The gnu.org webmaster team are going to be updating all the pages in the > gnu.org/software subdirectory, which includes - > > http://www.gnu.org/software/fortran > > This will involve changing the design of the page to match the new style > of gnu.org, and updating the information about the GNU Fortran project > if possible. > > Is there any information you would like adding to the project page or > any other changes you would like making to its content? I noticed this page now has a broken link to http://www.gnu.org/software/gcc/gcc.html which I believe is due to you guys now redirecting to gcc.gnu.org instead of mirroring the actual pages. You may want to adjust the link to http://www.gnu.org/software/gcc/ instead, for example. Also, let me include our dedicate list fort...@gcc.gnu.org and provide the text this crew is using for their own description: Gfortran is the name of the GNU Fortran project, developing a free Fortran 95/2003 compiler for GCC, the GNU Compiler Collection. The gfortran development effort uses an open development environment in order to attract a larger team of developers and to ensure that gfortran can work on multiple architectures and diverse environments. You may want to reuse that. One thing I noticed is that your page really referes to g77 when we now provide a more modern Fortran frontend. So, I would not refer to g77 at all, and also adjust the link your current have to "the online g77 documentation" to instead refer to http://gcc.gnu.org/onlinedocs/ref/gfortran/ which will also redirect to the documentation of the latest released version. (Do not follow the redirect, but really use the link as I specified it.) Hope this helps, Gerald
Re: Not using DECL_VALUE_EXPR for callee-copied parameters?
On Fri, Sep 11, 2009 at 06:39:10PM -0700, Ian Lance Taylor wrote: > Martin Jambor writes: > > > I have run the testsuite on hppa with the following patch and I > > successfully bootstrapped and tested it on x86_64. Unless someone > > objects, I will bootstrap it on hppa and commit it in a week or two > > along with Richi's patch verifying such decls don't leak to the IL > > (and then try to use the mechanism above to keep the debug info). > > Without meaning to criticize your investigation, I object on procedural > grounds--some maintainer must approve such a patch to mainline. I don't > think it qualifies as obvious. > I was apparently too tired when writing this, I obviously meant to propose to commit this in the list and hopefully get an approval. I just wanted to find out whether people would object to this first as bootstrapping and testing on hppa is tedious and there will be all sorts of weird problems making the debug info work again. Having said that, if anybody has problems with this patch going in, please speak out now rather than later. Sorry for the confusion, Martin
gcc-4.3-20090913 is now available
Snapshot gcc-4.3-20090913 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090913/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 151676 You'll find: gcc-4.3-20090913.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090913.tar.bz2 C front end and core compiler gcc-ada-4.3-20090913.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090913.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090913.tar.bz2 C++ front end and runtime gcc-java-4.3-20090913.tar.bz2 Java front end and runtime gcc-objc-4.3-20090913.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090913.tar.bz2The GCC testsuite Diffs from 4.3-20090906 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Annoucing regressions and bootstrap fail? (was: Bootstrap broken on sparc-linux trunk between 145310:145425 because of new genattrtab.c va_arg (p, HOST_WIDE_INT) warning)
On Sun, 5 Apr 2009, Laurent GUERBY wrote: >>> I'm thinking of changing my auto tester to report a broken bootstrap >>> (the first time a bootstrap fails), is there a normalized way to >> report such failures to gcc-testresults@ or g...@? >> I report it to gcc-regress...@. > It's documented by http://gcc.gnu.org/lists.html as "read-only": > > gcc-regression is a read-only moderate volume list where regression > results for the GCC compilers are posted. > > So I thought one couldn't post to it. Indeed, that looks like a mistake in the documentation of this list. > If there's consensus that's the right place to send automatic regression > and bootstrap fail reports I'll do that then. So far HJ and Geoff seem to be the main (if not sole) contributors to that least, but that sounds reasonable. For now I have applied the patch below to our web site; if there are further improvements you can think of -- don't be shy! :-) Gerald Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.103 diff -u -3 -p -r1.103 lists.html --- lists.html 4 Nov 2007 12:26:48 - 1.103 +++ lists.html 13 Sep 2009 22:45:55 - @@ -69,6 +69,10 @@ before subscribing< gcc-testresults is a moderate volume list where test results for the GCC compilers are posted. + http://gcc.gnu.org/ml/gcc-regression/";>gcc-regression + is a moderate volume list where regression results for the GCC compilers + are posted. + http://gcc.gnu.org/ml/libstdc++/";>libstdc++ is the main discussion and development list for the standard C++ library (libstdc++-v3). Patches to libstdc++-v3 should be sent to @@ -110,10 +114,6 @@ before subscribing< is a read-only, relatively low volume list which tracks checkins to the GCC webpages CVS repository. - http://gcc.gnu.org/ml/gcc-regression/";>gcc-regression - is a read-only moderate volume list where regression - results for the GCC compilers are posted. - http://gcc.gnu.org/ml/gccadmin/";>gccadmin is a read-only moderate volume list where output from cron jobs run by the gccadmin account on
RFC: cgraph/lowering vs. finish_file for GCC/UPC rewrites?
Recently, we have been working on upgrading GCC/UPC (see
http://gccupc.org) to the GCC trunk. Previously,
we've sync'ed with the latest stable release, but
now we want to stay more current.
When built with GCC versions 4.0 through 4.3, we used
the gimplify language hook, LANG_HOOKS_GIMPLIFY_EXPR,
to rewrite trees that refer to UPC constructs and UPC
shared variable references - converting them into
non-UPC, gimplified, tree structures. This worked
well, though we did need to extend the language hook
to include a gimplify test predicate and fallback
so that we can rewrite modify_expr's involving UPC
shared variables as the target:
int
upc_gimplify_expr (tree *expr_p,
gimple_seq *pre_p, gimple_seq *post_p,
bool (* gimple_test_f) (tree),
int fallback)
Working with the latest GCC 4.5 snapshot, we have run
into a problem that leads me to believe that the current
approach will no longer work with the 4.5/trunk
version of GCC.
In prior GCC versions, the gimplify pass was called
before the call graph pass. This meant that we could
safely employ the gimplify language hook to perform
the rewrites, which may emit inlined runtime calls.
An example UPC-related rewrite is to transform
UPC shared variable references into runtime calls.
This program:
shared int x;
shared int y;
int main()
{
x = y;
}
might be translated into something like:
int main()
{
int y_tmp = upc_get_int(upc_shared_addr(&y));
upc_put_int(upc_shared_addr(&x), &y_tmp);
}
The definitions of the runtime functions upc_put_int()
and upc_get_int() are found in a pre-included header
file (the UPC driver adds a -include switch on the
command line).
Depending upon optimization level and compile time
switches - calls to the UPC runtime functions can
be implemented as either inlined function calls or
conventional calls to pre-compiled library routines.
At optimization levels above -O0, most of the UPC
runtime is inlined, by default.
With the new/current organization of the
compilation/call graph passes, we end up with the
surprising result that the inlined runtime function
definitions "disappear" before UPC's gimplify pass
can refer to them. That's because the call graph
pass noticed that the inline runtime functions were
declared, but not referenced (yet). The gimplify pass
is then run against the remaining function bodies,
but the UPC runtime functions are no longer available.
One workaround for this issue might be to mark the
runtime functions, in a fashion similar to ctors/dtors
so that the call graph pass won't eliminate them.
I'm unsure if that will get the inlining aspects of
those routines right, and it might retain unused
function definitions in the form of compiled
non-inlined code.
GOMP appears to use a "lowering" pass that runs after
the call graph and gimplify passes. It calls runtime
routines via builtin function definitions, ensuring
that the function definitions won't go away. However,
it looks to me as if GOMP does not inline those
runtime functions?
OBJC implements some post-processing in the
finish_file() hook routine, which in turn calls
objc_finish_file(). That may be a reasonable place
to relocate UPC's tree rewrites, but that leads to
a few questions:
Can gimplify_expr() be safely called on the same tree
more than once? The question comes up because the
simplest thing is to retain the current infrastructure
where UPC rewrites occur in the gimplify language
hook. The second gimplify pass will redo some
work, calling out to the UPC language hook again,
but since all UPC constructs have been rewritten and
gimplified, there will be no additional work done,
besides the traversal.
How about an alternative approach that implements a
custom tree-walk inside finish_file() (that is similar
in structure to that implemented in omp-low.c).
Is this rewrite routine allowed to selectively
gimplify parts of the tree and/or to create temp
variables managed by the code in gimplify.c?
Is the description above, of the interactions
between the cgraph, gimplify and lowering passes
correct?
What approach would you recommend for the
implementation of UPC tree re-writes that will
support calls to the runtime (that are inlined,
if applicable)?
thanks,
- Gary
Re: Not using DECL_VALUE_EXPR for callee-copied parameters?
Hi Martin, > Having said that, if anybody has problems with this patch going in, > please speak out now rather than later. I very much appreciate the work you have done on this problem. However, the patch doesn't work as expected. I get multiple comparison failures with this change on hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.11. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: [gcc-in-cxx] Trunk fails to bootstrap with --enable-build-with-cxx
Jerry Quinn writes: > Index: include/libiberty.h > === > --- include/libiberty.h (revision 149964) > +++ include/libiberty.h (working copy) > @@ -100,7 +100,7 @@ > declaration without arguments. If it is 0, we checked and failed > to find the declaration so provide a fully prototyped one. If it > is 1, we found it so don't provide any declaration at all. */ > -#if !HAVE_DECL_BASENAME > +#if !HAVE_BASENAME > #if defined (__GNU_LIBRARY__ ) || defined (__linux__) || defined > (__FreeBSD__) || defined (__OpenBSD__) || defined(__NetBSD__) || defined > (__CYGWIN__) || defined (__CYGWIN32__) || defined (__MINGW32__) || defined > (HAVE_DECL_BASENAME) > extern char *basename (const char *); > #else This is a tough change to make. Several different packages use libiberty.h, and they are currently responsible for ensuring that HAVE_DECL_BASENAME is declared correctly before libiberty.h is #included. Changing this means looking at those packages and, most likely, changing them too. It may be better to test whether basename exists as you suggest, but to define HAVE_DECL_BASENAME based on HAVE_BASENAME. (By the way, you don't need to send diffs to generate files like configure and config.in, that just clutters up the patch. It's sufficient to include a reminder that those files need to be regenerated.) Ian
