[Bug preprocessor/96935] New: ICE in subspan, at input.h:69

[Bug preprocessor/96935] New: ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

            Bug ID: 96935
           Summary: ICE in subspan, at input.h:69
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Following ICE is seen :

x.cpp: In function 'void a()':
x.cpp:3: internal compiler error: in subspan, at input.h:69
    3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt,
str, ##args)
      |
x.cpp:7: note: in expansion of macro 'DB_PRINTF'
    7 |   DB_PRINTF("", "%llu", 0);
      |


Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go

Compiled with:  -O2 -Wformat 

Reproduces with 
 10.2, 10.1
 9.3, 9.1
Works with
 8.4
 7.5


The reduced testcase is :

#include "x.h"
#define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt, str,
##args)
extern "C" void db_printf(unsigned indent_len, unsigned column_split, const
char * fmt, const char * str, ...) __attribute__ ((format (printf, 3, 5)));
void a() {
  unsigned int indent_len = 0;
  DB_PRINTF("", "%llu", 0);
  // preprocesses to: db_printf(indent_len, 50, "%llu", "");
}

But I suspect the testcase is just garbage.

I tried various ways trying to reduce x.h, but even the slightest change makes
the problem go away. "x.h" recursively includes about 200 other header files.
A "flat" x.h (700k lines) (-fdirectives-only) does not reproduce the issue.

This ICE occurs on couple of dozen files in my project. Some print
 "during GIMPLE pass: strlen".

Goes away with --enable-checking=no, but then other problems show up (ICE in
linemap_compare_locations, at libcpp/line-map.c:1359 - which may or may not be
related)

I suppose my next best option is start a bisect between 8.x and 9.x ?

Thanks

[Bug preprocessor/96935] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #1 from Jan Smets <jan.smets at nokia dot com> ---
Proper backtrace (10.2)

x.cpp: In function ‘void a()’:
x.cpp:3: internal compiler error: in subspan, at input.h:69
    3 | #define DB_PRINTF(str, fmt, args...) db_printf(indent_len, 50, fmt,
str, ##args)
      |
x.cpp:7: note: in expansion of macro ‘DB_PRINTF’
    7 |   DB_PRINTF("", "%llu", 0);
      |
0x168ee7b char_span::subspan(int, int) const
        /jasmets/git/tools/gcc/gcc/input.h:69
0x168ee7b get_substring_ranges_for_loc
        /jasmets/git/tools/gcc/gcc/input.c:1467
0x168ee7b get_location_within_string(cpp_reader*, string_concat_db*, unsigned
int, cpp_ttype, int, int, int, unsigned int*)
        /jasmets/git/tools/gcc/gcc/input.c:1553
0x8fad84 c_get_substring_location(substring_loc const&, unsigned int*)
        /jasmets/git/tools/gcc/gcc/c-family/c-common.c:903
0x92e3ad get_corrected_substring
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:4505
0x92e3ad format_type_warning
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:4721
0x93142b check_format_types
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:4266
0x93142b argument_parser::check_argument_type(format_char_info const*,
length_modifier const&, tree_node*&, char const*&, bool, unsigned long&,
tree_node*&, int, char const*, char const*, unsigned int, char)
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:2859
0x9332e0 check_format_info_main
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:3998
0x9332e0 check_format_arg
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:1821
0x92f3a2 check_format_info
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:1543
0x92f3a2 check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec<unsigned int, va_heap, vl_ptr>*)
        /jasmets/git/tools/gcc/gcc/c-family/c-format.c:1197
0x922f09 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec<unsigned int, va_heap, vl_ptr>*)
        /jasmets/git/tools/gcc/gcc/c-family/c-common.c:5730
0x77d86f build_over_call
        /jasmets/git/tools/gcc/gcc/cp/call.c:8901
0x77f2ea build_new_function_call(tree_node*, vec<tree_node*, va_gc,
vl_embed>**, int)
        /jasmets/git/tools/gcc/gcc/cp/call.c:4613
0x8baac6 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
        /jasmets/git/tools/gcc/gcc/cp/semantics.c:2672
0x864abf cp_parser_postfix_expression
        /jasmets/git/tools/gcc/gcc/cp/parser.c:7468
0x84d261 cp_parser_unary_expression
        /jasmets/git/tools/gcc/gcc/cp/parser.c:8563
0x846d11 cp_parser_cast_expression
        /jasmets/git/tools/gcc/gcc/cp/parser.c:9459
0x8473e1 cp_parser_binary_expression
        /jasmets/git/tools/gcc/gcc/cp/parser.c:9562

[Bug preprocessor/96935] ICE in subspan, at input.h:69

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Guess the error is simply that we fall back to no columns and thus start.column
== 0 and we do

      char_span literal = line.subspan (start.column - 1, literal_length);

which means input.c:1467 should check whether start.column is >= 1

Might also trigger with

printf ("\
......")

who knows.

Your backtrace doesn't contain function argument values to verify.  Maybe you
can
build GCC with -O0 once and check?

[Bug preprocessor/96935] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #3 from Jan Smets <jan.smets at nokia dot com> ---
A bisect resulted in this commit :

commit 0d48e8779c6a9ac88f5efd1b4a2d40f43ef75faf
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Fri Oct 5 19:02:17 2018 +0000

    Support string locations for C++ in -Wformat (PR c++/56856)

    -Wformat in the C++ FE doesn't work as well as it could:
    (a) it doesn't report precise locations within the string literal, and
    (b) it doesn't underline arguments for those arguments
!CAN_HAVE_LOCATION_P,
    despite having location wrapper nodes.



Your suggestion doesn't trigger it for me.
I'v  built GCC with -g -O0 , but the standard provided backtrace didn't include
function call arguments.

A printf confirms your suspicion about start.column == 0 
 => start.column=0 literal_length=1

[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
            Summary|ICE in subspan, at          |[9/10/11 Regression] ICE in
                   |input.h:69                  |subspan, at input.h:69
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-09-16
     Ever confirmed|0                           |1
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Reduced:

void
foo (char const *name)
{
  /*
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
*/ __builtin_printf ("%s", name);
}

[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r269125.  Use -O to reproduce.

Bizarrely, it goes away when -Wall is in effect!

[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Candidate fix:

--- a/gcc/input.c
+++ b/gcc/input.c
@@ -1461,6 +1461,8 @@ get_substring_ranges_for_loc (cpp_reader *pfile,
       size_t literal_length = finish.column - start.column + 1;

       /* Ensure that we don't crash if we got the wrong location.  */
+      if (start.column < 1)
+   return "line is too long";
       if (line.length () < (start.column - 1 + literal_length))
    return "line is not wide enough";

[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:31dd5cd6344bfbbe122fb512993b128e11236d35

commit r11-3238-g31dd5cd6344bfbbe122fb512993b128e11236d35
Author: Marek Polacek <polacek@redhat.com>
Date:   Wed Sep 16 09:27:29 2020 -0400

    preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

    Here we ICE in char_span::subspan because the offset it gets is -1.
    It's -1 because get_substring_ranges_for_loc gets a location whose
    column was 0.  That only happens in testcases like the attached where
    we're dealing with extremely long lines (at least 4065 chars it seems).
    This does happen in practice, though, so it's not just a theoretical
    problem (e.g. when building the SU2 suite).

    Fixed by checking that the column get_substring_ranges_for_loc gets is
    sane, akin to other checks in that function.

    gcc/ChangeLog:

            PR preprocessor/96935
            * input.c (get_substring_ranges_for_loc): Return if start.column
            is less than 1.

    gcc/testsuite/ChangeLog:

            PR preprocessor/96935
            * gcc.dg/format/pr96935.c: New test.

[Bug preprocessor/96935] [9/10 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
                   |subspan, at input.h:69      |subspan, at input.h:69

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed on trunk so far.

[Bug preprocessor/96935] [9/10 Regression] ICE in subspan, at input.h:69

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Marek Polacek
<mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:d01c3def63caf59d1d156aec8d52a1540e5ffe27

commit r10-8772-gd01c3def63caf59d1d156aec8d52a1540e5ffe27
Author: Marek Polacek <polacek@redhat.com>
Date:   Wed Sep 16 09:27:29 2020 -0400

    preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

    Here we ICE in char_span::subspan because the offset it gets is -1.
    It's -1 because get_substring_ranges_for_loc gets a location whose
    column was 0.  That only happens in testcases like the attached where
    we're dealing with extremely long lines (at least 4065 chars it seems).
    This does happen in practice, though, so it's not just a theoretical
    problem (e.g. when building the SU2 suite).

    Fixed by checking that the column get_substring_ranges_for_loc gets is
    sane, akin to other checks in that function.

    gcc/ChangeLog:

            PR preprocessor/96935
            * input.c (get_substring_ranges_for_loc): Return if start.column
            is less than 1.

    gcc/testsuite/ChangeLog:

            PR preprocessor/96935
            * gcc.dg/format/pr96935.c: New test.

    (cherry picked from commit 31dd5cd6344bfbbe122fb512993b128e11236d35)

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10 Regression] ICE in    |[9 Regression] ICE in
                   |subspan, at input.h:69      |subspan, at input.h:69
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

[jan.smets at nokia dot com]

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

--- Comment #11 from Jan Smets <jan.smets at nokia dot com> ---
Thanks. Fix verified.

[Bug preprocessor/96935] [9 Regression] ICE in subspan, at input.h:69

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |10.3.0, 11.1.0
   Target Milestone|---                         |10.3
      Known to fail|                            |10.1.0, 10.2.0