[PATCH] diagnostics: Fix sporadic test failure

H.J. Lu hjl.tools@gmail.com
Wed Aug 25 18:07:00 GMT 2021


On Sat, May 29, 2021 at 1:03 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 5/29/2021 1:55 PM, Bernd Edlinger wrote:
> >
> > On 5/29/21 9:31 PM, Jeff Law wrote:
> >>
> >> On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
> >>> Hi,
> >>>
> >>> it turns out to be reproducible this way:
> >>>
> >>> COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
> >>>
> >>> Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
> >>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> >>>    -fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank line(s) in output
> >>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> >>>    -fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected multiline pattern lines 550-551 not found: "                            __builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\^~~~~~~\n"
> >>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> >>>    -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess errors)
> >>>
> >>> a lot more errors happen with COLUMNS=20.
> >>>
> >>> Tested on x86_64-pc-linux-gnu.
> >>> Is it OK for trunk?
> >>>
> >>>
> >>> Thanks
> >>> Bernd.
> >>>
> >>>
> >>> 2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>
> >>>
> >>>      * gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix caret_max_with.
> >>>      * gcc.dg/plugin/diagnostic_plugin_test_inlining.c
> >>>      (plugin_init): Likewise.
> >>>      * gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
> >>>      * gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
> >>>      (plugin_init): Likewise.
> >>>      * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
> >>>      (plugin_init): Likewise.
> >> So while you've got a patch here, you haven't indicated what the problem actually was.  I'm guessing caret_max_width was uninitialized and thus we got random-ish values.  Presumably those randomish-values are what caused tests to occasionally appear to truncate their output and fail?
> >>
> >> If that's the case, this is fine.  If it's something deeper, please provide a bit of background to help in evaluating the patch.
> >>
> > Yes, the problem is just the function get_terminal_width in diagnostic.c, can
> > somehow learn the X-terminal's window dimensions where the make check is
> > started:
> >
> > int
> > get_terminal_width (void)
> > {
> >    const char * s = getenv ("COLUMNS");
> >    if (s != NULL) {
> >      int n = atoi (s);
> >      if (n > 0)
> >        return n;
> >    }
> >
> > #ifdef TIOCGWINSZ
> >    struct winsize w;
> >    w.ws_col = 0;
> >    if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0)
> >      return w.ws_col;
> > #endif
> >
> >    return INT_MAX;
> > }
> >
> > and this is used to initialize context->caret_max_width in diagnostic_set_caret_max_width,
> > and possibly also other places. This causes a small variation in the output that
> > is trips the test cases.  It is just an extra newline in some cases, that I have not
> > debugged why exactly this happens, but I assume this is intentional to make the
> > diagnostics spanning multiple lines better readable to a human.
> Thanks.  So for the testsuite we certainly don't want to be doing that
> :-)  OK for the trunk, thanks for chasing it down -- I've been seeing
> these failures, but haven't had the time to chase down a root cause.
>

I'd like to backport it to GCC 11 branch to avoid random failures on
GCC 11 branch:

https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075244.html

Thanks.

-- 
H.J.


More information about the Gcc-patches mailing list