Hello Bernd,
Bernd Schmidt writes:
> I came across what I think is a bug in cxx_fundamental_alignment_p.
>
> User alignments are specified in units of bytes. This is documented,
> and we can also see the following in handle_aligned_attribute, for the
> case when we have no args:
> align_expr =
> 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
[...]
> 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
> +
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
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
[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
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
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
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 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,
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
>
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
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
Ilya Verbin writes:
(...)
> abidiff: ../../src/abg-comparison.cc:10731: virtual void
> abigail::comparison::fn_parm_diff::report(std::ostream&, const string&)
> const: Assertion `get_type_diff() && get_type_diff()->to_be_reported()'
> failed.
> Aborted (core dumped)
Woops. can you send me t
Manuel López-Ibáñez writes:
> Index: ChangeLog
> ===
> --- ChangeLog (revision 223445)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,8 @@
> +2015-05-20 Manuel López-Ibáñez
> +
> + * diagnostic.c (diagnostic_print_caret_li
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.
Manuel López-Ibáñez writes:
> Thanks for the review. I followed all your suggestions. For the
> accessor functions, I was not sure what type you would prefer, so I
> implemented them as C++ methods and made use of 'private' to be sure
> they are the only way to access the locations array. If you
Hello Manuel,
Sorry for my late reply, and thank you very much for working on this.
I have looked at the patch and I like it!
I guess I just have some few lateral nits to pick.
> The Fortran FE allows diagnostics with two different locations.
> Depending on whether these locations are on the sa
Hi!
Marek Polacek writes:
> This patch stifles -Wlogical-op a bit: don't warn if either operand
> comes from a macro expansion. As the comment says, it doesn't fix the
> bug completely, but it's a simple improvement.
I cannot approve this patch, but for what it's worth, I like it and
would vot
Jason Merrill writes:
> On 03/20/2015 12:48 PM, Jakub Jelinek wrote:
>> On Fri, Mar 20, 2015 at 12:30:44PM -0400, Jason Merrill wrote:
>>> On 03/11/2015 03:10 PM, Jakub Jelinek wrote:
__has_{cpp_,}attribute builtin macros are effectively function-like macros
taking one argument (and the
Hello Jakub,
Jakub Jelinek writes:
> __has_{cpp_,}attribute builtin macros are effectively function-like macros
> taking one argument (and the ISO preprocessor expands macros in the argument
> which is IMHO desirable), but the traditional preprocessor has been crashing
> on them or reporting err
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-
Ian Lance Taylor writes:
> On Thu, Jan 22, 2015 at 12:35 PM, Jakub Jelinek wrote:
>>
>> 2015-01-22 Jakub Jelinek
>>
>> * diagnostic-core.h (internal_error_no_backtrace): New prototype.
>> * diagnostic.def (DK_ICE_NOBT): New kind.
>> * diagnostic.c (diagnostic_action_af
Jakub Jelinek writes:
> On Mon, Jan 05, 2015 at 10:40:37PM +0100, Jakub Jelinek wrote:
>> > Are there any doc updates that need to happen as a result of this patch?
>> > Patch itself is fine for the trunk, just want to make sure the doc side is
>> > good too.
>>
>> You're right, I'll add documen
Tobias Burnus writes:
> 2014-12-06 Tobias Burnus
> Manuel L³pez-Ib¡±ez
>
> gcc/
> * diagnostic.c (get_terminal_width): Renamed from getenv_columns,
> removed static, and additionally use ioctl to get width.
> (diagnostic_set_caret_max_width): Update call.
>
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
Hello Manuel,
Manuel López-Ibáñez writes:
> New version of the patch. Tobias noticed several problems with the
> previous version:
>
> * Due to the use of placement-new for the buffered output_buffers
> pp_warning_buffer and pp_error_buffer, the pretty-printer destructor
> may end up trying to f
Hello Tobias,
Thank you for this patch. I have a few comments about it below. Just
as a heads-up, I am asking questions to Manuel in there, as well as
referring to comments from FX's. Please read below.
Tobias Burnus writes:
> This patch fixes a Fortran diagnostic "regression".
>
> With the
Manuel López-Ibáñez writes:
> libcpp uses diagnostic->override_column to give a custom column number
> to diagnostics. This is taken into account when building the prefix,
> but it was missing when placing the caret.
>
> Before:
>
> /home/manuel/override_column.c:1:4: warning: "/*" within comment
Hello Manuel, Tobias,
Manuel López-Ibáñez writes:
> This patch actually does not touch linemap but I will appreciate
> Dodji's comments about the approach.
Thanks :-)
> The problem is that in case of long lines, the column hint of 120
> might be too small, thus we do not have enough locations
Manuel López-Ibáñez writes:
> +/* Assert that becomes a conditional expression when not checking.
For the sake of clarity towards newcomers, I'd say:
Assert that becomes a conditional expression when checking is
disabled at compilation time.
> + Use this for conditions that should n
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 buffered until ei
Jason Merrill 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?
Yes. Tha
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,
Jakub Jelinek 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 supposed to
Jakub Jelinek 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?
>
> Ok, in
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 person that understands that
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_position_for_loc_and_offset):
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
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
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:
> 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
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
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
Manuel López-Ibáñez 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 Wformat warnings.
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 a écrit:
> This patch implements fix-it hints. See https://gcc.gnu.org/PR62314
>
> When the caret line is ac
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 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
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
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
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:
> 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.
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
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/
*
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
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.
>>
>&
Hello Nicholas,
Nicholas Ormrod 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 call, whereas non-built-i
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
Hello,
Jason Merrill 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 expans
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
Hello Nicholas,
Nicholas Ormrod 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 increased the preprocessed
> si
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
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,
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:
>
>
Jakub Jelinek writes:
[...]
> Here is the GCC side of the thing,
[...]
> 2014-05-23 Jakub Jelinek
>
> * asan.c (report_error_func): Add SLOW_P argument, use
> BUILT_IN_ASAN_*_N if set.
> (build_check_stmt): Likewise.
> (instrument_derefs): If T has insufficient ali
Jakub Jelinek writes:
> On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
>> 2014-05-22 Jakub Jelinek
>>
>> * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
>> BUILT_IN_ASAN_REPORT_STORE_N): New.
>> * asan.c (struct asan_mem_ref): Change access_size type to
>> HO
Jakub Jelinek writes:
[...]
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> libsanitizer.
[...]
>
> 2014-05-22 Jakub Jelinek
>
> * g++.dg/asan/asan_test.C: Add -std=c++11 and
> -DSANITIZER_USE_DEJAGNU_GTEST=1 to dg-options, remove
> -DASAN_U
Jakub Jelinek 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 at the end
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
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
* c-c++-common/cpp/warning-zero-location.c
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
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
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 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
"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:
> 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
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
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
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 &
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?
-
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
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
1 - 100 of 582 matches
Mail list logo
