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.

From-SVN: r186976

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.

From-SVN: r186975

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.

From-SVN: r186974

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.

From-SVN: r186973

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.

From-SVN: r186972

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.

From-SVN: r186971

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.

From-SVN: r186970

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.

From-SVN: r186969

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.

From-SVN: r186968

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'.

From-SVN: r186967

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.

From-SVN: r186966

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.

From-SVN: r186965

	* gcc-interface/decl.c (gnat_to_gnu_entity): In type annotation mode,
	do not adjust the size of a tagged type if there is a representation
	clause on it.  Otherwise, round the adjustment up to the alignment
	of the first field and use the appropriate helper routine.
	(maybe_pad_type): Do not warn in type annotation mode on a tagged type.
	(gnat_to_gnu_field): Do not error out under the same circumstances.
	(annotate_rep): In type annotation mode, do not adjust the offset of
	components of a tagged type with representation clause.  Otherwise,
	round the adjustment up to the alignment of the first field.

From-SVN: r186961

	* config/i386/i386.c (ix86_handle_struct_attribute): Use the proper
	predicate to discriminate types.
ada/
	* gcc-interface/utils.c (finish_record_type): Force the traditional GCC
	layout for bitfields on the type if it is packed or has a representation
	clause and an alternate layout is available.

From-SVN: r186958

c-common.c (check_function_arguments): Replace Wmissing-format-attribute with Wsuggest-attribute=format.

2012-04-30  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        * c-common.c (check_function_arguments): Replace
        Wmissing-format-attribute with Wsuggest-attribute=format.

From-SVN: r186957

	* gcc-interface/gigi.h (mark_out_of_scope): Delete.
	(destroy_gnat_to_gnu): Declare.
	(destroy_dummy_type): Likewise.
	* gcc-interface/decl.c (mark_out_of_scope): Delete.
	* gcc-interface/utils.c (destroy_gnat_to_gnu): New function.
	(destroy_dummy_type): Likewise.
	* gcc-interface/trans.c (gnat_validate_uc_list): New variable.
	(gigi): Call validate_unchecked_conversion on gnat_validate_uc_list
	after the translation is completed.  Call destroy_gnat_to_gnu and
	destroy_dummy_type at the end.
	(Subprogram_Body_to_gnu): Do not call mark_out_of_scope.
	(gnat_to_gnu) <N_Block_Statement>: Likewise.
	<N_Validate_Unchecked_Conversion>: Do not process the node, only push
	it onto gnat_validate_uc_list.
	(validate_unchecked_conversion): New function.

From-SVN: r186956

2012-04-30  Manuel López-Ibáñez  <manu@gcc.gnu.org>

gcc/
	* doc/invoke.texi (Wmissing-format-attribute): Document as an
	alias of Wsuggest-attribute=format.
c-family/
	* c.opt (Wsuggest-attribute=format): New. Alias of
	Wmissing-format-attribute.
	* c-format.c (decode_format_type): Replace
	Wmissing-format-attribute with Wsuggest-attribute=format.
	(check_function_format): Likewise.
cp/
	* typeck.c (convert_for_assignment):  Replace
	Wmissing-format-attribute with Wsuggest-attribute=format.
	* call.c (convert_for_arg_passing): Likewise.
gcc/
	* c-typeck.c (convert_for_assignment): Replace
	Wmissing-format-attribute with Wsuggest-attribute=format.
	(digest_init): Likewise.

From-SVN: r186955

From-SVN: r186952

2012-04-29  Marc Glisse  <marc.glisse@inria.fr>
	    Paolo Carlini  <paolo.carlini@oracle.com>

	PR libstdc++/51795
	* include/bits/stl_algobase.h (__lg<>(_Size)): Remove.
	(__lg(int), __lg(unsigned), __lg(long), __lg(unsigned long),
	__lg(long long), __lg(unsigned long long)): Define constexpr.
	* include/bits/random.h (_Mod<>): Overcome Schrage's algorithm
	limitations.
	(__mod): Adjust.
	(linear_congruential): Remove FIXME static_assert.
	* include/bits/random.tcc (_Mod<>): Adjust.
	* testsuite/26_numerics/random/linear_congruential_engine/operators/
	51795.cc: New.

Co-Authored-By: Paolo Carlini <paolo.carlini@oracle.com>

From-SVN: r186948

	* include/std/functional (function::function(F)): LWG 2132: Disable
	constructor if argument isn't callable.
	* testsuite/20_util/function/cons/callable.cc: New.

From-SVN: r186947

I noticed that the file lex.c had C++ style comments, which I believe
is against the coding standards of the project.

Fixed, tested and applied to master as per the obvious rule.

libcpp/

	* lex.c (lex_raw_string): Change C++ style comments into C
	style comments.
	(lex_string): Likewise.

From-SVN: r186946

2012-04-29  Manuel López-Ibáñez  <manu@gcc.gnu.org>

	PR 53149
        * gcc.dg/20011021-1.c: Adjust testcase.

From-SVN: r186945

2012-04-29  Marc Glisse  <marc.glisse@inria.fr>

	PR libstdc++/22200
    	* include/std/limits (numeric_limits<>::is_modulo): False for
    	signed types.

From-SVN: r186944

2012-04-29  Manuel López-Ibáñez  <manu@gcc.gnu.org>

        * opts.c (finish_options): Do not handle -Wmissing-noreturn here.
        * common.opt (Wmissing-noreturn): Alias of -Wsuggest-attribute=noreturn.

From-SVN: r186943

re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize)

2012-04-29  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/53148
	* frontend-passes.c (create_var):  If the statement has a label,
	put the label around the block.

2012-04-29  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/53148
	* gfortran.dg/function_optimize_12.f90:  New test.

From-SVN: r186942

	PR target/53156
	* gcc.target/cris/peep2-andu2.c: Tweak expected assembly
	code to match current output and cover new peephole2 pattern.

From-SVN: r186941

	PR target/53156
	* config/cris/cris.md (andqu): New peephole2.
	(andu): Tweak head comment.

From-SVN: r186940

From-SVN: r186938

From-SVN: r186934

libgcc/
2012-04-28  Aurelien Jarno  <aurelien@aurel32.net>

	* config.host (mips64*-*-linux*, mipsisa64*-*-linux*): Remove. 
	(mips*-*-linux*): Include mips/t-tpbit when long double is 
	16 bytes long.

From-SVN: r186931

Fixes issue 7.

From-SVN: r186929

	PR tree-optimization/38785
	* common.opt (ftree-partial-pre): New option.
	* doc/invoke.texi: Document it.
	* opts.c (default_options_table): Initialize flag_tree_partial_pre.
	* tree-ssa-pre.c (do_partial_partial_insertion): Insert only if it will
	benefit speed path.
	(execute_pre): Use flag_tree_partial_pre.

Co-Authored-By: Maxim Kuvyrkov <maxim@codesourcery.com>
Co-Authored-By: Steven Bosscher <steven@gcc.gnu.org>

From-SVN: r186928

Fixes issue 8 in gofrontend issues list.

From-SVN: r186926

From-SVN: r186925

	PR target/52999
	* config/pa/pa.c (pa_legitimate_constant_p): Don't put function labels
	in constant pool.

From-SVN: r186919

From-SVN: r186918

	PR go/52358
configure, runtime: Provide i386 long double math functions if needed.

From-SVN: r186915

	PR go/52358
math: Work around bug in Solaris 9 implementation of ldexp.

The bug is that ldexp(-1, -1075) should return -0, but the
Solaris 9 implementation returns +0.

From-SVN: r186913

From-SVN: r186911

This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore.  According to [lex.ext]p10, this is
ill-formed.

Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens.  This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=rev&revision=152287), and enables
backwards compatibility with code that uses formatting macros from
<inttypes.h>, as in the following code block:

  int main() {
    int64_t i64 = 123;
    printf("My int64: %"PRId64"\n", i64);
  }

Google ref b/6377711.

2012-04-27   Ollie Wild  <aaw@google.com>

	PR c++/52538
	* gcc/c-family/c-common.c: Add CPP_W_LITERAL_SUFFIX mapping.
	* gcc/c-family/c-opts.c (c_common_handle_option): Handle
	OPT_Wliteral_suffix.
	* gcc/c-family/c.opt: Add Wliteral-suffix.
	* gcc/doc/invoke.texi (Wliteral-suffix): Document new option.
	* gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.c: New test.
	* libcpp/include/cpplib.h (struct cpp_options): Add new field,
	warn_literal_suffix.
	(CPP_W_LITERAL_SUFFIX): New enum.
	* libcpp/init.c (cpp_create_reader): Default initialization of
	warn_literal_suffix.
	* libcpp/lex.c (lex_raw_string): Treat user-defined literals which
	don't begin with '_' as separate tokens and produce a warning.
	(lex_string): Ditto.

From-SVN: r186909