This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 2/2] Better system header location detection for built-in macro tokens


This patch fixes the regression reported in PR53463 for arm-none-eabi as
well.

Thanks,
Greta


> -----Original Message-----
> From: Dodji Seketeli [mailto:dodji@redhat.com]
> Sent: 21 May 2012 14:55
> To: GCC Patches
> Cc: Jason Merrill; Tom Tromey; Paolo Carlini
> Subject: [PATCH 2/2] Better system header location detection for built-
> in macro tokens
> 
> Hello,
> 
> 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 look at the location for the
> expansion point of the built-in macro instead.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
> 
> libcpp/
> 
> 	* line-map.c (linemap_location_in_system_header_p): Check
> 	expansion point location for built-in macro tokens.
> 
> gcc/testsuite/
> 
> 	* g++.dg/cpp/limits.C: New test.
> ---
>  gcc/testsuite/g++.dg/cpp/limits.C |   21 +++++++++++++++++++++
>  libcpp/line-map.c                 |   18 ++++++++++++++----
>  2 files changed, 35 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp/limits.C
> 
> diff --git a/gcc/testsuite/g++.dg/cpp/limits.C
> b/gcc/testsuite/g++.dg/cpp/limits.C
> new file mode 100644
> index 0000000..b64e1e2
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp/limits.C
> @@ -0,0 +1,21 @@
> +// { dg-options "-pedantic" }
> +// { dg-do compile }
> +
> +#include <limits>
> +
> +// Compiling this with -pedantic was wrongly triggering this error:
> +// libstdc++-v3/include/limits:1269:45: warning : use of C++0x long
> long integer constant [-Wlong-long]
> +//       min() _GLIBCXX_USE_NOEXCEPT { return -__LONG_LONG_MAX__ - 1;
> }
> +//                                             ^
> +// libstdc++-v3/include/limits:1272:44: warning : use of C++0x long
> long integer constant [-Wlong-long]
> +//       max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__; }
> +//                                            ^
> +// libstdc++-v3/include/limits:1342:44: warning : use of C++0x long
> long integer constant [-Wlong-long]
> +//       max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__ * 2ULL
> + 1
> +//                                            ^
> +
> +int
> +main ()
> +{
> +    return 0;
> +}
> diff --git a/libcpp/line-map.c b/libcpp/line-map.c
> index 6e514e5..5a2ca0f 100644
> --- a/libcpp/line-map.c
> +++ b/libcpp/line-map.c
> @@ -754,12 +754,22 @@ linemap_location_in_system_header_p (struct
> line_maps *set,
>  				     source_location location)
>  {
>    const struct line_map *map = NULL;
> -
> -  location =
> +  source_location loc =
>      linemap_resolve_location (set, location, LRK_SPELLING_LOCATION,
> &map);
> 
> -  if (location < RESERVED_LOCATION_COUNT)
> -    return false;
> +  if (loc < RESERVED_LOCATION_COUNT)
> +    {
> +      /* Maybe LOCATION is for a token that comes from the expansion
> +	 of a built-in macro.  In that case, we cannot know from its
> +	 spelling location (which is thus a reserved location) where
> +	 exactly the token is located.  So let's see where that
> +	 built-in macro has been expanded, instead.  */
> +      loc = linemap_resolve_location (set, location,
> +				      LRK_MACRO_EXPANSION_POINT,
> +				      &map);
> +      if (loc < RESERVED_LOCATION_COUNT)
> +	return false;
> +    }
> 
>    return LINEMAP_SYSP (map);
>  }
> --
> 		Dodji





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]