Hello Nicholas,
First of all, thank you for taking the time to dive into this code and
provide such a detailed analysis along with a patch. This is
appreciated.
Please find below my comments to some parts of your message.
Nicholas Ormrod nicholas.orm...@hotmail.com a écrit:
PR
Hello Nicholas,
Nicholas Ormrod nicholas.orm...@hotmail.com a écrit:
We currently have two possible approaches. I see the trade-offs between these
two solutions as follows:
Adding full line directives is not implemented, and will be more
complicated than my patch. It will require someone
.
(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 do...@redhat.com
---
gcc/c-family/c-ppoutput.c | 76 ++
gcc/testsuite/gcc.dg/cpp/syshdr4.c
Jason Merrill ja...@redhat.com 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. Let's emit a line change
Hello Nicholas,
Nicholas Ormrod nicholas.orm...@hotmail.com writes:
I found time this morning to run your changes through our system. I
patched our gcc-4.8.1 with your latest change, and ran it through our
folly testsuite.
Thanks!
One thing that I immediately noticed was that this
Jason Merrill ja...@redhat.com writes:
On 07/04/2014 05:13 AM, Dodji Seketeli wrote:
// preprocessed output
# 3 test.cpp 3 4
sys_token
# 3 test.cpp
3
# 3 test.cpp 3 4
sys_token
Yeah. For Built-in tokens that are expanded like that we only do track
their the location of their expansion
Hello,
Jason Merrill ja...@redhat.com writes:
// preprocessed output
# 3 test.cpp 3 4
sys_token
# 3 test.cpp
3
# 3 test.cpp 3 4
sys_token
Yeah. For Built-in tokens that are expanded like that we only do track
their the location of their expansion, not their spelling location. So
definition.
* toplev.c (general_init): Tell libcpp what the pre-defined
spelling location for built-in tokens is.
Signed-off-by: Dodji Seketeli do...@redhat.com
---
gcc/input.c | 16
gcc/input.h | 1 +
gcc/toplev.c | 2
/testsuite/ChangeLog:
* gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files.
Signed-off-by: Dodji Seketeli do...@redhat.com
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212194
138bc75d-0d04-0410-961f-82ee72b054a4
Signed-off-by: Dodji Seketeli do...@redhat.com
---
gcc/c-family/c-ppoutput.c
I forgot to say that ...
Dodji Seketeli do...@redhat.com writes:
[...]
When a built-in macro is expanded, the location of the token in the
epansion list is the location of the expansion point of the built-in
macro.
This patch creates a virtual location for that token instead,
effectively
Hello Nicholas,
Nicholas Ormrod nicholas.orm...@hotmail.com writes:
[...]
If you are also going to fix the locations of built-in tokens, it
would also be worth adjusting their expansion locations. As mentioned
in the bug report, built-in tokens are expanded at the closing paren
of a macro
Richard Biener richard.guent...@gmail.com writes:
On Tue, Jul 15, 2014 at 3:27 PM, Dodji Seketeli do...@redhat.com wrote:
Hello,
When a built-in macro is expanded, the location of the token in the
epansion list is the location of the expansion point of the built-in
macro.
This patch
the location of the
resulting token to that expansion point location.
(enter_macro_context): Pass the expansion point locatoin to
builtin_macro.
gcc/testsuite/
* gcc.dg/cpp/builtin-macro-{0,1}.c: New test files.
Signed-off-by: Dodji Seketeli do...@redhat.com
---
gcc
Joseph Myers jos...@codesourcery.com 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 person that
Jakub Jelinek ja...@redhat.com writes:
On Wed, Nov 12, 2014 at 02:09:59PM +0300, Yury Gribov wrote:
For asan you're right, we can have addresses of decls there etc.
If you have spare cycles, feel free to take over the patch and adjust it.
I guess I'd wait when this gets to trunk?
Jakub Jelinek ja...@redhat.com writes:
I am not sure, but I am wondering if we shouldn't save the previous uid
of 'stmt' here before setting it, and then restore it before getting out
of this function.
No, gimple uids are AFAIK undefined at the start of passes, passes that use
them are
.
Signed-off-by: Dodji Seketeli do...@redhat.com
---
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,7
Jeff Law l...@redhat.com 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
Jason Merrill ja...@redhat.com writes:
When I was fixing attribute deprecated for C++ templates, I found it
odd that the source location for the deprecated decl was embedded in
the warning rather than in a separate inform. This patch moves it
out.
Tested x86_64-pc-linux-gnu. OK for trunk?
Hello,
Jakub Jelinek ja...@redhat.com writes:
2014-09-24 Jakub Jelinek ja...@redhat.com
* ubsan.h (ubsan_get_source_location): New prototype.
* ubsan.c (ubsan_source_location_type): New variable.
Function renamed to ...
(ubsan_get_source_location_type): ... this.
Jason Merrill ja...@redhat.com writes:
On 10/06/2014 08:50 PM, Siva Chandra wrote:
On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill ja...@redhat.com wrote:
On 10/03/2014 05:41 PM, Siva Chandra wrote:
I understand that knowing whether a copy-ctor or a d-tor has been
explicitly defaulted is not
Manuel López-Ibáñez lopeziba...@gmail.com writes:
A few cleanups in line-map code. Bootstrapped and regression tested on
x86_64-linux-gnu.
Thanks for doing this.
OK?
Yes, barring this little nit:
[...]
Index: libcpp/line-map.c
Jakub Jelinek ja...@redhat.com writes:
[...]
Ok, tried to merge also g++.dg/asan from the same revision as you've merged
libsanitizer.
[...]
2014-05-22 Jakub Jelinek ja...@redhat.com
* g++.dg/asan/asan_test.C: Add -std=c++11 and
-DSANITIZER_USE_DEJAGNU_GTEST=1 to
Jakub Jelinek ja...@redhat.com writes:
On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
2014-05-22 Jakub Jelinek ja...@redhat.com
* sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
BUILT_IN_ASAN_REPORT_STORE_N): New.
* asan.c (struct asan_mem_ref): Change
Jakub Jelinek ja...@redhat.com writes:
[...]
Here is the GCC side of the thing,
[...]
2014-05-23 Jakub Jelinek ja...@redhat.com
* asan.c (report_error_func): Add SLOW_P argument, use
BUILT_IN_ASAN_*_N if set.
(build_check_stmt): Likewise.
(instrument_derefs):
Here is the patch I am committing right now.
gcc/ChangeLog
* input.c (location_get_source_line): Bail out on when line number
is zero, and test the return value of
lookup_or_add_file_to_cache_tab.
gcc/testsuite/ChangeLog
*
Dodji Seketeli do...@redhat.com writes:
Here is the patch I am committing right now.
gcc/ChangeLog
* input.c (location_get_source_line): Bail out on when line number
is zero, and test the return value of
lookup_or_add_file_to_cache_tab.
gcc/testsuite/ChangeLog
.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index a468447..2da 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-01-29 Dodji Seketeli do...@redhat.com
+
+ * c-c++-common/cpp/warning-zero-location-2.c: Fix error message
Jakub Jelinek ja...@redhat.com writes:
Hi!
The following testcase build with -ftrack-macro-expansion=0,
but don't build otherwise. The problem seems to be that
the libcpp for macro redefinition warning/error purposes if it sees
more than one paste operator adds those extra CPP_PASTE tokens
Hello Manuel,
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This is an old patch of mine that never got finished. I updated it following
the suggestions of Gabriel here
https://gcc.gnu.org/ml/gcc-patches/2012-04/msg00443.html
Thanks for looking at this again.
Bootstrapped and tested on
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 17 October 2014 19:33, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 17 Oct 2014, Manuel López-Ibáñez wrote:
Thus, I drafted some guidelines
at:https://gcc.gnu.org/wiki/Better_Diagnostics#guidelines
Please, could you take a look
Manuel López-Ibáñez lopeziba...@gmail.com writes:
On 17 October 2014 20:04, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 17 October 2014 19:33, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 17 Oct 2014, Manuel López-Ibáñez wrote:
Thus, I drafted some guidelines
Hello Manuel,
Manuel López-Ibáñez lopeziba...@gmail.com 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 m...@gcc.gnu.org
PR fortran/44054
* include/line-map.h
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 do...@redhat.com writes:
Hello Manuel,
Manuel López-Ibáñez
Hello Manuel,
Sorry for taking so long to reply to this.
FWIW, I like the direction of this. I find fix-it hints cool in
general. So thank you for working on this.
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
This patch implements fix-it hints. See https://gcc.gnu.org/PR62314
When
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
In some situations, we would like to point to a location which was not
encoded when tokenizing. This happens, for example, in two prominent
cases:
1) To get precise locations within strings
(https://gcc.gnu.org/PR52952) for example, for
Jakub Jelinek ja...@redhat.com writes:
Ok for trunk (the patch is on top of the tsan patch)?
2012-11-22 Jakub Jelinek ja...@redhat.com
* sanitizer.def: Add Address Sanitizer builtins.
Rename BUILT_IN_TSAN_READ_* to BUILT_IN_TSAN_READ* and
BUILT_IN_TSAN_WRITE_* to
Jason Merrill ja...@redhat.com 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
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli do...@redhat.com wrote:
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a010f1f..c39ef30 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15262,7 +15262,11
Jason Merrill ja...@redhat.com writes:
On 12/03/2012 08:27 AM, Dodji Seketeli wrote:
+ - HAS_EXPANSION_ARG_P: Set to TRUE iff at least one parameter
+ pack has got an argument that is an expansion.
The got is unnecessary, just has an argument is better.
Removed, thanks
Jakub Jelinek ja...@redhat.com writes:
2012-12-05 Jakub Jelinek ja...@redhat.com
* asan.c (instrument_derefs): Handle bitfield COMPONENT_REFs
accesses as reads/writes to their DECL_BIT_FIELD_REPRESENTATIVE.
After Richi's comments in this thread, I guess this is OK to me.
--
Jakub Jelinek ja...@redhat.com writes:
2012-12-05 Jakub Jelinek ja...@redhat.com
* asan.c (asan_init_shadow_ptr_types): Move earlier in the file.
Call initialize_sanitizer_builtins at the end.
(asan_pp_string): Use TREE_TYPE (shadow_ptr_types[0])
as character type
Jakub Jelinek ja...@redhat.com writes:
+++ gcc/asan.c2012-12-05 15:30:56.069890542 +0100
@@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
{
gimple call = gsi_stmt (*iter);
- gcc_assert (is_gimple_builtin_call (call));
+ gcc_checking_assert
Jakub Jelinek ja...@redhat.com writes:
On Mon, Dec 10, 2012 at 10:44:49PM +0100, Dodji Seketeli wrote:
Jakub Jelinek ja...@redhat.com writes:
+++ gcc/asan.c 2012-12-05 15:30:56.069890542 +0100
@@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
{
gimple call
Jakub Jelinek ja...@redhat.com writes:
* varasm.c (get_variable_section): Don't return lcomm_section
for asan_protect_global decls.
* asan.c (asan_protect_global): Only avoid public common variables.
Don't call get_variable_section here.
This is OK, thanks.
--
Jason Merrill ja...@redhat.com writes:
On 12/08/2012 05:12 PM, Dodji Seketeli wrote:
+ else if (arg_from_pack_level_to_prune || has_empty_arg)
+{
+ /* ... we just return a pack expansion which pattern is PATTERN
+ into which ARGS has been substituted
Jakub Jelinek ja...@redhat.com writes:
Actually, the problem was that libasan was linked in after libpthread.
Perhaps we need some driver hacks to make sure -lasan comes before -lpthread
when added automatically for -fsanitize=address (and similarly for -ltsan).
For now just tweaking
Jason Merrill ja...@redhat.com writes:
On 12/11/2012 10:55 AM, Dodji Seketeli wrote:
Oops, it seems I was too hasty in trying to do away with the
instantiation_yields_no_list_p parameter to
gen_elem_of_pack_expansion_instantiation.
I still think that the elem function should just deal
Jason Merrill ja...@redhat.com writes:
I'd also like to move the scan and PACK_EXPANSION_EXTRA_ARGS code back
out of the loop.
Like this?
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (argument_pack_element_is_expansion_p)
(make_argument_pack_select,
Jakub Jelinek ja...@redhat.com writes:
PR sanitizer/55508
* builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New.
* asan.c (ATTR_TMPURE_NOTHROW_LEAF_LIST,
ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): Define.
*
Hello,
Independently of this review, I think it's be interesting to hear
Kostya's voice on:
Jakub Jelinek ja...@redhat.com writes:
2) In large-func-test-1.C, I had to stop matching the backtrace after
_Znw[jm], because libasan is using the fast but inaccurate backtrace,
and while the tests
Ping?
---BeginMessage---
Jason Merrill ja...@redhat.com writes:
On 12/08/2012 05:12 PM, Dodji Seketeli wrote:
+ else if (arg_from_pack_level_to_prune || has_empty_arg)
+{
+ /* ... we just return a pack expansion which pattern is PATTERN
+ into which ARGS has been substituted
How about the below?
gcc/cp/
* pt.c (argument_pack_element_is_expansion_p)
(make_argument_pack_select, use_pack_expansion_extra_args_p)
(gen_elem_of_pack_expansion_instantiation): New static functions.
(has_bare_parameter_packs): Factorized out of ...
Hello,
In the example accompanying this patch, check_instantiated_arg tries
to ensure that a non-type template argument should be a constant if it
has integral or enumeration type.
The problem is that an alias template which type-id is, e.g, an
integer, looks like an argument that has
Gabriel Dos Reis g...@integrable-solutions.net writes:
The example is valid, but I am not sure I understand your
explanation...
Ah, sorry. I realize just now that I haven't mentioned the initial
erratic behaviour. Maybe that could have made my message easier to
understand.
So consider the
Gabriel Dos Reis g...@integrable-solutions.net writes:
Thank you very much for the explanation; your previous message
makes sense to me now.
You are welcome.
The question I have is why are we using TREE_TYPE of a TEMPLATE_DECL
to represent the current instantiation of a template alias?
My
Hello,
Consider this test case:
1 template const char *const C, typename T
2 struct A
3 {};
4
5 struct B {};
6
7 extern constexpr char HELLO_WORLD[] = hello world;
8
9 AHELLO_WORLD, B g; // -- This works fine
10
11 template typename T
Jason Merrill ja...@redhat.com writes:
On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
else if (TREE_TYPE (t)
INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
-!TREE_CONSTANT (t))
+!TREE_CONSTANT (t)
+ /* Class template and alias template arguments should
Gabriel Dos Reis g...@integrable-solutions.net writes:
G On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill ja...@redhat.com wrote:
On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
else if (TREE_TYPE (t)
INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
- !TREE_CONSTANT (t
Jason Merrill ja...@redhat.com writes:
On 12/22/2012 11:03 AM, Dodji Seketeli wrote:
[1]: The relacement of the VAR_DECL by its initializer is done by
decay_conversion by callig decl_constant_value_safe. That replacement
doesn't happen if processing_template_decl is not set. That's why
Jakub Jelinek ja...@redhat.com writes:
2012-12-21 Jakub Jelinek ja...@redhat.com
* varasm.c (output_constant_def_contents): For asan_protect_global
protected strings, adjust DECL_ALIGN if needed, before testing for
anchored symbols.
(place_block_symbol): Adjust
Jakub Jelinek ja...@redhat.com writes:
2012-12-19 Jakub Jelinek ja...@redhat.com
* c-c++-common/asan/null-deref-1.c: Add -fno-shrink-wrap to
dg-options.
This looks OK to me, thanks.
--
Dodji
Hello,
Consider the example of the problem report
1 template typename
2 constexpr bool the_truth () { return true; }
3
4 template bool
5struct Takes_bool { };
6
7 templatebool B
8using Alias = Takes_boolB;
9
10 templatetypename T
Jakub Jelinek ja...@redhat.com writes:
2012-12-19 Jakub Jelinek ja...@redhat.com
PR fortran/55341
* asan.c (asan_clear_shadow): New function.
(asan_emit_stack_protection): Use it.
This looks OK to me. Thanks.
--
Dodji
Jason Merrill ja...@redhat.com writes:
On 01/08/2013 08:58 AM, Dodji Seketeli wrote:
There, when we check the argument 'the_truthint()' to see if it
actually is a constant expression, in check_instantiated_arg, we fail
to recognize its constexpr-ness b/c we just look at its TREE_CONSTANT
Gabriel Dos Reis g...@integrable-solutions.net writes:
We already have various predicates to test for constant
expressions so I am uneasy to add yet another one.
I understand. I got lost in the number of existing predicates to test
for constant expressions, to the point that I thought
instantiate_alias_template on Alias
with the argument the_thruthint non folded. In that code patch, we
didn't even go through convert_template_argument like what I was saying.
More on this below.
Jason Merrill ja...@redhat.com writes:
On 01/09/2013 10:02 AM, Dodji Seketeli wrote:
As the argument
Thank you Dave for this documentation patch that looks OK to my casual
eyes. Let's CC the documentation maintainers.
Dave Johansen davejohan...@gmail.com a écrit:
Currently, the plugin documentation doesn't mention that it requires
gcc 4.5 or later. The patch to add this statement is attached
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli do...@redhat.com wrote:
But during the instantiation of the *members* of testint, we try to
instantiate Aliasthe_truthint, without coercing (and thus without
folding) the argument
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli do...@redhat.com wrote:
Also, I am not sure if this patch would be appropriate for commit, now
that we are in 'regression-only' mode. But seeing this alias-template
related thing
Jakub Jelinek ja...@redhat.com writes:
On Fri, Jan 11, 2013 at 11:41:34AM +0100, Dodji Seketeli wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli do...@redhat.com wrote:
Also, I am not sure if this patch would be appropriate
Jason Merrill ja...@redhat.com writes:
On 01/11/2013 05:38 AM, Dodji Seketeli wrote:
but when I read the code, it looks like this is not necessary. Am I
missing something? In any case, I haven't put that code in the new
coerce_innermost_template_parms. Is that OK?
I agree that it seems
Hello,
As the subject suggests, the little patch-set that follows this
message implements a basic optimization for the Address Sanitizer
pass: in the same basic block, it avoids instrumenting an access to a
memory region, if that same access has been instrumented before.
As we store instrumented
Hello,
The hash table type can handle creation and removal of entries with
malloc/free. This patchlet adds support for using new/delete. It's
useful for hash table entry types that have constructors (and/or
destructors), to prevent the user from having to type boilerplate code
to initialize
Hello,
Like what Address Sanitizer does in LLVM, this patch avoids instrumented
duplicated memory accesses in the same basic blocks.
The approach taken is very conservative, to keep the pass simple, for
a start.
A memory access is considered to be a triplet made of an expression
tree
Jakub Jelinek ja...@redhat.com writes:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-01-22 Jakub Jelinek ja...@redhat.com
PR sanitizer/55374
* gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
LIBASAN_EARLY_SPEC is defined.
index 1a8a822..8ae9343 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,9 @@
+2013-02-04 Dodji Seketeli do...@redhat.com
+
+ Add missing explicit instantiation for std::lower_bound template
+ * libstdc++-v3/src/c++11/hashtable_c++0x.cc (namespace std): Add
Jakub Jelinek ja...@redhat.com writes:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-02-05 Jakub Jelinek ja...@redhat.com
PR sanitizer/55374
* config/gnu-user.h (LIBTSAN_EARLY_SPEC): Define.
(STATIC_LIBTSAN_LIBS): Likewise.
* gcc.c
Paolo Carlini paolo.carl...@oracle.com writes:
Since commit r195676[1], it looks like
libstdc++-v3/src/c++11/hashtable_c++0x.cc is missing an explicit
instantiation for std::lower_bound. This leads to libstdc++.so having
the symbol for that (missing) instantiation be undefined, thus
Jakub Jelinek ja...@redhat.com writes:
On Tue, Feb 12, 2013 at 03:19:37PM +0100, Dodji Seketeli wrote:
gcc/
* Makefile.in (asan.o): Add new dependency on hash-table.h
* asan.c (struct asan_mem_ref, struct mem_ref_hasher): New types.
(asan_mem_ref_init, asan_mem_ref_get_end
Hello,
It appeared that in my previous patch, a stupid thinko can lead to a
crash when instrumenting some builtin functionsK. Fixed thus.
Tested against trunk on x86_64-unknown-linux-gnu, and a bootstrap is underway.
gcc/
* asan.c (instrument_builtin_call): Really put the length of
Jakub Jelinek ja...@redhat.com writes:
This is just a small improvement for Dodji's work. We can flush the hash
table with memory references known to be instrumented only at extended basic
block boundaries, no need to flush it at every bb (of course, for 4.9 we
want to do something better).
Hello,
This PR uncovers an issue my latest optimization patch on Address
Sanitizer introduced.
This is in the context of instrumenting an access to a memory region,
like in:
void
foo (char *a, char *b, int s)
{
__builtin_memmove (a, b, s);
}
In this case, asan has to
for this PR, and for bootstrapping the
patch on his fast iron on i686 and x86_64 for all languages.
--
Dodji
From b52987810a313657202fc7ecae6b503311146302 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Thu, 10 Mar 2011 14:10:05 +0100
Subject: [PATCH] PR c++/PR48035
Jakub Jelinek ja...@redhat.com writes:
http://gcc.gnu.org/wiki/HowToPrepareATestcase
recommends abort instead and it is existing practice too.
Sure. I am going to update my local copy of the patch and re-post. I
used return as I noticed it was working. I didn't realize the
abort/exit was
Tom Tromey tro...@redhat.com writes:
I would like to ask that it be considered for 4.6.
IIRC, if this patch does not go in 4.6, then we have to write some
special and ugly GDB code to work around the debuginfo generated by 4.6.
I would much prefer it if there was no need to write this code.
-to-member-function types
as well.
Tested on x86_64-unknown-linux-gnu against trunk.
I am proposing this for 4.7.
--
Dodji
From 36d971de3a01c83f8e23c4016262ea73357f6bd6 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Tue, 15 Mar 2011 16:50:30 +0100
Subject
Mark Mitchell m...@codesourcery.com writes:
And, in any case, if it's a regression it's OK with me.
Thanks. I have committed the patch back into 4.6.
--
Dodji
we compile with optimizations. I am not sure how right that
would be.
Tested on x86_64-unknown-linux-gnu against trunk.
--
Dodji
From dc3dea429f1471540867a0b7e694a60494062ac0 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Tue, 29 Mar 2011 16:56:20 +0200
87f97cc32bfac37264aa414c43d4ad47a9a35d72 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Tue, 29 Mar 2011 16:56:20 +0200
Subject: [PATCH] PR debug/47471 (set prologue_end in .debug_line)
gcc/
* dwarf2out.c (dwarf2out_source_line):
Avoid emitting redundant consecutive .loc asm
Hello,
While looking at something else, I noticed that preprocessing this
code snippet:
cat -n test.c
~=~
void foo (void)
{
int i1, j1, k1;
#define p parallel
#define P(x) private (x##1)
#define S(x) shared (x##1)
#define F(x) firstprivate (x##1)
#pragma omp p P(i) \
S(j) \
F(k)
;
}
~=~
Hello,
Sorry for getting back to this just now, and thank you very much for the
review. Please find below my reply to your comments.
Tom Tromey tro...@redhat.com writes:
Dodjiexpanded_location xloc;
Dodjiif (loc = BUILTINS_LOCATION)
Dodji -{
Dodji - xloc.file = loc ==
Hello,
Consider this short code snippet:
struct A
{
virtual void foo();
};
template typename T
void
bar(T x)
{
A b = *x;
b.foo();
}
When we look at b.foo() during the parsing (in
cp_parser_postfix_expression), 'b.foo()' is (rightfully)
committing this then.
--
Dodji
commit 9ff90e47bafaab67e0c41aa5341a2424726db8a8
Author: Dodji Seketeli do...@redhat.com
Date: Wed Apr 13 12:30:51 2011 +0200
PR c++/48574
gcc/cp/
* class.c (fixed_type_or_null): We cannot determine the dynamic
type
Hello,
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Fri, Dec 10, 2010 at 5:11 AM, Dodji Seketeli do...@redhat.com wrote:
This patch adds statistics about the memory consumption of line maps
to the output of -fmem-report. It has been useful in trying to reduce
the memory
Jason Merrill ja...@redhat.com writes:
My point was more that the name of the function is confusing;
Sorry about that.
if what you get back is another virtual location, that's not what I
would consider a def point.
For tokens that are not function-like macro arguments, I think the
Hello Romain,
Sorry for my late reply to this thread.
Romain Geissler romain.geiss...@st.com a écrit:
Just to be sure I understand, do you need to be notified about *uses* of
types and decls as well? If so, maybe a new kind of event should
probably be defined, because PLUGIN_FINISH_DECL and
Romain Geissler romain.geiss...@gmail.com a écrit:
I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
The followings does not currently trigger the PLUGIN_FINISH_DECL
(or not in all cases), but should them ?
- function parameters (in the function prototype)
- definition
Romain Geissler romain.geiss...@gmail.com a écrit:
The deprecated attribute was just an example. I may need to apply any type
attribute
when a new type is parsed, which is currently not possible with the current
C++
front-end.
So then it seems to me like you might need to emit an event
Jason Merrill ja...@redhat.com writes:
On 09/21/2011 02:32 PM, Dodji Seketeli wrote:
FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its
replacement. ha ha) to hint at the fact that it really has to do with
a token that is an /argument/ for a function-like macro.
I disagree
1 - 100 of 546 matches
Mail list logo
