[Bug preprocessor/112956] New: Valgrind errors on pr88974.c

[Bug preprocessor/112956] New: Valgrind errors on pr88974.c

[jakub at gcc dot gnu.org]

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

            Bug ID: 112956
           Summary: Valgrind errors on pr88974.c
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

With valgrind checking I'm seeing:
/home/jakub/src/gcc/obj88/gcc/xgcc -B/home/jakub/src/gcc/obj88/gcc/
/home/jakub/src/gcc/gcc/testsuite/c-c++-common/cpp/pr88974.c
-fdiagnostics-plain-output -Wc++
-compat -E -o pr88974.i
/home/jakub/src/gcc/gcc/testsuite/c-c++-common/cpp/pr88974.c:4:31: error:
missing terminating > character
/home/jakub/src/gcc/gcc/testsuite/c-c++-common/cpp/pr88974.c:4:31: error:
missing ')' after "__has_include" operand
==600549== Conditional jump or move depends on uninitialised value(s)
==600549==    at 0x1DD3A05: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:3050)
==600549==    by 0x1DBFC7F: _cpp_parse_expr (expr.cc:1392)
==600549==    by 0x1DB9471: do_if(cpp_reader*) (directives.cc:2087)
==600549==    by 0x1DBB4D8: _cpp_handle_directive (directives.cc:572)
==600549==    by 0x1DCD488: _cpp_lex_token (lex.cc:3682)
==600549==    by 0x1DD3A97: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:2936)
==600549==    by 0x7F7EE4: scan_translation_unit (c-ppoutput.cc:350)
==600549==    by 0x7F7EE4: preprocess_file(cpp_reader*) (c-ppoutput.cc:106)
==600549==    by 0x7F6235: c_common_init() (c-opts.cc:1280)
==600549==    by 0x704C8B: lang_dependent_init (toplev.cc:1837)
==600549==    by 0x704C8B: do_compile (toplev.cc:2135)
==600549==    by 0x704C8B: toplev::main(int, char**) (toplev.cc:2306)
==600549==    by 0x7064BA: main (main.cc:39)

--- libcpp/lex.cc.jj    2023-12-01 08:10:44.686296604 +0100
+++ libcpp/lex.cc       2023-12-11 10:58:08.907527616 +0100
@@ -3833,6 +3833,7 @@ _cpp_lex_direct (cpp_reader *pfile)
          pfile->state.in_deferred_pragma = false;
          if (!pfile->state.pragma_allow_expansion)
            pfile->state.prevent_expansion--;
+         result->src_loc = 0;
          return result;
        }
       if (!_cpp_get_fresh_line (pfile))
@@ -3849,6 +3850,8 @@ _cpp_lex_direct (cpp_reader *pfile)
              /* Now pop the buffer that _cpp_get_fresh_line did not.  */
              _cpp_pop_buffer (pfile);
            }
+         else
+           result->src_loc = 0;
          return result;
        }
       if (buffer != pfile->buffer)
or even just the second hunk of it fixes this (but otherwise untested so far).

[Bug preprocessor/112956] Valgrind errors on pr88974.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2023-12-11

[Bug preprocessor/112956] Valgrind errors on pr88974.c

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The above patch breaks a lot of tests though.
+FAIL: c-c++-common/cpp/eof-1.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/eof-1.c  -Wc++-compat  unterminated macro (test for
errors, line 7)
+FAIL: c-c++-common/cpp/eof-2.c  -Wc++-compat   dg-regexp 8 not found:
"[^\\n]*eof-2.h:4:21: error: unterminated argument list invoking macro "f"\\n"
+FAIL: c-c++-common/cpp/eof-2.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/eof-3.c  -Wc++-compat   dg-regexp 6 not found:
"[^\\n]*eof-2.h:4:21: error: unterminated argument list invoking macro "f"\\n"
+FAIL: c-c++-common/cpp/eof-3.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/fmax-include-depth.c  -Wc++-compat   (test for errors,
line 4)
+FAIL: c-c++-common/cpp/fmax-include-depth.c  -Wc++-compat  (test for excess
errors)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat   at line 5 (test for errors,
line 4)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat   at line 6 (test for errors,
line 4)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat  (test for excess errors)
+FAIL: gcc.dg/cpp/assert2.c (test for excess errors)
+FAIL: gcc.dg/cpp/assert2.c assert w/o predicate (test for errors, line 5)
+FAIL: gcc.dg/cpp/assert2.c test w/o predicate (test for errors, line 10)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c  (test for errors, line 50)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c  (test for errors, line 54)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c (test for excess errors)
+FAIL: gcc.dg/cpp/directiv.c  (test for errors, line 34)
+FAIL: gcc.dg/cpp/directiv.c (test for excess errors)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 10)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 16)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 22)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 31)
+FAIL: gcc.dg/cpp/expr-overflow-1.c (test for excess errors)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c  (test for errors, line 50)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c  (test for errors, line 54)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c (test for excess errors)
+FAIL: gcc.dg/cpp/gnu11-elifdef-3.c  (test for warnings, line 28)
+FAIL: gcc.dg/cpp/gnu11-elifdef-3.c  (test for warnings, line 37)
...

[Bug preprocessor/112956] Valgrind errors on pr88974.c

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- libcpp/lex.cc.jj    2023-12-11 12:39:23.353442196 +0100
+++ libcpp/lex.cc       2023-12-12 13:15:07.154019695 +0100
@@ -3809,7 +3809,7 @@ _cpp_get_fresh_line (cpp_reader *pfile)
 cpp_token *
 _cpp_lex_direct (cpp_reader *pfile)
 {
-  cppchar_t c;
+  cppchar_t c = 0;
   cpp_buffer *buffer;
   const unsigned char *comment_start;
   bool fallthrough_comment = false;
@@ -3833,6 +3833,7 @@ _cpp_lex_direct (cpp_reader *pfile)
          pfile->state.in_deferred_pragma = false;
          if (!pfile->state.pragma_allow_expansion)
            pfile->state.prevent_expansion--;
+         result->src_loc = pfile->line_table->highest_line;
          return result;
        }
       if (!_cpp_get_fresh_line (pfile))
@@ -3849,6 +3850,8 @@ _cpp_lex_direct (cpp_reader *pfile)
              /* Now pop the buffer that _cpp_get_fresh_line did not.  */
              _cpp_pop_buffer (pfile);
            }
+         else if (c == 0)
+           result->src_loc = pfile->line_table->highest_line;
          return result;
        }
       if (buffer != pfile->buffer)
seems to work though (at least in quick cpp.exp testing).

[Bug preprocessor/112956] Valgrind errors on pr88974.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:819bc4f6700847068883eb862dfaed11f30db80b

commit r14-6513-g819bc4f6700847068883eb862dfaed11f30db80b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Dec 13 21:13:22 2023 +0100

    libcpp: Fix valgrind errors on pr88974.c [PR112956]

    On the c-c++-common/cpp/pr88974.c testcase I'm seeing
    ==600549== Conditional jump or move depends on uninitialised value(s)
    ==600549==    at 0x1DD3A05: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:3050)
    ==600549==    by 0x1DBFC7F: _cpp_parse_expr (expr.cc:1392)
    ==600549==    by 0x1DB9471: do_if(cpp_reader*) (directives.cc:2087)
    ==600549==    by 0x1DBB4D8: _cpp_handle_directive (directives.cc:572)
    ==600549==    by 0x1DCD488: _cpp_lex_token (lex.cc:3682)
    ==600549==    by 0x1DD3A97: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.cc:2936)
    ==600549==    by 0x7F7EE4: scan_translation_unit (c-ppoutput.cc:350)
    ==600549==    by 0x7F7EE4: preprocess_file(cpp_reader*) (c-ppoutput.cc:106)
    ==600549==    by 0x7F6235: c_common_init() (c-opts.cc:1280)
    ==600549==    by 0x704C8B: lang_dependent_init (toplev.cc:1837)
    ==600549==    by 0x704C8B: do_compile (toplev.cc:2135)
    ==600549==    by 0x704C8B: toplev::main(int, char**) (toplev.cc:2306)
    ==600549==    by 0x7064BA: main (main.cc:39)
    error.  The problem is that _cpp_lex_direct can leave result->src_loc
    uninitialized in some cases and later on we use that location_t.

    _cpp_lex_direct essentially does:
      cppchar_t c;
    ...
      cpp_token *result = pfile->cur_token++;

     fresh_line:
      result->flags = 0;
    ...
      if (buffer->need_line)
        {
          if (pfile->state.in_deferred_pragma)
            {
              result->type = CPP_PRAGMA_EOL;
              ... // keeps result->src_loc uninitialized;
              return result;
            }
          if (!_cpp_get_fresh_line (pfile))
            {
              result->type = CPP_EOF;
              if (!pfile->state.in_directive && !pfile->state.parsing_args)
                {
                  result->src_loc = pfile->line_table->highest_line;
                  ...
                }
              ... // otherwise result->src_loc is sometimes uninitialized here
              return result;
            }
          ...
        }
    ...
      result->src_loc = pfile->line_table->highest_line;
    ...
      c = *buffer->cur++;
      switch (c)
        {
    ...
        case '\n':
    ...
          buffer->need_line = true;
          if (pfile->state.in_deferred_pragma)
            {
              result->type = CPP_PRAGMA_EOL;
    ...
              return result;
            }
          goto fresh_line;
    ...
        }
    ...
    So, if _cpp_lex_direct is called without buffer->need_line initially set,
    result->src_loc is always initialized (and actually hundreds of tests rely
    on that exact value it has), even when c == '\n' and we set that flag later
    on and goto fresh_line.  For CPP_PRAGMA_EOL case we have in that case
    separate handling and don't goto.
    But if _cpp_lex_direct is called with buffer->need_line initially set and
    either decide to return a CPP_PRAGMA_EOL token or if getting a new line
fails
    for some reason and we return an CPP_ERROR token and we are in directive
    or parsing args state, it is kept uninitialized and can be whatever the
    allocation left it there as.

    The following patch attempts to keep the status quo, use value that was
    returned previously if it was initialized (i.e. we went through the
    goto fresh_line; statement in c == '\n' handling) and only initialize
    result->src_loc if it was uninitialized before.

    2023-12-13  Jakub Jelinek  <jakub@redhat.com>

            PR preprocessor/112956
            * lex.cc (_cpp_lex_direct): Initialize c to 0.
            For CPP_PRAGMA_EOL tokens and if c == 0 also for CPP_EOF
            set result->src_loc to highest locus.

[Bug preprocessor/112956] Valgrind errors on pr88974.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.