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
> 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
|| 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
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
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
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
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
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 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
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
ge
+get_decl_source_range (tree decl)
+{
Likewise.
--
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
therwise, if we could do
away with duplicating the start location and still miminize the churn,
maybe we should try.
--
Dodji
u noticed
anythying related to that during bootstrap?
Cheers,
--
Dodji
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
(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
; + * diagnostic.c (diagnostic_print_caret_line): Fix off-by-one error
> + when printing the caret character.
> +
This is OK, thanks!
Cheers,
--
Dodji
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.
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
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
;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
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
* 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
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
>>
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
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
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
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-
* 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
-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
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
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
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
pp_warning_buffer->flush_p = false;
> + pp_error_buffer = new output_buffer ();
> + pp_error_buffer->flush_p = false;
> }
Cheers,
--
Dodji
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
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
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
anges and thank for your time and dedication.
Cheers,
--
Dodji
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
OK for trunk?
Yes. Thanks!
--
Dodji
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
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,
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
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
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
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
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
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
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
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
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
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
th ubsan_get_source_location_type () type.
> (asan_add_global): Provide global decl location info
> if possible.
This is OK, thanks.
--
Dodji
e:
linemap_position_for_line_and_column(map,
SOURCE_LINE(map, loc),
column)
instead of doing (loc + to_column) to get to the new location.
[...]
> + gcc_assert (map == linemap_lookup (set, r));
OK.
> + return r;
> +}
[...]
I hope this helps.
Cheers,
--
Dodji
replacement fix-it hints? For instance, from a
user (of the diagnostics primitives) code standpoint, would these be
done through additional functions like emit_deletion_fixit() and
emit_replacement_fixit() with possible different parameters? Or would
you rather add additional parameters to emit_fixing_hint() to support
that?
> +{
> + diagnostic_info diagnostic;
> + va_list ap;
> +
> + va_start (ap, msg);
> + diagnostic_set_info (&diagnostic, msg, &ap, location, DK_FIXIT);
> + if (!global_dc->show_caret)
> +{
> + report_diagnostic (&diagnostic);
> +}
Useless curly brackets here.
Thank you for looking into this.
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
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
> 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
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
fsanitize=leak.
This looks OK to me.
Thanks!
--
Dodji
l.
Oh, I see. Thanks.
Maybe a comment there would be helpful then :-)
Thanks.
--
Dodji
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
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/
*
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
builtin_macro_text): Honor the
cpp_reader::forced_token_location_p data member to force the value
__LINE__ expands to accordlingly.
(builtin_macro): Take the expansion point location as parameter.
Use cpp_force_token_locations() to set the location of the
resulti
Richard Biener writes:
> On Tue, Jul 15, 2014 at 3:27 PM, Dodji Seketeli 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.
>>
>&
as non-built-in tokens are expanded at the
> opening paren. This is weird.
Yes it is weird.
>From what I understood while looking at this, this is also a separate
issue that ought to be addressed in a separate patch with a separate
test case. I'll look at that.
Cheers.
--
Dodji
I forgot to say that ...
Dodji Seketeli 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,
> ef
/testsuite/ChangeLog:
* gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files.
Signed-off-by: Dodji Seketeli
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212194
138bc75d-0d04-0410-961f-82ee72b054a4
Signed-off-by: Dodji Seketeli
---
gcc/c-family/c-ppoutput.c | 81
definition.
* toplev.c (general_init): Tell libcpp what the pre-defined
spelling location for built-in tokens is.
Signed-off-by: Dodji Seketeli
---
gcc/input.c | 16
gcc/input.h | 1 +
gcc/toplev.c | 2 +-
libcpp
"3"
originates from a built-in macro.
> It seems to me that it doesn't really have its own location, and so
> we should be able to use whatever the current location is and not emit
> a line note.
The issue is that the location for "3" is not virtual, so there is not
much we can do about it.
But then I have just wrote the support for making that "3" token have a
virtual location. I am sending a small patchset as a follow-up to this
message.
Cheers.
--
Dodji
Jason Merrill 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
_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
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.
.
(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
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
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
If T has insufficient alignment,
> force same handling as for odd sizes.
>
> * c-c++-common/asan/misalign-1.c: New test.
> * c-c++-common/asan/misalign-2.c: New test.
>
> ok for trunk if it bootstraps/regtests?
Yes, this is OK for me.
Thanks.
--
Dodji
of two or larger than 16.
>> (instrument_derefs): Don't give up if size_in_bytes is not
>> power of two or is larger than 16.
>
> Both patches bootstrapped/regtested on x86_64-linux and i686-linux
> successfully, ok for trunk for both?
Yes, this is OK. Thanks.
--
Dodji
g++.dg/asan/asan_test_config.h: Likewise.
This is OK.
Thanks.
--
Dodji
/cpp/pr58844-1.c: New test.
> * c-c++-common/cpp/pr58844-2.c: New test.
Thanks.
--
Dodji
f --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
+
+ * c-c++-common/cpp/warning-zero-location-2.c: Fix error message
+ selector.
+
2014
Dodji Seketeli 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/testsuit
*/
+
+#define _GNU_SOURCE/* { dg-warning "redefined" } */
+
+/* { dg-message "" "#define _GNU_SOURCE" {target *-*-* } 0 }
--
Dodji
Jakub Jelinek writes:
> On Fri, Jan 24, 2014 at 04:40:52PM +0100, Dodji Seketeli wrote:
>> > The patch causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 .
>> > The follow-up patch (fp == NULL check) doesn't help.
>>
>> I am looking into that, sorry
Markus Trippelsdorf writes:
> On 2014.01.22 at 09:16 +0100, Dodji Seketeli wrote:
>> Bernd Edlinger writes:
>>
>> > Hi,
>>
>> Hello,
>>
>> > since there was no progress in the last 2 months on that matter,
>>
>> Sorry, this is
Jakub Jelinek writes:
> On Wed, Jan 22, 2014 at 09:16:02AM +0100, Dodji Seketeli wrote:
>> +static fcache*
>> +add_file_to_cache_tab (const char *file_path)
>> +{
>> +
>> + FILE *fp = fopen (file_path, "r");
>> + if (ferror (fp))
>&
e reach the size of the line.
* Makefile.in: Add vec.o to OBJS-libcommon
gcc/testsuite/ChangeLog:
* c-c++-common/cpp/warning-zero-in-literals-1.c: New test file.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204453
138bc75d-0d04-0410-961f-82ee72b054a4
Signed-off-by: Dodji Seketel
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
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
| provides a workaround in non-compiler-rt maintained files.
Let's get this in then :-)
Cheers.
--
Dodji
is is OK, if nobody objects in the next 48h.
Thanks.
--
Dodji
on x86_64-linux and i686-linux, ok for trunk?
Yes, this is OK with the incremental patch for the documentation.
Thanks.
--
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
>>
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
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
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 &
; S%s_ = ", to_base36 (i - 1));
if (TYPE_P (el) &&
(CP_TYPE_RESTRICT_P (el)
|| CP_TYPE_VOLATILE_P (el)
--
Dodji
ile, so that there is no buffer overflow
here.
--
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
1 - 100 of 595 matches
Mail list logo
