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.
Let's CC Vladimir on this easy one.
Cheers.
Jan-Benedict Glaw a écrit:
> On Fri, 2013-09-20 20:51:37 +0200, Jan-Benedict Glaw
> wrote:
>> Hi!
>>
>> With the VAX target, I see this warning:
>>
>> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
>> -fno-rtti -fasynchrono
Hello,
Consider this invalid example given in the PR, where T is not defined:
1 template
2 struct X {
3 using type = T;
4 };
g++ yields the confusing diagnostics:
test.cc:3:10: error: expected nested-name-specifier before 'type'
using type = T;
^
test.c
Jakub Jelinek a écrit:
> --- gcc/cp/call.c.jj 2012-09-27 12:45:49.0 +0200
> +++ gcc/cp/call.c 2012-10-01 17:53:17.594609236 +0200
> @@ -557,7 +557,10 @@ null_ptr_cst_p (tree t)
> {
>/* Core issue 903 says only literal 0 is a null pointer constant. */
>if (cxx_di
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
Hello Dominique,
domi...@lps.ens.fr (Dominique Dhumieres) writes:
> The following tests are failing (with -m32):
>
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
> FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess err
Hans-Peter Nilsson writes:
> This caused a build failure, see PR54860.
I am on it.
Sorry for the inconvenience.
--
Dodji
Jason Merrill writes:
> Let's move the alias template case from
> primary_template_instantiation_p into alias_template_specialization_p
> and call the latter from the former. And also call it from tsubst.
Like the below?
Note that I have changed the type of the argument of
alias_template_speci
Hello,
The three patches following this messages fix fallouts from my c++11
attributes patch that I committed earlier.
Here is their summary:
Disambiguate nested objc-message-expressions and c++11 attributes
Update g++.dg/cpp0x/gen-attrs-{8,36,37}.C as c++11 attributes to
types are ignor
Hello,
A couple of obj-c++ tests were failing[1] because the tokens '[[' can
either be the beginning of a c++11 attribute (that is itself at the
beginning of a statement), or the beginning of a nested
objc-message-expression. This patch resolves the ambiguity by
tentatively parsing the c++11 attr
Hello,
The current implementation of C++11 attributes forbids them from being
applied to a type unless the type is being declared. I forgot to
adjust g++.dg/cpp0x/gen-attrs-{8,36,37}.C that was being run only on
ia32.
Fixed thus, tested on i386-unknown-linux-gnu and
x86_64-unknown-linux-gnu agai
Hello,
On targets cris-elf, alpha and sparc (for instance) it can happen that
the attribute_tables variable is empty for fortran. So
register_scoped_attributes (called by init_attributes) won't call
register_scoped_attributes, so the hash table member of
scoped_attributes is not created.
Later w
domi...@lps.ens.fr (Dominique Dhumieres) a écrit:
> The following tests are failing (with -m32):
>
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
> FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
> FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors)
> FAIL: g++.
Hello Florian,
Let's CC Jason for this optimization patch.
Florian Weimer a écrit:
> If the size of the inner array elements is 1 and we do not need a
> cookie, we do not need to insert an overflow check. This applies to
> the relatively frequent new char[n] case.
I just have one question for
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))
>>
Hello,
While reading alias.c, it seemed to me that some comments could use
some cleanups.
OK for trunk?
Thanks.
gcc/
* alias.c: Cleanup comments.
---
gcc/alias.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/gcc/alias.c b/gcc/alias.c
Hello Manuel,
Let's CC Gaby on this one as well.
Manuel López-Ibáñez writes:
> The problem is that the macro unwinder code is changing the original
> diagnostic type and not restoring it, so the code detecting that we
> ICE fails to abort, which triggers another ICE, and so on. But there
> is n
The C++ bits look good to my casual non-maintainer eyes. Let's CC
Jason.
Thanks.
Jonathan Wakely a écrit:
> This adds a warning switch for the existing "returning address of
> local variable" warnings in the C and C++ FEs which are enabled by
> default but have no switch controlling them. Addi
Hello,
The three patches following up this message implement instrumenting
memory access builtins calls in AddressSanitizer, like what the llvm
implementation does.
The first two patches do some factorizing that is used by the third
one. I have split them up like this to ease the review and to e
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 change.
void
foo (
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 ()
{
char fo
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
strategy used by the l
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);
>> +
Jakub Jelinek writes:
>> For 'strlen', can the memory check be done at the end of the string
>> using the returned length?
>
> Guess strlen is commonly expanded inline, so it would be worthwhile to check
> the shadow memory after the call (well, we could check the first byte
> before the call and
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?
>> >
>
I am not a maintainer so the below are just some casual comments of
mine. I am deferring to the maintainers for a real review.
Manuel López-Ibáñez writes:
> gcc/
> * tree-diagnostic.c (maybe_unwind_expanded_macro_loc):
> Use diagnostic_attach_note.
> * diagnostic.c (diagnostic
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
Jakub Jelinek writes:
>> +instrument_derefs (iter, dest, location, is_store);
>
> BUILTIN_ATOMIC_LOAD* are just loads and so should clear is_store.
Done.
>
>> + if (len != NULL_TREE)
>> +{
>> + is_store = (dest != NULL_TREE);
>> +
>> + if (source0 != NULL_TREE)
>> +instru
Jakub Jelinek writes:
>> + location_t location = gimple_location (call);
>
> I'd call the var just loc, that is far more commonly used and shorter.
Done.
>
>> + /* If we initially had an instruction like:
>> +
>> + int n = strlen (str)
>> +
>> + we now want to instrument the access to
Hello,
In this PR, G++ embarrassingly fails to parse the simple alignas
expression below:
alignas(double) int f;
even though the simple-declaration production in Clause 7 suggests
otherwise.
Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
PR c++/54955
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);
Hello,
Consider this short example:
template
struct X { };
template
using Y = const X;
using Z = Y;
G++ crashes in lookup_class_template_1 while trying to build the alias
template instantiation Y.
I think this is indirectly due to the fact that lookup_class_template_1
Thank you Joshua for following up on this. Please find below some
comments of mine that mostly belong to the nitpicking department.
Joshua J Cogliati writes:
[...]
> A split out patch to make the floating conversions explicit is attached
> at the PR 53001 page, but is not included in this patc
Hello Joshua,
Joshua J Cogliati writes:
> I am not certain that c.opt was modified correctly.
I don't see any problem with the c.opt part. So unless another
maintainer says otherwise, I'd say this is OK.
> 1. warn_float_patch_and_new_testcase.diff
> This adds a new testcase and checks for flo
"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
Jakub Jelinek writes:
> On Thu, Oct 31, 2013 at 03:36:07PM +0100, Bernd Edlinger wrote:
>> if you want to read zero-chars, why don't you simply use fgetc,
>> optionally replacing '\0' with ' ' in read_line?
>
> Because it is too slow?
>
> getline(3) would be much better for this purpose, though o
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,
Bernd Edlinger writes:
> I see another "read_line" at gcov.c, which seems to be a copy.
>
> Maybe this should be changed too?
I have seen it as well.
I'd rather have the patch be reviewed and everthing, and only then
propose to share the implementation with the gcov module.
--
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
Bernd Edlinger writes:
> If you want to have at least a chance to survive something like:
>
>
> dd if=/dev/zero of=test.c bs=10240 count=1000
>
> gcc -Wall test.c
>
>
> Then you should change the implementation of read_line to
> _not_ returning something like 100GB of zeros.
I'd say that in
Sorry for my late reply on this.
I just have one very small nit for one ChangeLog entry, expressed
below. If nobody objects in the next 48 hours, I'd say this is OK to
commit with the nit fixed.
I am not seeing your name in the MAINTAINERS file. Have you filed
copyright assignment to the FSF an
"H.J. Lu" a écrit:
>> 2012-11-24 H.J. Lu
>>
>> * configure.ac: Append gdbasan.in to .gdbinit if CFLAGS contains
>> -fsanitize=address.
>> * configure: Regenerated.
>>
>> * gdbasan.in: New file.
This is OK, if nobody objects in the next 48h.
Thanks.
--
Jakub Jelinek writes:
> Hi!
>
> Here is an updated version which doesn't warn about #include_next.
> Ok for trunk?
>
> 2013-12-10 Jakub Jelinek
>
> * sanitizer_common/Makefile.am (AM_CPPFLAGS): Add
> -isystem $(top_srcdir)/include/system.
> * sanitizer_common/Makefile.in: Reg
Jakub Jelinek writes:
> This is a second attempt at libsanitizer symbolization using
> libbacktrace. The compiler-rt maintained bit have been
> already added by the recent merge from compiler-rt, so this
> patch is mostly configury/Makefile stuff. Rather than using
> libbacktrace.la built in li
Jakub Jelinek a écrit:
>
> 2013-12-10 Jakub Jelinek
>
> * sanitizer_common/sanitizer_symbolizer_libbacktrace.h
> (LibbacktraceSymbolizer::Demangle): New declaration.
> * sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc
> (POSIXSymbolizer::Demangle): Use libbacktr
Hello David,
I like this! Thank you very much for working on this.
I think this patch is in great shape, and once we agree on some of the
nits I have commented on below, I think it should go in. Oh, it also
needs the first patch (1/5, dejagnu first) to go in first, as this one
depends on it. I
Hello,
David Malcolm a écrit:
> This is an updated version of:
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00736.html
>
> Changes in V2 of the patch:
> * c_lex_with_flags: don't write through the range ptr if it's NULL
> * don't add any fields to the C++ frontend's cp_token for now
>
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
Hello,
Similarly to a comment I made on the previous patch of the series,
+++ b/libcpp/include/line-map.h
[...]
struct GTY(()) location_adhoc_data {
source_location locus;
+ source_range src_range;
void * GTY((skip)) data;
};
Could we just change the type of locus
Manuel López-Ibáñez writes:
> Currently, #pragma GCC diagnostic is handled entirely by the FE. This
> has several drawbacks:
>
> * PR c++/53431 - C++ preprocessor ignores #pragma GCC diagnostic: The
> C++ parser lexes (and preprocesses) before handling the pragmas.
>
> * PR 53920 - "gcc -E" does
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
[Note to libcpp, C, and Fortran maintainers: we still need your input :-)]
Hello,
David Malcolm writes:
[...]
> Here's the revised comment I put in the attached patch:
[...]
> + The class caches the lookup of the color codes for the above.
> +
> + The class also has responsibility for tr
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
David Malcolm a écrit:
> This patch adds a test plugin that recurses down an expression tree,
> printing diagnostics showing the ranges of each node in the tree.
>
> It corresponds to:
> [PATCH 15/22] Add plugin to recursively dump the source-ranges in a tree
> https://gcc.gnu.org/ml/gcc-pa
[...]
> diff --git a/libcpp/line-map.c b/libcpp/line-map.c
[...]
> +
> + /* Any ordinary locations ought to be "pure" at this point: no
> + compressed ranges. */
> + linemap_assert (locus < RESERVED_LOCATION_COUNT
> + || locus >= LINE_MAP_MAX_LOCATION_WITH_COLS
> +
> 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 am definitely to ge
Hello Manuel,
Manuel López-Ibáñez writes:
> 2014-08-03 Manuel López-Ibáñez
>
> PR fortran/44054
> c-family/
> * c-format.c: Handle Fortran flags.
> * diagnostic.c (build_message_string): Make it extern.
> * diagnostic.h (build_message_string): Make it extern.
Small nit; the d
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/
*
Marek Polacek a écrit:
> diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
> index 0b9d6f6..e3bfd46 100644
> --- gcc/testsuite/gcc.dg/concat.c
> +++ gcc/testsuite/gcc.dg/concat.c
> @@ -1,6 +1,7 @@
> /* Copyright (C) 2001 Free Software Foundation, Inc. */
>
> /* { dg-do
Marek Polacek a écrit:
> Thise testcases use predefined identifiers, and without the
> dg-options, they would compile with -ansi -pedantic-errors and fail.
> Setting dg-options to "" makes the -ansi -pedantic-errors go away.
> Setting it to e.g. -std=gnu99 would work as well.
Oh, I see. Thanks.
Jakub Jelinek writes:
> Right now when -fsanitize=leak adds -llsan, it adds it late on the command
> line, so e.g. -lstdc++ comes after it, which seems to be bad.
> The following patch puts it early on the link command line like we do for
> -lasan or -ltsan. Bootstrapped/regtested on x86_64-lin
Marek Polacek a écrit:
> On Wed, Aug 13, 2014 at 09:03:37PM +0200, Manuel López-Ibáñez wrote:
>> I don't think this is the right fix. The problem is that we are trying
>> to print the caret in a column that is larger than the line_width. We
>> do this because the file given by the line directive
Manuel López-Ibáñez writes:
> This patch is in preparation for further patches moving the Fortran FE
> to use the common diagnostics machinery.
>
> Fortran has its own way of printing the caret information, so we need
> a way to override the default in the diagnostics machinery. A simple
> way is
Hello Manuel,
Manuel López-Ibáñez writes:
> Hi,
>
> This patch is relative to this one here:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01652.html
>
> It implements the Fortran style of prefix and caret line in the
> gfc_diagnostic_starter by using the common pretty-printer.
>
> This requir
Hello Manuel,
Manuel López-Ibáñez writes:
> The idea is that when we see a change of classification, and the
> option was originally unspecified, we record the command-line status.
> This way, when doing pop later, we already check if the option was
> reclassified so we get the command-line stat
Hello,
It appeared that gcov.c and input.c both have a static function named
read_line. I guess we ought to keep just one.
So I changed the one in input.c as it handles lines with bytes of zero
value (as of the work on PR preprocessor/58580) to make it suitable for
what the uses of read_line in
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
Hello,
As it appeared that concerns about the speed of
location_get_source_line were as present as the need of just fixing
this bug, I have conflated the two concerns in a new attempt below,
trying to address the points you guys have raised during the previous
reviews.
The patch below introduces
Hello,
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 -O0 output pattern test, is
=
==21832==ERROR: AddressSanitizer: stack-buffer-overf
Jakub Jelinek writes:
>> -OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o
>> input.o version.o
>> +OBJS-libcommon = diagnostic.o diagnostic-color.o pretty-print.o intl.o
>> vec.o input.o version.o
>
> Too long line?
Fixed in my local copy of the patch, thanks.
>
>> +
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 -
Hello,
Below is the updated patch amended to take your previous comments in
account.
In add_file_to_cache_tab the evicted cache array entry is the one that
was less used.
Incidentally I also fixed some thinkos and issued that I have seen in
the previous patch.
Bootstrapped on x86_64-unknown-lin
Bernd Edlinger writes:
>> + memmove (*line, l, len);
>> + (*line)[len - 1] = '\0';
>> + *line_len = --len;
>
> Generally, I would prefer to use memcpy,
> if it is clear that the memory does not overlap.
I don't mind. I'll change that in my local copy. Thanks.
> You copy one char too much and
Bernd Edlinger writes:
>>> 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"?
>>
>
> I meant the operator -- in *line_len = --len;
Sorry, I don't see how that is an issu
Sorry, I missed one question in the previous email.
Bernd Edlinger writes:
> and what is it if there is no terminal '\n' ?
In that case it's that the entire file is made of one line. For that
case get_next_line has allocated enough space for one
byte-passed-the-end of the file, so that there i
I guess we should CC Jason for this ...
ccout...@google.com (Cary Coutant) a écrit:
This patch fixes a few ICEs I encountered when enabling DEBUG_MANGLE.
I've also changed dump_substitution_candidates to output the substitution
index in base 36, to match the actual mangled name.
OK for trunk?
-
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 &
Hello,
Jakub Jelinek writes:
> --- gcc/cgraph.h.jj 2013-11-13 18:32:52.0 +0100
> +++ gcc/cgraph.h 2013-11-15 12:05:25.950985500 +0100
> @@ -520,6 +520,11 @@ class GTY((tag ("SYMTAB_VARIABLE"))) var
> public:
>/* Set when variable is scheduled to be assembled. */
>unsigne
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
>>
Jakub Jelinek writes:
> This patch adds support for -fsanitize=leak and -static-liblsan options.
> If combined with -fsanitize=address, it does nothing,
>From this hunk:
@@ -8123,7 +8133,10 @@ sanitize_spec_function (int argc, const
return (flag_sanitize & SANITIZE_THREAD) ? "" : N
Hello,
Jakub Jelinek writes:
> 2014-09-24 Jakub Jelinek
>
> * 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. Cache
> return value
Jason Merrill writes:
> On 10/06/2014 08:50 PM, Siva Chandra wrote:
>> On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill 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 sufficient to
Manuel López-Ibáñez 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
> ===
> --- lib
Hello Manuel,
Manuel López-Ibáñez 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 x86_64-linux-gnu.
Manuel López-Ibáñez writes:
> On 17 October 2014 19:33, Joseph S. Myers 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 and comment whether I got i
Manuel López-Ibáñez writes:
> On 17 October 2014 20:04, Manuel López-Ibáñez wrote:
>> On 17 October 2014 19:33, Joseph S. Myers 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
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_position_for_loc_and_offset):
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 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 a écrit:
> PR preprocessor/60723
>
> Description:
>
>
Hello Nicholas,
Nicholas Ormrod 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 else to implement
> it,
.
(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
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.
1 - 100 of 582 matches
Mail list logo
