Mention -freport-bug on GCC wiki

[Maxim Ostapenko]

Hi, community!

To simplify generating a preprocessed file if ICE is occurred, GCC 
(since 5.0 version) introduces a special -freport-bug option. Looking to 
GCC bug reporting guide (https://gcc.gnu.org/bugs/#detailed), it may be 
useful to mention -freport-bug on this page. Does this make sense? If 
so, could someone help me with publishing such information on GCC wiki 
page? Here a draft text to be published:



How to generate preprocessed source file if ICE (internal compiler 
error) occurred on your code.


To help you generate a preprocessed file from your ICE reprocase, GCC 
(since 5.0 version) introduces a special -freport-bug option. You can 
add it into your CFLAGS and expect the preprocessed code to be generated:


gcc all-your-options -freport-bug source-file

.
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*Preprocessed source stored into /tmp/cclPPsxk.out file, please attach 
this to your bugreport*.


The .out file would contain preprocessed code itself, as well as gcc -v 
output and full compilation line to reproduce the issue. This 
information would help GCC developers to fix the bug faster and would 
make their life a bit easier.




-Thanks,
Maxim

Re: Source Code for Profile Guided Code Positioning

[Maxim Ostapenko]

On 20/01/16 10:08, Sriraman Tallam wrote:

On Fri, Jan 15, 2016 at 9:51 AM, Yury Gribov  wrote:

On 01/15/2016 08:44 PM, vivek pandya wrote:

Thanks Yury for
https://gcc.gnu.org/ml/gcc-patches/2011-09/msg01440.html this link.
It implements procedure reordering as linker plugin.
I have some questions :
1 ) Can you point me to some documentation for "how to write plugin
for linkers " I am I have not seen doc for structs with 'ld_' prefix
(i.e defined in plugin-api.h )
   2 ) There is one more algorithm for Basic Block ordering with
execution frequency count in PH paper . Is there any implementation
available for it ?


Quite frankly - I don't know (I've only learned about Google implementation
recently).

I've added Sriram to maybe comment.

Sorry for the late response.  The google/gcc_4_9 branch has the source
of function reordering linker Plugin.  It is available in the
function_reordering_plugin directory under the top level gcc
directory.

The function reordering plugin constructs a callgraph and uses profile
information to do a Pettis Hansen style function reordering.   This
plugin does not do basic block re-ordering.

There is no documentation as such that I am aware of to write a linker
plugin.  Here is a very brief overview.   The linker calls the
plugin's "onload" function when registering the plugin and the plugin
inturn can register two call-backs with the linker, "claim_file_hook"
and the "all_symbols_read_hook".  "claim_file_hook" is called  for
each object file that the linker prcesses and the
"all_symbols_read_hook" is called after all the symbols have been read
by the linker.  These are just two different interesting points in the
course of a link.

The plugin can also get handles to linker functions like
"get_input_section_name" which it can use to process sections given
their handle. You can also check the gold linker tests for simpler
plugin examples.

HTH,
Thanks
Sri


Very interesting, thank you! Actually, I see -freorder-functions switch 
in GCC that allows perform pretty the same optimizations in linker, 
right? Just wondering if you achieved to get performance improvements 
against -freorder-functions with your plugin.


Thanks,
-Maxim


-Y

Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after

[Maxim Ostapenko]

Hi.

On 31/03/16 12:52, Gayan Pathirage wrote:

Hi,

I find it difficult to locate the information regarding the version of
the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could
anyone suggest me a location where I can find this information.


This is indeed difficult. AFAIK, there isn't any mapping between LLVM 
and GCC ASan releases, we just merge sanitizer library from upstream to 
GCC source tree from time to time. GCC wiki doesn't have a dedicated 
page for AddressSanitizer, so I suppose that the most appropriate method 
for discovering such an information is just looking into ASan source code.




My question is due to some of the run time flags defined in ASAN is
not recognized in GCC based binary (i.e. GCC 4.9.3). e.g.
ASAN_OPTIONS=help=1:halt_on_error=0


ASAN_OPTIONS=help=1 was introduced in GCC 5 and 
ASAN_OPTIONS=halt_on_error will be available in GCC 6.




Also what is the GCC policy behind updating LLVM sanitizers to their
latest version?


As I mentioned above, we merge sanitizer library from upstream to GCC 
source tree from time to time during the active development stage (stage 
1, see https://gcc.gnu.org/develop.html).


-Maxim



Rgds,

Gayan

Re: How to identify the version of the LLVM AddressSanitizer integrated to GCC 4.9.3 and after

[Maxim Ostapenko]

On 31/03/16 18:20, Gayan Pathirage wrote:

Hi Maxim,

Thanks a lot for the information. I find it very useful for my future tests.

Also I found this page maintained by ASAN developers
https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC
which lists some of the differences.


Yes, but please note, that this page describes differences between two 
particular revisions. For current trunk (and release) GCC and LLVM 
versions the situation might be different.




Finally any plans to integrate other sanitizer tools by LLVM in to
GCC, like Memory Sanitizer, Data Flow Sanitizer ?


AFAIK, there aren't any plans on porting MSan and DFSan to GCC (see 
https://gcc.gnu.org/ml/gcc/2014-10/msg0.html for MSan). TSan and 
UBSan are already present in GCC.


-Maxim



Best Regards,

Gayan

On Thu, Mar 31, 2016 at 4:40 PM, Maxim Ostapenko
 wrote:

Hi.

On 31/03/16 12:52, Gayan Pathirage wrote:

Hi,

I find it difficult to locate the information regarding the version of
the sanitizers (i.e. LLVM Sanitizers) integrated with GCC 4.9.3. Could
anyone suggest me a location where I can find this information.


This is indeed difficult. AFAIK, there isn't any mapping between LLVM and
GCC ASan releases, we just merge sanitizer library from upstream to GCC
source tree from time to time. GCC wiki doesn't have a dedicated page for
AddressSanitizer, so I suppose that the most appropriate method for
discovering such an information is just looking into ASan source code.


My question is due to some of the run time flags defined in ASAN is
not recognized in GCC based binary (i.e. GCC 4.9.3). e.g.
ASAN_OPTIONS=help=1:halt_on_error=0


ASAN_OPTIONS=help=1 was introduced in GCC 5 and ASAN_OPTIONS=halt_on_error
will be available in GCC 6.


Also what is the GCC policy behind updating LLVM sanitizers to their
latest version?


As I mentioned above, we merge sanitizer library from upstream to GCC source
tree from time to time during the active development stage (stage 1, see
https://gcc.gnu.org/develop.html).

-Maxim


Rgds,

Gayan

[RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko]

Hi!

Although in languages like C and C++ unsigned integer overflow reliably 
wraps around and well defined, sometimes it may indicate an error in 
code and lead to undesirable consequences and even security 
vulnerabilities 
(https://android-developers.blogspot.ru/2016/05/hardening-media-stack.html). 
Clang has corresponding '-fsanitize=unsigned-integer-overflow' option 
that may catch some of these errors (but misses some important cases 
such as pointers overflow), GCC has not and instruments only signed 
integer operations (S = S {+, -, *} S).


Although GCC has a nice framework for instrumenting even "mixed" binary 
operations (e.g. S = U + S) in middle end, implemented by Jakub some 
time ago (see expand_addsub_overflow, expand_mul_overflow etc in 
internal-fn.c), adding support for sanitizing unsigned and "mixed" 
binary operations seems to be quite problematic in terms of huge amount 
of false positive reports that may pop up in following cases:


1) Some code intentionally relies on overflows, e.g. when computing hash 
codes. Unfortunately, it seems that we cannot do anything with it on 
compiler side, programmer will need to do some filtering here by himself.


2) Unfortunately, it seems that C and C++ FEs don't provide suitable 
interfaces to get *LHS* real type when building binary expressions, so 
*build_binary_op* doesn't know about *LHS* real type and we can easily 
end up with false positive report e.g. in such code:


int
cmp (const char *s1, const char *s2)
{
  return strlen (s1) - strlen (s2);
}

because in gimple we would have something like this:

  unsigned int tmp, len1, len2;
  int result;
  .
  tmp = len1 - len2;  <= FP here if len1 < len2
  result = (int) tmp;
  return result;

3) GCC relies on unsigned integer overflows when constructing 
POINTER_PLUS expressions. We need a special treatment for this case, 
because it's quite common to have a negative offset from a given pointer 
and we don't want have false reports here.


This very draft patch (of course we would need more testcases, changelog 
entry etc) adds support for '-fsanitize=unsigned-integer-overflow' to 
GCC for PLUS, MINUS and MULT operations, extending its functionality to 
support pointers overflow and binary operations with different signess 
of theirs operands ("mixed" binary operations, say, S = U + S). It 
simply replaces all +, - and * by new ISAN_CHECK_{ADD, SUB, MUL} 
intrinsics in C and C++ FEs to be lowered later during intrinsics 
expansion. For example, if we have a + b expression, it would be 
replaced in FE by following call:


a + b -> ISAN_CHECK_ADD (a, b, a_unsiged_p, b_unsigned_p, result_unsigned_p)

where *a_unsiged_p* is 1 if *a* is unsigned and 0 otherwise. The same 
rule applies for *b_unsigned_p*. The *result_unsigned_p* value should 
reflect result type signess, but as mentioned in 2), we don't know it 
when building binary expression, so we can only guess it from arguments 
types and maybe change it (in a very hackish way) later (see 
*isan_maybe_change_ifn_sign_arg* function) in order to reduce number of 
FPs (in fact, these hacks can significantly reduce FPs ratio, ~ 30%). 
These values will be used in *expand_addsub_overflow* and 
*expand_mul_overflow* functions to compute overflow correctly.


This patch survives GCC bootstrap, I've also managed to build Firefox 
and Chromium with '-fsanitize=unsigned-integer-overflow' enabled. The 
tool found several bugs in opensource software:


1) Integer overflow when computing len parameter in "file" utility 
(http://bugs.gw.com/view.php?id=555)
2) Pointer overflow (nullptr - 1) in Google's skia library 
(https://bugs.chromium.org/p/skia/issues/detail?id=5415)
3) Unsigned integer overflow in HAL component in Firefox 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1280514)


Is community interested in such a tool? Any feedback would be greatly 
appreciated, especially some points how we can figure out real result 
type for *LHS* of binary expressions in

*build_binary_op* in order to avoid unnecessary FPs and ugly hacks in FEs.

Thanks,
-Maxim
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 5d234a5..1cdba47 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -6838,6 +6838,7 @@ builtin_mathfn_code (const_tree t)
   const_call_expr_arg_iterator iter;
 
   if (TREE_CODE (t) != CALL_EXPR
+  || !CALL_EXPR_FN (t)
   || TREE_CODE (CALL_EXPR_FN (t)) != ADDR_EXPR)
 return END_BUILTINS;
 
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 3301c31..29c7ce1 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4248,10 +4248,18 @@ pointer_int_sum (location_t loc, enum tree_code resultcode,
 		 tree ptrop, tree intop, bool complain)
 {
   tree size_exp, ret;
+  HOST_WIDE_INT op1 = 0;
 
   /* The result is a pointer of the same type that is being added.  */
   tree result_type = TREE_TYPE (ptrop);
 
+  if (flag_sanitize & SANITIZE_UI_OVERFLOW)
+{
+  /* First, try to avoid FPs if INTOP is negativ

Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko]

CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.

On 04/07/16 14:12, Maxim Ostapenko wrote:

Hi!

Although in languages like C and C++ unsigned integer overflow 
reliably wraps around and well defined, sometimes it may indicate an 
error in code and lead to undesirable consequences and even security 
vulnerabilities 
(https://android-developers.blogspot.ru/2016/05/hardening-media-stack.html). 
Clang has corresponding '-fsanitize=unsigned-integer-overflow' option 
that may catch some of these errors (but misses some important cases 
such as pointers overflow), GCC has not and instruments only signed 
integer operations (S = S {+, -, *} S).


Although GCC has a nice framework for instrumenting even "mixed" 
binary operations (e.g. S = U + S) in middle end, implemented by Jakub 
some time ago (see expand_addsub_overflow, expand_mul_overflow etc in 
internal-fn.c), adding support for sanitizing unsigned and "mixed" 
binary operations seems to be quite problematic in terms of huge 
amount of false positive reports that may pop up in following cases:


1) Some code intentionally relies on overflows, e.g. when computing 
hash codes. Unfortunately, it seems that we cannot do anything with it 
on compiler side, programmer will need to do some filtering here by 
himself.


2) Unfortunately, it seems that C and C++ FEs don't provide suitable 
interfaces to get *LHS* real type when building binary expressions, so 
*build_binary_op* doesn't know about *LHS* real type and we can easily 
end up with false positive report e.g. in such code:


int
cmp (const char *s1, const char *s2)
{
  return strlen (s1) - strlen (s2);
}

because in gimple we would have something like this:

  unsigned int tmp, len1, len2;
  int result;
  .
  tmp = len1 - len2;  <= FP here if len1 < len2
  result = (int) tmp;
  return result;

3) GCC relies on unsigned integer overflows when constructing 
POINTER_PLUS expressions. We need a special treatment for this case, 
because it's quite common to have a negative offset from a given 
pointer and we don't want have false reports here.


This very draft patch (of course we would need more testcases, 
changelog entry etc) adds support for 
'-fsanitize=unsigned-integer-overflow' to GCC for PLUS, MINUS and MULT 
operations, extending its functionality to support pointers overflow 
and binary operations with different signess of theirs operands 
("mixed" binary operations, say, S = U + S). It simply replaces all +, 
- and * by new ISAN_CHECK_{ADD, SUB, MUL} intrinsics in C and C++ FEs 
to be lowered later during intrinsics expansion. For example, if we 
have a + b expression, it would be replaced in FE by following call:


a + b -> ISAN_CHECK_ADD (a, b, a_unsiged_p, b_unsigned_p, 
result_unsigned_p)


where *a_unsiged_p* is 1 if *a* is unsigned and 0 otherwise. The same 
rule applies for *b_unsigned_p*. The *result_unsigned_p* value should 
reflect result type signess, but as mentioned in 2), we don't know it 
when building binary expression, so we can only guess it from 
arguments types and maybe change it (in a very hackish way) later (see 
*isan_maybe_change_ifn_sign_arg* function) in order to reduce number 
of FPs (in fact, these hacks can significantly reduce FPs ratio, ~ 
30%). These values will be used in *expand_addsub_overflow* and 
*expand_mul_overflow* functions to compute overflow correctly.


This patch survives GCC bootstrap, I've also managed to build Firefox 
and Chromium with '-fsanitize=unsigned-integer-overflow' enabled. The 
tool found several bugs in opensource software:


1) Integer overflow when computing len parameter in "file" utility 
(http://bugs.gw.com/view.php?id=555)
2) Pointer overflow (nullptr - 1) in Google's skia library 
(https://bugs.chromium.org/p/skia/issues/detail?id=5415)
3) Unsigned integer overflow in HAL component in Firefox 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1280514)


Is community interested in such a tool? Any feedback would be greatly 
appreciated, especially some points how we can figure out real result 
type for *LHS* of binary expressions in
*build_binary_op* in order to avoid unnecessary FPs and ugly hacks in 
FEs.


Thanks,
-Maxim


diff --git a/gcc/builtins.c b/gcc/builtins.c
index 5d234a5..1cdba47 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -6838,6 +6838,7 @@ builtin_mathfn_code (const_tree t)
   const_call_expr_arg_iterator iter;
 
   if (TREE_CODE (t) != CALL_EXPR
+  || !CALL_EXPR_FN (t)
   || TREE_CODE (CALL_EXPR_FN (t)) != ADDR_EXPR)
 return END_BUILTINS;
 
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 3301c31..29c7ce1 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -4248,10 +4248,18 @@ pointer_int_sum (location_t loc, enum tree_code resultcode,
 		 tree ptrop, tree intop, bool complain)
 {
   tree size_exp, ret;
+  HOST_WIDE

Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko]

On 11/07/16 18:05, Jakub Jelinek wrote:

On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:

CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.


Jakub, thanks for your summary.


I'm not convinced it is a good idea, that is why we've intentionally left it
out when adding UBSan support, IMHO such an option defines substantially
different languages.


The reason why I thought about -fsanitize=unsigned-integer-overflow 
would be useful is that people still hit on undesired integer overflows 
in their code (that may even lead to security vulnerabilities), despite 
the fact some people intentionally rely on them. Of course those people 
can just ignore -fsanitize=unsigned-integer-overflow. But others might 
find this option to be useful in their projects (e.g. Android people), 
because it finds real bugs in their code (even this very draft version 
managed to find several bugs in OSS projects).




The wrapping behavior of unsigned integer arithmetics is
integral part of the language, lots of code obviously relies on it.
E.g. in unsigned arithmetics, x - y and t = -y; x + t is the same thing,
while the patch would treat that differently.  Or would it even allow
unary negation of non-zero unsigned values?  On IRC I've mentioned e.g.
loops with unsigned iterator and bounds that can iterate forward or backward
at runtime, like:
void foo (unsigned start, unsigned end, unsigned step)
{
   for (unsigned i = start; i != end; i += step)
 ...
}
would one have to rewrite this to do something like: "step_is_negative" ? i -= 
-step : i += step
instead?  How would code portably say that for a given arithmetics it really
does assume wrapping behavior?  Replacing x = y + z; with
(void) __builtin_add_overflow (y, z, &x);
is not sufficiently portable, trying x = (y + z) & ~(unsigned) 0;
I assume would still trigger, because the unsigned arithmetics still
"overflows".


True, one should rewrite this like "step_is_negative" ? i -= -step : i 
+= step to avoid false positive report here. Another option would be 
just to ignore a FP report here or use some post processing to filter it 
out. Anyway, there is a bunch of situations where we can't simply 
determine whether overflow is desired or not and people would need to 
decide by themselves.




I'm really surprised you didn't run into many more "issues" during your
tests.


Well, I used some heuristics (e.g. guessing the real type of LHS of 
binary expression) to reduce number of these "issues" during my tests. 
Actually, I didn't see many such cases:


void foo (unsigned start, unsigned end, unsigned step)
{
  for (unsigned i = start; i != end; i += step)
...
}

instead, much more common were:

void bar(char *start, unsigned offset)
{
   ...
   char *end = start + offset;
}

with negative offset. And here we need a special treatment (I treated 
'offset' as a signed value when expanding a ISAN_CHECK_ADD builtin in 
expand_addsub_overflow, this is not portable, but works most of the time).


-Maxim


Jakub

Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko]

On 11/07/16 19:28, Jeff Law wrote:

On 07/11/2016 10:08 AM, Maxim Ostapenko wrote:

On 11/07/16 18:05, Jakub Jelinek wrote:

On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:

CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.


Jakub, thanks for your summary.


I'm not convinced it is a good idea, that is why we've intentionally
left it
out when adding UBSan support, IMHO such an option defines 
substantially

different languages.


The reason why I thought about -fsanitize=unsigned-integer-overflow
would be useful is that people still hit on undesired integer overflows
in their code (that may even lead to security vulnerabilities), despite
the fact some people intentionally rely on them.
An integer overflow where the result feeds a malloc/alloca is 
definitely a security issue.There may be others.


So one of the questions one might reasonably try to answer is can we 
limit sanitization to those cases that are most likely going to be of 
interest to developers. 


Thank you for your point. I think the easiest case here is pointer 
overflow (since we have a dedicated place where we construct 
POINTER_PLUS expression).
As for other cases, generally it's not easy to understand whether given 
binary expression is interesting or not. Of course, in some more or less 
trivial cases, such as

void foo (unsigned a, unsigned b)
{
unsigned len = a + b;
void *p = malloc (len);
}

we can make such decision, but in others, such as

void foo (unsigned len)
{
...
void *p = malloc (len);
}

void bar ()
{
...
unsigned len = a + b;
foo (len);
}

we can't (and this is quite common code I believe). So, we can end up 
with missing some important cases.


I suspect that in general integer overflow happens far often than 
developers realize and that there'll be so many false positives that 
the results will be ignored.


Yeah, even in small projects I observe a bunch of places where integer 
overflow happens. And yes, FPs are the real problem here...




Jeff

Re: [RFC][Draft patch] Introduce IntegerSanitizer in GCC.

[Maxim Ostapenko]

On 12/07/16 12:20, Yuri Gribov wrote:

On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
 wrote:

On 11/07/16 19:28, Jeff Law wrote:

On 07/11/2016 10:08 AM, Maxim Ostapenko wrote:

On 11/07/16 18:05, Jakub Jelinek wrote:

On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:

CC'ing Jakub, Marek and Kostya, sanitizer maintainers in GCC.


Jakub, thanks for your summary.


I'm not convinced it is a good idea, that is why we've intentionally
left it
out when adding UBSan support, IMHO such an option defines substantially
different languages.


The reason why I thought about -fsanitize=unsigned-integer-overflow
would be useful is that people still hit on undesired integer overflows
in their code (that may even lead to security vulnerabilities), despite
the fact some people intentionally rely on them.

An integer overflow where the result feeds a malloc/alloca is definitely a
security issue.There may be others.

So one of the questions one might reasonably try to answer is can we limit
sanitization to those cases that are most likely going to be of interest to
developers.


Thank you for your point. I think the easiest case here is pointer overflow
(since we have a dedicated place where we construct POINTER_PLUS
expression).
As for other cases, generally it's not easy to understand whether given
binary expression is interesting or not. Of course, in some more or less
trivial cases, such as
void foo (unsigned a, unsigned b)
{
 unsigned len = a + b;
 void *p = malloc (len);
}

we can make such decision, but in others, such as

void foo (unsigned len)
{
 ...
 void *p = malloc (len);
}

void bar ()
{
 ...
 unsigned len = a + b;
 foo (len);
}

we can't (and this is quite common code I believe). So, we can end up with
missing some important cases.


I suspect that in general integer overflow happens far often than
developers realize and that there'll be so many false positives that the
results will be ignored.


Yeah, even in small projects I observe a bunch of places where integer
overflow happens. And yes, FPs are the real problem here...

There are people who would tolerate FPs if the tool indeed helps to
find vulnerabilities. Especially if there is easy way to suppress
checks in set of functions/files who intentionally rely on unsigned
overflow (hash functions, etc.).

What are the FP rates you see with current version of the patch?


A lot... this depends of particular project. Say, GCC has so much code 
that essentially relies on unsigned integer overflows, that I can't even 
tell you a ratio.
For, Firefox I saw ~90% of FP ratio (given the fact I use several hacks 
in GCC to reduce this ratio), they are mostly come from hashing code and 
MULT expressions.




-Y

Re: GCC 7.0.0 Status Report (2016-10-21)

[Maxim Ostapenko]

Hi,

On 21/10/16 16:46, Jakub Jelinek wrote:

Status
==

Trunk which will eventually become GCC 7 is still in Stage 1 but its
end is near and we are planning to transition into Stage 3 starting
Nov 13th end of day time zone of your choice.

This means it is time to get things you want to have in GCC 7 finalized
and reviewed.  As usual there may be exceptions to late reviewed features
but don't count on that.  Likewise target specific features can sneak in
during Stage 3 if maintainers ok them.


Are there any plans on libsanitizer merge from upstream?
If yes, I can suggest my hands unless someone is already working on this 
task.


-Maxim




Quality Data


Priority  #   Change from last report
---   ---
P14+   1
P2  117+  27
P3  192+ 174
P4  109+   9
P5   29-   1
---   ---
Total P1-P3 313+ 202
Total   451+ 210


Previous Report
===

https://gcc.gnu.org/ml/gcc/2016-04/msg00106.html

Re: GCC 7.0.0 Status Report (2016-10-21)

[Maxim Ostapenko]

On 25/10/16 11:36, Jakub Jelinek wrote:

On Tue, Oct 25, 2016 at 11:32:25AM +0300, Maxim Ostapenko wrote:

On 21/10/16 16:46, Jakub Jelinek wrote:

Status
==

Trunk which will eventually become GCC 7 is still in Stage 1 but its
end is near and we are planning to transition into Stage 3 starting
Nov 13th end of day time zone of your choice.

This means it is time to get things you want to have in GCC 7 finalized
and reviewed.  As usual there may be exceptions to late reviewed features
but don't count on that.  Likewise target specific features can sneak in
during Stage 3 if maintainers ok them.

Are there any plans on libsanitizer merge from upstream?
If yes, I can suggest my hands unless someone is already working on this
task.

If you could do it, it would be greatly appreciated, if not, I'll try to squeeze
it into my todo list.


Ok, I'll prepare a patch and post it for review in gcc-patches ML.

-Maxim



Jakub

[RFC] Don't inline builtin memory functions when ASan is enabled.

[Maxim Ostapenko]

Hi,

At this moment, most of GCC builtin memory functions (for example 
strcpy, stpcpy, wcpcpy, strdup, etc) are not instrumented by GCC, 
however some of them are rather dangerous. If GCC inlines these builtin 
functions, we will miss important checks for arguments, and possible 
overflow won't be detected. I know, that Clang ASan team simply disable 
inlining of builtin functions in Clang if -fsanitize=address is enabled 
and rely on libsanitizer's hooks.


The main benefit of this approach is that we won't miss overflow in 
builtins, that can significantly increase target programs safety. Also, 
some redundant checks will be removed for builtin functions, that are 
instrumented and are not inlined for some reasons.


The potential disadvantage of this approach is performance decreasing 
for sanitized programs.


Does disabling of builtin functions inlining look sane in this case? If 
yes, I can provide performance investigation and prepare the patch.


What do you think?

-Maxim

Re: -fsanitize=thread support on ppc64

[Maxim Ostapenko]

Hi,

On 23/01/17 14:33, Jakub Jelinek wrote:

Hi!

I've noticed today there is tsan_rtl_ppc64.S file since the latest
merge from upstream.  Does that mean tsan is supposed to work
on ppc64?  Just powerpc64le-*-linux*, or powerpc64-*-linux* too?


FWIW LLVM has build bots for both ppc64le-linux and ppc64be-linux, see:
http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux
http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux

Thus TSan is supposed to work on ppc64, I guess.

-Maxim


If yes, then libsanitizer/configure.tgt should be changed to reflect that
change.

Jakub