toplevel *again* out of sync
I hate to say this when I don't have the time to fix it myself, but toplevel of gcc and src is once more out of sync, and this is bad. I think that we should apply a *very* strict policy of not approving toplevel patches unless the toplevel files are in sync. Thanks in advance to anyone that "volunteers" to fix things... Paolo
Re: toplevel *again* out of sync
Hi Paolo, * Paolo Bonzini wrote on Sat, Oct 02, 2010 at 10:47:18AM CEST: > I think that we should apply a *very* strict policy of not approving > toplevel patches unless the toplevel files are in sync. > > Thanks in advance to anyone that "volunteers" to fix things... You beat me by a couple of hours. I'll fix it later today, it's only a couple of patches (not from me though). Cheers, Ralf
make recheck?
Is there a way to rerun only failed tests after a 'make -k check'? If not, should there be, and how would one go about implementing this (I know the makefile parts but not the dejagnu bits). Asking because it could help speed up patch development: 1) hack hack hack 2) make -k check-$whatever 3) go back to (1) until satisfactory 4) git commit patch, undo patch in work tree, rebuild 5) run 'make recheck' to ensure all new failures were already old. This doesn't satisfy patch submission rules, but for patch series development it might, in stages before actually submitting. Thanks, Ralf
Re: toplevel *again* out of sync
This is how things look like currently:
There are five patches in GCC not in src, four for toplevel and one for
config/; there are no patches in src not in GCC. There is one
problematic sync.
Not in src:
b9a8e4c49ae2f195c2c0c4646a75f33ff926986f aka r162482
4ae8c98f346e631b735be15b09a41a1a043454d2 aka r163839
62932e4dc2db82e1bdef5e2afbad33154bb8d5f2 aka r164481
d34b0d1e4502f0a0879adac335534686cc5b550a aka r164756
The combined patch for the above four is at the end of this message.
The following patch has been committed to GCC and to src, but the two
commits are not identical, and the commit to src is lacking a ChangeLog
entry:
65b688d722ec8d604aa6e37a7fa16eb21c72fd8c aka r162530 aka
| 2010-07-26 Naveen.H.S
|
| * configure.ac: Support all v850 targets.
| * configure: Regenerate.
Nick, Naveen, the diff between the GCC and the src commits is this;
which variant is correct?
| --- gcc/configure.ac2010-10-02 09:33:07.0 +0200
| +++ src/configure.ac2010-10-02 14:20:36.0 +0200
| @@ -968,7 +968,7 @@
| noconfigdirs="$noconfigdirs bfd binutils gas gcc gdb ld
target-libstdc++-v3 opcodes target-libgloss ${libgcj}"
| ;;
|v850*-*-*)
| -noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
| +noconfigdirs="$noconfigdirs ${libgcj}"
| ;;
|vax-*-vms)
| noconfigdirs="$noconfigdirs bfd binutils gdb ld target-newlib opcodes
target-libgloss ${libgcj}"
|
Please fix the wrong side, and fix src/ChangeLog. Thanks.
Other than that, below is the combined patch I intend to commit to src
unless there are disagreements.
Thanks,
Ralf
ChangeLog:
2010-10-02 Ralf Wildenhues
Sync from GCC:
2010-09-30 Michael Eager
* configure.ac (microblaze): Add target-libssp to noconfigdirs.
* configure: Regenerate.
2010-09-21 Iain Sandoe
* configure.ac (enable-lto): Add Darwin to the list of supported lto
targets and amend comment.
* configure: Regenerate.
2010-09-03 Jack Howarth
* configure.ac: Enable LTO by default on Darwin.
* configure: Regenerate.
2010-07-23 Marc Glisse
PR bootstrap/44455
* configure.ac (extra_mpfr_configure_flags): Copy from
extra_mpc_gmp_configure_flags.
* configure: Re-generated.
config/ChangeLog:
2010-10-02 Ralf Wildenhues
Sync from GCC:
2010-09-10 Jonathan Yong
* dfp.m4: Enable decimal float for i?86 cygwin
and mingw, and for x86_64 mingw.
Index: configure.ac
===
RCS file: /cvs/src/src/configure.ac,v
retrieving revision 1.106
diff -u -r1.106 configure.ac
--- configure.ac27 Sep 2010 20:22:46 - 1.106
+++ configure.ac2 Oct 2010 12:33:36 -
@@ -887,7 +887,7 @@
noconfigdirs="$noconfigdirs ld binutils gprof target-libgloss ${libgcj}"
;;
microblaze*)
-noconfigdirs="$noconfigdirs gprof ${libgcj}"
+noconfigdirs="$noconfigdirs gprof target-libssp ${libgcj}"
;;
mips*-sde-elf*)
skipdirs="$skipdirs target-libiberty"
@@ -1348,7 +1348,7 @@
if test "x$with_gmp$with_gmp_include$with_gmp_lib" = x && test -d
${srcdir}/gmp; then
gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/'"$lt_cv_objdir $gmplibs"
gmpinc='-I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp '"$gmpinc"
- extra_mpfr_configure_flags='--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp'
+ extra_mpfr_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/'"$lt_cv_objdir"
extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/'"$lt_cv_objdir"
# Do not test the gmp version. Assume that it is sufficient, since
# it is in the source tree, and the library has not been built yet
@@ -1787,17 +1787,19 @@
AC_SUBST(libelflibs)
AC_SUBST(libelfinc)
fi],[if test x"$default_enable_lto" = x"yes" ; then
-# On non-ELF platforms, LTO must be explicitly enabled.
-enable_lto=no
+case $target in
+ *-apple-darwin*) ;;
+ # On other non-ELF platforms, LTO must be explicitly enabled.
+ *) enable_lto=no ;;
+esac
else
- # Apart from ELF platforms, only Windows supports LTO so far. It
- # would also be nice to check the binutils support, but we don't
+ # Apart from ELF platforms, only Windows and Darwin support LTO so far.
+ # It would also be nice to check the binutils support, but we don't
# have gcc_GAS_CHECK_FEATURE available here. For now, we'll just
# warn during gcc/ subconfigure; unless you're bootstrapping with
# -flto it won't be needed until after installation anyway.
case $target in
- *-cygwin*|*-mingw*) ;;
- *-apple-darwin*) ;;
+ *-cygwin*|*-mingw* | *-apple-darwin*) ;;
*) if test x"$enable_lto" = x"yes"; then
AC_MSG_ERROR([LTO support is not enabled for this target.])
fi
Index: config/dfp.m4
===
Re: toplevel *again* out of sync
> Other than that, below is the combined patch I intend to commit to src > unless there are disagreements. Ok, thanks. DJ, can you amend your scripts so that the head of gcc/ChangeLog and src/ChangeLog is included? This will make it easier to bug relevant people. Paolo
Re: make recheck?
On Sat, Oct 2, 2010 at 5:54 AM, Ralf Wildenhues wrote: > Is there a way to rerun only failed tests after a 'make -k check'? > If not, should there be, and how would one go about implementing this > (I know the makefile parts but not the dejagnu bits). > > Asking because it could help speed up patch development: > 1) hack hack hack > 2) make -k check-$whatever > 3) go back to (1) until satisfactory > 4) git commit patch, undo patch in work tree, rebuild > 5) run 'make recheck' to ensure all new failures were already old. > > This doesn't satisfy patch submission rules, but for patch series > development it might, in stages before actually submitting. > > Thanks, > Ralf > I know there's a way to run a specific exp file, and a specific test from that file: RUNTESTFLAGS=file.exp RUNTESTFLAGS=file.exp=test Something like that. That's not entirely what you want, though.
Re: make recheck?
* NightStrike wrote on Sat, Oct 02, 2010 at 05:47:24PM CEST: > On Sat, Oct 2, 2010 at 5:54 AM, Ralf Wildenhues wrote: > > Is there a way to rerun only failed tests after a 'make -k check'? > > If not, should there be, and how would one go about implementing this > > (I know the makefile parts but not the dejagnu bits). > I know there's a way to run a specific exp file, and a specific test > from that file: > > RUNTESTFLAGS=file.exp > RUNTESTFLAGS=file.exp=test > > Something like that. > > That's not entirely what you want, though. Well, I'd like a reverse mapping from the failures in recorded *.log files to a set of RUNTESTFLAGS arguments to pass. That's how we implemented 'recheck' in Autotest and in the Automake parallel-tests driver. Ahh, maybe some sed scripting is enough to there though ... Thanks, Ralf
Re: make recheck?
On Sat, Oct 2, 2010 at 05:54, Ralf Wildenhues wrote: > Asking because it could help speed up patch development: > 1) hack hack hack > 2) make -k check-$whatever > 3) go back to (1) until satisfactory > 4) git commit patch, undo patch in work tree, rebuild > 5) run 'make recheck' to ensure all new failures were already old. This sounds like a great idea. You'd need to extract the FAIL lines from the .log file and backtrack to figure out which .exp file produced them. This would give you the input for RUNTESTFLAGS=f.exp=... I don't recall if you can specify more than one file in the RUNTESTFLAGS argument, though. Diego.
Re: Range-based for in c++98
2010/10/1 Jason Merrill :
> It took me some searching, but yes, it does:
>
> "A type-specifier-seq shall not define a class or enumeration unless it
> appears in the type-id of an alias-declaration (7.1.3)."
>
> Normal declarations don't have a type-specifier-seq, they have a
> decl-specifier-seq.
No wonder I couldn't find it!
> I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
> instead of cp_parser_type_specifier_seq and then wait to complain about
> defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to me that it was
because it called cp_parser_commit_to_tentative_parse(), and if then I
wanted to roll-back the parsing of the range-for, I went badly. I had
to agree with Manuel that the tentative parsing is a bit messy...
But, I managed to solve this particual issue with the following patch
(no improvement in the error messages, however):
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 164871)
+++ gcc/cp/parser.c (working copy)
@@ -8644,21 +8644,13 @@ cp_parser_range_for (cp_parser *parser)
tree stmt, range_decl, range_expr;
cp_decl_specifier_seq type_specifiers;
cp_declarator *declarator;
- const char *saved_message;
tree attributes, pushed_scope;
cp_parser_parse_tentatively (parser);
- /* New types are not allowed in the type-specifier-seq for a
- range-based for loop. */
- saved_message = parser->type_definition_forbidden_message;
- parser->type_definition_forbidden_message
-= G_("types may not be defined in range-based for loops");
/* Parse the type-specifier-seq. */
cp_parser_type_specifier_seq (parser, /*is_declaration==*/true,
- /*is_trailing_return=*/false,
+ /*is_trailing_return=*/true,
&type_specifiers);
- /* Restore the saved message. */
- parser->type_definition_forbidden_message = saved_message;
/* If all is well, we might be looking at a declaration. */
if (cp_parser_error_occurred (parser))
{
Admittedly, this is not a "trailing_return_type", but AFAICT it has
exactly the same restrictions. Maybe renaming the parameter would be a
good idea.
Regards.
Rodrigo
[rfc] stack alignment macro cleanup
Currently we have STACK_BOUNDARY -- minimum alignment enforced by hardware. PREFERRED_STACK_BOUNDARY -- a preserved alignment greater than what the hw enforces (defaults to STACK_BOUNDARY) INCOMING_STACK_BOUNDARY -- an alignment provided by callers on function entry. (defaults to PREFERRED_STACK_BOUNDARY) MIN_STACK_BOUNDARY (undocumented; local to i386 atm) -- appears to be the ABI specified stack boundary, i.e. the minimum that must be in place at a call site. This somehow differs from I_S_B due to proliferation of command-line options. MAX_STACK_ALIGNMENT -- biggest stack alignment guaranteed by the backend. (defaults to STACK_BOUNDARY, @c sez ought to be P_S_B) MAX_SUPPORTED_STACK_ALIGNMENT (undocumented; defined solely by defaults.h) -- the same as M_S_A, but with the P_S_B default. I would like to reduce this to STACK_BOUNDARY -- unchanged INCOMING_STACK_BOUNDARY -- default to S_B; x86 backend drops MIN_S_B. MAX_STACK_BOUNDARY -- default to I_S_B. and delete many of the x86 backend options that fiddle stuff that users ought not be fiddling. Like forcing the use of DRAP register. Thoughts? r~
gcc-4.6-20101002 is now available
Snapshot gcc-4.6-20101002 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101002/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 164908 You'll find: gcc-4.6-20101002.tar.bz2 Complete GCC (includes all of below) MD5=4066c6774584c697fc6d91b21dbfa46f SHA1=7a20fc478638ffcd283306c22f530b810dd8d280 gcc-core-4.6-20101002.tar.bz2C front end and core compiler MD5=c9579385729be1299eae0a22a8cd527b SHA1=3b4ef93b70afa9934bded4c164ed648a177e31ec gcc-ada-4.6-20101002.tar.bz2 Ada front end and runtime MD5=c284c8e3ac2c35b6db49e93591c541f3 SHA1=ff16f7eb3d6fbcd5f21323f5e1efaa87a17f647d gcc-fortran-4.6-20101002.tar.bz2 Fortran front end and runtime MD5=771dbf6bbec828cbd31669f6f94587ab SHA1=9f729eb34e689e458f500278b88d9e88de6c522e gcc-g++-4.6-20101002.tar.bz2 C++ front end and runtime MD5=ebaaf3ac1350a1040fb801d396b1119d SHA1=ad07d73791819f3c88cfee4a4f9ce06d6d4d8a26 gcc-java-4.6-20101002.tar.bz2Java front end and runtime MD5=d9d9673a0f2ca6b6410c80671044552d SHA1=0f4650ebe7f12c843be2f3428be3150c9170a1e2 gcc-objc-4.6-20101002.tar.bz2Objective-C front end and runtime MD5=2a0ae098848c12df00a8db9751a40509 SHA1=b54cc7bc9a117fde30f8e9a96d77bdced744fc9d gcc-testsuite-4.6-20101002.tar.bz2 The GCC testsuite MD5=23a0d9581d1a67b2f36eb9bef6abab0d SHA1=57589d5586ca8f1ef9d27f906bb5752ffaaba9d4 Diffs from 4.6-20100925 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: [rfc] stack alignment macro cleanup
On Sat, Oct 2, 2010 at 1:01 PM, Richard Henderson wrote: > Currently we have > > STACK_BOUNDARY > -- minimum alignment enforced by hardware. > > PREFERRED_STACK_BOUNDARY > -- a preserved alignment greater than what the hw enforces > (defaults to STACK_BOUNDARY) > > INCOMING_STACK_BOUNDARY > -- an alignment provided by callers on function entry. > (defaults to PREFERRED_STACK_BOUNDARY) > > MIN_STACK_BOUNDARY > (undocumented; local to i386 atm) > -- appears to be the ABI specified stack boundary, i.e. > the minimum that must be in place at a call site. This > somehow differs from I_S_B due to proliferation of > command-line options. It is used to implement -mstackreliagn. I think you should just move it to i386.c. Otherwise, you have to copy the same logic to where it is used in i386.c. > > MAX_STACK_ALIGNMENT > -- biggest stack alignment guaranteed by the backend. > (defaults to STACK_BOUNDARY, @c sez ought to be P_S_B) > > MAX_SUPPORTED_STACK_ALIGNMENT > (undocumented; defined solely by defaults.h) > -- the same as M_S_A, but with the P_S_B default. > > I would like to reduce this to > > STACK_BOUNDARY > -- unchanged > > INCOMING_STACK_BOUNDARY > -- default to S_B; x86 backend drops MIN_S_B. On ia32, INCOMING_STACK_BOUNDARY may be different from PREFERRED_STACK_BOUNDARY. It is used to support linking against libraries with 4byte incoming stack boundary and generate 16byte outgoing stack boundary. > > MAX_STACK_BOUNDARY > -- default to I_S_B. > > and delete many of the x86 backend options that fiddle > stuff that users ought not be fiddling. Like forcing > the use of DRAP register. > -mdrap is mainly for testing purpose and used in testsuite. It has caught many bugs. Removing it means regressions may become latent. -- H.J.
