Re: Problem in cxx_fundamental_alignment_p?

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

Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)

> 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

Re: [PATCH 10/10] Compress short ranges into source_location

[...] > 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 > +

Re: [PATCH 5/5] Add plugin to recursively dump the source-ranges in a tree (v2)

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 >

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

[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

Re: [RFC PATCH] parse #pragma GCC diagnostic in libcpp

Manuel López-Ibáñez <lopeziba...@gmail.com> writes: > On 25 September 2015 at 17:14, Dodji Seketeli <do...@redhat.com> wrote: >> The caller of do_pragma(), which is destringize_and_run() then detects >> that pfile->directive_result.type is set, and then puts th

Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2)

Manuel López-Ibáñez <lopeziba...@gmail.com> a écrit: > On 25 September 2015 at 10:51, Dodji Seketeli <do...@seketeli.org> 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 MAINTAIN

Re: [PATCH 4/5] Implement tree expression tracking in C FE (v2)

David Malcolm <dmalc...@redhat.com> 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 >> >> [

Re: [RFC PATCH] parse #pragma GCC diagnostic in libcpp

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. > > *

Re: [PATCH 3/5] Implement token range tracking within libcpp and the C FE (v2)

David Malcolm <dmalc...@redhat.com> 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 locatio

Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2)

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

Re: PR pretty-print/67567 do not pass NULL as a string

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

Re: [PATCH 3/5] Implement token range tracking within libcpp and the C FE (v2)

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++

Re: [PATCH 4/5] Implement tree expression tracking in C FE (v2)

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

Re: [PATCH] Import liboffloadmic from upstream

Ilya Verbin <iver...@gmail.com> 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

Re: [PATCH] Import liboffloadmic from upstream

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)

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

Manuel López-Ibáñez lopeziba...@gmail.com writes: Index: ChangeLog === --- ChangeLog (revision 223445) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2015-05-20 Manuel López-Ibáñez m...@gcc.gnu.org + + *

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

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

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

Manuel López-Ibáñez lopeziba...@gmail.com 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

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

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

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

Hi! Marek Polacek pola...@redhat.com 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

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

Jason Merrill ja...@redhat.com 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

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

Hello Jakub, Jakub Jelinek ja...@redhat.com 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

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

Jakub Jelinek ja...@redhat.com 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 the top-most invocation

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

Jakub Jelinek ja...@redhat.com 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_context): Pass the location

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

to for trunk when stage 1 re-opens? Cheers, Signed-off-by: Dodji Seketeli do...@redhat.com --- 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

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

. (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-1.c: New test case. Signed-off-by: Dodji Seketeli do...@redhat.com --- gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c | 28

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

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

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

Ian Lance Taylor i...@golang.org writes: On Thu, Jan 22, 2015 at 12:35 PM, Jakub Jelinek ja...@redhat.com wrote: 2015-01-22 Jakub Jelinek ja...@redhat.com * diagnostic-core.h (internal_error_no_backtrace): New prototype. * diagnostic.def (DK_ICE_NOBT): New kind. *

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

Jakub Jelinek ja...@redhat.com 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

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

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

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

Tobias Burnus bur...@net-b.de writes: 2014-12-06 Tobias Burnus bur...@net-b.de Manuel L³pez-Ib¡±ez m...@gcc.gnu.org gcc/ * diagnostic.c (get_terminal_width): Renamed from getenv_columns, removed static, and additionally use ioctl to get width.

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

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 bur...@net-b.de writes: This patch fixes a Fortran diagnostic regression.

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

Hello Manuel, Manuel López-Ibáñez lopeziba...@gmail.com 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

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

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

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

Manuel López-Ibáñez lopeziba...@gmail.com 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: /*

Re: [PATCH linemap] Make some asserts fail gracefully

Manuel López-Ibáñez lopeziba...@gmail.com 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

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

Hello Manuel, Tobias, Manuel López-Ibáñez lopeziba...@gmail.com 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

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

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

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

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?

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

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

Re: [PATCH] Optimize ASAN_CHECK checks

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?

Re: [PATCH] Optimize ASAN_CHECK checks

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

Add more comments to some gimple property accessors

. 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

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

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

Re: [PATCH diagnostics] PR 53061 cleanup initialization

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

Re: C/C++ diagnostics guidelines

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

Re: C/C++ diagnostics guidelines

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

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

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

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

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

Re: [PATCH] cleanups in line-map

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

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

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

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

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.

Re: [RFC/PATCH] Fix-it hints

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

Re: [RFC/PATCH] More precise diagnostic locations: dynamic locations for columns vs explicit offset

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

Re: [PATCH diagnostics/Fortran] Implement Fortran prefix/caret style using the common diagnostics machinery

Hello Manuel, Manuel López-Ibáñez lopeziba...@gmail.com 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.

Re: [PATCH/PR c/59304] #pragma diagnostic pop after warning fails for options unspecified in the command-line and disabled by default

Hello Manuel, Manuel López-Ibáñez lopeziba...@gmail.com 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

Re: [PATCH] Move caret printing to diagnostics_finalizer

Manuel López-Ibáñez lopeziba...@gmail.com 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.

Re: [PATCH] Handle -fsanitize=leak more similarly to address/thread

Jakub Jelinek ja...@redhat.com 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

Re: [PATCH] Fix UB in diagnostic.c

Marek Polacek pola...@redhat.com 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

Re: [C PATCH] Diagnose predefined identifiers in pedantic mode

Marek Polacek pola...@redhat.com 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. */

Re: [C PATCH] Diagnose predefined identifiers in pedantic mode

Marek Polacek pola...@redhat.com 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

Re: [PATCH] PR preprocessor/61817 - Fix location of tokens in built-in macro expansion list

the expansion point locatoin to builtin_macro. gcc/testsuite/ * gcc.dg/cpp/builtin-macro-{0,1,2,3}.c: New test files. Signed-off-by: Dodji Seketeli do...@redhat.com --- gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c | 18 ++ gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c | 30

Re: [PATCH Fortran/Diagnostics] Move Fortran to common diagnostics machinery

Hello Manuel, Manuel López-Ibáñez lopeziba...@gmail.com writes: 2014-08-03 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 c-family/ * c-format.c: Handle Fortran flags. * diagnostic.c (build_message_string): Make it extern. * diagnostic.h (build_message_string):

Re: [PATCH 1/2] Support location tracking for built-in macro tokens

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

[PATCH] PR preprocessor/61817 - Fix location of tokens in built-in macro expansion list

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

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

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

[PATCH 1/2] Support location tracking for built-in macro tokens

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

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

/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

Re: [PATCH 1/2] Support location tracking for built-in macro tokens

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

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

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

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

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

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

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

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

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

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

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

Re: [PATCH, cpp] Fix line directive bug

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

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

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

Re: libsanitizer merge from upstream r208536

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

Re: libsanitizer merge from upstream r208536

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

Re: libsanitizer merge from upstream r208536

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):

Re: [PATCH] Fix -ftrack-macro-expansion preprocessing of A######A (PR preprocessor/58844)

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

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

. 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

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

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 *

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

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

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Markus Trippelsdorf mar...@trippelsdorf.de writes: On 2014.01.22 at 09:16 +0100, Dodji Seketeli wrote: Bernd Edlinger bernd.edlin...@hotmail.de writes: Hi, Hello, since there was no progress in the last 2 months on that matter, Sorry, this is my bad. I got sidetracked

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Jakub Jelinek ja...@redhat.com 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 for the inconvenience. I'd say

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Jakub Jelinek ja...@redhat.com 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)) +{ + fclose (fp); + return NULL

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

-by: Dodji Seketeli do...@seketeli.org --- gcc/Makefile.in| 3 +- gcc/diagnostic.c | 19 +- gcc/diagnostic.h | 1 + gcc/input.c| 633

Re: [PATCH] Allow building if libsanitizer on RHEL5 (i.e. with 2.6.18-ish kernel headers, take 2)

Jakub Jelinek ja...@redhat.com writes: Hi! Here is an updated version which doesn't warn about #include_next. Ok for trunk? 2013-12-10 Jakub Jelinek ja...@redhat.com * sanitizer_common/Makefile.am (AM_CPPFLAGS): Add -isystem $(top_srcdir)/include/system. *

Re: [PATCH] Use libbacktrace for libsanitizer symbolization (take 2, PR sanitizer/59136)

Jakub Jelinek ja...@redhat.com 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

Re: [PATCH] libsanitizer demangling using cp-demangle.c

Jakub Jelinek ja...@redhat.com a écrit: 2013-12-10 Jakub Jelinek ja...@redhat.com * sanitizer_common/sanitizer_symbolizer_libbacktrace.h (LibbacktraceSymbolizer::Demangle): New declaration. * sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc

Re: [PATCH] Put a breakpoint on __asan_report_error for ASAN

H.J. Lu hjl.to...@gmail.com a écrit: 2012-11-24 H.J. Lu hongjiu...@intel.com * 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

Re: [PATCH] Asan constructor init order checking

Hello, Jakub Jelinek ja...@redhat.com 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. */

Re: [PATCH] Asan constructor init order checking

Dodji Seketeli do...@redhat.com 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

Re: [PATCH] Asan constructor init order checking

Jakub Jelinek ja...@redhat.com writes: On Fri, Nov 22, 2013 at 04:38:58PM +0100, Dodji Seketeli wrote: Jakub Jelinek ja...@redhat.com writes: --- gcc/cgraph.h.jj2013-11-13 18:32:52.0 +0100 +++ gcc/cgraph.h 2013-11-15 12:05:25.950985500 +0100 @@ -520,6 +520,11 @@ class

Re: [PATCH] Support -fsanitize=leak

Jakub Jelinek ja...@redhat.com 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

Re: [patch] Fix ICEs when DEBUG_MANGLE is enabled

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?

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Jakub Jelinek ja...@redhat.com 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 (*line)[len - 1] == '\n' first before you decide

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Bernd Edlinger bernd.edlin...@hotmail.de 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

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Sorry, I missed one question in the previous email. Bernd Edlinger bernd.edlin...@hotmail.de 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

  1   2   3   4   5   6   >