Re: [patch] Disable static build for libjava
* Matthias Klose wrote on Sat, Jul 09, 2011 at 05:37:46PM CEST: On 07/07/2011 10:35 PM, Ralf Wildenhues wrote: On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote: On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote: +AC_PROG_LIBTOOL This tests the wrong compiler and toolchain. The compiler you want to test doesn't exist yet at the time this configure script is run. So you might as well deduce the switch you need from a fixed set or other GCC configure data. Or you put AC_PROG_LIBTOOL in libjava/ but pass down the value of enable_static_libjava as --en/disable-static there. here is the updated patch. AC_PROG_LIBTOOL is already called in libjava/ ok to install? OK, thanks. Cheers, Ralf toplevel 2011-07-09 Matthias Klose d...@ubuntu.com * Makefile.tpl (EXTRA_CONFIGARGS_LIBJAVA): Define. * Makefile.def (target_modules/libjava): Pass $(EXTRA_CONFIGARGS_LIBJAVA). * configure.ac: Pass --disable-static in EXTRA_CONFIGARGS_LIBJAVA, if not configured with --enable-static-libjava. * Makefile.in: Regenerate. * configure: Likewise. gcc/ 2011-07-09 Matthias Klose d...@ubuntu.com * doc/install.texi: Document --enable-static-libjava.
PATCH RFA: Build stages 2 and 3 with C++
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc installed and used by most people will
be built by a C++ compiler. This will ensure that gcc is fully
buildable with C++, while retaining the ability to bootstrap with only a
C compiler, not a C++ compiler. This will permit us to experiment with
optionally using C++ for some code, using a #ifdef to select the C
implementation or the C++ implementation.
I would suggest that we consider releasing 4.7 this way, as a small
trial for building gcc with C++.
This is a big step, so I am sending the patch to both gcc@ and
gcc-patches@ for comments.
Bootstrapped and ran testsuite on x86_64-unknown-linux-gnu.
Ian
2011-07-15 Ian Lance Taylor i...@google.com
* configure.ac: Add --enable-build-poststage1-with-cxx. If set,
make C++ a boot_language. Set and substitute
POSTSTAGE1_CONFIGURE_FLAGS.
* Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable.
(STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS).
* configure, Makefile.in: Rebuild.
Index: configure.ac
===
--- configure.ac (revision 176348)
+++ configure.ac (working copy)
@@ -1126,6 +1126,13 @@ AC_ARG_ENABLE(build-with-cxx,
ENABLE_BUILD_WITH_CXX=$enableval,
ENABLE_BUILD_WITH_CXX=no)
+# Build stage1 with C and build stages 2 and 3 with C++.
+AC_ARG_ENABLE(build-poststage1-with-cxx,
+[AS_HELP_STRING([--enable-build-poststage1-with-cxx],
+ [build stages 2 and 3 with C++, not C])],
+ENABLE_BUILD_POSTSTAGE1_WITH_CXX=$enableval,
+ENABLE_BUILD_POSTSTAGE1_WITH_CXX=yes)
+
# Used for setting $lt_cv_objdir
_LT_CHECK_OBJDIR
@@ -1696,9 +1703,11 @@ if test -d ${srcdir}/gcc; then
exit 1
fi
- if test $language = c++ \
- test $ENABLE_BUILD_WITH_CXX = yes; then
- boot_language=yes
+ if test $language = c++; then
+ if test $ENABLE_BUILD_WITH_CXX = yes \
+ || test $ENABLE_BUILD_POSTSTAGE1_WITH_CXX = yes; then
+ boot_language=yes
+ fi
fi
case ,${enable_languages}, in
@@ -2397,10 +2406,10 @@ case $have_compiler:$host:$target:$enab
;;
esac
-case ,$enable_languages,:$ENABLE_BUILD_WITH_CXX:$enable_bootstrap in
- *,c++,*:yes:yes) ;;
- *:yes:yes)
-AC_MSG_ERROR([bootstrapping with --enable-build-with-cxx requires c++ in --enable-languages])
+case ,$enable_languages,:,$ENABLE_BUILD_WITH_CXX,$ENABLE_BUILD_POSTSTAGE1_WITH_CXX,:$enable_bootstrap in
+ *,c++,*:*:*) ;;
+ *:*,yes,*:yes)
+AC_MSG_ERROR([bootstrapping with --enable-build-with-cxx or --enable-build-postage1-with-cxx requires c++ in --enable-languages])
;;
esac
@@ -3188,6 +3197,15 @@ case ${enable_werror} in
esac
AC_SUBST(stage2_werror_flag)
+# If using ENABLE_BUILD_POSTSTAGE1_WITH_CXX, pass
+# --enable-build-with-cxx after stage1.
+if test $ENABLE_BUILD_POSTSTAGE1_WITH_CXX = yes; then
+ POSTSTAGE1_CONFIGURE_FLAGS=--enable-build-with-cxx
+else
+ POSTSTAGE1_CONFIGURE_FLAGS=
+fi
+AC_SUBST(POSTSTAGE1_CONFIGURE_FLAGS)
+
# Specify what files to not compare during bootstrap.
compare_exclusions=gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*
Index: Makefile.tpl
===
--- Makefile.tpl (revision 176348)
+++ Makefile.tpl (working copy)
@@ -416,6 +416,7 @@ TFLAGS =
STAGE_CFLAGS = $(BOOT_CFLAGS)
STAGE_TFLAGS = $(TFLAGS)
STAGE_CONFIGURE_FLAGS=@stage2_werror_flag@
+POSTSTAGE1_CONFIGURE_FLAGS = @POSTSTAGE1_CONFIGURE_FLAGS@
[+ FOR bootstrap-stage +]
# Defaults for stage [+id+]; some are overridden below.
@@ -426,7 +427,10 @@ STAGE[+id+]_CXXFLAGS = $(CXXFLAGS)
STAGE[+id+]_CXXFLAGS = $(STAGE[+id+]_CFLAGS)
@endif target-libstdc++-v3-bootstrap
STAGE[+id+]_TFLAGS = $(STAGE_TFLAGS)
-STAGE[+id+]_CONFIGURE_FLAGS = $(STAGE_CONFIGURE_FLAGS)
+# STAGE1_CONFIGURE_FLAGS overridden below, so we can use
+# POSTSTAGE1_CONFIGURE_FLAGS here.
+STAGE[+id+]_CONFIGURE_FLAGS = \
+ $(STAGE_CONFIGURE_FLAGS) $(POSTSTAGE1_CONFIGURE_FLAGS)
[+ ENDFOR bootstrap-stage +]
# Only build the C compiler for stage1, because that is the only one that
@@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@
# the last argument when conflicting --enable arguments are passed.
# * Likewise, we force-disable coverage flags, since the installed
# compiler probably has never heard of them.
+# * Don't remove this, because above we added
+# POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which
+# we don't want for STAGE1_CONFIGURE_FLAGS.
STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \
--disable-coverage --enable-languages=$(STAGE1_LANGUAGES)
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 176348)
+++
Re: PATCH RFA: Build stages 2 and 3 with C++
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. Do you build libstdc++ at stage1 also? That is what happens if you don't have a C++ compiler to begin with. Thanks, Andrew Pinski
Re: PATCH RFA: Build stages 2 and 3 with C++
Andrew Pinski pins...@gmail.com writes: On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. This means that the gcc installed and used by most people will be built by a C++ compiler. This will ensure that gcc is fully buildable with C++, while retaining the ability to bootstrap with only a C compiler, not a C++ compiler. This will permit us to experiment with optionally using C++ for some code, using a #ifdef to select the C implementation or the C++ implementation. I would suggest that we consider releasing 4.7 this way, as a small trial for building gcc with C++. Do you build libstdc++ at stage1 also? That is what happens if you don't have a C++ compiler to begin with. Yes. With this patch, we build cc1plus at stage 1, and use it to build libstdc++ at stage 1, and use both to build stage 2. Ian
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor i...@google.com wrote:
Andrew Pinski pins...@gmail.com writes:
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1.
Do you build libstdc++ at stage1 also? That is what happens if you
don't have a C++ compiler to begin with.
Yes. With this patch, we build cc1plus at stage 1, and use it to build
libstdc++ at stage 1, and use both to build stage 2.
I think that we might also want to have some easy documented way to build the
stage1
directly with g++, assuming (or when) it is already available.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [pph] Expect checksums for tests marked with pph asm xdiff (issue4744043)
gch...@google.com (Gabriel Charette) writes: + set expectedSum [exec tr -d \} [exec cut -f 4 -d\ $xdiff_entry]] + set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]] You don't need cut and tr if you have tcl. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: PATCH to support running the G++ testsuite in C++0x mode
On 07/15/2011 09:29 PM, Jason Merrill wrote: On 07/13/2011 04:28 PM, Jason Merrill wrote: I'm using --tool_opts to pass the extra -std=c++0x argument to the compiler. Previously in my own testing I've used --target_board=unix/-std=c++0x, but that is problematic because options from --target_board come after options from dg-options, leading to spurious failures on tests that explicitly specify -std=c++98. I also considered using the --additional_options flag which lib/g++.exp tries to support, but it doesn't work (runtest.exp treats any --a* as --all) and in any case is redundant with --tool_opts. Unfortunately, a bug in dejagnu means that --tool_opts breaks multilib support; see the URL in the patch and GCC bug 49741. So I've resurrected --additional_options, renamed to --extra_opts because runtest.exp will let that through. Applying to trunk. The change to the toplevel Makefile.in was made in the generated file. I didn't revert it with today's change. Matthias
Re: *ping* - Re: [Patch, Fortran] Support allocatable *scalar* coarrays
Sorry for pinging again, but the patch is large enough to block a bit my progress ... Other pending patches - which should be quickly reviewable:: - http://gcc.gnu.org/ml/fortran/2011-07/msg00170.html - http://gcc.gnu.org/ml/fortran/2011-07/msg00142.html Tobias Tobias Burnus wrote: *ping* http://gcc.gnu.org/ml/fortran/2011-07/msg00106.html On 07/11/2011 09:49 AM, Tobias Burnus wrote: On 07/10/2011 09:56 PM, Tobias Burnus wrote: This patch implemented the trans*.c part of allocatable scalar coarrays; contrary to noncoarray allocatable scalars, they have cobounds and thus use an array descriptor. I found a test case (part of Reinhold Bader's fortran_tests), which gave an ICE: Allocatable scalar coarrays with SAVE. I have fixed that (trans-decl.c) and added a test. The attached patch was build and regtested on x86-64-linux. OK for the trunk? Tobias
Re: [PATCH, MELT] Add PRE_GENERICIZE callback support in MELT
Right, here is the new version of the patch (with the correct files).
I added, a function register_pre_genericize_hook in
melt/warmelt-base.melt to be called when we want to register a MELT
function to handle the callback, so we don't manually set
sysdata_pre_genericize field.
Pierre Vittet
On 15/07/2011 18:41, Romain Geissler wrote:
Le 15 juil. 2011 à 18:17, Pierre Vittet a écrit :
Hello,
The following patch add support for PLUGIN_PRE_GENERICIZE callback.
The add_sysdata_pre_genericize patch add a field (sysdata_pre_genericize) in
initial system data, allowing to register a closure to be called on
PLUGIN_PRE_GENERICIZE event. This patch must be first applied and a make
warmelt-upgrade must be run in order to regenerate generated melt files.
The add_pre_genericize_hook patch add a function (in melt-runtime.c) to be
called on PLUGIN_PRE_GENERICIZE, which call the closure sysdata_pre_genericize
defined by the users.
Thanks
Pierre Vittet
add_sysdata_pre_genericize-176032.ChangeLogadd_sysdata_pre_genericize-176032.diffadd_pre_genericize_hook-176032.ChangeLogadd_pre_genericize_hook-176032.ChangeLog~
Great !
You forgot to attach the patch for melt-runtime.c (there is only the changelog)
I know your performing some simple static analysis, mostly based on matching
some c source code patterns (check that there is a if (fopen_result) just after
a fopen.
Is there a particular reason to do that as a pass (so at the gimple level)
rather that doing it just after the function has been parsed (eg upon
PLUGIN_PRE_GENERICIZE) ?
2011-07-15 Pierre Vittet pier...@pvittet.com
* melt-runtime.h (enum FSYDAT*): Add a FSYSDAT_PRE_GENERICIZE field.
* melt/warmelt-first.melt (class_system_data): add a
sysdata_pre_genericize field.
Index: gcc/melt/warmelt-first.melt
===
--- gcc/melt/warmelt-first.melt (revision 176032)
+++ gcc/melt/warmelt-first.melt (working copy)
@@ -441,6 +441,8 @@ don't instanciate this class!}#
sysdata_stdout ;raw file for stdout
sysdata_stderr ;raw file for stderr
sysdata_dumpfile ;raw file for dump_file
+ sysdata_pre_genericize ;closure to be called for
PLUGIN_PRE_GENERICIZE:
+ ;look at gcc/c-decl.c.
sysdata_unit_starter ;closure to be called at
;compilation unit start
sysdata_unit_finisher;closure to be called at
Index: gcc/melt-runtime.h
===
--- gcc/melt-runtime.h (revision 176032)
+++ gcc/melt-runtime.h (working copy)
@@ -2324,6 +2324,7 @@ enum
FSYSDAT_STDOUT, /* raw boxed file for stdout */
FSYSDAT_STDERR, /* raw boxed file for stderr */
FSYSDAT_DUMPFILE,/* raw boxed file for dump_file */
+ FSYSDAT_PRE_GENERICIZE, /* closure for PLUGIN_PRE_GENERICIZE */
FSYSDAT_UNIT_STARTER,/* closure for start of compilation
unit */
FSYSDAT_UNIT_FINISHER,/* closure for start of compilation unit */
FSYSDAT_OPTION_SET, /* closure to set options */
2011-07-15 Pierre Vittet pier...@pvittet.com
* melt-runtime.c (melt_really_initialize): Register a new Callback to
PLUGIN_PRE_GENERICIZE.
(melt_pre_genericize_callback): New function, use field
sysdata_pre_genericize to transmit the callbacks.
* melt/warmelt-base.melt (register_pre_genericize_hook): New function.
Index: gcc/melt-runtime.c
===
--- gcc/melt-runtime.c (revision 176032)
+++ gcc/melt-runtime.c (working copy)
@@ -9044,6 +9044,35 @@ melt_pragma_callback (void *gcc_data ATTRIBUTE_UNU
#endif /*GCC 4.6 for handling pragma support*/
+
+/* This function is used when PLUGIN_PRE_GENERICIZE callback is invoked. It
+ calls the closure registered in field sydata_pre_genericize of
+ initial_system_data. The first argument is the tree containing the function
+ declaration (as given in file gcc/c-decl.c). */
+static void
+melt_pre_genericize_callback (void *ptr_fndecl,
+ void *user_data ATTRIBUTE_UNUSED)
+{
+ MELT_ENTERFRAME (2, NULL);
+#define pregenclosv meltfram__.mcfr_varptr[0]
+#define fndeclv meltfram__.mcfr_varptr[1]
+ fndeclv = meltgc_new_tree ((meltobject_ptr_t) MELT_PREDEF (DISCR_TREE),
+((tree) ptr_fndecl));
+ pregenclosv = melt_get_inisysdata (FSYSDAT_PRE_GENERICIZE);
+ if (melt_magic_discr ((melt_ptr_t) pregenclosv) == MELTOBMAG_CLOSURE)
+{
+ MELT_LOCATION_HERE
+ (melt_pre_genericize befire applying pre_genericize closure);
+ (void) melt_apply ((meltclosure_ptr_t) pregenclosv, (melt_ptr_t) fndeclv,
+, NULL, , NULL);
+}
+ MELT_EXITFRAME ();
Re: [4.6] Fix PR tree-optimization/49725
On Thu, Jul 14, 2011 at 11:43 PM, Eric Botcazou ebotca...@adacore.com wrote: Hi, this is the ICE at -O2 on ACATS c34005a introduced on the 4.6 branch by Martin's latest SRA patch. But it's actually the same PRE issue as: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02210.html Bootstrapped/regtested on i586-suse-linux, OK for 4.6 branch? Ok. Thanks, Richard. 2011-07-14 Eric Botcazou ebotca...@adacore.com PR tree-optimization/49725 Backport from mainline 2011-03-31 Eric Botcazou ebotca...@adacore.com * tree-ssa-pre.c (create_component_ref_by_pieces_1) ARRAY_REF: Drop a zero minimum index only if it is redundant -- Eric Botcazou
Re: [patch] Fix PR middle-end/49732
On Thu, Jul 14, 2011 at 11:44 PM, Eric Botcazou ebotca...@adacore.com wrote: Hi, this is a regression present on mainline and 4.6 branch. The compiler crashes during gimplification because there is a COMPOUND_EXPR shared between the TYPE_SIZE and TYPE_SIZE_UNIT expressions of an array type. Now this isn't supposed to happen because we run an unsharing pass before gimplification. The problem here is that we have a forward declaration (DECL_EXPR) of a pointer type to the array type. So, during the marking phase of the unsharing pass, the array type gets marked as visited through the pointer, which prevents it from being walked during the same phase when its own DECL_EXPR is processed. This pointer/pointed-to type business is an old pattern. Five years ago, Olivier changed gimplify_type_sizes like so: 2006-10-06 Olivier Hainque hain...@adacore.com * gimplify.c (gimplify_type_sizes) [POINTER_TYPE, REFERENCE_TYPE]: Don't recurse on the pointed-to type. because of a related problem. It turns out that we need the same change in the DECL_EXPR case of walk_tree_1 to fix the bug at hand, which is sort of logical as there is a strong relationship between them: case DECL_EXPR: /* If this is a TYPE_DECL, walk into the fields of the type that it's defining. We only want to walk into these fields of a type in this case and not in the general case of a mere reference to the type. The criterion is as follows: if the field can be an expression, it must be walked only here. This should be in keeping with the fields that are directly gimplified in gimplify_type_sizes in order for the mark/copy-if-shared/unmark machinery of the gimplifier to work with variable-sized types. Note that DECLs get walked as part of processing the BIND_EXPR. */ Tested on x86_64-suse-linux, OK for mainline and 4.6 branch? Ok. Thanks, Richard. 2011-07-14 Eric Botcazou ebotca...@adacore.com PR middle-end/49732 * tree.c (walk_tree_1) DECL_EXPR: Do not walk a pointed-to type. 2011-07-14 Eric Botcazou ebotca...@adacore.com * gnat.dg/pointer_controlled.adb: New test. -- Eric Botcazou
Re: DOC patch: about gengtype plugins
On Fri, 15 Jul 2011, Laurynas Biveinis wrote: 2011/7/6 Basile Starynkevitch bas...@starynkevitch.net: * doc/plugins.texi (Building GCC plugins): gengtype needs its gtype.state Replace than in the patch with as. I assume it passes make info? OK with that change, thank you. And a full stop at the end of the ChangeLog entry. And perhaps corresponding instead of its in the ChangeLog? Gerald
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
On Monday 11 July 2011 09:49:20 Tobias Burnus wrote: On 07/10/2011 09:56 PM, Tobias Burnus wrote: This patch implemented the trans*.c part of allocatable scalar coarrays; contrary to noncoarray allocatable scalars, they have cobounds and thus use an array descriptor. I found a test case (part of Reinhold Bader's fortran_tests), which gave an ICE: Allocatable scalar coarrays with SAVE. I have fixed that (trans-decl.c) and added a test. The attached patch was build and regtested on x86-64-linux. OK for the trunk? Tobias Hello, let me understand one thing about coarray scalars: despite their name, they are arrays, right? Then when you do in gfc_conv_array_ref: + if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se-expr))) + se-expr = build_fold_indirect_ref (gfc_conv_array_data (se-expr)); [...] return; you are returning scalar[1] instead of scalar (== scalar[this_image()]) or scalar[whatever_image_selector], aren't you? Sorry for the delay; it seems that the more it goes, the more you are the only one who can maintain coarray stuff. :-( Mikael
[PATCH 0/7] Tracking locations of tokens resulting from macro expansion
Hello, This is an update of the patch set that I initially posted to http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00858.html. The main goals achieved by this set are the following: - Decrease the overall memory consumption. On the tests I have done on a reasonably big C++ program compiled with the previous patch set, I have noticed a global memory consumption peak increase of 13%, for the whole compilation. With this new patch set, the global memory consumption peak is down to 0.6%. Details of the figures are appended at the end of this message. To do this, I have quite heavily modified the patch Generate virtual locations for tokens and I have added the patch Reduce memory waste due to non-power-of-2 allocs. The changes of these patches are explained in their respective preambles. - Change the diagnostics output as suggested by Paolo and Gaby in the sub-thread http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00987.html. Besides, I have hopefully addressed most of the comments that were made in the initial discussion thread. Gaby suggested that I drop the -ftrack-macro-expansion flag that I have added to enable this feature. Now that the memory consumption has been reduce to something that is more acceptable, I guess this goal is closer now. However, I have kept the flag for now as I believe there is value in keeping it to ease testing and performance comparison measures on real life examples. When I am comfortable with those aspects, I'll happily remove that flag, e.g, after a period of enabling it by default. Please find below a summary of the patches of this set as well as the details of the memory consumption gain I measured. Linemap infrastructure for virtual locations Generate virtual locations for tokens Emit macro expansion related diagnostics Support -fdebug-cpp option Add line map statistics to -fmem-report output Kill pedantic warnings on system headers macros Reduce memory waste due to non-power-of-2 allocs gcc/Makefile.in |2 +- gcc/ada/gcc-interface/trans.c | 10 +- gcc/c-decl.c| 17 +- gcc/c-family/c-lex.c| 10 +- gcc/c-family/c-opts.c | 17 + gcc/c-family/c-pch.c|2 +- gcc/c-family/c-ppoutput.c | 98 ++- gcc/c-family/c.opt | 12 + gcc/c-parser.c | 12 +- gcc/c-tree.h|2 +- gcc/cp/error.c |5 +- gcc/diagnostic.c| 25 +- gcc/diagnostic.h|2 +- gcc/doc/cppopts.texi| 29 + gcc/doc/invoke.texi |6 +- gcc/fortran/cpp.c | 22 +- gcc/input.c | 105 ++- gcc/input.h | 22 +- gcc/java/jcf-parse.c|2 +- gcc/testsuite/g++.dg/cpp0x/initlist15.C |1 + gcc/testsuite/g++.old-deja/g++.robertl/eb43.C |4 + gcc/testsuite/g++.old-deja/g++.robertl/eb79.C |4 + gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-1.c | 21 + gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-2.c | 21 + gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-3.c | 14 + gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-4.c | 14 + gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-1.c | 32 + gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-2.c | 34 + gcc/testsuite/gcc.dg/cpp/syshdr3.c | 16 + gcc/testsuite/gcc.dg/cpp/syshdr3.h |7 + gcc/testsuite/gcc.dg/nofixed-point-2.c |6 +- gcc/testsuite/gcc.target/i386/sse-vect-types.c |6 + gcc/toplev.c|4 + gcc/tree-diagnostic.c | 181 +++- gcc/tree-diagnostic.h |3 +- libcpp/directives-only.c|7 +- libcpp/directives.c | 21 +- libcpp/errors.c | 21 +- libcpp/expr.c | 176 ++-- libcpp/files.c | 24 +- libcpp/include/cpp-id-data.h|6 + libcpp/include/cpplib.h | 15 +- libcpp/include/line-map.h | 827 +-- libcpp/init.c |5 +- libcpp/internal.h | 60 +- libcpp/lex.c| 107 ++- libcpp/line-map.c | 831 -- libcpp/macro.c | 1350 --- libcpp/traditional.c|7 +- 49 files changed, 3656 insertions(+), 569 deletions(-) create mode
[PATCH 4/7] Support -fdebug-cpp option
This patch adds -fdebug-cpp option. When used with -E this dumps the
relevant macro map before every single token. This clutters the output
a lot but has proved to be invaluable in tracking some bugs during the
development of the virtual location support.
Tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
* include/cpplib.h (struct cpp_options)debug: New struct member.
* include/line-map.h (linemap_dump_location): Declare ...
* line-map.c (linemap_dump_location): ... new function.
gcc/
* doc/cppopts.texi: Document -fdebug-cpp.
* doc/invoke.texi: Add -fdebug-cpp to the list of preprocessor
options.
gcc/c-family/
* c.opt (fdebug-cpp): New option.
* c-opts.c (c_common_handle_option): Handle the option.
* c-ppoutput.c (maybe_print_line_1): New static function. Takes an
output stream in parameter. Factorized from ...
(maybe_print_line): ... this. Dump location debug information when
-fdebug-cpp is in effect.
(print_line_1): New static function. Takes an output stream in
parameter. Factorized from ...
(print_line): ... here. Dump location information when -fdebug-cpp
is in effect.
(scan_translation_unit): Dump location information when
-fdebug-cpp is in effect.
---
gcc/c-family/c-opts.c |4 +++
gcc/c-family/c-ppoutput.c | 57
gcc/c-family/c.opt|4 +++
gcc/doc/cppopts.texi | 12 +
gcc/doc/invoke.texi |2 +-
libcpp/include/cpplib.h |4 +++
libcpp/include/line-map.h |4 +++
libcpp/line-map.c | 35 +++
8 files changed, 110 insertions(+), 12 deletions(-)
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index d36c396..61fa0ea 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -628,6 +628,10 @@ c_common_handle_option (size_t scode, const char *arg, int
value,
cpp_opts-preprocessed = value;
break;
+case OPT_fdebug_cpp:
+ cpp_opts-debug = 1;
+ break;
+
case OPT_ftrack_macro_expansion:
if (value)
value = 2;
diff --git a/gcc/c-family/c-ppoutput.c b/gcc/c-family/c-ppoutput.c
index 92e7fd3..4969b9a 100644
--- a/gcc/c-family/c-ppoutput.c
+++ b/gcc/c-family/c-ppoutput.c
@@ -59,7 +59,9 @@ static void account_for_newlines (const unsigned char *,
size_t);
static int dump_macro (cpp_reader *, cpp_hashnode *, void *);
static void dump_queued_macros (cpp_reader *);
+static void print_line_1 (source_location, const char*, FILE *);
static void print_line (source_location, const char *);
+static void maybe_print_line_1 (source_location, FILE *);
static void maybe_print_line (source_location);
static void do_line_change (cpp_reader *, const cpp_token *,
source_location, int);
@@ -243,7 +245,12 @@ scan_translation_unit (cpp_reader *pfile)
in_pragma = false;
}
else
- cpp_output_token (token, print.outf);
+ {
+ if (cpp_get_options (parse_in)-debug)
+ linemap_dump_location (line_table, token-src_loc,
+print.outf);
+ cpp_output_token (token, print.outf);
+ }
if (token-type == CPP_COMMENT)
account_for_newlines (token-val.str.text, token-val.str.len);
@@ -297,8 +304,9 @@ scan_translation_unit_trad (cpp_reader *pfile)
/* If the token read on logical line LINE needs to be output on a
different line to the current one, output the required newlines or
a line marker, and return 1. Otherwise return 0. */
+
static void
-maybe_print_line (source_location src_loc)
+maybe_print_line_1 (source_location src_loc, FILE *stream)
{
int src_line = LOCATION_LINE (src_loc);
const char *src_file = LOCATION_FILE (src_loc);
@@ -306,7 +314,7 @@ maybe_print_line (source_location src_loc)
/* End the previous line of text. */
if (print.printed)
{
- putc ('\n', print.outf);
+ putc ('\n', stream);
print.src_line++;
print.printed = 0;
}
@@ -318,22 +326,37 @@ maybe_print_line (source_location src_loc)
{
while (src_line print.src_line)
{
- putc ('\n', print.outf);
+ putc ('\n', stream);
print.src_line++;
}
}
else
-print_line (src_loc, );
+print_line_1 (src_loc, , stream);
+
+}
+
+/* If the token read on logical line LINE needs to be output on a
+ different line to the current one, output the required newlines or
+ a line marker, and return 1. Otherwise return 0. */
+
+static void
+maybe_print_line (source_location src_loc)
+{
+ if (cpp_get_options (parse_in)-debug)
+linemap_dump_location (line_table, src_loc,
+ print.outf);
+ maybe_print_line_1 (src_loc, print.outf);
}
/* Output a line marker for logical line LINE. Special flags are 1
or 2 indicating entering or leaving a file.
[PATCH 3/7] Emit macro expansion related diagnostics
In this third instalment the diagnostic machinery -- when faced with
the virtual location of a token resulting from macro expansion -- uses
the new linemap APIs to unwind the stack of macro expansions that led
to that token and emits a [hopefully] more useful message than what we
have today.
diagnostic_report_current_module has been slightly changed to use the
location given by client code instead of the global input_location
variable. This results in more precise diagnostic locations in general
but then the patch adjusts some C++ tests which output changed as a
result of this.
Three new regression tests have been added.
The mandatory screenshot goes like this:
[dodji@adjoa gcc]$ cat -n test.c
1#define OPERATE(OPRD1, OPRT, OPRD2) \
2 OPRD1 OPRT OPRD2;
3
4#define SHIFTL(A,B) \
5 OPERATE (A,,B)
6
7#define MULT(A) \
8 SHIFTL (A,1)
9
10void
11g ()
12{
13 MULT (1.0);/* 1.0 1; -- so this is an error. */
14}
[dodji@adjoa gcc]$ ./cc1 -quiet -ftrack-macro-expansion test.c
test.c: In function ‘g’:
test.c:5:14: erreur: invalid operands to binary (have ‘double’ and ‘int’)
test.c:2:9: note: in expansion of macro 'OPERATE'
test.c:5:3: note: expanded from here
test.c:5:14: note: in expansion of macro 'SHIFTL'
test.c:8:3: note: expanded from here
test.c:8:3: note: in expansion of macro 'MULT2'
test.c:13:3: note: expanded from here
The combination of this patch and the previous ones boostrapped with
--enable-languages=all,ada and passed regression tests on
x86_64-unknown-linux-gnu.
libcpp/
* include/line-map.h (linemap_expand_location_full): Add an output
parameter returning the spelling location the input location got
resolved to, at declaration point ...
* line-map.c (linemap_expand_location_full): ... and at definition
point.
gcc/
* gcc/diagnostic.h (diagnostic_report_current_module): Add a
location parameter.
* diagnostic.c (diagnostic_report_current_module): Add a location
parameter to the function definition. Use it instead of
input_location. Fully expand the location rather than just
looking up its map and risking to touch a resulting macro map.
(default_diagnostic_starter): Pass the relevant diagnostic
location to diagnostic_report_current_module.
* tree-diagnostic.c (maybe_unwind_expanded_macro_loc): New.
(virt_loc_aware_diagnostic_finalizer): Likewise.
(diagnostic_report_current_function): Pass the
relevant location to diagnostic_report_current_module.
* tree-diagnostic.h (virt_loc_aware_diagnostic_finalizer): Declare
new function.
* input.c (expand_location): Adjust call to
linemap_expand_location_full.
* toplev.c (general_init): By default, use the new
virt_loc_aware_diagnostic_finalizer as diagnostic finalizer.
gcc/cp/
* error.c (cp_diagnostic_starter): Pass the relevant location to
diagnostic_report_current_module.
(cp_diagnostic_finalizer): Call virt_loc_aware_diagnostic_finalizer.
gcc/testsuite/
* gcc.dg/cpp/macro-exp-tracking-1.c: New test.
* gcc.dg/cpp/macro-exp-tracking-2.c: Likewise.
* gcc.dg/cpp/macro-exp-tracking-3.c: Likewise.
* gcc.dg/cpp/pragma-diagnostic-2.c: Likewise.
* g++.dg/cpp0x/initlist15.C: Discard errors pointing at multiple
levels of included files.
* g++.old-deja/g++.robertl/eb43.C: Likewise.
* g++.old-deja/g++.robertl/eb79.C: Likewise.
* gcc.target/i386/sse-vect-types.c: Likewise.
---
gcc/Makefile.in |2 +-
gcc/cp/error.c |5 +-
gcc/diagnostic.c| 14 +-
gcc/diagnostic.h|2 +-
gcc/input.c |2 +-
gcc/testsuite/g++.dg/cpp0x/initlist15.C |1 +
gcc/testsuite/g++.old-deja/g++.robertl/eb43.C |4 +
gcc/testsuite/g++.old-deja/g++.robertl/eb79.C |4 +
gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-1.c | 21 +++
gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-2.c | 21 +++
gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-3.c | 14 ++
gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-4.c | 14 ++
gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-2.c | 34 +
gcc/testsuite/gcc.target/i386/sse-vect-types.c |6 +
gcc/toplev.c|3 +
gcc/tree-diagnostic.c | 181 ++-
gcc/tree-diagnostic.h |3 +-
libcpp/include/line-map.h | 14 ++-
libcpp/line-map.c |4 +-
19 files changed, 332 insertions(+), 17 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-1.c
create mode 100644
[PATCH 7/7] Reduce memory waste due to non-power-of-2 allocs
This patch basically arranges for the allocation size of line_map
buffers to be as close as possible to a power of two. This
*significantly* decreases peak memory consumption as (macro) maps are
numerous and stay live during all the compilation.
Ideally, I'd prefer some parts of this patch to be integrated into the
memory allocator. That is, I'd like to see the memory allocator have
an interface that returns the actual size of memory it has allocated.
This would help client code like this one to avoid requesting memory
unnecessarily. I am proposing this patch as is for now, at least to
see if the approach would be acceptable.
Tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
* line-map.c (next_largest_power_of_two): New.
(new_linemap): Use it.
---
libcpp/line-map.c | 50 +++---
1 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index d69160c..327ce85 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -95,6 +95,18 @@ linemap_tracks_macro_expansion_locs_p (struct line_maps *set)
return LINEMAPS_MACRO_MAPS (set) != NULL;
}
+/* Return the smallest power of two that is greater than N. */
+static unsigned
+next_largest_power_of_two (unsigned n)
+{
+ n |= (n 1);
+ n |= (n 2);
+ n |= (n 4);
+ n |= (n 8);
+ n |= (n 16);
+ return n+1;
+}
+
/* Create a new line map in the line map set SET, and return it.
REASON is the reason of creating the map. It determines the type
of map created (ordinary or macro map). Note that ordinary maps and
@@ -109,19 +121,43 @@ new_linemap (struct line_maps *set,
bool macro_map_p = (reason == LC_ENTER_MACRO);
struct line_map *result;
- if (LINEMAPS_USED (set, macro_map_p) == LINEMAPS_ALLOCATED (set,
macro_map_p))
+ if (LINEMAPS_USED (set, macro_map_p)
+ == LINEMAPS_ALLOCATED (set, macro_map_p))
{
/* We ran out of allocated line maps. Let's allocate more. */
+ unsigned alloc_size;
line_map_realloc reallocator
= set-reallocator ? set-reallocator : xrealloc;
+
+ /* We are going to execute some dance to try to reduce the
+overhead of the memory allocator, in case we are using the
+ggc-page.c one.
+
+The actual size of memory we are going to get back from the
+allocator is the smallest power of 2 that is greater than the
+size we requested. So let's consider that size then. */
+
+ alloc_size =
+ (2 * LINEMAPS_ALLOCATED (set, macro_map_p) + 256)
+ * sizeof (struct line_map);
+
+ alloc_size = next_largest_power_of_two (alloc_size);
+
+ /* Now alloc_size contains the exact memory size we would get if
+we have asked for the initial alloc_size amount of memory.
+Let's get back to the number of macro map that amounts
+to. */
LINEMAPS_ALLOCATED (set, macro_map_p) =
- 2 * LINEMAPS_ALLOCATED (set, macro_map_p) + 256;
- LINEMAPS_MAPS (set, macro_map_p)
- = (struct line_map *) (*reallocator) (LINEMAPS_MAPS (set, macro_map_p),
- LINEMAPS_ALLOCATED (set,
- macro_map_p)
- * sizeof (struct line_map));
+ alloc_size / (sizeof (struct line_map));
+
+ /* And now let's really do the re-allocation. */
+ LINEMAPS_MAPS (set, macro_map_p) =
+ (struct line_map *) (*reallocator)
+ (LINEMAPS_MAPS (set, macro_map_p),
+(LINEMAPS_ALLOCATED (set, macro_map_p)
+ * sizeof (struct line_map)));
+
result =
LINEMAPS_MAPS (set, macro_map_p)[LINEMAPS_USED (set, macro_map_p)];
memset (result, 0,
--
1.7.6
[PATCH 5/7] Add line map statistics to -fmem-report output
This patch adds statistics about line maps' memory consumption and
macro expansion to the output of -fmem-report. It has been useful in
trying to reduce the memory consumption of the macro maps support.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/
* input.c (ONE_K, ONE_M, SCALE, STAT_LABEL, FORMAT_AMOUNT): New
macros.
(num_expanded_macros_counter, num_macro_tokens_counter): Declare
new counters.
(dump_line_table_statistics): Define new function.
* input.h (dump_line_table_statistics): Declare new function.
* toplev.c (dump_memory_report): Call dump_line_table_statistics.
libcpp/
* line-map.h (struct linemap_stats): Declare new struct.
(linemap_get_statistics): Declare ...
* line-map.c (linemap_get_statistics): ... new function.
* macro.c (num_expanded_macros_counter, num_macro_tokens_counter):
Declare new counters.
(enter_macro_context, replace_args): Update
num_macro_tokens_counter.
(cpp_get_token_1): Update num_expanded_macros_counter.
---
gcc/input.c | 83 +
gcc/input.h |2 +
gcc/toplev.c |1 +
libcpp/include/line-map.h | 17 +
libcpp/line-map.c | 62 +
libcpp/macro.c| 29 +--
6 files changed, 190 insertions(+), 4 deletions(-)
diff --git a/gcc/input.c b/gcc/input.c
index f3c7bfa..614db3e 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -61,3 +61,86 @@ expand_location (source_location loc)
}
return xloc;
}
+
+#define ONE_K 1024
+#define ONE_M ONE_K * ONE_K
+
+/* Display a number as an integer multiple of either:
+ - 1024, if said integer is = to 10 K (in base 2)
+ - 1024 * 1024, if said integer is = 10 M in (base 2)
+ */
+#define SCALE(x) ((unsigned long) ((x) 10 * ONE_K \
+ ? (x) \
+ : ((x) 10 * ONE_M \
+? (x) / ONE_K \
+: (x) / (ONE_M
+
+/* For a given integer, display either:
+ - the character 'k', if the number is higher than 10 K (in base 2)
+ but strictly lower than 10 M (in base 2)
+ - the character 'M' if the number is higher than 10 M (in base2)
+ - the charcter ' ' if the number is strictly lower than 10 K */
+#define STAT_LABEL(x) ((x) 10 * ONE_K ? ' ' : ((x) 10 * ONE_M ? 'k' : 'M'))
+
+/* Display an integer amount as multiple of 1K or 1M (in base 2à).
+ Display the correct unit (either k, M, or ' ') after the amout, as
+ well. */
+#define FORMAT_AMOUNT(size) SCALE (size), STAT_LABEL (size)
+
+/* Counters defined in libcpp's macro.c. */
+extern unsigned num_expanded_macros_counter;
+extern unsigned num_macro_tokens_counter;
+
+/* Dump statistics to stderr about the memory usage of the line_table
+ set of line maps. This also displays some statistics about macro
+ expansion. */
+
+void
+dump_line_table_statistics (void)
+{
+ struct linemap_stats s;
+
+ memset (s, 0, sizeof (s));
+
+ fprintf (stderr, Number of expanded macros: %u\n,
+ num_expanded_macros_counter);
+ if (num_expanded_macros_counter != 0)
+fprintf (stderr, Average number of tokens per macro expansion: %u\n,
+num_macro_tokens_counter / num_expanded_macros_counter);
+ linemap_get_statistics (line_table, s);
+
+ fprintf (stderr,
+ \nLine Table allocations during the
+ compilation process\n);
+ fprintf (stderr, Total allocated maps size: %5lu%c\n,
+ SCALE (s.total_allocated_map_size),
+ STAT_LABEL (s.total_allocated_map_size));
+ fprintf (stderr, Total used maps size:%5lu%c\n,
+ SCALE (s.total_used_map_size),
+ STAT_LABEL (s.total_used_map_size));
+ fprintf (stderr, Ordinary map used size: %5lu%c\n,
+ SCALE (s.ordinary_maps_used_size),
+ STAT_LABEL (s.ordinary_maps_used_size));
+ fprintf (stderr, Macro maps used size:%5lu%c\n,
+ SCALE (s.macro_maps_used_size),
+ STAT_LABEL (s.macro_maps_used_size));
+ fprintf (stderr, Number of ordinary maps allocated: %5lu%c\n,
+ SCALE (s.num_ordinary_maps_allocated),
+ STAT_LABEL (s.num_ordinary_maps_allocated));
+ fprintf (stderr, Number of ordinary maps used:%5lu%c\n,
+ SCALE (s.num_ordinary_maps_used),
+ STAT_LABEL (s.num_ordinary_maps_used));
+ fprintf (stderr, Number of macro maps used: %5lu%c\n,
+ SCALE (s.num_macro_maps_used),
+ STAT_LABEL (s.num_macro_maps_used));
+ fprintf (stderr, Ordinary maps allocated size:%5lu%c\n,
+ SCALE (s.ordinary_maps_allocated_size),
+ STAT_LABEL (s.ordinary_maps_allocated_size));
+ fprintf (stderr, Macro maps locations size: %5lu%c\n,
+ SCALE (s.macro_maps_locations_size),
+ STAT_LABEL
[PATCH 6/7] Kill pedantic warnings on system headers macros
This patch leverages the virtual location infrastructure to avoid emitting pedantic warnings related to macros defined in system headers but expanded in normal TUs. The point is to make diagnostic routines use virtual locations of tokens instead of their spelling locations. The diagnostic routines in turn indirectly use linemap_location_in_system_header_p to know if a given virtual location originated from a system header. The patch has two main parts. The libcpp part makes diagnostic routines called from the preprocessor expression parsing and number conversion code use virtual locations. The C FE part makes diagnostic routines called from the type specifiers validation code use virtual locations. This fixes the relevant examples presented in the comments of the bug but I guess, as usual, libcpp and the FEs will need on-going care to use more and more virtual locations of tokens instead of spelling locations. The combination of the patch and the previous ones boostrapped with --enable-languages=all,ada and passed regression tests on x86_64-unknown-linux-gnu. libcpp/ * include/cpplib.h (cpp_classify_number): Add a location parameter to the declaration. * internal.h (_cpp_get_prev_token_spelling_loc): Declare. * lex.c (_cpp_get_prev_token_spelling_loc): Factorize this from ... * errors.c (cpp_diagnostic): ... here. * expr.c (SYNTAX_ERROR_AT, SYNTAX_ERROR2_AT): New macros to emit syntax error using a virtual location. (cpp_classify_number): Add a virtual location parameter. Use SYNTAX_ERROR_AT instead of SYNTAX_ERROR, cpp_error_with_line instead of cpp_error and cpp_warning_with_line instead of cpp_warning. Pass the new virtual location parameter to those diagnostic routines. (eval_token): Add a virtual location parameter. Pass it down to cpp_classify_number. Use cpp_error_with_line instead of cpp_error, cpp_warning_with_line instead of cpp_warning, and pass the new virtual location parameter to these. (_cpp_parse_expr): Use cpp_get_token_with_location instead of cpp_get_token, to get the virtual location of the token. Use SYNTAX_ERROR2_AT instead of SYNTAX_ERROR2, cpp_error_with_line instead of cpp_error. Use the virtual location instead of the spelling location. * macro.c (maybe_adjust_loc_for_trad_cpp): Define new static function. (cpp_get_token_with_location): Use it. gcc/c-family * c-lex.c (c_lex_with_flags): Adjust to pass the virtual location to cpp_classify_number. gcc/ * c-tree.h (finish_declspecs): Add a virtual location parameter. * c-decl.c (finish_declspecs): Add a virtual location parameter. Use error_at instead of error and pass down the virtual location to pewarn and error_at. (declspecs_add_type): Use in_system_header_at instead of in_system_header. * c-parser.c (c_parser_declaration_or_fndef): Pass virtual location of the relevant token to finish_declspecs. (c_parser_struct_declaration, c_parser_parameter_declaration): Likewise. (c_parser_type_name): Likewise. gcc/testsuite/ * gcc.dg/cpp/syshdr3.h: New test header. * gcc.dg/cpp/syshdr3.c: New test file. * gcc.dg/nofixed-point-2.c: Adjust to more precise location. --- gcc/c-decl.c | 17 ++-- gcc/c-family/c-lex.c |4 +- gcc/c-parser.c | 12 ++- gcc/c-tree.h |2 +- gcc/testsuite/gcc.dg/cpp/syshdr3.c | 16 +++ gcc/testsuite/gcc.dg/cpp/syshdr3.h |7 ++ gcc/testsuite/gcc.dg/nofixed-point-2.c |6 +- libcpp/errors.c| 21 + libcpp/expr.c | 176 +++- libcpp/include/cpplib.h|3 +- libcpp/internal.h |1 + libcpp/lex.c | 29 + 12 files changed, 183 insertions(+), 111 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr3.c create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr3.h diff --git a/gcc/c-decl.c b/gcc/c-decl.c index 3ed3c46..d2f013b 100644 --- a/gcc/c-decl.c +++ b/gcc/c-decl.c @@ -8910,7 +8910,7 @@ declspecs_add_type (location_t loc, struct c_declspecs *specs, break; case RID_COMPLEX: dupe = specs-complex_p; - if (!flag_isoc99 !in_system_header) + if (!flag_isoc99 !in_system_header_at (loc)) pedwarn (loc, OPT_pedantic, ISO C90 does not support complex types); if (specs-typespec_word == cts_void) @@ -9433,7 +9433,8 @@ declspecs_add_attrs (struct c_declspecs *specs, tree attrs) double. */ struct c_declspecs * -finish_declspecs (struct c_declspecs *specs) +finish_declspecs (struct c_declspecs *specs,
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
Mikael Morin wrote: let me understand one thing about coarray scalars: despite their name, they are arrays, right? Yes and no. In terms of the language, they are scalars - but they have a codimension, e.g. integer, save :: A[4:6, 7:*] is a scalar variable on each image, but it has a coarank of 2 with lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7. (The value of cobound(A, dim=2) depends on the number of images, it's = 7 in this example.) In terms of gfortran, nonallocatable coarrays are normal scalars - with a lang-specific node attached to them, which contains the cobounds, i.e., GFC_ARRAY_TYPE_P (type) = 1; GFC_TYPE_ARRAY_CORANK (type) = as-corank; with GFC_TYPE_ARRAY_LBOUND (type, dim) containing the trees for dim = (rank + 1) ... (rank + corank). The same scheme is used for assumed-type coarrays: subroutine sub(B, n) integer :: B(:)[5:7, n:*] Note that here that contrary to the dimension, the codimension is not : (i.e. assumed shape) but that it is assumed-size. For allocatable (scalar) coarrays, one has: integer, allocatable :: B[:, :] ! Note: The coshape is deferred ... allocate (B[2:3, 5:*]) Again, one has the actual data and the cobounds. For that case, I have decided to store the information in the array descriptor of rank == 0 and dim[0 ... corank-1] for the bounds. Thus, desc-data contains the scalar but the variable itself is a descriptor (GFC_DESCRIPTOR_TYPE_P). The corank is not stored in the descriptor, but as one knows the number of codimensions (an explicit interface is required for allocatable coarray dummies), one knows the corank. Then when you do in gfc_conv_array_ref: + if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se-expr))) + se-expr = build_fold_indirect_ref (gfc_conv_array_data (se-expr)); [...] return; you are returning scalar[1] instead of scalar (== scalar[this_image()]) or scalar[whatever_image_selector], aren't you? Well, the current implementation supports effectively only a single image - for -fcoarray=single on purpose and for -fcoarray=lib because it has not yet been implemented. Later, one has to add some function call for scalar[image_numer] while scalar itself is the local variable and can be handled as above. The expression of scalar ends up having expr-ref-type == REF_ARRAY with dimen_type == DIMEN_THIS_IMAGE. That way one can distinguish a reference to the local coarray and to a remote coarray (coindexed variable); note that coarray[this_image()] also counts as remote/coindexed. Sorry for the delay; it seems that the more it goes, the more you are the only one who can maintain coarray stuff. :-( Well, Daniel Carrera develops into an trans*.c, allocate, libgfortran/caf/ expert :-) Tobias PS: I should document somewhere how coarrays are implemented internally.
Re: PATCH RFA: Build stages 2 and 3 with C++
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? Diego.
Re: [PATCH 0/7] Tracking locations of tokens resulting from macro expansion
Dodji Seketeli wrote: Support -fdebug-cpp option Regarding Fortran: I think having a full support for the macro expansion would be quite a lot of work, but I think -fdebug-cpp comes for free as it is handled by libcpp. Thus, how about adding support for that flag also to Fortran? Tobias
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
On Sat, Jul 16, 2011 at 05:25:36PM +0200, Tobias Burnus wrote: PS: I should document somewhere how coarrays are implemented internally. gcc/gcc4x/gcc/fortran/gfc-internals.texi :-) -- Steve
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote: Mikael Morin wrote: let me understand one thing about coarray scalars: despite their name, they are arrays, right? Yes and no. In terms of the language, they are scalars - but they have a codimension, e.g. integer, save :: A[4:6, 7:*] is a scalar variable on each image, but it has a coarank of 2 with lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7. ucobound(A, dim=1) == 6 ? Otherwise I'm even more confused. Then when you do in gfc_conv_array_ref: + if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se-expr))) + se-expr = build_fold_indirect_ref (gfc_conv_array_data (se-expr)); [...] return; you are returning scalar[1] instead of scalar (== scalar[this_image()]) or scalar[whatever_image_selector], aren't you? Well, the current implementation supports effectively only a single image - for -fcoarray=single on purpose and for -fcoarray=lib because it has not yet been implemented. Later, one has to add some function call for scalar[image_numer] while scalar itself is the local variable and can be handled as above. Ah, OK; that's where I was misunderstanding coarrays. I was thinking that a (possibly out of date) copy of remote images was available locally, like a normal array; and with any network exchanges happening during the SYNC* calls only. In fact network traffic happens anywhere there are square brackets, and SYNC* are mere iddle waits, right? The expression of scalar ends up having expr-ref-type == REF_ARRAY with dimen_type == DIMEN_THIS_IMAGE. That way one can distinguish a reference to the local coarray and to a remote coarray (coindexed variable); note that coarray[this_image()] also counts as remote/coindexed. While it seems to work well, we would probably have gained some clarity by using a separate struct for coarray references. For example with the current scheme, array[1,2] has type ARRAY_FULL, but some dimen_type are of type DIMEN_ELEMENT. Odd. Sorry for the delay; it seems that the more it goes, the more you are the only one who can maintain coarray stuff. :-( Well, Daniel Carrera develops into an trans*.c, allocate, libgfortran/caf/ expert :-) Thanks for all the clarifications. Patch is OK (I guess). Mikael
Re: PATCH [5/n] X32: Supprot 32bit address
On Fri, Jul 15, 2011 at 10:18 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
If the first form of the address is not OK (it does not represent the
hardware operation), then it should not enter into the insn stream.
This means, that it should be fixed (legitimized) to second form by
appropriate function (it looks that LEGITIMIZE_RELOAD_ADDRESS should
fix it, since the incorrect address is generated by IRA/reload). After
this operation, various predicates, based on ix86_decompose_address
will start to work, since they will decompose valid memory addresses.
IRA/.RELOAD isn't prepared to deal with it and it just ICEs. I opened
a few GCC bugs on this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744
is one of them. That is why I went this route.
Hm, but it crashed in postreload pass since the address was not in the
legitimate form. This is exactly what LEGITIMIZE_RELOAD_ADDRESS
fixes. Did you try to go this route?
It ran into various ICEs like:
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o m.s -mx32
-std=gnu99
-O2 -fPIC m.i
m.i: In function \u2018__kernel_rem_pio2\u2019:
m.i:18:1: error: insn does not satisfy its constraints:
(insn 108 106 186 3 (set (reg:SI 40 r11 [207])
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx [205])
(const_int 8 [0x8]))
(subreg:SI (plus:DI (reg/f:DI 7 sp)
(const_int 208 [0xd0])) 0))
(const_int -160 [0xff60]))) m.i:3 251 {*lea_1_x32}
(nil))
m.i:18:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [m.s] Error 1
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
They make things even more complex. ix86_simplify_base_index_disp
is called after reload is done since we can do this translation safely
only on hard registers, not on pseudo registers.
Hi Uros,
The current implementation has been tested extensively. I'd like to keep
it ASIS so that we can have a working x32 support. We will revisit it later:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49765
after we have a working x32 GCC.
Thanks.
--
H.J.
Re: [PATCH 0/7] Tracking locations of tokens resulting from macro expansion
Tobias Burnus bur...@net-b.de a écrit: Dodji Seketeli wrote: Support -fdebug-cpp option Regarding Fortran: I think having a full support for the macro expansion would be quite a lot of work, I know nothing about Fortran, but I would hope that adding support for this feature to it should not be hard. Here is what happens basically, when -ftrack-macro-expansion is on: 1/ locations that are instance of source_location are now virtual locations. They encode locations of tokens across macro expansion. 2/ the code that unwinds and prints the stack of macro expansion is the function maybe_unwind_expanded_macro_loc, and is called by the diagnostic finalizer, which passes it the (now virtual) location of the diagnostic. Each front ends provide its own diagnostic finalizer. By default (in general_init) I have set this diagnostic finalizer to virt_loc_aware_diagnostic_finalizer which calls maybe_unwind_expanded_macro_loc. This is done in the patch [PATCH 3/7] Emit macro expansion related diagnostics. If Fortran provides its own different diagnostic finalizer, it can call maybe_unwind_expanded_macro_loc in there. I believe this should be enough. but I think -fdebug-cpp comes for free as it is handled by libcpp. Thus, how about adding support for that flag also to Fortran? Except that I know zilsh about Fortran and it would take me some time, at least for testing. But yes, I think it would be good to have it for Fortran. I'll put that on my TODO list, unless someone beats me to it. -- Dodji
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
On 07/16/2011 06:43 PM, Mikael Morin wrote: Well, the current implementation supports effectively only a single image - for -fcoarray=single on purpose and for -fcoarray=lib because it has not yet been implemented. Later, one has to add some function call for scalar[image_numer] while scalar itself is the local variable and can be handled as above. Ah, OK; that's where I was misunderstanding coarrays. I was thinking that a (possibly out of date) copy of remote images was available locally, like a normal array; and with any network exchanges happening during the SYNC* calls only. In fact network traffic happens anywhere there are square brackets, and SYNC* are mere iddle waits, right? I am no expert, but I'll try to answer: Yes. Yes, network traffic happens whenever there are square brackets and no copies are stored locally. However, you have no guarantee of how far ahead other images are. For example: real :: foo[:] foo = this_image() if (this_image() == 1) then foo = foo + foo[2] end if if (this_image() == 2) then foo = foo + foo[1] end if This program could do all sorts of crazy things. As you said, the SYNC is a idle wait, just to make processes wait for each other. The following program is predictable: real :: foo[:] foo = this_image() sync all if (this_image() == 1) then foo = foo + foo[2] end if sync all if (this_image() == 2) then foo = foo + foo[1] end if Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: [Patch, Fortran] Support allocatable *scalar* coarrays
Mikael Morin wrote: On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote: integer, save :: A[4:6, 7:*] is a scalar variable on each image, but it has a coarank of 2 with lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7. ucobound(A, dim=1) == 6 ? Otherwise I'm even more confused. Sorry for the typo. It's indeed 6. Ah, OK; that's where I was misunderstanding coarrays. I was thinking that a (possibly out of date) copy of remote images was available locally, like a normal array; and with any network exchanges happening during the SYNC* calls only. In fact network traffic happens anywhere there are square brackets, and SYNC* are mere iddle waits, right? In terms of the Fortran standard: Yes. In terms of the implementation: It depends. For the front end: It simply requests to receive (or send) remote data when it sees a [...] - for pushing data to an remote image, it might even be asynchrnous. However, the current plan for libcaf_mpi is that one has two-sided communication; the image which wants to have the content of a remote image sends a request - and waits for the answer while continuing to process incoming requests. Thus, if the image is unlucky, it has to wait until the other image hits a SYNC and can then answer requests. If it is lucky, the other image also has some remove access and can directly process the request. Via a helper process, the answer could be provided faster - or via one-sided communication - or in case of a shared memory implementation. While it seems to work well, we would probably have gained some clarity by using a separate struct for coarray references. For example with the current scheme, array[1,2] has type ARRAY_FULL, but some dimen_type are of type DIMEN_ELEMENT. Odd. Presumably. The problem is that codimensions act on one hand like normal dimensions but on the other hand they are different. When declaring them, rank + corank = 15, adding them as extra dimension is also logical etc. On the other hand, when referencing a local coarray, one has no brackets and if there is a bracket, one can only give an element (single coarray) and not a range or vector. Thanks for all the clarifications. Patch is OK (I guess). Thanks for the review! Tobias
Re: PATCH [5/n] X32: Supprot 32bit address
On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu hjl.to...@gmail.com wrote: Yes, this is an example from PR I am referring to. Did you try to define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this. They make things even more complex. ix86_simplify_base_index_disp is called after reload is done since we can do this translation safely only on hard registers, not on pseudo registers. Hi Uros, The current implementation has been tested extensively. I'd like to keep it ASIS so that we can have a working x32 support. We will revisit it later: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49765 after we have a working x32 GCC. This can not be only my decision, I have CCd other x86 maintainers and RMs for their opinion on this question. Uros.
Re: PATCH RFA: Build stages 2 and 3 with C++
On 07/16/2011 08:52 AM, Ian Lance Taylor wrote: I would like to propose this patch as a step toward building gcc using a C++ compiler. This patch builds stage1 with the C compiler as usual, and defaults to building stages 2 and 3 with a C++ compiler built during stage 1. I just completed a run using the following language configure options: ../gcc/configure \ ... --enable-build-with-cxx \ --enable-languages=c,c++,fortran,ada \ on x86-64-unknown-linux-gnu. As far as I can see it was successful: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01852.html For extra fun, the 0:20 UTC run at home using: ../gcc/configure \ ... --with-build-config=bootstrap-lto \ is going to use Ada as a language *of choice* instead of Fortran based on the value of $RANDOM in the bash shell :-) language=fortran if [ $RANDOM -lt 16384 ] then language=ada fi ../gcc/configure \ --prefix=/tmp/lto \ --enable-languages=$language \ --with-build-config=bootstrap-lto \ I'll see you tomorrow (evil cackle) :-) All this is using: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-1) toon@super:~$ gnat -v GNAT 4.6.1 ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: PATCH RFA: Build stages 2 and 3 with C++
Diego Novillo dnovi...@google.com writes: On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote: 2011-07-15 Ian Lance Taylor i...@google.com * configure.ac: Add --enable-build-poststage1-with-cxx. If set, make C++ a boot_language. Set and substitute POSTSTAGE1_CONFIGURE_FLAGS. * Makefile.tpl (POSTSTAGE1_CONFIGURE_FLAGS): New variable. (STAGE[+id+]_CONFIGURE_FLAGS): Add $(POSTSTAGE1_CONFIGURE_FLAGS). * configure, Makefile.in: Rebuild. I agree with this change. For reference, have you measured the difference in bootstrap time? Clearly, it will be slower, but how much? I have not measured the change in bootstrap time, no. Ian
Re: [PATCH 0/3] Fix PR47654 and PR49649
On 07/07/2011 08:07 PM, Sebastian Pop wrote:
Hi,
Hi Sebastian,
sorry for taking so long. Here some comments from me:
First there are two cleanup patches independent of the fix:
Start counting nesting level from 0.
Do not compute twice type, lb, and ub.
Then the patch that fixes PR47654:
Fix PR47654: Compute LB and UB of a CLAST expression.
One of the reasons we cannot determine the IV type only from the
polyhedral representation is that as in the testcase of PR47654, we
are asked to generate an induction variable going from 0 to 127. That
could be represented with a char. However the upper bound
expression of the loop generated by CLOOG is min (127, 51*scat_1 + 50)
and that would overflow if we use a char type. To evaluate a type
in which the expression 51*scat_1 + 50 does not overflow, we have to
compute an upper and lower bound for the expression.
To fix the problem exposed by Tobias:
for (i = 0 ; i 2; i++)
for (j = i ; j i + 1; j++)
for (k = j ; k j + 1; k++)
for (m = k ; m k + 1; m++)
for (n = m ; n m + 1; n++)
A[0] += A[n];
I am a little bit afraid that we will increase the type size by an
order of magnitude (or at least one bit) for each nesting level.
instead of computing the lb and ub of scat_1 in 51*scat_1 + 50 based
on the type of scat_1 (that we already code generated when building
the outer loop), we use the polyhedral representation to get an
accurate lb and ub for scat_1.
I think this part is OK.
With the new cloog-isl you may get even more information (and
consequently smaller tyes), if you do not only us domain + scattering,
but intersect it with the subset of the scattering space that the loop
enumerates (This information is available in cloog-isl).
Another way to get smaller types is to only get the maximal/minimal
value each constraint can have. Let this be an upper bound up =
min(5+3*n-8*m+33*i, 5i), which has two constraints.
5+3*n-8*m+33*i and 5i. Here we do not need to ensure that every single
result during the calculation of 5+3*n-8*m+33*i fits into its type.
Overflows during addition and multiplication should not affect the final
result, as long as the overflow follows modulo semantics and as long as
the type is large enough to store the final value. Only for the
calculations like min/max/div/mod we need to ensure that every
intermediate value fits in the range of the used type.
When translating the substitutions of a user statement using this
precise method, like for example S5 in:
for (scat_1=0;scat_1=min(T_3-1,T_4-1);scat_1++) {
S5(scat_1);
we get a type that is too precise: based on the interval [0,99] we get
the type unsigned char when the type of scat_1 is int, misleading
the vectorizer due to the insertion of spurious casts:
Here I am a little lost. You write using the precise method you get an
interval [0,99] for the example in vect-pr43423.c. This is the example:
int a[100], b[100], c[100];
void foo(int n, int mid)
{
int i;
for(i=0; in; i++)
{
if (i mid)
a[i] = a[i] + b[i];
else
a[i] = a[i] + c[i];
}
}
I do not see, how you would derive this small type, as the parameters of
function foo() allow a range that is a lot larger.
So lets assume the size of n is known and limited to 100 in the context.
Like this you may be able to get such a precise type.
# Access function 0: (int) {(unnamed-unsigned:8) graphite_IV.7_56, +, 1}_3;
#)
affine dependence test not usable: access function not affine or constant.
So we have to keep around the previous code gcc_type_for_clast_* that
computes the type of an expression as the max precision of the
components of that expression, and use that when computing the types
of substitution expressions.
Here I am lost again. I understand that very small types may introduce
more casts (and casts are always difficult to analyze). However, I do
not understand your solution.
First of all it seems the gcc_type_for_clast ... functions are always
needed to calculate the types, as just using polyhedral methods would
not get larger types, as they may be needed for intermediate results.
Which functions in your patch (or in the current graphite code), are
only needed to ensure that no problematic casts are inserted? This would
probably help me to understand how they ensure no problematic casts are
generated.
Cheers
Tobi
P.S.: I would love to see this upper/lower bound calculation being part
of CLooG.
Re: PATCH to support running the G++ testsuite in C++0x mode
On 07/16/2011 04:39 AM, Matthias Klose wrote:
The change to the toplevel Makefile.in was made in the generated file.
Oops, I was forgetting about the new Makefile system. This patch fixes
that, and also adds a check-target-libmudflap-c++ target to check-c++.
Jason
commit b1d35a4f5c4b4f0ae6fef6aea0698febecfb8c9b
Author: Jason Merrill ja...@redhat.com
Date: Sat Jul 16 22:05:47 2011 -0400
* Makefile.def (language=c++): Add check-c++0x and
check-target-libmudflap-c++.
* Makefile.tpl (check-target-libmudflap-c++): New.
* Makefile.in: Regenerate.
diff --git a/Makefile.def b/Makefile.def
index 0cc6ef6..5116341 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -511,8 +511,9 @@ dependencies = { module=configure-target-newlib; on=all-ld; };
dependencies = { module=configure-target-libgfortran; on=all-target-libquadmath; };
languages = { language=c; gcc-check-target=check-gcc; };
-languages = { language=c++; gcc-check-target=check-c++;
-lib-check-target=check-target-libstdc++-v3; };
+languages = { language=c++; gcc-check-target=check-c++ check-c++0x;
+lib-check-target=check-target-libstdc++-v3;
+lib-check-target=check-target-libmudflap-c++; };
languages = { language=fortran; gcc-check-target=check-fortran;
lib-check-target=check-target-libquadmath;
lib-check-target=check-target-libgfortran; };
diff --git a/Makefile.in b/Makefile.in
index e80f048..3b8e6c7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -40120,6 +40120,13 @@ maintainer-clean-target-libgomp:
+@if target-libmudflap
+.PHONY: check-target-libmudflap-c++
+check-target-libmudflap-c++:
+ $(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) c++frags.exp check-target-libmudflap
+
+@endif target-libmudflap
+
# --
# GCC module
# --
@@ -40153,13 +40160,8 @@ check-gcc-c++:
r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
- (cd gcc $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++);
-check-gcc-c++0x:
- r=`${PWD_COMMAND}`; export r; \
- s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- $(HOST_EXPORTS) \
- (cd gcc $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++0x);
-check-c++: check-gcc-c++ check-target-libstdc++-v3 check-gcc-c++0x
+ (cd gcc $(MAKE) $(GCC_FLAGS_TO_PASS) check-c++ check-c++0x);
+check-c++: check-gcc-c++ check-target-libstdc++-v3 check-target-libmudflap-c++
.PHONY: check-gcc-fortran check-fortran
check-gcc-fortran:
diff --git a/Makefile.tpl b/Makefile.tpl
index ea3d08d..0d2a0bf 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -1393,6 +1393,13 @@ ENDIF raw_cxx +]
[+ ENDFOR recursive_targets +]
[+ ENDFOR target_modules +]
+@if target-libmudflap
+.PHONY: check-target-libmudflap-c++
+check-target-libmudflap-c++:
+ $(MAKE) RUNTESTFLAGS=$(RUNTESTFLAGS) c++frags.exp check-target-libmudflap
+
+@endif target-libmudflap
+
# --
# GCC module
# --
