[Bug c++/55962] New: improper location for static_assert

[Bug c++/55962] New: improper location for static_assert

[akim.demaille at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55962

             Bug #: 55962
           Summary: improper location for static_assert
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: akim.demaille@gmail.com


In the following test case the location of the error points to the end of the
function, instead of the static_assert itself.

Cheers.  (And happy new year!).

$ cat sa.cc
template <typename T>
int
foo(int b)
{
  static_assert(T::value, "toto");
  return b;
}

int
main()
{
  foo<int>(12);
}
$ g++-mp-4.8 -Wall -std=c++11 sa.cc
sa.cc: In instantiation of 'int foo(int) [with T = int]':
sa.cc:12:14:   required from here
sa.cc:6:11: error: 'value' is not a member of 'int'
   return b;
           ^
$ g++-mp-4.8 --version
g++-mp-4.8 (MacPorts gcc48 4.8-20130106_0) 4.8.0 20130106 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/55962] improper location for static_assert

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55962

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-01-13
                 CC|                            |manu at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-13 19:17:05 UTC ---
Confirmed. If you run GCC under GDB, you'll notice that the call 

  if (expr == error_mark_node || TREE_CODE (expr) == TREE_LIST)
    {
      if (complain & tf_error)
        qualified_name_lookup_error (scope,
                                     TREE_OPERAND (qualified_id, 1),
=>                                   expr, input_location);
      return error_mark_node;
    }


uses input_location. I think it should use an explicit location. The problem is
how to get the location of 'value' to this point. 

Up one-level input_location is "hacked" to be 

 loc = input_location;
  if (EXPR_HAS_LOCATION (t))
    input_location = EXPR_LOCATION (t);

but in this case t is just:

 <scope_ref 0x7ffff753e640 tree_0
    arg 0 <template_type_parm 0x7ffff75439d8 T type_0 type_6 VOID
        align 8 symtab 0 alias set -1 canonical type 0x7ffff75439d8
       index 0 level 1 orig_level 1
        chain <type_decl 0x7ffff753f958 T>>
    arg 1 <identifier_node 0x7ffff7552d10 value
        bindings <(nil)>
        local bindings <(nil)>>>

so it doesn't have a location, so it uses input_location.

The issue seems to be that input_location has somehow been smashed by something
else. For the testcase:

void assert(int, const char *);
template <typename T>
int
foo(int b)
{
  assert(T::value, "toto");
  return b;
}

int
main()
{
  foo<int>(12);
}


we get:

test.cc:6:26: error: ‘value’ is not a member of ‘int’
   assert(T::value, "toto");
                          ^
which is slightly better and the only difference seems to be the value of
input_location in the condition above.

This requires much more investigation.

[Bug c++/55962] improper location for static_assert

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55962

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87386
             Status|NEW                         |RESOLVED
           Keywords|                            |diagnostic
   Target Milestone|---                         |9.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 9 by the patch which fixed PR 87386. There are already some
testcases which seems to match this one too.