Re: [PATCH] Support -fsanitize=leak

on x86_64-linux and i686-linux, ok for trunk? Yes, this is OK with the incremental patch for the documentation. Thanks. -- Dodji

Re: [PATCH] Provide global var location info for asan

th ubsan_get_source_location_type () type. > (asan_add_global): Provide global decl location info > if possible. This is OK, thanks. -- Dodji

Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

r properties which make the 'tor non-trivial) incorrectly >> conclude that the the 'tor is user defined, and hence not-trivial. > > I've been thinking that we should just mark the 'tor as trivial or not > directly rather than hint at it. FWIW, this would be my inclination too. I think it would make the job of the debug info consumer a lot easier. Thanks. -- Dodji

Re: [PATCH] cleanups in line-map

issing? I'd prefer to see this forward declaration stay, FWIW. Otherwise, this cleanup patch looks good to me. If it was my call, I'd say "OK with that change". Thank you for tackling this. -- Dodji

Re: [PATCH diagnostics] PR 53061 cleanup initialization

ntext) = cp_diagnostic_starter; >/* diagnostic_finalizer is already c_diagnostic_finalizer. */ > - diagnostic_format_decoder (global_dc) = cp_printer; > + diagnostic_format_decoder (context) = cp_printer; > +} > > +/* cxx_pp is a C++ front-end-specific pretty printer: this > +is where we dump C++ ASTs as strings. It is mostly used only by > +the various tree -> string functions that are occasionally > +called from the debugger or by the front-end for things like > +__PRETTY_FUNCTION__. */ > +void > +init_error (void) I think this comment should start saying that init_error initializes the global cxx_pp variable that is used as the memory store for the string representation of AST artifacts. And then maybe refer to the comment of cxx_pp for more details. OK to commit with the above changes. Thanks. -- Dodji

Re: C/C++ diagnostics guidelines

that these guidelines would be even better served by standing on their own page. If nobody objects, I can create a DiagnosticsGuidelines page in the wiki with the content that you added. Cheers, -- Dodji

Re: C/C++ diagnostics guidelines

rning options. > > I believe there are also some rules about when to use some special > line-map functions that arise when warning about macros like NULL, but > I am not aware of the specifics. It would be useful if someone added > those. > > Dodji, Paolo? Do you know what I'm talking about? Hmmh, I am not sure. Do you have any example of warning about such macros? Cheers, -- Dodji

Re: [PATCH diagnostics/fortran] dynamically generate locations from offset + handle %C

Hello Manuel, Manuel López-Ibáñez writes: > Dodji, are the linemap_asserts() appropriate? Yes they are. I have some additional comments though. > libcpp/ChangeLog: > > 2014-10-16 Manuel López-Ibáñez > > PR fortran/44054 > * include/line-map.h (linemap_positi

Re: [PATCH diagnostics/fortran] dynamically generate locations from offset + handle %C

Sorry, I forgot to make it clear that I have no power to approve the line-map changes. I just gave my casual point view; so please take it for what it is worth. I am CC-ing Tom and Jason who can approve this. Cheers. Dodji Seketeli writes: > Hello Manuel, > > Manuel López-Ibáñe

Re: [PATCH, cpp] Fix line directive bug‏

t;# 3 "src.cpp" 4" that doesn't mention the '3' flags and thus says that the rest of the tokens are *not* system tokens. What do you think? [1]: A system macro is a macro defined in a system header. [2]: A system token is a token coming from the expansion of a system macro Cheers, -- Dodji

Re: [PATCH, cpp] Fix line directive bug

implement > it, but should fix the problem in its entirety. Okay, let me look at this full-blown solution and I'll propose a patch soon. Cheers. -- Dodji

[PATCH] PR preprocessor/60723 - missing system-ness marks for macro

. (scan_translation_unit_directives_only): Adjust. gcc/testsuite/ChangeLog: * gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files. Signed-off-by: Dodji Seketeli --- gcc/c-family/c-ppoutput.c | 76 ++ gcc/testsuite/gcc.dg/cpp/syshdr4.c | 24

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

Jason Merrill writes: > On 06/27/2014 03:27 AM, Dodji Seketeli wrote: >> + && print.prev_was_system_token != !!in_system_header_at(loc)) >> +/* The system-ness of this token is different from the one >> + of the previous token.

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

_emitted = do_line_change (pfile, token, loc, false); > > This line_marker_emitted assignment is immediately overwritten, two lines > below. However, from a > maintainability perspective, this is probably a good assignment to > keep. Yeah, maintainability is why I kept it. But if the maintainers feel strongly about it I can, certainly just remove that assignment. Thank you for your time on this! Cheers. -- Dodji

Re: [PATCH diagnostics/fortran] Handle two locations for the same diagnostic. Convert all gfc_warning_1 and gfc_notify_std_1 calls

cation]; > + } > + > + inline location_t get_location (unsigned int index_of_location) const > + { > +gcc_checking_assert (index_of_location < MAX_LOCATIONS_PER_MESSAGE); > +return this->locations[index_of_location]; > + } > + > +private: > + location_t locations[MAX_LOCATIONS_PER_MESSAGE]; > }; > [...] OK to commit with the changes above. Thanks a lot! -- Dodji

Re: [PATCH diagnostics/fortran] Handle two locations for the same diagnostic. Convert all gfc_warning_1 and gfc_notify_std_1 calls

Manuel López-Ibáñez writes: > On 15 May 2015 at 10:39, Dodji Seketeli wrote: >> Manuel López-Ibáñez writes: >>> -/* Expand the location of this diagnostic. Use this function for >>> consistency. */ >>> +/* Return the location associated to this diagnostic.

Re: [obvious fix] fix off-by-one error when printing the caret character

; + * diagnostic.c (diagnostic_print_caret_line): Fix off-by-one error > + when printing the caret character. > + This is OK, thanks! Cheers, -- Dodji

Re: [PATCH] Quiet down -Wlogical-op a bit (PR c/61534)

;s worth, I like it and would vote for it to go in. > I did this by introducing a new macro. Fair enough. [...] > Bootstrapped/regtested on x86_64-linux, ok for trunk? [+1] from me. Thanks! -- Dodji

Re: [PATCH diagnostics/fortran] Handle two locations for the same diagnostic. Convert all gfc_warning_1 and gfc_notify_std_1 calls

imum "display width" that the diagnostic machinery allows for a line. That display width is, from I see in adjust_line(), diagnostic_context::caret_max_width minus a margin; and the margin is 10. If I am right, then I think the name diagnostic_same_locus() should be changed to something more meaningful. The 'locus' here seems confusing and makes the code hard to understand, IMHO. Especially given that we are talking about 'locations' as well. What do you think? I would also change the 10 literal into a named constant and use it at the other spots where we use the 10 today. Because otherwise, seeing that 10 literal magically appear in this function like this is ... surprising. Is it not? [...] > Bootstrapped and regression tested on x86_64-linux-gnu. Thanks! > > OK? > It's mostly OK to me, barring the points I have raised and for which I need input from you. Sorry again for taking so much time in reviewing this. Thanks! -- Dodji

Re: [PATCH] Optimize ASAN_CHECK checks

x27;d wait when this gets to trunk? > > Ok, in that case I've bootstrapped/regtested on x86_64-linux/i686-linux what > I have with > the ASAN_CHECK_NON_ZERO_LEN stuff removed from it (all non-INTEGER_CST > lengths ignored). Dodji, is this ok for trunk? [...] > +++ gcc/sanop

Re: [PATCH] Optimize ASAN_CHECK checks

ybe I should follow up with a doc patch for the (otherwise very terse) comment of gimple_set_uid and gimple_uid accessors. Thanks. -- Dodji

Add more comments to some gimple property accessors

accessors. Signed-off-by: Dodji Seketeli --- gcc/gimple.h | 57 +++-- 1 file changed, 51 insertions(+), 6 deletions(-) diff --git a/gcc/gimple.h b/gcc/gimple.h index c7aaa81..27bb7b6 100644 --- a/gcc/gimple.h +++ b/gcc/gimple.h @@ -1585,

Re: [PR c/52952] More precise locations within format strings

Jeff Law writes: > OK, let's go ahead and make that official. Please update MAINTAINERS ;-) I have just added a line for myself as a maintainer for the line map sub system in the MAINTAINERS file. Thanks! -- Dodji

Re: RFA (diagnostics): PATCH to move deprecated source location to separate note

OK for trunk? Yes. Thanks! -- Dodji

Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery

Manuel López-Ibáñez writes: > * Dodji: Do the common diagnostics part look reasonable? Yes they do. I just have one minor comment nit: [...] > Index: gcc/pretty-print.h [...] > + > + /* Nonzero means that text should be flushed when > + appropriate. Otherwise, text is

Re: [PATCH linemap] Make some asserts fail gracefully

anges and thank for your time and dedication. Cheers, -- Dodji

Re: [PATCH fortran/linemap] Add enough column hint to fit any possible offset

line in terms of column count and pass that to linemap_line_start. We must just keep in mind that the line subsystem has a hard limit on column numbers (I think it's 100 000 columns at the moment). Passed that limit, we give up tracking column numbers in source locations; that means that all columns numbers are set to zero. I hope this is useful. Cheers, -- Dodji

Re: [PATCH obvious/diagnostics] Honor override_column when printing the caret

verride_column; >line = location_get_source_line (s, &line_width); >if (line == NULL || s.column > line_width) > return; Thinking about it again, it would be nice to have a regression test for this. At some point, I guess we should do something for regression' tests about the placement of the caret. Oh well. Cheers, -- Dodji

Re: [PATCH] Fix __has_{cpp_}attribute with -traditional-cpp (PR preprocessor/65238)

* gcc.dg/cpp/trad/pr65238-4.c: New test. I do not have the rights to ACK this but FWIW it looks OK to me. Sorry for the delay in reviewing this. Thanks! Cheers, -- Dodji

Re: [PATCH] Fix __has_{cpp_}attribute with -traditional-cpp (PR preprocessor/65238)

ion that the effects of '#pragma GCC poison' are undefined. So I thought this useful particular use case of __has_attribute(U) might well be another of such case even if it's not a directive. Just my 2 cents. -- Dodji

Re: [PATCH] Don't emit backtrace from driver upon fatal compiler signals

* gcc.c (execute): Use internal_error_no_backtrace instead of >> internal_error. >> fortran/ >> * gfc-diagnostic.def (DK_ICE_NOBT): New kind. > > This is OK. FWIW, this is fine from me too, > Thanks for taking care of this. Indeed. Cheers, -- Dodji

[PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

function-like macro, or the location of the expansion point of the top-most object-like macro. (cpp_get_token_1): Store the top-most macro node in the new pfile->top_most_macro_node data member. gcc/testsuite/ChangeLog: * gcc.dg/cpp/builtin-macro-

[PATCH, libcpp] Do not modify a token once it has been initialized

to for trunk when stage 1 re-opens? Cheers, Signed-off-by: Dodji Seketeli --- libcpp/macro.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libcpp/macro.c b/libcpp/macro.c index 9571345..ca199ba 100644 --- a/libcpp/macro.c +++ b/libcpp/macro.c @@ -442,9 +442,12

Re: [PATCH, libcpp] Do not modify a token once it has been initialized

Andreas Schwab writes: >> + /* force the location of the token emitted by _cpp_lex_direct() to > > s/force/Force/ Thanks for noticing this, Andreas! I have updated my local copy of the patch to fix that. Cheers! -- Dodji

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

Jakub Jelinek writes: > On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote: >> [This is a P1 regression for gcc 5] >> libcpp/ChangeLog: >> >> * internal.h (cpp_reader::top_most_macro_node): New data member. >> * macro.c (enter_macro_conte

Re: [PATCH] PR preprocessor/64803 - __LINE__ inside macro is not constant

Jakub Jelinek writes: > On Mon, Feb 02, 2015 at 03:41:50PM +0100, Dodji Seketeli wrote: >> libcpp/ChangeLog: >> >> * internal.h (cpp_reader::top_most_macro_node): New data member. >> * macro.c (enter_macro_context): Pass the location of the end of >>

Re: [PR c/52952] More precise locations within format strings

Joseph Myers writes: [...] >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers >> do not feel comfortable reviewing line-map changes, could you nominate >> Dodji as line-map maintainer if he is willing to accept it? I think he >> is currently the pers

Re: Problem in cxx_fundamental_alignment_p?

7;val' being an alignment that is greater than MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node), TYPE_ALIGN_UNIT (long_double_type_node)) in the g++.dg/cpp0x/gen-attrs-*.C series of tests? -- Dodji

Re: [PATCH] Import liboffloadmic from upstream

(core dumped) Woops. can you send me the exact two libraries so that I can see what's going wrong? You can quickly file an issue to https://sourceware.org/bugzilla/enter_bug.cgi?product=libabigail or just send me the two binaries by email. I'll quickly look into this. Sorry for the inconvenience. Cheers, -- Dodji

Re: [PATCH] Import liboffloadmic from upstream

Ilya Verbin writes: > On Tue, Sep 01, 2015 at 09:58:22 +0200, Dodji Seketeli wrote: >> Woops. can you send me the exact two libraries so that I can see what's >> going wrong? You can quickly file an issue to >> https://sourceware.org/bugzilla/enter_bug.cgi?product=lib

Re: [RFC] diagnostics.c: For terminals, restrict messages to terminal width?

l, do you remember why we didn't query the TIOCGWINSZ ioctl property to get the terminal size when that capability was available? > Comments? If the change comes with ChangeLog, passes bootstrap and nobody else objects, I pre-approve this patch. Thanks! -- Dodji

Re: [PATCH fortran/diagnostics] Move gfc_error (buffered) to common diagnostics

pp_warning_buffer->flush_p = false; > + pp_error_buffer = new output_buffer (); > + pp_error_buffer->flush_p = false; > } Cheers, -- Dodji

Re: [RFC] diagnostics.c: For terminals, restrict messages to terminal width?

Manuel López-Ibáñez writes: [...] > On 10 December 2014 at 12:10, Dodji Seketeli wrote: [...] >> Manuel, was there a particular reason to avoid mentioning the COLUMNS >> environment variable in the documentation? > > Not that I remember. Perhaps the documentation should

Re: [PATCH fortran/diagnostics] Move gfc_error (buffered) to common diagnostics (try 2)

Manuel López-Ibáñez writes: > New version using XNEW. Bootstrapped & tested on x86_64-linux-gnu. > > OK? The diagnostics infrastructure changes are OK for me. Thanks! Cheers, -- Dodji

Re: [RFC] diagnostics.c: For terminals, restrict messages to terminal width?

r.c (gfc_get_terminal_width): Renamed from > get_terminal_width and use same-named common function. > (gfc_error_init_1): Update call. The diagnostics infrastructure changes are OK for me. Thanks! Cheers, -- Dodji

Re: [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

-common/ubsan/sanitize-all-2.c: New test. > * c-c++-common/ubsan/sanitize-all-3.c: New test. > * c-c++-common/ubsan/sanitize-all-4.c: New test. This is OK. Thanks! -- Dodji

Re: [asan] change libasan to libsanitizer

f: Change libasan module to libsanitizer. >> * Makefile.in: Regenerate. >> * libsanitizer: Change libasan to libsanitizer and add >> an empty tsan directory under libsanitizer. >> >> Thanks, >> Wei. > -- Dodji

Re: [PATCH 06/13] Implement protection of stack variables

izer? The later. As I said in my reply to David, I am going to resubmit a patch that exposes that change as part of the initial import patch of the series. Cheers. -- Dodji

Re: [PATCH 06/13] Implement protection of stack variables

Xinliang David Li writes: > Changing the option is part of the plan. Indeed. > Dodji, can you make the option change part of one the patches (e.g, > the first one that introduces it) -- there seems no need for a > separate patch for it. Sure thing. I have done the change on m

Re: [PATCH 06/13] Implement protection of stack variables

it easier to understand the whole thing than starring at source code and asm dumps of asan@{llvm,gcc}. :) Cheers. -- Dodji

Re: [PATCH 02/13] Rename tree-asan.[ch] to asan.[ch]

t; intermediate patches in the series I agree with this line of reasoning; I tried to squash and split the patches of the set to comply abide by your request. I'll be posting a new patch set accordingly. Sorry for the nuisance. -- Dodji

Re: [PATCH 00/13] Request to merge Address Sanitizer in

lso rebased the patches on top of trunk of today. Below is the new summary of the patch set. It has been bootstrapped and passed regression testing on x86_64-unknown-linux-gnu against trunk. Diego Novillo (1): Initial import of asan from the Google branch Dodji Seketeli (3): Make build_check

[PATCH 01/10] Initial import of asan from the Google branch into trunk

/asan.c create mode 100644 gcc/asan.h diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan new file mode 100644 index 000..704aa61 --- /dev/null +++ b/gcc/ChangeLog.asan @@ -0,0 +1,12 @@ +2012-10-10 Wei Mi + Diego Novillo + Dodji Seketeli + + * Makefile.in: Add asan.c

[PATCH 02/10] Initial asan cleanups

go Novillo Dodji Seketeli diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 3bade7f..c86bbeb 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2210,7 +2210,7 @@ stor-layout.o : stor-layout.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ asan.o : asan.c asan.h $(CONFIG_H) poi

[PATCH 03/10] Emit GIMPLE directly instead of gimplifying GENERIC.

eLog.asan b/gcc/ChangeLog.asan index d13a584..973ee6b 100644 --- a/gcc/ChangeLog.asan +++ b/gcc/ChangeLog.asan @@ -1,4 +1,31 @@ 2012-10-11 Jakub Jelinek + Dodji Seketeli + + * Makefile.in (GTFILES): Add $(srcdir)/asan.c. + (asan.o): Update the dependencies of asan.o. + * asan.

[PATCH 04/10] Allow asan at -O0

(pass_asan_O0): New declaration. + 2012-10-11 Jakub Jelinek Dodji Seketeli diff --git a/gcc/asan.c b/gcc/asan.c index baaec0f..e7f4943 100644 --- a/gcc/asan.c +++ b/gcc/asan.c @@ -123,7 +123,7 @@ build_check_stmt (tree base, location_t location, bool is_store, int

[PATCH 05/10] Implement protection of stack variables

xit_block (); insn_locations_finalize (); + if (var_ret_seq) +{ + rtx after = return_label; + rtx next = NEXT_INSN (after); + if (next && NOTE_INSN_BASIC_BLOCK_P (next)) + after = next; + emit_insn_after (var_ret_seq, after); +} + /* Zap the tree EH table. */ set_eh_throw_stmt_table (cfun, NULL); diff --git a/gcc/toplev.c b/gcc/toplev.c index 68849f5..0fa8ce3 100644 --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1542,7 +1542,9 @@ process_options (void) } /* Address Sanitizer needs porting to each target architecture. */ - if (flag_asan && targetm.asan_shadow_offset == NULL) + if (flag_asan + && (targetm.asan_shadow_offset == NULL + || !FRAME_GROWS_DOWNWARD)) { warning (0, "-fasan not supported for this target"); flag_asan = 0; -- Dodji

[PATCH 06/10] Implement protection of global variables

(decl) > BITS_PER_UNIT) ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (DECL_ALIGN_UNIT (decl))); assemble_variable_contents (decl, name, dont_output_data); + if (asan_protected) + { + unsigned HOST_WIDE_INT int size + = tree_low_cst (DECL_SIZE_UNIT (decl), 1); + assemble_zeros (asan_red_zone_size (size)); + } } } @@ -6926,6 +6946,8 @@ place_block_symbol (rtx symbol) decl = SYMBOL_REF_DECL (symbol); alignment = DECL_ALIGN (decl); size = tree_low_cst (DECL_SIZE_UNIT (decl), 1); + if (flag_asan && asan_protect_global (decl)) + size += asan_red_zone_size (size); } /* Calculate the object's offset from the start of the block. */ -- Dodji

[PATCH 07/10] Make build_check_stmt accept an SSA_NAME for its base

/asan.c | 36 +++- 2 files changed, 28 insertions(+), 13 deletions(-) diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan index a2e18ce..395ba4f 100644 --- a/gcc/ChangeLog.asan +++ b/gcc/ChangeLog.asan @@ -1,3 +1,8 @@ +2012-10-26 Dodji Seketeli

[PATCH 08/10] Factorize condition insertion code out of build_check_stmt

| 120 + 2 files changed, 81 insertions(+), 44 deletions(-) diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan index 395ba4f..903dc52 100644 --- a/gcc/ChangeLog.asan +++ b/gcc/ChangeLog.asan @@ -1,5 +1,10 @@ 2012-10-26 Dodji Seketeli

[PATCH 09/10] Instrument built-in memory access function calls

w parameter of build_check_stmt. Fix detection of bit-field access. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/asan@192845 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog.asan | 18 ++ gcc/asan.c | 612 ++++++--- 2 files change

[PATCH 10/10] Import the asan runtime library into GCC tree

patch -- Dodji

Re: [asan] change libasan to libsanitizer

is hopefully what I did in the patch submission [asan] -> [trunk] I did in the sub-thread rooted by http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00227.html. -- Dodji

Re: [PATCH 08/10] Factorize condition insertion code out of build_check_stmt

Jakub Jelinek writes: > On Sat, Nov 03, 2012 at 12:03:45AM +0100, Dodji Seketeli wrote: >> + int fallthrough_probability = >> +then_more_likely_p >> +? PROB_VERY_UNLIKELY >> +: PROB_ALWAYS - PROB_VERY_UNLIKELY; > > Just a formatting nit, I think =

Re: [PATCH 03/11] Emit GIMPLE directly instead of gimplifying GENERIC.

gcc/asan.c | 284 +++-- gcc/asan.h | 2 +- 4 files changed, 200 insertions(+), 123 deletions(-) diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan index d13a584..0345ac7 100644 --- a/gcc/ChangeLog.asan +++ b/gcc/ChangeLog.asan @@ -1,4

Re: [PATCH 02/10] Initial asan cleanups

> On 2012-11-02 15:57 , Dodji Seketeli wrote: > > > /* AddressSanitizer, a fast memory error detector. > > - Copyright (C) 2011 Free Software Foundation, Inc. > > + Copyright (C) 2011, 2012 Free Software Foundation, Inc. > > I *think* we should only mention

Re: [PATCH 01/10] Initial import of asan from the Google branch into trunk

e 100644 index 000..704aa61 --- /dev/null +++ b/gcc/ChangeLog.asan @@ -0,0 +1,12 @@ +2012-10-10 Wei Mi + Diego Novillo + Dodji Seketeli + + * Makefile.in: Add asan.c and its dependencies. + * common.opt: Add -faddress-sanitizer option. + * invoke.texi: Do

Re: [PATCH 05/10] Implement protection of stack variables

finalize (); + if (var_ret_seq) +{ + rtx after = return_label; + rtx next = NEXT_INSN (after); + if (next && NOTE_INSN_BASIC_BLOCK_P (next)) + after = next; + emit_insn_after (var_ret_seq, after); +} + /* Zap the tree EH table. */ set_eh_throw_stmt_table (cfun, NULL); diff --git a/gcc/toplev.c b/gcc/toplev.c index d9dfb2a..8911ca3 100644 --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1542,7 +1542,9 @@ process_options (void) } /* Address Sanitizer needs porting to each target architecture. */ - if (flag_asan && targetm.asan_shadow_offset == NULL) + if (flag_asan + && (targetm.asan_shadow_offset == NULL + || !FRAME_GROWS_DOWNWARD)) { warning (0, "-faddress-sanitizer not supported for this target"); flag_asan = 0; -- 1.7.11.7 -- Dodji

Re: [PATCH 06/10] Implement protection of global variables

Diego Novillo writes: > On 2012-11-02 16:01 , Dodji Seketeli wrote: > > > * varasm.c: Include asan.h. > > (assemble_noswitch_variable): Grow size by asan_red_zone_size > > if decl is asan protected. > > (place_block_symbol): Likewise. > >

Re: [PATCH 09/10] Instrument built-in memory access function calls

Diego Novillo writes: > On 2012-11-02 16:05 , Dodji Seketeli wrote: > >> +static bool >> +maybe_instrument_builtin_call (gimple_stmt_iterator *iter) >> +{ >> + gimple call = gsi_stmt (*iter); >> + location_t loc = gimple_location (call); >> + >&g

Re: [PATCH 10/10] Import the asan runtime library into GCC tree

Diego Novillo writes: > On 2012-11-02 16:10 , Dodji Seketeli wrote: > >> * configure.ac: Add libsanitizer to target_libraries. >> * Makefile.def: Ditto. >> * configure: Regenerate. >> * Makefile.in: Regenerate. >> * libsanit

Re: [asan] Patch - fix an ICE in asan.c

ed git tree with all these patches cleanly stacked on top of trunk by doing: git clone -b asan-merge-assemble git://seketeli.net/~dodji/gcc.git You can browse the patchset it via the web at: http://seketeli.net/git/~dodji/gcc.git/log/?h=asan-merge-assemble Cheers. -- Dodji

Re: [PATCH 00/13] Request to merge Address Sanitizer in

. -- Dodji

Re: [PATCH 05/10] Implement protection of stack variables

Jakub Jelinek writes: > On Mon, Nov 12, 2012 at 12:30:37PM +0100, Dodji Seketeli wrote: >> + For this function, the stack protected by asan will be organized as >> + follows, from the top of the stack to the bottom: >> + >> + Slot 1/ [red zone of 32 bytes called '

Re: [asan] Patch - fix an ICE in asan.c

break; > >/* (dest, src, n) style memops. */ Indeed. I was about to send a similar patch after Tobias' report. Thanks. -- Dodji

Re: [PATCH 00/13] Request to merge Address Sanitizer in

Hello Jack, Jack Howarth writes: >> >> Dodji, >> I am finding that at r193442 bootstrapping on >> x86_64-apple-darwin12 fails with... >> ../../../../gcc-4.8-20121112/libsanitizer/interception/interception_mac.cc:16:41: >> fatal error: mach_overr

Re: PATCH: PR other/55292: libsanitizer doesn't support x32

Diego Novillo a écrit: > Patches to libsanitizer should be sent upstream. We should only > contain a copy of the master in the LLVM repository. There should be > instructions in libsanitizer/README.gcc (Jakub, Dodji, are they there? > I can't check ATM). No there are no

Re: Committed: framework bits for disabling libsanitizer. RFC on which targets for which to disable it.

== > --- configure.ac (revision 193455) > +++ configure.ac (working copy) > @@ -547,6 +547,13 @@ case "${target}" in > ;; > esac > > +# Disable libsanitizer for some systems. > +case "${target}" in > + cris-*-* | crisv32-*-* | mmix-*-*) > +noconfigdirs="$noconfigdirs target-libsanitizer" > +;; > +esac > + [...] -- Dodji

Re: Committed: framework bits for disabling libsanitizer. RFC on which targets for which to disable it.

Jakub Jelinek writes: > On Tue, Nov 13, 2012 at 02:17:55PM +0100, Dodji Seketeli wrote: >> What do the maintainers think? > > Yes. And it shouldn't be just based on target CPU, but also based > on target OS, I don't think libsanitizer supports anything but linux (gl

[PATCH] Enable libsanitizer just on x86 linux for now

libsanitizer on all systems but x86 linux for now. case "${target}" in - cris-*-* | crisv32-*-* | mmix-*-*) -noconfigdirs="$noconfigdirs target-libsanitizer" + x86_64-*-linux-* | i?86-*-linux-*) ;; - powerpc-*-aix* | rs6000-*-aix*) + *) noconfigdirs="$noconfigdirs target-libsanitizer" ;; esac -- Dodji

Re: Committed: framework bits for disabling libsanitizer. RFC on which targets for which to disable it.

145.html . > > I don't think disabling libsanitizer is an emergency for darwin. I guess when the issue of the missing files is resolved, we can enable building libsanitizer on Darwin proper. Here is the patchlet I am proposing so far http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00993.html. -- Dodji

Re: ASAN merge...

ASAN is not currently > ported to any target other than x86/linux, so it should just be > completely disabled until the other ports start showing up. > > Dodji is your patch committed? Yes it is. It was even ironed out by a later patch from Richard Henderson. This should hopefully be fixed now. -- Dodji

Re: ASAN merge...

fic code to asan_linux.cc >> >> This should be fixed by Dodji's recent patch. ASAN is not currently >> ported to any target other than x86/linux, so it should just be >> completely disabled until the other ports start showing up. >> >> Dodji is your patch c

Re: [PATCH][Revised] Enable libsanitizer on darwin

; patches. If I do, I'd need to understand more than I do. What we > don't want, a half implementation that is worse than saying, > unsupported. I don't mind if the support isn't complete, yet, what is > there works fine. -- Dodji

[PATCH] Enable building of libsanitizer on sparc linux again.

David Miller wrote > From: Dodji Seketeli > Date: Wed, 14 Nov 2012 14:26:40 +0100 > > > I guess we could do that. That would build libsanitizer, but asan will > > still not be available on sparc if the asan_shadow_offset() target hook > > is not provided. Is th

Re: [PATCH] Copy libsanitizer from llvm at revision 167890

his needs to change. >>> >> >> That is the real problem. We need a GCC libsanitizer maintainer > > We already have FOUR. Kostya, Jakub, Dmitry and Dodji. > > Folks, please update MAINTAINERS to avoid confusion. Done, and committed the below. ChangeLog:

Re: [asan] Patch - fix an ICE in asan.c

type of __asan_{,un}register_globals. Set DECL_IGNORED_P on > the decls. This looks OK to me. Thanks! -- Dodji

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

David Miller writes: > From: Dodji Seketeli > Date: Thu, 15 Nov 2012 11:56:40 +0100 > >> David Miller wrote >> >>> From: Dodji Seketeli >>> Date: Wed, 14 Nov 2012 14:26:40 +0100 >>> >>> > I guess we could do that. That would build

Re: [PATCH 00/13] Request to merge Address Sanitizer in

Alexander can officially ACK it? I am mentioning Alexander because of what Konstantin is saying ... > Also, Alexander Potapenko is the best person to ask about asan-darwin. here. > Maybe we can add him to the list of sanitizer maintainers? Seconded. At least for libsanitier/Darwin. Cheers. -- Dodji

[PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum

-0,0 +1,11 @@ +// Origin: PR c++/54875 +// { dg-do compile { target c++11 } } + +template +using AddConst = T const; + +enum FwdEnum : int; + +int main() { + AddConst *ptr = nullptr; +} -- 1.7.11.7 -- Dodji

[PING] [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack

I am friendly pinging the patch below ... Dodji Seketeli a écrit: > Hello, > > Consider this example: > > 1template struct List {}; > 2template struct Z {static const int value = T;}; > 3template using LZ = List...>; >

[PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

I am friendly pinging the patch below ... Dodji Seketeli a écrit: > Hello, > > Consider this invalid example given in the PR, where T is not defined: > > 1template > 2struct X { > 3using type = T; > 4}; >

Re: [PATCH] PR c++/54875 - Error when instantiating an alias template that resolves to an enum

Jason Merrill writes: > On 11/16/2012 07:43 AM, Dodji Seketeli wrote: >> So I guess that condition should be changed to TREE_CODE >> (template_type) == ENUMERAL_TYPE, to specifically detect the member >> enum of a class template case. > > Why does that help? What is

Re: Patch: add AM_MAINTAINER_MODE in libsanitizer

T_AUTOMAKE(foreign) > AM_ENABLE_MULTILIB(, ..) > +AM_MAINTAINER_MODE > > # Calculate toolexeclibdir > # Also toolexecdir, though it's only used in toolexeclibdir -- Dodji

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

new file mode 100644 index 000..086b5e5 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-28.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" } +}; -- Dodji

Re: [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack

,0 +1,22 @@ +// Origin: PR c++/53609 +// { dg-do compile { target c++11 } } + +template struct List{ static const bool is_ok = false;}; +template struct Z +{ + static const int value = T; + static const int value_square = T * T; +}; + +template class U> +struct List, U<3>, U<4>, U<9>> { static const bool is_ok = true;}; + +template using LZ = List...>; + +template +struct F +{ + using N = LZ::value, Z<9>::value>; +}; + +static_assert (F, Z<3>>::N::is_ok, ""); -- 1.7.11.7 -- Dodji

Re: [asan] Another ICE fix

Jakub Jelinek writes: > Fixed thusly, ok for trunk? > > 2012-11-27 Jakub Jelinek > > * asan.c (instrument_assignment): Instrument lhs only > for gimple_store_p and rhs1 only for gimple_assign_load_p. This is OK, thanks. And sorry for the delay. -- Dodji

Re: [asan] Fix some asan ICEs

trument_builtin_call): Don't instrument BUILT_IN_ATOMIC_LOAD, > BUILT_IN_ATOMIC_TEST_AND_SET, BUILT_IN_ATOMIC_CLEAR, > BUILT_IN_ATOMIC_EXCHANGE, BUILT_IN_ATOMIC_COMPARE_EXCHANGE > and BUILT_IN_ATOMIC_STORE. This is OK. Thanks, and sorry for the delay. -- Dodji

Re: [PATCH] Convert asan to use sanitizer.def builtins, initialize them if the FE didn't

what we have for sync-builtins.def. I think this kind of comments are a great asset for people who are new to the file. Otherwise, the asan parts of the patch looks OK to me. Thanks. -- Dodji

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

Jason Merrill writes: > Oops, thought I had sent this before. No problem. Thank you for replying now× > On 11/17/2012 10:23 AM, Dodji Seketeli wrote: > > - if (cp_parser_parse_definitely (parser)) > > + /* Note that if we actually see the '=' token after

<    1   2   3   4   5   6   >