Re: Rust frontend patches v1

Dear Philip, Another thing to pay attention to is the move to Sphinx for documentation: https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html Best, Manuel. On Wed, 10 Aug 2022 at 20:57, Philip Herron wrote: > Hi everyone > > For my v2 of the patches, I've been spending a lot of time

Re: [PATCH 2/2] Documentation hyperlinks for [-Wname-of-option] (PR 87488)

Hi David, While I agree that this is quite cool to have, the following: +/* DOCUMENTATION_ROOT_URL should be supplied via -D by the Makefile + (see --with-documentation-root-url). + + Expect an anchor of the form "index-Wfoo" e.g. + , and thus an id within + the URL

Re: [PATCH] ux.texi: move "Quoting" and "Fix-it hints" from DiagnosticsGuidelines wiki page

On Wed, 24 Oct 2018, 17:39 David Malcolm, wrote: > Manu: are you wiki user "ManuelLopezIbanez", and are you happy to have > any/all of your gcc wiki edits copied into gcc itself, covered under > the usual FSF copyright assignment? > I'm wiki user "ManuelLopezIbanez". I believe nothing I have

Re: [PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

On 07/10/18 23:38, Martin Sebor wrote: + pretty_printer posval; + if (pos != error_mark_node) +{ + /* Only format the position value when it's valid. By convention +do not quote constant integers. */ + pp_space (); + if (TREE_CODE (pos) != INTEGER_CST) +

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On 17/08/18 17:50, Andreas Schwab wrote: On Aug 17 2018, Manuel López-Ibáñez wrote: However, I see that GCC trunk still counts tabs as 1-column, probably because emacs counts tabs as one column when interpreting column numbers in the output of GCC. That is not true. Emacs is using screen

Re: [committed] diagnostics: add line numbers to source (PR other/84889)

On 09/08/18 21:09, David Malcolm wrote: It turns out that we convert tab characters to *single* space characters when printing source code. This behavior has been present since Manu first implemented -fdiagnostics-show-caret in r186305 (aka 5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985),

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

On 14 Feb 2018 8:16 pm, "Pedro Alves" wrote: Instead of a class that has to have a constructor for every type you want to pass as plural selector to the _n functions, which increases coupling, I'd suggest using a conversion function, and overload that. I.e., something like,

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

On 13 Feb 2018 5:58 pm, "Martin Sebor" wrote: I wanted to make the _n() functions like warning_n() more robust by letting them accept a tree argument (as well as offset_int and wide_int) in addition to HOST_WIDE_INT but I can't do it if they can't work with these types.

Re: [PATCH] adjust warning_n() to take uhwi (PR 84207)

On 13/02/18 03:10, Martin Sebor wrote: PS Is there any reason why diagnostic-core.h and diagnostic.c does not/should not include tree.h and other GCC headers? The short reason is that we want to keep the core diagnostics as independent of the rest of the compiler as possible so that using it

Re: [PATCH][mingw] Enable colorized diagnostics

On 10 Oct 2017 2:34 am, "Liu Hao" wrote: Since on *nix it is not when `colorize_start()` is called that the terminal color is changed (it is when those ANSI escape codes are delivered to the other peer which will translate them), and the string passed to `fputs()` is free to

Re: [PATCH][mingw] Enable colorized diagnostics

On 09/10/17 23:25, Manuel López-Ibáñez wrote: Even if the host-specific part is not done, I honestly think it is a good idea to match grep's code as much as possible since we may want to merge bugfixes between the two and eventually this code may end up in gnulib. Moreover, if somebody else

Re: [PATCH][mingw] Enable colorized diagnostics

On 08/10/17 12:39, Liu Hao wrote: On 2017/9/28 4:09, Joseph Myers wrote: On Thu, 28 Sep 2017, Liu Hao wrote: Colorized diagnostics used to be disabled for MinGW targets (on which the macro `_WIN32` is defined), and this patch enables it. I'd hope this is all to do with MinGW host, and

replace libiberty with gnulib (was: Re: [PATCH 0/2] add unique_ptr class)

On 05/09/17 18:40, Pedro Alves wrote: On 09/05/2017 05:52 PM, Manuel López-Ibáñez wrote: Yeah, ISTR it was close, though there were a couple things that needed addressing still. The wiki seems to miss a pointer to following iterations/review of that patch (mailing list archives don't cross

Re: [PATCH 0/2] add unique_ptr class

On 05/08/17 20:05, Pedro Alves wrote: That'd be an "obvious" choice, and I'm not terribly against it, though I wonder whether it'd be taking over a name that has a wider scope than intended? I.e., GNU is a larger set of projects than the GNU toolchain. For example, there's Gnulib, which

Re: [PATCH 1/2] C++ template type diff printing

On 08/05/17 17:51, David Malcolm wrote: So I think it can work if we add a "needs quoting" flag to the postprocessing phase, if we need to handle the case where %H and %I ever appear without 'q' (and have the delayed handling stash that flag, and do the quoting there). I'll look at implementing

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

On 11/09/16 14:02, Mark Wielaard wrote: -Wshadow-local which warns if a local variable shadows another local variable or parameter, -Wshadow-compatible-local which warns if a local variable shadows another local variable or parameter whose type is compatible with that of the shadowing

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On 05/09/16 20:42, Manuel López-Ibáñez wrote: On 05/09/16 18:25, Jakub Jelinek wrote: Hi! While most of the i386.opt -m= options have enum args and thus cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also -mrecip=) don't use that, with the CPU strings being

Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On 05/09/16 18:25, Jakub Jelinek wrote: Hi! While most of the i386.opt -m= options have enum args and thus cmdline_handle_error handles those, -march=/-mtune=/-m*-strategy= (and also -mrecip=) don't use that, with the CPU strings being maintained inside of a function rather than in some

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 3 September 2016 at 02:11, Eric Gallager <eg...@gwmail.gwu.edu> wrote: > On 9/2/16, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: >> On 3 Sep 2016 12:56 a.m., "Eric Gallager" <eg...@gwmail.gwu.edu> wrote: >>> I tried that but it doesn't look l

Re: [PATCH] Move class substring_loc from c-family into gcc

On 02/09/16 23:55, Martin Sebor wrote: diff --git a/gcc/substring-locations.h b/gcc/substring-locations.h index f839c74..bb0de4f 100644 --- a/gcc/substring-locations.h +++ b/gcc/substring-locations.h @@ -20,6 +20,73 @@ along with GCC; see the file COPYING3. If not see #ifndef

Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

On 02/09/16 20:27, Segher Boessenkool wrote: On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote: ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*, unsigned int)’: ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized in this function

Re: PR35503 - warn for restrict pointer

On 02/09/16 18:44, David Malcolm wrote: Much better would be to have the formatting be done inside the diagnostics subsystem's call into pp_format, with something like this: warning_at_rich_loc_n (, OPT_Wrestrict, arg_positions .length (),

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

>> --Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral @gol >> +-Wno-format-contains-nul -Wno-format-extra-args -Wformat-length=1 @gol >> >> Most options that take levels are documented as: >> >> -Wshift-overflow -Wshift-overflow=@var{n} >> -Wstrict-overflow

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

On 24/08/16 14:56, Richard Biener wrote: You never typoed gcc t.c -o t.c ? ;) (I did ... :/) With GCC >=5 $ gcc t.c -o t.c gcc: fatal error: input file ‘t.c’ is the same as output file compilation terminated. You are welcome ;-) Manuel.

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 23 August 2016 at 22:56, Martin Sebor wrote: > Attached is the latest patch. Some suggestions: --Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral @gol +-Wno-format-contains-nul -Wno-format-extra-args -Wformat-length=1 @gol Most options that take levels

Re: [PATCH/BUILD] [GSOC] [REPLACING LIBIBERTY WITH GNULIB]

On 22 August 2016 at 17:34, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > On 22 August 2016 at 17:27, ayush goel <ayushgoel1...@gmail.com> wrote: >> Links to the patches containing the work: >> >> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.htm

Re: [PATCH/BUILD] [GSOC] [REPLACING LIBIBERTY WITH GNULIB]

On 22 August 2016 at 17:27, ayush goel wrote: > Links to the patches containing the work: > > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html Actually, the above version is outdated and it should not be reviewed. The latest version of this patch, is this one:

Re: C++11? (Re: protected alloca class for malloc fallback)

On 22/08/16 13:02, Eric Gallager wrote: As a rookie programmer considering possibly contributing to GCC in the future once I'm more confident in my abilities, switching to C++11 would increase the barrier for me to contribute. I currently really only know C, and I still have to learn C++ in

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 20 August 2016 at 11:22, ayush goel wrote: >> >> We're talking about a one-line change, but this is absolutely >> crucial and central to use of gnulib. Until this is correct, >> any previous host-specific testing is invalid, unfortunately. >> >> In the previous

Re: Implement -Wimplicit-fallthrough (take 3)

On 18/08/16 18:07, David Malcolm wrote: This isn't quite the way that fix-its are meant to be used, in my mind, at least: the insertion text is supposed to be something that could be literally inserted into the code (e.g. by an IDE) i.e. it should be a code fragment, rather than a message to

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 15 August 2016 at 13:50, ayush goel wrote: > Included gnulib’s config.h header file inside gcc’s config.h itself as > per the discussions. > > Built and tested the system. You need to mention how you build it (languages, bootstrap, etc.) and how you tested it

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10 August 2016 at 15:44, Paolo Bonzini <bonz...@gnu.org> wrote: > > > On 10/08/2016 16:42, Manuel López-Ibáñez wrote: >> > > My only fear is that people not using -Wpedantic nor -pedantic-errors >> > > expect that GNU extensions work. This is a GNU

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10 August 2016 at 13:06, Paolo Bonzini <bonz...@gnu.org> wrote: > > > On 10/08/2016 13:31, Manuel López-Ibáñez wrote: >> My only fear is that people not using -Wpedantic nor -pedantic-errors >> expect that GNU extensions work. This is a GNU extension that defines >

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 10 August 2016 at 14:40, ayush goel wrote: > On 9 August 2016 at 2:20:59 PM, Pedro Alves (pal...@redhat.com) wrote: >> the scheme of configuring gnulib in a separate directory as borrowed from gdb >> requires including two config.h headers -- the gnulib client's, and

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10 August 2016 at 11:06, Paolo Bonzini wrote: > While I disagree with their inclusion of the warning to -Wall, I think > it is a good addition overall. First, it is a logical extension of the > existing warning for breaking defined across a macro and its caller. > Second, it

Re: [PATCH] cpp/c: Add -Wexpansion-to-defined

On 9 August 2016 at 22:21, Paolo Bonzini <bonz...@gnu.org> wrote: > > > On 09/08/2016 20:30, Manuel López-Ibáñez wrote: >>> >>> >>> + cpp_opts->warn_expansion_to_defined = cpp_warn_expansion_to_defined; >>> + if (cpp_warn_expansion_to

Re: [PATCH] cpp/c: Add -Wexpansion-to-defined

On 09/08/16 16:59, Paolo Bonzini wrote: Index: gcc/c-family/c-opts.c === --- gcc/c-family/c-opts.c (revision 239276) +++ gcc/c-family/c-opts.c (working copy) @@ -1256,6 +1256,10 @@ sanitize_cpp_opts (void)

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 29 July 2016 at 17:55, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > On 29 July 2016 at 17:51, Joseph Myers <jos...@codesourcery.com> wrote: >> On Wed, 20 Jul 2016, Manuel López-Ibáñez wrote: >> >>> On 20 July 2016 at 19:21, ayush goel <ay

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 31 July 2016 at 23:39, Joseph Myers <jos...@codesourcery.com> wrote: > On Sat, 30 Jul 2016, Manuel López-Ibáñez wrote: > >> > Building for different targets is fairly irrelevant here; the issue is >> > building for different hosts, which is harder. >> >&g

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On 29 July 2016 at 18:27, David Malcolm <dmalc...@redhat.com> wrote: > On Fri, 2016-07-29 at 17:53 +0100, Manuel López-Ibáñez wrote: >> On 29 July 2016 at 16:25, David Malcolm <dmalc...@redhat.com> wrote: >> > >> > FWIW, it appears that clang uses th

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 29 July 2016 at 23:10, Joseph Myers wrote: > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> >> GCC can run on other systems besides OSX and GNU/Linux, how can you >> >> test that your change does not break anything on those systems? >> >> >> > Well I have access

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 29 July 2016 at 17:51, Joseph Myers <jos...@codesourcery.com> wrote: > On Wed, 20 Jul 2016, Manuel López-Ibáñez wrote: > >> On 20 July 2016 at 19:21, ayush goel <ayushgoel1...@gmail.com> wrote: >> > Hey, >> > As a first step of my G

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On 29 July 2016 at 16:25, David Malcolm wrote: > > FWIW, it appears that clang uses the on-demand approach; the relevant > code appears to be StringLiteral::getLocationOfByte: > http://clang.llvm.org/doxygen/Expr_8cpp_source.html#l01008 As far as I know, llvm doesn't do

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On 27 July 2016 at 15:30, David Malcolm wrote: >> Perhaps it could live for now in c-format.c, since it is the only >> place using it? > > Martin Sebor [CC-ed] wants to use it from the middle-end: > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html > so it's unclear

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On 26/07/16 18:11, David Malcolm wrote: gcc/ChangeLog: * gcc.c (cpp_options): Rename string to... (cpp_options_): ...this, to avoid clashing with struct in cpplib.h. It seems to me that you need this because now gcc.c includes cpplib.h via input.h, which seems wrong.

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 26 July 2016 at 14:51, ayush goel <ayushgoel1...@gmail.com> wrote: > On 26 July 2016 at 3:38:59 AM, Manuel López-Ibáñez > (lopeziba...@gmail.com) wrote: >> Why the change from "fnmatch.h" to ? > > Gnulib doesn’t contain a header for fnmatch. It itself relie

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 25 July 2016 at 18:18, ayush goel wrote: > On top of the previously filed patch for importing gnulib (the link > isn’t available on the archive yet, however this contains some of the > information: >

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 20 July 2016 at 19:21, ayush goel wrote: > Hey, > As a first step of my GSOC project > (https://gcc.gnu.org/wiki/replacelibibertywithgnulib) I have imported > the gnulib library inside the gcc tree. I have created gnulib as a top > level directory which contains the

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On 19 July 2016 at 18:47, Jeff Law <l...@redhat.com> wrote: > On 07/17/2016 09:52 AM, Manuel López-Ibáñez wrote: >> >> + if (is_vla) >> +gcc_assert (warn_vla_limit > 0); >> + if (!is_vla) >> +gcc_assert (warn_alloca_limit > 0); >> &

Re: Importing gnulib into the gcc tree

On 16 July 2016 at 10:54, ayush goel wrote: > Hi, > Thanks for the feedbacks. > > —> I’m already configuring gcc with multiple languages and multilib enabled > > —> The changes have been bootstrapped and regression tested (complete check, > make -k -j20 check). > > —> As

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On 15/07/16 18:05, Aldy Hernandez wrote: +case OPT_Walloca_larger_than_: + if (!value) + inform (loc, "-Walloca-larger-than=0 is meaningless"); + break; + +case OPT_Wvla_larger_than_: + if (!value) + inform (loc, "-Wvla-larger-than=0 is meaningless"); +

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On 17/07/16 15:43, Patrick Palka wrote: On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote: You repeatedly are making bad assumptions and assertions without having studied much about GCC. You assume that GNU ar is the only archiver in use. You propose removing

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 01/07/16 19:15, Martin Sebor wrote: + /* Differentiate between an exact and inexact buffer overflow +or truncation. */ + const char *fmtstr; + if (res->number_chars < 0) + fmtstr = info->bounded + ? "output may

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 12/07/16 16:59, Martin Sebor wrote: You're probably right. I suspect I have a tendency to overuse the quotes (e.g, the -Wplacement-new warning also quotes the sizes). If there aren't yet (I vague recall coming across something on the GCC Wiki but can't find it now), it would be helpful to

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On 11 July 2016 at 11:10, Aldy Hernandez <al...@redhat.com> wrote: > On 07/10/2016 07:41 PM, Manuel López-Ibáñez wrote: >>> >>> +Walloca >>> +LangEnabledBy(C ObjC C++ ObjC++) >>> +; in common.opt >>> + >>> +Walloca= >>> +

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

+Walloca +LangEnabledBy(C ObjC C++ ObjC++) +; in common.opt + +Walloca= +LangEnabledBy(C ObjC C++ ObjC++) +; in common.opt + I'm not sure what you think the above means, but this is an invalid use of LangEnabledBy(). (It would be nice if the .awk scripts were able to catch it and give an

Re: Importing gnulib into the gcc tree

On 10 July 2016 at 17:04, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > Hi Ayush, > > Some suggestions: Also, it may be a good idea to configure with: --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --enable-multilib so that you get as much coverage as po

Re: Importing gnulib into the gcc tree

libiberty library in the > list now. Bootstrapped the system with the changes as well. > > PFA the updated patch > > -- > Thanks, > Ayush Goel > > On 8 July 2016 at 2:29:04 AM, Manuel López-Ibáñez (lopeziba...@gmail.com) > wrote: >> On 7 July 2016 at 13:48, ayus

Re: Importing gnulib into the gcc tree

On 7 July 2016 at 13:48, ayush goel wrote: > In order to show the setup works, I’ve replaced libiberty’s version by > obstack by gnulib’s. This was made possible by replacing the corresponding > header file and then including gnulib headers and gnulib static library in

Re: [PATCH 2/2] C++ FE: handle misspelled identifiers and typenames

On 30/06/16 19:53, David Malcolm wrote: This is a port of the C frontend's r237714 [1] to the C++ frontend: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01052.html offering spelling suggestions for misspelled identifiers, macro names, and some keywords (e.g. "singed" vs "signed" aka PR

Re: [PATCH] PR driver/69265: add hint for options with misspelled arguments

On 10/05/16 22:03, David Malcolm wrote: On Tue, 2016-05-10@22:09 +0200, Bernhard Reutner-Fischer wrote: On Mon, May 09, 2016@08:14:47PM -0400, David Malcolm wrote: - inform (loc, "valid arguments to %qs are: %s", option ->opt_text, s); + const char *hint = find_closest_string (arg,

Re: [PATCH, cpp] Fix pr61817 and 69391

On 05/04/16 17:22, Richard Henderson wrote: These two related PRs are all about remembering where a macro is expanded. Worse, we've got two competing goals -- the real location of the expansion, for __LINE__, and the virtual location of the expansion, for diagnostics. There seems to be no way

Re: C++ PATCH for c++/70449 (ICE when printing a filename of unknown location)

On 30 March 2016 at 23:42, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > On 30/03/16 17:14, Marek Polacek wrote: >> >> This test ICEs since the addition of the assert in pp_string which ensures >> that >> we aren't trying to print an empty stri

Re: C++ PATCH for c++/70449 (ICE when printing a filename of unknown location)

On 30/03/16 17:14, Marek Polacek wrote: This test ICEs since the addition of the assert in pp_string which ensures that we aren't trying to print an empty string. But that's what happens here, the location is actually UNKNOWN_LOCATION, so LOCATION_FILE on that yields null. Fixed byt not trying

Re: [PATCH] Reuse the saved_scope structures allocated by push_to_top_level

On 3 March 2016 at 15:39, Patrick Palka <patr...@parcs.ath.cx> wrote: > On Thu, Mar 3, 2016 at 10:22 AM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> It would be an overall improvement if it was neither a TREE_LIST, nor a >> TREE_VECTOR: https://gcc.gn

Re: Proposed Patch for Bug 69687

On 03/03/16 14:21, Bernd Schmidt wrote: On 03/02/2016 06:22 PM, Mike Stump wrote: So, check for overflow, or better use unsigned values that are large enough to never overflow. With no possibility for overflow, you can then retest the bug and see if there are any other failure modes and fix

Re: [PATCH] Reuse the saved_scope structures allocated by push_to_top_level

On 03/03/16 14:49, Patrick Palka wrote: I think the slowness of this function is mostly due to the pointer chasing performed in the function store_bindings, where we iterate over all the names in each non-global scope to figure out whether to preserve them. It would probably improve performance

Re: [PATCH] Specify that new ports should use LRA

On 2 March 2016 at 21:47, H.J. Lu <hjl.to...@gmail.com> wrote: > On Wed, Mar 2, 2016 at 12:18 PM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> Pre-approved by Jeff here: >> https://gcc.gnu.org/ml/gcc-help/2016-03/msg6.html >> >> C

Re: [PATCH] PR c/69993: improvements to wording of -Wmisleading-indentation

On 02/03/16 04:20, Patrick Palka wrote: Using this wording order makes it seem that the problem is with the if statement, because we emit a warning about it and then emit "only" a note for the misleadingly-indented goto statement. ... on second thought, I may be overthinking the semantic

[PATCH] Specify that new ports should use LRA

Pre-approved by Jeff here: https://gcc.gnu.org/ml/gcc-help/2016-03/msg6.html Committed as revision 233914. Index: ChangeLog === --- ChangeLog (revision 233913) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2016-03-02 Manuel

Re: [PATCH] PR28901 Add two levels for -Wunused-const-variable.

On 23/02/16 08:56, Jakub Jelinek wrote: On Tue, Feb 23, 2016@09:53:57AM +0100, Mark Wielaard wrote: --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,10 @@ +2016-02-23 Mark Wielaard + Jakub Jelinek + + PR c/69911 + * cgraphunit.c

Re: [C++ patch] report better diagnostic for static following '[' in parameter declaration

On 29/01/16 17:01, Prathamesh Kulkarni wrote: Thanks for the review. AFAIK the type-qualifiers would be const, restrict, volatile and _Atomic (n1570 p 6.7.3) ? I added a check for those and for variable length array. I am having issues with writing the test-case, some cases pass with -std=c++11

Re: [wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2)

On 20 January 2016 at 17:38, Gerald Pfeifer wrote: > On Wed, 20 Jan 2016, Jakub Jelinek wrote: >>> Content-Security-Policy: default-src 'self' http: https: >>> >>> So either we get the configuration of the web server changed, or >>> indeed we need to touch all those existing

Re: [wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2)

On 19/01/16 17:08, Gerald Pfeifer wrote: On Fri, 15 Jan 2016, David Malcolm wrote: Here's an updated version of the above, which the W3C validator reports as being clean (fixing various "&" and "<" and a missing end-tag). Nice - and a lot of nice changes you implemented since GCC 5! Am I

Re: [wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit (v2)

On 19 January 2016 at 19:31, Mike Stump <mikest...@comcast.net> wrote: > On Jan 19, 2016, at 11:05 AM, Manuel López-Ibáñez <lopeziba...@gmail.com> > wrote: >> >> Am I the only one who doesn't see the colors at >> https://gcc.gnu.org/gcc-6/changes.html#c-fami

Re: genattrab.c generate switch

On 18/01/16 14:39, Jesper Broge Jørgensen wrote: No i have not gone through copyright assignment. This is my first time trying to contribute to a GNU project so i have tried following the "Contributing to GCC"@ https://gcc.gnu.org/contribute.html There i followed the advice to run the patch

Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code

On 14/12/15 16:40, Markus Trippelsdorf wrote: On 2015.12.14@11:20 -0500, Trevor Saunders wrote: On Mon, Dec 14, 2015@10:01:27AM +0100, Richard Biener wrote: On Sun, Dec 13, 2015@9:03 PM, Andi Kleen wrote: Markus Trippelsdorf writes: Many

Re: [Patch, Fortran] PR68815 - replace '%s' quotes by %< ... %>

On 12/09/2015 03:53 PM, Tobias Burnus wrote: In principle, %<%c%> and %<%d%> should be convertable to %qc and %qd (as the code is more readable), but the current function annotation prevent this, telling that the q flag is not valid for %c and %d. As %< is fine, I didn't dig into it. You need

Re: PATCH to shorten_compare -Wtype-limits handling

On 20 November 2015 at 22:28, Jeff Law wrote: >>> That was the overall plan and he posted a patch for that. But that patch >>> didn't do the due diligence to verify that once the shortening code was >>> made >>> "pure" that we didn't regress on the quality of the code we

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

On 4 December 2015 at 17:53, Jakub Jelinek wrote: > + > + if (e->unknown_error) > + error_at (loc, e->unknown_error, option->opt_text); > + else > + error_at (loc, "unrecognized argument in option %qs", > +

Re: PATCH to shorten_compare -Wtype-limits handling

On 20 November 2015 at 17:42, Jeff Law wrote: > So we have to detangle the operand shortening from warning detection. Kai's > idea was to first make the shortening code "pure" in the sense that it would > have no side effects other than to generate the warnings. Canonicalization

Re: PATCH to shorten_compare -Wtype-limits handling

On 20 November 2015 at 16:10, Martin Sebor wrote: >>> Hmm, it looks like using expansion_point_if_in_system_header might avoid >>> the first issue you mention. >> >> >> Thus. > > > Great, thanks! (I'll have to remember the trick for my own use!) I added this to

Re: PATCH to shorten_compare -Wtype-limits handling

On 19 November 2015 at 17:54, Jeff Law wrote: >> But there were a couple of patches from you some time ago, for >> example: http://permalink.gmane.org/gmane.comp.gcc.patches/343476 >> >> What happened with those? > > On hold pending fixing the type-limits warning placement.

Re: PATCH to shorten_compare -Wtype-limits handling

On 19 November 2015 at 17:09, Jeff Law wrote: > The even longer term direction for this code is to separate out the > type-limits warning from the canonicalization and shortening. I've got a > blob of code form Kai that goes in that direction, but it needs more > engineering

Re: [PATCH] Add clang-format config to contrib folder

On 18/11/15 17:05, Jeff Law wrote: As we've been continuously converting our source base to C++, the clang-format should provide better results than a collection of regular expressions (check_GNU_style.sh). As a reference file I attach gcc/tree-ssa-uninit.c file. Feel free to comment the

Re: [C++ PATCH] Issue hard error even with -fpermissive for certain goto violations (PR c++/67409)

On 18/11/15 22:55, Jakub Jelinek wrote: static bool -identify_goto (tree decl, const location_t *locus) +identify_goto (tree decl, const location_t *locus, bool harderr) { - bool complained = (decl -? permerror (input_location, "jump to label %qD", decl) -

Re: [PATCH c/c++] use explicit locations for some warnings in c-pragma.c

On 4 November 2015 at 09:45, Mike Stump wrote: > in the top of the tree. This is bad as the same line appears in a PASS: and > an XFAIL:. Each test case should be unique. Should it be updated to 64? I think it is sufficient to change it to: /* { dg-warning "24:missing"

Re: [PATCH] v4 of diagnostic_show_locus and rich_location

On 12 October 2015 at 16:44, David Malcolm wrote: > v4 of the patch does the conversion of Fortran, and eliminates the > adaptation layer. No partial transitions here! > > Manu: I hope this addresses your concerns. Yes, it looks great. I don't understand how this - and

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

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 again. So next time the FE > requests

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

On 25 September 2015 at 22:11, David Malcolm wrote: >> >> + if (0) >> +show_ruler (context, line_width, m_x_offset); >> >> This should probably be removed from the final code to be committed. > > FWIW, the ruler is very helpful to me when debugging the locus-printing >

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

On 25 September 2015 at 22:18, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > On 25 September 2015 at 22:11, David Malcolm <dmalc...@redhat.com> wrote: context->last_location = diagnostic_location (diagnostic, 0); - expanded_location s0 = diagnostic_expand_locat

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

+ If SHOW_CARET_P is true, then the range should be rendered with + a caret at its starting location. This + is for use by the Fortran frontend, for implementing the + "%C" and "%L" format codes. */ + +void +rich_location::set_range (unsigned int idx, source_range src_range, +

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

On 25 September 2015 at 23:24, David Malcolm <dmalc...@redhat.com> wrote: > On Fri, 2015-09-25 at 23:13 +0200, Manuel López-Ibáñez wrote: >> + If SHOW_CARET_P is true, then the range should be rendered with >> + a caret at its starting location. This >> + is for

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

On 25 September 2015 at 23:15, David Malcolm wrote: > My recollection is that I saw that the Fortran frontend has logic for > calling into diagnostic_print_caret_line, noticed that the fortran > testsuite has dg- assertions about finding specific messages, and I got > worried

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

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! :) Cheers, Manuel.

Re: fdiagnostics-color=never does not disable color for some diagnostics

On 24 September 2015 at 15:06, Jason Merrill <ja...@redhat.com> wrote: > On 09/22/2015 04:23 PM, Manuel López-Ibáñez wrote: >> >> +error_at (loc, "-Werror=%s: no option -%s", arg, new_option); >> + else if (!(cl_options[option_index].flags & CL_WAR

[PATCH c-family/49654/49655] reject invalid options in pragma diagnostic

Use find_opt instead of linear search through options in handle_pragma_diagnostic (PR 49654) and reject non-warning options and options not valid for the current language (PR 49655). Boot on x86_64-linux-gnu. OK? gcc/testsuite/ChangeLog: 2015-09-22 Manuel López-Ibáñez <m...@gcc.gnu.

fdiagnostics-color=never does not disable color for some diagnostics

but the last one, which is moved to the first position. Boot on x86_64-linux-gnu OK? gcc/ChangeLog: 2015-09-22 Manuel López-Ibáñez <m...@gcc.gnu.org> PR driver/67640 * opts-common.c (prune_options): Discard all -fdiagnostics-color but the last one, which is moved to the

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

On 21 September 2015 at 12:29, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Sep 21, 2015 at 11:59 AM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> On 21 September 2015 at 10:18, Richard Biener >> <richard.guent...@gmail.com> wrote: >

Re: [PATCH tree-inline] do not say "called from here" with UNKNOWN_LOCATION

On 21 September 2015 at 12:29, Richard Biener wrote: >>> least note the function we are failing to inline to (thus, use >>> DECL_SOURCE_LOCATION >>> of cfun->decl). So better add a diag_location and compute that upfront to >>> avoid >>> repeating the check. >> >>

  1   2   3   4   5   >