From: dnovillo
This patch merely imports the initial state of asan as it was in the
Google branch.
It provides basic infrastructure for asan to instrument memory
accesses on the heap, at -O3. Note that it supports neither stack nor
global variable protection.
The rest of the patches of the set
From: jakub
This patch defines a new asan_shadow_offset target macro, instead of
having a mere macro in the asan.c file. It becomes thus cleaner to
define the target macro for targets that supports asan, namely x86 for
now. The ASAN_SHADOW_SHIFT (which, along with the asan_shadow_offset
constan
From: wmi
It appeared that we were forgetting to protect global variables that
are already 32 bytes aligned. Fixed thus.
* varasm.c (assemble_variable): Set asan_protected even
for decls that are already ASAN_RED_ZONE_SIZE or more
bytes aligned.
git-svn-id: svn+ssh://gc
From: dnovillo
Following a discussion we had on this list, this patch renames the
file tree-asan.* into asan.*.
* asan.c: Rename from tree-asan.c.
Update all users.
* asan.h: Rename from tree-asan.h
Update all users.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/bran
From: dodji
This patch splits a new create_cond_insert_point_before_iter function
out of build_check_stmt, to be used by a later patch.
Tested by running cc1 -fasan on the test program below with and
without the patch and by inspecting the gimple output to see that
there is no change.
void
foo
From: jakub
This patch defines a new asan pass gate that is activated at -O0, in addition
to the -O3 level at which it was initially activated. The patch also
does some comment cleanups here and there.
* asan.c (build_check_stmt): Rename join_bb variable to else_bb.
(gate_asan_O
From: jakub
After the previous patches uncovered the fact a NOTE_INSN_BASIC_BLOCK
could show up in the middle of a basic block and thus violating an
important invariant. THe cfgexpand.c hunk fixes that.
Then it appeared that we could get tree sharing violation if
build_check_stmt doesn't unshar
From: Dodji Seketeli
Hello,
The set of patches following this message represents the work that
happened on the asan branch to build up the Address Sanitizer work
started in the Google branch.
Address Sanitizer (aka asan) is a memory error detector. It finds
use-after-free and {heap,stack
From: dodji
This patch makes build_check_stmt accept its memory access parameter
to be an SSA name. This is useful for a subsequent patch that will
re-use.
Tested by running cc1 -fasan on the program below with and without the
patch and inspecting the gimple output to see that there is no
From: jakub
This patch cleanups the instrumentation code generation by emitting
GIMPLE directly, as opposed to emitting GENERIC tree and then
gimplifying them. It also does some cleanups here and there
* Makefile.in (GTFILES): Add $(srcdir)/asan.c.
* asan.c (shadow_ptr_types): N
From: jakub
This patch implements the protection of stack variables.
To understand how this works, lets look at this example on x86_64
where the stack grows downward:
int
foo ()
{
char a[23] = {0};
int b[2] = {0};
a[5] = 1;
b[1] = 2;
return a[5] + b[1];
}
For this function
From: jakub
This patch implements the protection of global variables.
The basic idea is to insert a red zone between two global variables
and install a constructor function that calls the asan runtime to do
the populating of the relevant shadow memory regions at load time.
So the patch lays out
From: dodji
This patch instruments many memory access patterns through builtins.
Basically, for a call like:
__builtin_memset (from, 0, n_bytes);
the patch would only instrument the accesses at the beginning and at
the end of the memory region [from, from + n_bytes]. This is the
ese comments right in tree.h so that they are easier to find next
time.
OK to commit this comment-only patchlet to trunk then?
Thanks.
From 1ad29143764a72d27b1ecf3c06b4ba72bfaf4fe8 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli
Date: Wed, 4 Sep 2013 10:32:36 +0200
Subject: [PATCH] More comm
Ian Lance Taylor a écrit:
> On Wed, Sep 4, 2013 at 1:46 AM, Dodji Seketeli wrote:
>>
>> +/* In a FUNCTION_DECL, nonzero means a built in function of a
>> + standard library or more generally a built in function that is
>> + recognized by optimizers and expanders.
^
> [...]
>
> Ping:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01568.html
> `--> http://gcc.gnu.org/ml/gcc-patches/2013-09/txtnrNwaGiD3x.txt
>
> MfG, JBG
--
Dodji
le mode 100644
index 000..086b5e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-23.C
@@ -0,0 +1,7 @@
+// Origin: PR c++/54401
+// { dg-do compile { target c++11 } }
+
+template
+struct X {
+using type = T; // { dg-error "expected type-specifier|does not name a
type" }
+};
--
1.7.11.4
--
Dodji
hat we just use maybe_constant_value here?
Even after reading the comments of these two functions, /having/ to use
them like this seems confusing to the casual reader in me.
--
Dodji
Jason Merrill writes:
> OK.
Thanks. Committed to trunk at revision r192199.
--
Dodji
Friendly pinging this patch.
Dodji Seketeli writes:
> Hello,
>
> In the example of this problem report, during the substituting of int
> into 'function', tsubst_aggr_type fails for the alias ctxt1. This is
> because TYPE_TEMPLATE_INFO looks for the TEMPLATE_INFO of
test for excess errors)
> FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5)
> FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for excess errors)
Thank you for the heads-up. I am currently testing a patch for these.
Sorry for the inconvenience.
--
Dodji
Hans-Peter Nilsson writes:
> This caused a build failure, see PR54860.
I am on it.
Sorry for the inconvenience.
--
Dodji
def int type;
+};
+
+template
+void function()
+{
+ using ctx1 = context;
+ typename ctx1::type f1;
+
+ typedef context ctx2;
+ typename ctx2::type f2;
+}
+
+int main()
+{
+ function();
+}
+
--
Dodji
+++-
gcc/testsuite/g++.dg/cpp0x/gen-attrs-8.C | 2 +-
5 files changed, 27 insertions(+), 10 deletions(-)
--
Dodji
ment (parser);
+ else
+ /* Warn about parsing c++11 attribute in non-c++1 mode, only
+ when we are sure that we have actually parsed them. */
+ maybe_warn_cpp0x (CPP0X_ATTRIBUTES);
}
else
{
--
Dodji
pected" }
-int * [[gnu::stdcall]] myFn01( void) { return 0; }// { dg-warning "attribute
only applies to function types" }
+int * [[gnu::stdcall]] myFn01( void) { return 0; }// { dg-warning "ignored" }
--
1.7.11.4
--
Dodji
ce->attribute_hash != NULL);
str.str = attr->name;
str.length = strlen (str.str);
--
Dodji
rors)
> FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5)
> FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for excess errors)
These should now be fixed in trunk by revision r192300.
Cheers.
--
Dodji
EW_USES_COOKIE is set. Is it
still used?
--
Dodji
Florian Weimer a écrit:
> On 10/10/2012 06:02 PM, Dodji Seketeli wrote:
>
>> I just have one question for own education.
>>
>> Regarding:
>>
>> @@ -2450,7 +2450,13 @@
>>if (array_p && TYPE_VEC_NEW_USES_COOKIE (elt_type))
>>
irst, but does not contain the fields whose address are never
+ taken. For types that do escape the compilation unit, the data
+ structures will have identical information.
*/
/* The alias sets assigned to MEMs assist the back-end in determining
--
Dodji
iners think otherwise,
I'll abide.
> Dodji, does it look ok? I am not sure how much testsuite coverage we
> have for the macro unwinder, so I hope I didn't mess it up in some
> non-trivial testcase.
The test cases for the unwinder are not really tight. They are
mainly gcc.dg/
s errors" "" {target "*-*-*"}
> 0 }
> +
> +int& bad1()
> +{
> + int x = 0; // { dg-error "reference to local variable" }
> + return x;
> +}
> +
> +int* bad2()
> +{
> + int x = 0; // { dg-error "address of local variable" }
> + return &x;
> +}
> +
> +const int& bad4()
> +{
> + return int(); // { dg-error "returning reference to
> temporary" }
> +}
> diff --git a/gcc/testsuite/gcc.dg/Wreturn-local-addr.c
> b/gcc/testsuite/gcc.dg/Wreturn-local-addr.c
> new file mode 100644
> index 000..d496d20
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Wreturn-local-addr.c
> @@ -0,0 +1,9 @@
> +/* { dg-do assemble } */
> +/* { dg-options "-Werror=return-local-addr" } */
> +/* { dg-message "some warnings being treated as errors" "" {target "*-*-*"}
> 0 } */
> +
> +int* bad()
> +{
> + int x = 0;
> + return &x; /* { dg-error "address of local variable" } */
> +}
--
Dodji
_stmt
[asan] Instrument built-in memory access function calls
gcc/asan.c | 482 +
1 file changed, 419 insertions(+), 63 deletions(-)
--
Dodji
fter (&gsi, g, GSI_NEW_STMT);
base_addr = gimple_assign_lhs (g);
--
Dodji
&then_bb,
+ &else_bb);
base = unshare_expr (base);
- gsi = gsi_last_bb (cond_bb);
-
/* If BASE can already be an SSA_NAME; in that case, do not create a
new SSA_NAME for it. */
if (TREE_CODE (base) != SSA_NAME)
--
1.7.11.7
--
Dodji
s), false);
+ gimple s = gsi_stmt (i);
+
+ if (gimple_assign_single_p (s))
+ instrument_assignment (&i);
+ else if (is_gimple_call (s))
+ maybe_instrument_call (&i);
}
}
}
--
Dodji
Jakub Jelinek writes:
> On Tue, Oct 23, 2012 at 03:08:07PM +0200, Dodji Seketeli wrote:
>> +static gimple_stmt_iterator
>> +create_cond_insert_point_before_iter (gimple_stmt_iterator *iter,
>> + bo
Jakub Jelinek writes:
> On Tue, Oct 23, 2012 at 03:11:29PM +0200, Dodji Seketeli wrote:
>> + /* (src, n) style memops. */
>> +case BUILT_IN_STRNDUP:
>> + source0 = gimple_call_arg (call, 0);
>> + len = gimple_call_arg (call, 1);
>> +
he first byte
> before the call and the last one after the call).
How do I get the result of the (strlen) call in gimple?
--
Dodji
Jakub Jelinek writes:
> On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
>> Jakub Jelinek writes:
>>
>> >> For 'strlen', can the memory check be done at the end of the string
>> >> using the returned length?
>> >
>
These bits looks good to me, barring ...
[...]
> +void
> +diagnostic_attach_note (diagnostic_context *context,
> +location_t location,
> +const char * gmsgid, ...)
> +{
... this function that lacks a comment.
Thanks.
--
Dodji
itpos % (size_in_bytes * BITS_PER_UNIT) ?
> 1 byte or 2 byte access at bitpos 80 is fine, but 4 byte access is not.
Of course it should be that. I have updated the patch.
Jakub Jelinek writes:
> On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
>> Jakub
instrument_derefs (&i, gimple_assign_lhs (s),
- gimple_location (s), true);
- instrument_derefs (&i, gimple_assign_rhs1 (s),
- gimple_location (s), false);
+ gimple s = gsi_stmt (i);
+
+ if (gimple_assign_single_p (s))
+ instrument_assignment (&i);
+ else if (is_gimple_call (s))
+ maybe_instrument_call (&i);
}
}
}
--
1.7.11.7
--
Dodji
block) continue;
for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
- gimple s = gsi_stmt (i);
- if (!gimple_assign_single_p (s))
- continue;
- instrument_derefs (&i, gimple_assign_lhs (s),
- gimple_location (s), true);
- instrument_derefs (&i, gimple_assign_rhs1 (s),
- gimple_location (s), false);
+ gimple s = gsi_stmt (i);
+
+ if (gimple_assign_single_p (s))
+ instrument_assignment (&i);
+ else if (is_gimple_call (s))
+ maybe_instrument_call (&i);
}
}
}
--
Dodji
000..3cc5897
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C
@@ -0,0 +1,4 @@
+// Origin: PR c++/54955
+// { dg-do compile { target c++11 } }
+
+alignas(double) int f;
--
1.7.11.7
--
Dodji
Jason Merrill writes:
> On 10/26/2012 01:37 PM, Dodji Seketeli wrote:
>> cp_next_tokens_can_be_std_attribute_p (cp_parser *parser)
>> {
>> - return cp_nth_tokens_can_be_std_attribute_p (parser, 1);
>> + cp_token *token = cp_lexer_peek_token (parser->lexer);
n the main variant of the type.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-25.C: New test file.
In the example of this patch, g++ crashes when trying to build the
alias template Y
+ struct X { };
+
+template
+ using Y = const X;
+
+using Z = Y;
--
Dodji
on between signed and unsigned integers
> +which are all warned about immediately, so this is unused
> + UNSAFE_REAL Conversions that reduce the precision of reals
> +including conversions from reals to integers
> + */
> +enum conversion_safety { SAFE_CONVERSION = 0, UNSAFE_OTHER, UNSAFE_SIGN,
> UNSAFE_REAL };
> +
[...]
Other than these nits, the patch looks nice to me.
Thank you for working on this.
--
Dodji
ld say that this is a new file. Here
what it says is that it's a modification of an existing file.
Thank you for your time on this.
--
Dodji
"Joseph S. Myers" writes:
> On Mon, 28 Oct 2013, Dodji Seketeli wrote:
>
>> * c-family/c-common.c (unsafe_conversion_p): Make this function
>
> As previously noted, c-family/ has its own ChangeLog, so the c-family/
> part does not go in the ChangeLog
Hello,
In this problem report, the compiler is fed a (bogus) translation unit
in which some literals contains bytes whose value is zero. The
preprocessor detects that and proceeds to emit diagnostics for that
king of bogus literals. But then when the diagnostics machinery
re-reads the input file
ine(3) would be much better for this purpose, though of course
> it is a GNU extension in glibc and so we'd need some fallback, which
> very well could be the fgetc or something similar.
So would getline (+ the current patch as a fallback) be acceptable?
--
Dodji
Jakub Jelinek writes:
> I think even as a fallback is the patch too expensive.
> I'd say best would be to write some getline API compatible function
> and just use it, using fread on say fixed size buffer.
OK, thanks for the insight. I have just used the getline_fallback
function you proposed,
ion with the gcov module.
--
Dodji
Jakub Jelinek writes:
[...]
> Eventually, I think using int for sizes is just a ticking bomb, what if
> somebody uses > 2GB long lines? Surely, on 32-bit hosts we are unlikely to
> handle it, but why couldn't 64-bit host handle it? Column info maybe bogus
> in there, sure, but at least we shou
Bernd Edlinger writes:
[...]
>> if (!string_len)
>> {
>> string_len = 200;
>> - string = XNEWVEC (char, string_len);
>> + string = XCNEWVEC (char, string_len);
>> }
>> + else
>> + memset (string, 0, string_len);
>
> Is this memset still necessary?
Of course not ...
[...]
> If "ptr" is passed
eep in mind that in subsequent patches, read_line might be re-used
by e.g, gcov in nominal contexts where we don't have zeros in the middle
of the line. In that case, speed can be a concern.
Thanks for the helpful thoughts.
--
Dodji
e_conversion_p): switching return type to
conversion_safety enumeration.
OK to commit with the above changes, if you have your copyright properly
assigned to the FSF.
Thank for working on this. It is appreciated.
--
Dodji
is is OK, if nobody objects in the next 48h.
Thanks.
--
Dodji
| provides a workaround in non-compiler-rt maintained files.
Let's get this in then :-)
Cheers.
--
Dodji
hen. I am little
bit concerned about the maintenance cost of this over time. I guess we
can figure out a way to factorize libbacktrace if the cost of its
maintenance really rises.
> Regtested on x86_64-linux (--target_board=unix\{-m32,-m64\}), ok for
> trunk (will do full bootstrap/regtest momentarily)?
Looks good to me.
Thank you.
--
Dodji
cmp,
> __asan_internal_strncmp): New functions.
> * sanitizer_common/Makefile.in: Regenerated.
> * libbacktrace/Makefile.in: Regenerated.
> * configure: Regenerated.
> * configure.ac: Regenerated.
> * config.h.in: Regenerated.
This looks good to me.
Thanks.
--
Dodji
u noticed
anythying related to that during bootstrap?
Cheers,
--
Dodji
therwise, if we could do
away with duplicating the start location and still miminize the churn,
maybe we should try.
--
Dodji
Manuel López-Ibáñez a écrit:
> 2015-09-15 Manuel López-Ibáñez
>
> PR pretty-print/67567
> * resolve.c (resolve_fl_procedure): Work-around when iface->module
> == NULL.
This is OK, thanks.
--
Dodji
ge
+get_decl_source_range (tree decl)
+{
Likewise.
--
Dodji
it into a
flag which type is an enum that says how the the pragma is to be
handled; either internally and its tokens shouldn't be visible to the FE
(this is what the current pragma_entry::is_internal means), internally
and the tokens would be visible to the FE, or deferred.
Then do do_pragma() would be adjusted to change the if (p->is_deferred)
clause to allow the third handling kind I just talked about.
I hope this helps.
Cheers,
--
Dodji
David Malcolm a écrit:
> On Fri, 2015-09-25 at 11:13 +0200, Dodji Seketeli wrote:
[...]
>> Funny; I first overlooked this comment of you, and then when reading the
>> patch, I asked myself "why keep the existing location_t" ? I mean, in
>> here:
>>
>&g
Manuel López-Ibáñez a écrit:
> On 25 September 2015 at 10:51, Dodji Seketeli wrote:
>> The line-map parts are OK to me too, but I have no power on those. So I
>
> You are listed as "line map" maintainer in MAINTAINERS. I rooted for
> you! :)
Right, I meant the libc
David Malcolm a écrit:
> On Fri, 2015-09-25 at 16:06 +0200, Dodji Seketeli wrote:
>> Hello,
>>
>> Similarly to a comment I made on the previous patch of the series,
>>
>> +++ b/libcpp/include/line-map.h
>>
>> [...]
>>
>> struc
oday, FEs emits diagnostics with ranges
that always starts with a caret.
But I think it's easy to imagine hypothetic (and reasonably probable)
examples where we'd have only one range with a caret, associated to other
ranges with no caret. The ranges with no carets would thus require the
show_caret_p argument to be non-null. In fact, patch 2/5 has one of
these examples in a comment in line-map.h:
+ Example C
+ *
+ a = (foo && bar)
+ ~~~ ^~ ~~~
+ This rich location has three ranges:
+ - Range 0 has its caret and start location at the first "&" and
+ end at the second "&.
+ - Range 1 has its start and finish at the "f" and "o" of "foo";
+ the caret is not flagged for display, but is perhaps at the "f"
+ of "foo".
+ - Similarly, range 2 has its start and finish at the "b" and "r" of
+ "bar"; the caret is not flagged for display, but is perhaps at the
+ "b" of "bar".
We'll then start seeing cases with show_caret_p being false when *new*
diagnostics are added to FEs to leverage on this new feature.
So I don't think this "show_caret_p" argument's value is an issue, quite
the contrary; it's an interesting feature.
Cheers,
--
Dodji
Manuel López-Ibáñez writes:
> On 25 September 2015 at 17:14, Dodji Seketeli wrote:
>> The caller of do_pragma(), which is destringize_and_run() then detects
>> that pfile->directive_result.type is set, and then puts the tokens of
>> the pragma back into the input stream
ugin/diagnostic_plugin_show_trees.c: New file.
> * gcc.dg/plugin/plugin.exp (plugin_test_list): Add
> diagnostic_plugin_show_trees.c and
> diagnostic-test-show-trees-1.c.
For what it's worth, this looks good to me.
Thanks!
--
Dodji
|| locus >= LINEMAPS_MACRO_LOWEST_LOCATION (set)
not part of pure_location_p() ? I mean, would it make sense to say that
a locus that that satisfies that condition is pure?
By the way, I like this great piece of code of yours, kudos!
Cheers,
--
Dodji
> Talking about risks: the reduction of the space for ordinary maps by a
> factor of 32, by taking up 5 bits for the packed range information
> optimization (patch 10):
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02539.html
> CCing Dodji: Dodji; is this reasonable?
FWIW, I a
tern.
Small nit; the diagnostic.[ch] files are in gcc/, not in c-family.
The language-agnostic diagnostic infrastructure changes otherwise look
OK to me.
Thanks.
--
Dodji
E__ expands to accordlingly.
(builtin_macro): Use cpp_force_token_locations() to set the
location of the resulting token to that expansion point location.
(enter_macro_context): Pass the expansion point locatoin to
builtin_macro.
gcc/testsuite/
*
79c830e..c234470 100644
> --- gcc/testsuite/gcc.dg/pr33676.c
> +++ gcc/testsuite/gcc.dg/pr33676.c
> @@ -1,4 +1,5 @@
> /* { dg-do run } */
> +/* { dg-options "" } */
> /* { dg-options "-O0 -mtune=i386 -fomit-frame-pointer" { target { { i?86-*-*
> x86_64-*-* } && ia32 } } } */
Likewise.
Cheers.
--
Dodji
l.
Oh, I see. Thanks.
Maybe a comment there would be helpful then :-)
Thanks.
--
Dodji
fsanitize=leak.
This looks OK to me.
Thanks!
--
Dodji
gt; Yea, I think this would be much better, thanks. Done in the
> following.
Yes, I agree with this as well.
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
Yes, this is OK to me.
Thank you for looking into this.
Cheers.
--
Dodji
> Bootstrapped and regression tested on x86-64-linux.
>
> OK?
This is OK for me.
Please commit it if nobody objects in the next 48 hours.
Thank you :-)
Cheers.
--
Dodji
ew
> line is needed.
> * diagnostic.h (struct diagnostic_context):
> Bootstrapped and regression tested on x86_64-linux-gnu.
>
> OK?
The generic diagnostics part is OK.
Thanks!
Cheers.
--
Dodji
ommand-line status.
>
> gcc/testsuite/ChangeLog:
>
> 2014-08-19 Manuel López-Ibáñez
>
> PR c/59304
> * gcc.dg/pr59304.c: New test.
Thank you!
--
Dodji
buffer = ptr;
lines++;
diff --git a/gcc/input.h b/gcc/input.h
index 128e28c..d7c8a0e 100644
--- a/gcc/input.h
+++ b/gcc/input.h
@@ -66,4 +66,6 @@ extern location_t input_location;
void dump_line_table_statistics (void);
+const char * read_line (FILE *, int *);
+
#endif
--
Dodji
Changelog doesn't match diff. (function names wrong, no mention of gcov)
Woops, sorry about that. The second patch attached is an update that
should address that. And with the changes in the first patch, this
new factorization patch is smaller.
Jakub Jelinek writes:
> On Thu, Nov
+-common/cpp/warning-zero-in-literals-1.c
new file mode 100644
index
..ff2ed962ac96e47ae05b0b040f4e10b8e09637e2
GIT binary patch
literal 240
zcmdPbSEyDinfo_ordinary.used == 0)
+return false;
+
+ /* Now look for the last ordinary map created for FILE_NAME. */
+ int i;
+ for (i = set->info_ordinary.used - 1; i >= 0; --i)
+{
+ const char *fname = set->info_ordinary.maps[i].d.ordinary.to_file;
+ if (fname && !strcmp (fname, file_name))
+ break;
+}
+
+ if (i < 0)
+return false;
+
+ /* The highest location for a given map is either the starting
+ location of the next map minus one, or -- if the map is the
+ latest one -- the highest location of the set. */
+ source_location result;
+ if (i == (int) set->info_ordinary.used - 1)
+result = set->highest_location;
+ else
+result = set->info_ordinary.maps[i].start_location - 1;
+
+ *loc = result;
+ return true;
+}
+
/* Compute and return statistics about the memory consumption of some
parts of the line table SET. */
--
Dodji
-overflow on address
0x7fff75df96f4 at pc 0x7f98ecbab68b bp 0x7fff75df96b0 sp 0x7fff75df95b8
READ of size 6 at 0x7fff75df96f4 thread T0
#0 0x7f98ecbab68a in __interceptor_memcmp
/home/dodji/git/gcc/master/libsanitizer/asan/asan_interceptors.cc:295
(discriminator 7)
#1 0x7f98ecbb6393 in
smallest counter?
Hehe, the LRU idea occurred to me too, but I dismissed the idea as
something probably over-engineered. But now that you are mentioning it
I guess I should give it a try ;-) I'll post a patch about that later
then.
>> + fcache * r = lookup_file_in_cache_tab (file_path);
>> + if (r == NULL)
>
> Formatting (no space after *, extra space after ==).
Fixed in my local copy. Thanks.
--
Dodji
Jakub Jelinek writes:
> On Mon, Nov 11, 2013 at 03:01:53PM +0100, Dodji Seketeli wrote:
>> Since a couple of days I am seeing failure on the tests above on my
>> Fedora system. The errors look like:
>>
>> FAIL: c-c++-common/asan/memcmp-1.c -
testsuite/c-c++-common/cpp/warning-zero-in-literals-1.c
b/gcc/testsuite/c-c++-common/cpp/warning-zero-in-literals-1.c
new file mode 100644
index
..ff2ed962ac96e47ae05b0b040f4e10b8e09637e2
GIT binary patch
literal 240
zcmdPbSEyDinfo_ordinary.used == 0)
+return false;
+
+ /* Now look for the last ordinary map created for FILE_NAME. */
+ int i;
+ for (i = set->info_ordinary.used - 1; i >= 0; --i)
+{
+ const char *fname = set->info_ordinary.maps[i].d.ordinary.to_file;
+ if (fname && !strcmp (fname, file_name))
+ break;
+}
+
+ if (i < 0)
+return false;
+
+ /* The highest location for a given map is either the starting
+ location of the next map minus one, or -- if the map is the
+ latest one -- the highest location of the set. */
+ source_location result;
+ if (i == (int) set->info_ordinary.used - 1)
+result = set->highest_location;
+ else
+result = set->info_ordinary.maps[i + 1].start_location - 1;
+
+ *loc = result;
+ return true;
+}
+
/* Compute and return statistics about the memory consumption of some
parts of the line table SET. */
--
Dodji
al copy. Thanks.
> You copy one char too much and set it to zero?
It's not one char too much. That char is the terminal '\n' in most
cases.
> Using -- on a value that goes out of scope looks
> awkward IMHO.
I don't understand this sentence. What do you mean by "Using -- on a
value that goes out of scope"?
--
Dodji
copying is less surprising. And
from what I could see from the tests I have done, the copying doesn't
make the thing slower than without the patch. So I'd like to keep this
unless folks have very strong feeling about it.
--
Dodji
ile, so that there is no buffer overflow
here.
--
Dodji
; S%s_ = ", to_base36 (i - 1));
if (TYPE_P (el) &&
(CP_TYPE_RESTRICT_P (el)
|| CP_TYPE_VOLATILE_P (el)
--
Dodji
Jakub Jelinek writes:
> On Tue, Nov 12, 2013 at 04:33:41PM +0100, Dodji Seketeli wrote:
>> +
>> + memmove (*line, l, len);
>> + (*line)[len - 1] = '\0';
>> + *line_len = --len;
>
> Shouldn't this be testing that len > 0 &
above) we are un-poisoning all
dynamically initialized global variables.
Also, do we have some tests for this? I am not sure how I'd write
multi-tu dejagnu tests for this myself though ;-)
Other than that, LGTM.
Thanks.
--
Dodji
Dodji Seketeli writes:
> Also, do we have some tests for this? I am not sure how I'd write
> multi-tu dejagnu tests for this myself though ;-)
Woops, I have just seen the sub-thread about the tests with Konstantin,
you and Alexey. Sorry.
Cheers.
--
Dodji
Jakub Jelinek writes:
> On Fri, Nov 22, 2013 at 04:38:58PM +0100, Dodji Seketeli wrote:
>> Jakub Jelinek writes:
>>
>> > --- gcc/cgraph.h.jj2013-11-13 18:32:52.0 +0100
>> > +++ gcc/cgraph.h 2013-11-15 12:05:25.950985500 +0100
>>
1 - 100 of 595 matches
Mail list logo
