PR preprocessor/53463 - Fix system header detection for built-in macro tokens

The location for a built-in macro token is BUILTIN_LOCATION.  When we
see that location value, we cannot know if that token was used in a
system header or not.  And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.

In that case, I think we ought to step-up to see where the built-in
macro has been expanded, until we see a location that is not for a
built-in macro.  Then we can check if the resulting location is in a
system header or not.

Now that we step up to the location of first non-built-in-macro token,
it appeared that for
testsuite/c-c++-common/dfp/convert-int-saturate.c, G++ then fails to
emit the warning in:

    volatile unsigned int usi;
    int
    main ()
    {
      usi = DEC32_MAX;  /* { dg-warning "overflow in implicit constant conversion" } */
     ...
    }

Because DEC32_MAX is defined in the system header float.h as a
built-in macro:

    #define DEC32_MAX	__DEC32_MAX__

And during the parsing of the assignment expression that should have
led to the warning above, input_location is set to the location for
the DEC32_MAX, which is actually the location for the built-in
__DECL32_MAX_EXP.

A possible fix is to use the location of the "=" operator as the
default location for assignment expressions.  This is what the patch
does.

I had to adjust a couple of tests to arrange for this.

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

libcpp/

	PR preprocessor/53463
	* line-map.c (linemap_location_in_system_header_p): For built-in
	macro tokens, check the first expansion point location for that is
	not for a token coming from a built-in macro.

gcc/cp/

	PR preprocessor/53463
	* parser.c (cp_parser_assignment_expression): Use the location
	for the LHS as the default location for the expression.

gcc/testsuite/

	PR preprocessor/53463
	* g++.dg/cpp/limits.C: New test.
	* g++.dg/parse/error19.C: Adjust.
	* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
	* g++.dg/warn/pr35635.C: Likewise.
	* g++.old-deja/g++.pt/assign1.C: Likewise.

From-SVN: r188203

libcpp/ChangeLog

@@ -1,3 +1,10 @@
+2012-06-04  Dodji Seketeli  <dodji@redhat.com>
+
+	PR preprocessor/53463
+	* line-map.c (linemap_location_in_system_header_p): For built-in
+	macro tokens, check the first expansion point location that is not
+	for a token coming from a built-in macro.
+
 2012-05-29  Joseph Myers  <joseph@codesourcery.com>
 
 	* directives.c: Fix typos.

libcpp/line-map.c

@@ -755,13 +755,35 @@ linemap_location_in_system_header_p (struct line_maps *set,
 {
   const struct line_map *map = NULL;
 
-  location =
-    linemap_resolve_location (set, location, LRK_SPELLING_LOCATION, &map);
-
   if (location < RESERVED_LOCATION_COUNT)
     return false;
 
-  return LINEMAP_SYSP (map);
+  /* Let's look at where the token for LOCATION comes from.  */
+  while (true)
+    {
+      map = linemap_lookup (set, location);
+      if (map != NULL)
+	{
+	  if (!linemap_macro_expansion_map_p (map))
+	    /* It's a normal token.  */
+	    return LINEMAP_SYSP (map);
+	  else
+	    {
+	      /* It's a token resulting from a macro expansion.  */
+	      source_location loc =
+		linemap_macro_map_loc_unwind_toward_spelling (map, location);
+	      if (loc < RESERVED_LOCATION_COUNT)
+		/* This token might come from a built-in macro.  Let's
+		   look at where that macro got expanded.  */
+		location = linemap_macro_map_loc_to_exp_point (map, location);
+	      else
+		location = loc;
+	    }
+	}
+      else
+	break;
+    }
+  return false;
 }
 
 /* Return TRUE if LOCATION is a source code location of a token coming