[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jul 19 07:35:05 2016
New Revision: 238456

URL: https://gcc.gnu.org/viewcvs?rev=238456=gcc=rev
Log:
2016-07-19  Richard Biener  

PR lto/71907
* lto-streamer-out.c (DFS::DFS_write_tree_body): For blocks
with an abstract origin that is not an inlined function outer
scope add a self-reference as abstract origin.
* tree-streamer-out.c (write_ts_block_tree_pointers): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/tree-streamer-out.c

[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
We can stream a fake abstract origin, refering to $self.  That fixes the issue
but I'm not sure of all the side-effects.

Testing that.

[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So the issue is that the BLOCK of the call is one w/o an abstract origin (its
supercontext is the inline-BLOCK).  This is because LTO drops all abstract
origins but FUNCTION_DECLs (aka inlined_function_outer_scope_p).

This has been this way in GCC 5 as well but I suppose we were lucky to drop
the inner BLOCK there for some reason.  In fact the situation was the same
there we just failed to preserve the in-system-header bit of the location:

In function ‘strcpy’,
inlined from ‘main’ at /tmp/t.c:5:5:
/usr/include/bits/string3.h:104:10: warning: call to __builtin___memcpy_chk
will always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
  ^

[Bug middle-end/71907] [6/7 regression] missing buffer overflow warnings with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, lto
   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-18
  Component|lto |middle-end
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
With LTO we expand from

  :
  s = "12345678";
  __builtin___memcpy_chk (, , 9, 4);
  __builtin_puts ();

and we _do_ enter expand_builtin_memory_chk warning_at code.  But the location
is completely bogus:

(gdb) p richloc
$11 = {static MAX_RANGES = 3, static MAX_FIXIT_HINTS = 2, m_num_ranges = 1, 
  m_ranges = {{m_loc = 2147483649, m_show_caret_p = true}, {m_loc = 32767, 
  m_show_caret_p = 144}, {m_loc = 32767, m_show_caret_p = 23}}, 
  m_column_override = 0, m_have_expanded_location = false, 
  m_expanded_location = {
file = 0xc0cc90 , 
line = -12960, column = 32767, data = 0x7fffcd00, sysp = 96}, 
  m_num_fixit_hints = 0, m_fixit_hints = {0x7fffccc0, 0x7fffcd00}}

in particular 'sysp' is not zero.  Thus:

> gcc-6 t.c -O2 -D_FORTIFY_SOURCE=2 -flto -Wsystem-headers
In function ‘strcpy’,
inlined from ‘main’ at t.c:5:5:
/usr/include/bits/string3.h:104:10: warning: call to __builtin___memcpy_chk
will always overflow destination buffer
   return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
  ^

and viola, it works.  This probably means tree_nonartificial_location doesn't
work correctly (anymore).  I will have a closer look.