Fix cpp_sys_macro_p with -ftrack-macro-expansion

cpp_sys_macro_p crashes when -ftrack-macro-expansion is on.  The issue
can be reproduced by running the tests:

    runtest --tool gcc --tool_opts="-ftrack-macro-expansion" cpp.exp=sysmac1.c
    runtest --tool gcc --tool_opts="-ftrack-macro-expansion" cpp.exp=sysmac2.c

This is because it just doesn't support that mode.  Fixed thus.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion turned on
exhibits other separate issues that are addressed in subsequent
patches.  This patch just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

libcpp/

	* macro.c (cpp_sys_macro_p):  Support -ftrack-macro-expansion.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186965 138bc75d-0d04-0410-961f-82ee72b054a4
Fix token pasting with -ftrack-macro-expansion

This patch makes token pasting work with -ftrack-macro-expansion
turned on.  It improves some pasting related tests of the gcc.dg/cpp
subdirectory.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

libcpp/

	* macro.c (paste_all_tokens): Put the token resulting from pasting
	into an extended token context with -ftrack-macro-location is in
	effect.

gcc/testsuite/

	* gcc.dg/cpp/paste17.c: New test case for
	-ftrack-macro-expansion=2 mode only.
	* gcc.dg/cpp/macro-exp-tracking-5.c: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186966 138bc75d-0d04-0410-961f-82ee72b054a4
Fix PCH crash on GTYed pointer-to-scalar field of a struct

When -ftrack-macro-expansion is activated, the PCH generation
machinery can crash in gt_pch_save when it's about to relocate the
pointer for the
line_maps::info_macro::maps[i]::d.macro.macro_locations member.

The call that crashes (in ggc-common.c) is:

    state.ptrs[i]->note_ptr_fn (state.ptrs[i]->obj,
				state.ptrs[i]->note_ptr_cookie,
				relocate_ptrs, &state);

The ->note_ptr_fn called in this case is the gengtype-generated
gt_pch_p_9line_maps function.  It crashes because the second argument
passed to it is a pointer to struct line_map, instead of being a
pointer to struct line_maps (extra 's') like what the function
expects.

You can see the crash for the test case:

    runtest --tool g++ --tool_opts="-ftrack-macro-expansion" pch.exp=system-1.C

I believe it's because a part of the code of gt_pch_nx_line_maps
(generated as part of gtype-desc.c by gengtype) is not correct.  Note
that this gt_pch_nx_line_maps function is called from gt_pch_save in
the snippet:

  for (rt = gt_ggc_rtab; *rt; rt++)
    for (rti = *rt; rti->base != NULL; rti++)
      for (i = 0; i < rti->nelt; i++)
	(*rti->pchw)(*(void **)((char *)rti->base + rti->stride * i));

So, in that gt_pch_nx_line_maps, in the branch that starts with the
code:

      if ((*x).info_macro.maps != NULL) {
        size_t i3;
        for (i3 = 0; i3 != (size_t)(((*x).info_macro).used); i3++) {
          switch (((*x).info_macro.maps[i3]).reason == LC_ENTER_MACRO)

we have the code:

    gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations,
			(*x).info_macro.maps,
			 gt_pch_p_9line_maps,
			  gt_types_enum_last);

This last snippet registers gt_pch_p_9line_maps to be called on the
object pointed by (*x).info_macro.maps[i3].d.macro.macro_locations (as
a first argument), with (*x).info_macro.maps as its second argument.

Note that (*x).info_macro.maps is of type struct line_map*, while 'x'
is of type struct line_maps* - beware, there is an 's' at the end of
the latter.

The problem is that gt_pch_p_9line_maps requires that its second
argument be an instance of _struct line_maps_, not struct line_map.
So later when gt_pch_p_9line_maps is called, it just crashes.

More generally, these gt_pch_p_xxx functions seem to require that
their second argument be an instance of the xxx in question.  And that
invariant is violated by the snippet of code above.

The invariant seems to be violated only for the case where a GTYed
structure (possibly embedded in another GTYed structure) contains a
pointer to a scalar (that is not a string) which memory is ggc/GTY
managed, like the line_map_macro::macro_locations field.  And this
only happens for PCH generation.

Looking at gengtype.c, it seems like write_types_process_field can be
fooled in that case.  It expects that the expression d->prev_val[3]
contains the name of the second argument of the gt_pch_p_xxx (which is
generically referenced by wtd->subfield_marker_routine there).  That
expression can resolve to either "x", as we would like it to be, but
can also resolve to another arbitrary name for e.g, the case of a
pointer-to-struct used as a root).

This patch simply forces the second argument of gt_pch_p_xxx to be 'x'
even in the case of a member that is a pointer to a scalar.

As a result, here is the the diff the new generated gtype-desc.c file:

@@ -5234,7 +5234,7 @@ gt_pch_nx_line_maps (void *x_p)
                 size_t i2;
                 for (i2 = 0; i2 != (size_t)(2 * ((*x).info_ordinary.maps[i0].d.macro).n_tokens); i2++) {
                 }
-                gt_pch_note_object ((*x).info_ordinary.maps[i0].d.macro.macro_locations, (*x).info_ordinary.maps, gt_pch_p_9line_maps, gt_types_enum_last);
+                gt_pch_note_object ((*x).info_ordinary.maps[i0].d.macro.macro_locations, x, gt_pch_p_9line_maps, gt_types_enum_last);
               }
               break;
             default:
@@ -5261,7 +5261,7 @@ gt_pch_nx_line_maps (void *x_p)
                 size_t i5;
                 for (i5 = 0; i5 != (size_t)(2 * ((*x).info_macro.maps[i3].d.macro).n_tokens); i5++) {
                 }
-                gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations, (*x).info_macro.maps, gt_pch_p_9line_maps, gt_types_enum_last);
+                gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations, x, gt_pch_p_9line_maps, gt_types_enum_last);
               }
               break;
             default:
@@ -9366,7 +9366,7 @@ gt_pch_na_regno_reg_rtx (ATTRIBUTE_UNUSED void *x_p)
     for (i1 = 0; i1 != (size_t)(crtl->emit.x_reg_rtx_no); i1++) {
       gt_pch_n_7rtx_def (regno_reg_rtx[i1]);
     }
-    gt_pch_note_object (regno_reg_rtx, &regno_reg_rtx, gt_pch_pa_regno_reg_rtx, gt_types_enum_last);
+    gt_pch_note_object (regno_reg_rtx, x, gt_pch_pa_regno_reg_rtx, gt_types_enum_last);
   }
 }

I think it's pretty much what I was willing to have.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits
other separate issues that are addressed in subsequent patches.
This patch just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned
off, though.

gcc/

	* gengtype.c (write_types_process_field):  Force second argument
	of the call to the PCH object hierarchy walker to be 'x'.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186967 138bc75d-0d04-0410-961f-82ee72b054a4
Fix expansion point loc for macro-like tokens

Consider the test case gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c.
Its interesting part is:

    #define A(x) vari x /* line 7.  */
    #define vari(x)
    #define B , varj
    int A(B) ;  /* line 10.  */

In its initial version, this test was being pre-processed as:

    # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    # 1 "build/gcc//"
    # 1 "<command-line>"
    # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    # 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    int
    # 7 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
		 vari

	, varj ;

Note how "int" and "vari" are on separate lines, whereas "int" and
", varj" are on the same line.

This looks like a bug to me, even independantly from the macro
location tracking work.

With macro location tracking turned on, the preprocessed output
becomes:

    # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    # 1 "<command-line>"
    # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    # 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
    int vari , varj ;

Which, IMO, is what we'd expect.

This is due to an unexpected side effect of enter_macro_context when
passed a token that might look like a function-like macro at first
sight, but that it eventually considers to not be a macro after all.

This is the case for the "vari" token which looks like a macro when it
is first lexed, but is eventually considered to be a normal token by
enter_macro_context because it's not used as a function-like macro
invocation.

In that case, besides returning NULL, enter_macro_context sets
pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set
the location of the "vari" to the expansion point of A.

enter_macro_context sets pfile->context->c.macro to NULL in that case
because funlike_invocation_p reads one token pass "foo", sees that
there is no '(' token, so we are not invoking the function-like
parameter.  It then puts the tokens (which it has read after "foo")
back into the tokens stream by calling _cpp_push_token_context on it,
which sets pfile->context->c.macro to NULL, saying in essence that the
current macro expansion context is "stopped".

The fix here is to teach _cpp_push_token and
push_extended_tokens_context to continue the current macro context
when passed a NULL macro.  But then, now that there can be several
continguous contexts associated with the same macro, we need to teach
_cpp_pop_context to re-enable the expansion of the current macro only
when we are really out of expanding the current macro.  Otherwise we
can run in cases where we have recursive expansions of the same macro.

Tested on x86_64-unknown-linux-gnu against trunk.  Now this test has
the same output with and without tracking locations accross macro
expansions.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

libcpp/
	* macro.c (macro_of_context): New static function.
	(_cpp_push_token_context, push_extended_tokens_context): If the
	macro argument is NULL, it means we are continuing the expansion
	of the current macro, if any.  Update comments.
	(_cpp_pop_context): Re-enable expansion of the macro only when we
	are really out of the context of the current expansion.

gcc/testsuite/

	* gcc.dg/debug/dwarf2/pr41445-5.c: Adjust.
	* gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186968 138bc75d-0d04-0410-961f-82ee72b054a4
Make expand_location resolve to locus in main source file

Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a header
somewhere.  Turning on -ftrack-macro-expansion by default was
triggering a lot of failures (not necessarily related to diagnostics)
because expand_location resolves to spelling locations instead.

So I have changed expand_location to honour the initial expectation.

In addition, I came up with the new expand_location_to_spelling_point
used in diagnostic_build_prefix because the diagnostic system, on the
other hand, wants to point to the location of the token where it was
spelled, and then display the error context involving all the macro
whose expansion led to that spelling point - if we are in the context
of a macro expansion there.

This seems to me like a reasonable balance.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk and
whitnessed that a lot more tests were PASSing.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/

	* input.c (expand_location_1): New.  Takes a parameter to choose
	whether to resolve the location to spelling or expansion point.
	Was factorized from ...
	(expand_location): ... here.
	(expand_location_to_spelling_point): New.  Implemented in terms of
	expand_location_1.
	* diagnostic.c (diagnostic_build_prefix): Use the new
	expand_location_to_spelling_point instead of expand_location.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186969 138bc75d-0d04-0410-961f-82ee72b054a4
Strip "<built-in>" loc from displayed expansion context

Now that diagnostics for tokens coming from macro expansions point to
the spelling location of the relevant token (and then displays the
context of the expansion), some ugly (not so seldom) corner cases can
happen.

When the relevant token is a built-in token (which means the location
of that token is BUILTINS_LOCATION) the location prefix displayed to
the user in the diagnostic line is the "<built-in>:0:0" string.  For
instance:

    <built-in>:0:0: warning: conversion to 'float' alters 'int' constant value

For the user, I think this is surprising and useless.

A more user-friendly approach would be to refer to the first location
that (in the reported macro expansion context) is for a location in
real source code, like what is shown in the new test case
gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C accompanying
this patch.

To do this, I am making the line-map module provide a new
linemap_unwind_to_first_non_reserved_loc function that resolves a
virtual location to the first spelling location that is in real source
code.

I am then using that facility in the diagnostics printing module and
in the macro unwinder to avoid printing diagnostics lines that refer
to the locations for built-ins or more generally for reserved
locations.  Note that when I start the dance of skipping a built-in
location I also skip locations that are in system headers, because it
turned out that a lot of those built-ins are actually used in system
headers (e.g, "#define INT_MAX __INT_MAX__" where __INT_MAX__ is a
built-in).

Besides the user-friendliness gain, this patch allows a number of
regression tests to PASS unchanged with and without
-ftrack-macro-expansion.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

libcpp/

	* include/line-map.h (linemap_unwind_toward_expansion): Fix typo
	in comment.
	(linemap_unwind_to_first_non_reserved_loc): Declare new function.
	* line-map.c (linemap_unwind_to_first_non_reserved_loc): Define
	new function.

gcc/

	* input.c (expand_location_1): When expanding to spelling location
	in a context of a macro expansion, skip reserved system header
	locations.  Update comments.  * tree-diagnostic.c
	(maybe_unwind_expanded_macro_loc): Likewise.

gcc/testsuite/

	* g++.dg/warn/Wconversion-real-integer2.C: New test.
	* g++.dg/warn/Wconversion-real-integer-3.C: Likewise.
	* g++.dg/warn/conversion-real-integer-3.h: New header used by the
	new test above.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186970 138bc75d-0d04-0410-961f-82ee72b054a4
Fix -Wuninitialized for -ftrack-macro-expansion

Besides the warning emitted by warn_uninit, this function wants
to hint the user at where the uninitialized variable was declared, for
cases where the declaration location is outside the current function.

Now that expand_location expands to the location that is in the main
source file (even for -ftrack-macro-expansion) the hinting part was
not working well for cases where the variable is declared in a macro
(outside the function), which is then expanded in the function.

So I had to adjust warn_uninit a little bit to make it consider the
spelling location of the variable declaration.

I have fixed the test gcc.dg/cpp/pragma-diagnostic-2.c on which I
believe gcc shouldn't emit any error.

Here is the new output on that test:

=~=
gcc.dg/cpp/pragma-diagnostic-2.c: In function 'g':
gcc.dg/cpp/pragma-diagnostic-2.c:10:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: 'a' was declared here
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: in expansion of macro 'CODE_WITH_WARNING'
gcc.dg/cpp/pragma-diagnostic-2.c:17:3: note: expanded from here
gcc.dg/cpp/pragma-diagnostic-2.c: In function 'h':
gcc.dg/cpp/pragma-diagnostic-2.c:10:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: 'a' was declared here
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: in expansion of macro 'CODE_WITH_WARNING'
gcc.dg/cpp/pragma-diagnostic-2.c:27:3: note: expanded from here
=~=

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion turned on
exhibits other separate issues that are addressed in subsequent
patches.  This patch just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/
	* tree-ssa.c (warn_uninit): Use the spelling location of the
	variable declaration.  Use linemap_location_before_p for source
	locations.

gcc/testsuite/

	* gcc.dg/cpp/pragma-diagnostic-2.c:  Fix this.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186971 138bc75d-0d04-0410-961f-82ee72b054a4
Make conversion warnings work on NULL with -ftrack-macro-expansion

There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null).  NULL is defined as a
macro in a system header, so calling warning or warning_at on a
virtual location of NULL yields no diagnostic.  So the test
accompanying this patch (as well as others), was failling when run
with -ftrack-macro-expansion.

I think it's necessary to use the location of NULL that is in the main
source code (instead of, e.g, the spelling location that is in the
system header where the macro is defined) in those cases.  Note that
for __null, we don't have the issue.

I have augmented the test of this patch to check that we don't regress
when handling __null.

Tested on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/
	* input.h (expansion_point_location_if_in_system_header): Declare
	new function.
	* input.c (expansion_point_location_if_in_system_header): Define it.
gcc/cp/

	* call.c (conversion_null_warnings): Use the new
	expansion_point_location_if_in_system_header.
	* cvt.c (build_expr_type_conversion): Likewise.
	* typeck.c (cp_build_binary_op): Likewise.

gcc/testsuite/

	* g++.dg/warn/Wconversion-null-2.C: Add testing for __null,
	alongside the previous testing for NULL.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186972 138bc75d-0d04-0410-961f-82ee72b054a4
Fix va_arg type location

Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location that is recorded for
"some_type" is not correct.  We wrongly record a location that is in
the system header where the va_args macro is defined.

This patch changes that to correctly record the location for the type
operand of the va_arg expression.

With this patch applied, the
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C test PASSes with and
without -ftrack-macro-expansion.

Tested on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/cp/

	* cp-tree.h (build_x_va_arg): Take an additional location
	parameter.
	* call.c (build_x_va_arg): Take a loc parameter for the location
	of the type of the va_arg expression.
	* parser.c (cp_parser_primary_expression): Pass the type of the
	type in the va_arg expression to build_x_va_arg.
	* pt.c (tsubst_copy): Adjust calls to build_x_va_arg.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186973 138bc75d-0d04-0410-961f-82ee72b054a4
Fix location for static class members

Consider the test case g++.dg/other/offsetof5.C:

    #include <stddef.h>

    struct A
    {
      char c;
      int &i;
    };

    int j = offsetof (A, i);		// { dg-warning "invalid access|offsetof" }

    template <typename T>
    struct S
    {
      T h;
      T &i;
      static const int j = offsetof (S, i);	// { dg-warning "invalid access|offsetof" }
    };

    int k = S<int>::j;			// { dg-message "required from here" }

The second warning (that involves the instantiation of the S template)
is not emitted when -ftrack-macro-expansion is on.

This is because during the instantiation of the member j of S
template, the location that is used for the warning is the one for the
DECL j (set by instantiate_decl).  And that location is inaccurately
set to the locus of 'offsetof', which is a macro defined in a system
header, so it's discarded by the diagnostics machinery.

Note that when we reach the point where we emit the warning in
build_class_member_access_expr offsetof expression has long been
folded, so we cannot use e.g, the location of the ')' token that would
have been in the source code.  So I believe the location of 'j' is the
best we can get at this point.

The patch below sets the location of the DECL for 'j' to what I
believe is its precise location; with that, the test case passes with
and without -ftrack-macro-expansion.  But I had to adjust
g++.dg/template/sfinae6_neg.C for that.

Tested on x86_64-unknown-linux-gnu against trunk.

gcc/cp

	* decl.c (grokdeclarator): Use the location carried by the
	declarator for the DECL of the static class member.

gcc/testsuite/

	* g++.dg/template/sfinae6_neg.C: Adjust.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186974 138bc75d-0d04-0410-961f-82ee72b054a4
Fix va_start related location

In gcc/testsuite/gcc.dg/pr30457.c, the first warning was not being
emitted because the relevant location was inside the var_start macro
defined in a system header.  It can even point to a token for a
builtin macro there.  This patch unwinds to the first token in real
source code in that case.

Tested on x86_64-unknown-linux-gnu against trunk.

	* builtins.c (fold_builtin_next_arg): Unwinds to the first
	location in real source code.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186975 138bc75d-0d04-0410-961f-82ee72b054a4
Adjust relevant test cases wrt -ftrack-macro-expansion=[0|2]

Even after all the patches I have already submitted, some test cases
where errors happens on tokens that are defined in macros see their
output change in an incompatible way, when you run them with or
without -ftrack-macro-expansion.

I think this is expected, because the (spelling) locus inside the
definition of the macro pointed to with -ftrack-macro-expansion is
different from the locus of the expansion point of the macro pointed
to without -ftrack-macro-expansion.

In those cases this patch either adjusts the test case and forces it
be run either with -ftrack-macro-expansion, or it just forces it to be
run without -ftrack-macro-expansion.

There are so many libstdc++ tests that were failing because of that
benign issue that I preferred to just run them with
-ftrack-macro-expansion diabled, after inspecting each of them to be
sure there was nothing more serious underneath.

Boostrapped on x86_64-unknown-linux-gnu against trunk with and without
-ftrack-macro-expansion turned on.

gcc/testsuite/

	* objc.dg/foreach-7.m: Force the test case to run without
	-ftrack-macro-expansion.
	* c-c++-common/tm/attrib-1.c: Likewise.
	* c-c++-common/warn-ommitted-condop.c: Likewise.
	* gcc.dg/assign-warn-1.c: Likewise.
	* gcc.dg/assign-warn-2.c: Likewise.
	* gcc.dg/attr-alloc_size.c: Likewise.
	* gcc.dg/builtin-stringop-chk-1.c: Likewise.
	* gcc.dg/builtin-stringop-chk-2.c: Likewise.
	* gcc.dg/builtin-strncat-chk-1.c: Likewise.
	* gcc.dg/c90-const-expr-9.c: Likewise.
	* gcc.dg/c99-const-expr-9.c: Likewise.
	* gcc.dg/cpp/direct2.c: Likewise.  Adjust.
	* gcc.dg/cpp/direct2s.c: Likewise.
	* gcc/testsuite/gcc.dg/cpp/pr28709.c: Likewise.
	* gcc.dg/cpp/pragma-diagnostic-1.c: Likewise.
	* gcc.dg/dfp/composite-type.c: Likewise.
	* gcc.dg/uninit-6-O0.c: Adjust the test case and force it to run
	with -ftrack-macro-expansion
	* g++.dg/cpp0x/constexpr-ex3.C: Likewise.
	* g++.dg/cpp0x/constexpr-overflow.C: Likewise.
	* g++.dg/ext/cleanup-1.C: Likewise.
	* g++.dg/ext/gnu-inline-global-reject.C: Likewise.
	* g++.dg/template/sfinae10.C: Likewise.
	* g++.dg/tm/wrap-2.C: Likewise.
	* g++.dg/warn/Wconversion-real-integer.C: Likewise.
	* g++.dg/warn/Wsign-conversion.C: Likewise.
	* g++.dg/warn/multiple-overflow-warn-1.C: Likewise.
	* g++.old-deja/g++.mike/p10769b.C: Likewise.
	* g++.dg/warn/Wdouble-promotion.C: Adjust the test case and force
	it to run with -ftrack-macro-expansion.
	* libstdc++-v3/scripts/testsuite_flags.in: By default, run the
	test cases without -ftrack-macro-expansion.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186976 138bc75d-0d04-0410-961f-82ee72b054a4
Switch -ftrack-macro-expansion=2 on by default.

This switches the compiler to -ftrack-macro-expansion=2 by default.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.

libcpp/

	* init.c (cpp_create_reader): Switch -ftrack-macro-expansion=2 on
	by default.  Add comments.

gcc/docs/

	* cppopts.texi: Adjust for enabling -ftrack-macro-expansion=2 by
	default.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186977 138bc75d-0d04-0410-961f-82ee72b054a4
Add -Wvarargs option

Several warnings related to questionable usage cases of variadic
function related macros (like va_start) could not be controlled by any
warning-related macro.  Fixed thus, by introducing the -Wvarargs
option.

Tested on x86_64-unknown-linux-gnu against trunk.

gcc/c-family/

	* c.opt (Wvarargs):  Define new option.

gcc/
	* builtins.c (fold_builtin_next_arg):  Use OPT_Wvarargs as an
	argument for the various warning_at calls.

gcc/doc/

	* invoke.texi: Update the documentation.

gcc/testsuite/

	* c-c++-common/Wvarargs.c: New test case.
	* c-c++-common/Wvarargs-2.c: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186978 138bc75d-0d04-0410-961f-82ee72b054a4
	* config/i386/i386.md (and<mode>3): Expand masking operations with
	0xff, 0xffff or 0xffffffff immediates to corresponding zero_extend RTX.
	(and splitter): Split to DImode zero_extend RTX for DImode operand[0].



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186979 138bc75d-0d04-0410-961f-82ee72b054a4
2012-04-30  Ian Bolton	<ian.bolton at arm.com>
	    Sameera Deshpande  <sameera.deshpande at arm.com>
	    Greta Yorsh	 <greta.yorsh at arm.com>

	* config/arm/arm-protos.h (ldm_stm_operation_p): New declaration.
	* config/arm/arm.c (ldm_stm_operation_p): New function.
	* config/arm/predicates.md (load_multiple_operation): Update predicate.
	(store_multiple_operation): Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186980 138bc75d-0d04-0410-961f-82ee72b054a4
2012-04-24  Ian Bolton  <ian.bolton at arm.com>
            Sameera Deshpande  <sameera.deshpande at arm.com>
            Greta Yorsh  <greta.yorsh at arm.com>

        * config/arm/arm-protos.h (ldm_stm_operation_p): New parameters.
        * config/arm/arm.c (ldm_stm_operation_p): New parameters.
        * config/arm/predicates.md (load_multiple_operation): Add arguments.
        (store_multiple_operation): Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186981 138bc75d-0d04-0410-961f-82ee72b054a4
Fix email addresses


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186982 138bc75d-0d04-0410-961f-82ee72b054a4
2012-04-30  Andrew Stubbs  <ams@codesourcery.com>

	* config/arm/arm.c (neon_valid_immediate): Allow const_int.
	(arm_print_operand): Add 'x' format.
	* config/arm/constraints.md (Dn): Allow const_int.
	* config/arm/neon.md (neon_mov<mode>): Use VDX to allow DImode.
	Use 'x' format to print constants.
	* config/arm/predicates.md (imm_for_neon_mov_operand): Allow const_int.
	* config/arm/vfp.md (movdi_vfp): Disable for const_int when neon
	is enabled.
	(movdi_vfp_cortexa8): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186983 138bc75d-0d04-0410-961f-82ee72b054a4
2012-04-30  Andrew Stubbs  <ams@codesourcery.com>

	* config/arm/arm.md (negdi2): Use gen_negdi2_neon.
	* config/arm/neon.md (negdi2_neon): New insn.
	Also add splitters for core and NEON registers.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186984 138bc75d-0d04-0410-961f-82ee72b054a4