+@opindex Wodr
+@opindex Wno-odr
+@opindex Wodr
+Warn about One Definition Rule violations during link time optimization.
+Require @option{-flto-odr-type-merging} to be enabled. Enabled by default
Duplicated @opindex Wodr. (@item is missing)
Requires. Period after default
But according to
All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument
and -Wmemset-transposed-args) are implemented in a hackish way, because we
fold everything too early. Perhaps for such analysis we want a FOLDED_EXPR
which would have arguments what it has been folded to and the
since displaying the caret was made the default, the -Wstack-usage warning has
a strange-looking final part:
stack-usage-2.c: In function 'foo2':
stack-usage-2.c:16:1: warning: stack usage is 920 bytes [-Wstack-usage=]
}
^
Your patch hides the caret but the location still points to the
On 12 July 2014 03:39, Eric Botcazou ebotca...@adacore.com wrote:
Your patch hides the caret but the location still points to the
closing brace (so if you use an IDE like emacs this is where you will
go).
Is there a location for the definition? Could we store/pass one to this
point?
On 11 November 2014 17:10, Jason Merrill ja...@redhat.com wrote:
On 10/31/2014 10:01 PM, Manuel López-Ibáñez wrote:
+sense. So let's live the location intact in that case. */
s/live/leave/
+ /* If MAP is not the last line map of its set, then the new location
+ (loc
On 12 November 2014 15:24, Andreas Schwab sch...@suse.de wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 217191)
+++ libcpp/line-map.c (working copy
On 12 November 2014 15:38, Marek Polacek pola...@redhat.com wrote:
On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote:
../../libcpp/line-map.c:667:65: error: suggest braces around empty body in
an 'if' statement [-Werror=empty-body]
I just (r217418) bootstrapped this code
On 12 November 2014 15:54, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 12 November 2014 15:38, Marek Polacek pola...@redhat.com wrote:
On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote:
../../libcpp/line-map.c:667:65: error: suggest braces around empty body
On 12 November 2014 22:41, Jakub Jelinek ja...@redhat.com wrote:
I think we had discussions on this topic, the important thing is that we
don't want to generate different warnings based on whether -save-temps has
been used, there could be just comment in between ) and ; etc.
How can
I think it is great that =auto becomes the default. However, adding a
configure option for this seems overkill. If anyone really really
wishes to change the default, they can simply edit a single-line in
common.opt.
Apart from that, I really cannot understand why someone would want the
options
Committed as obvious (after bootstrappingregtest).
https://gcc.gnu.org/r217457
2014-11-13 Manuel López-Ibáñez m...@gcc.gnu.org
* opts-global.c (postpone_unknown_option_warning): Fix spelling.
(print_ignored_options): Fix quoting.
* opts.c (common_handle_option): Likewise
On 13 November 2014 03:07, Mike Stump mikest...@comcast.net wrote:
On Nov 12, 2014, at 3:52 PM, Manuel López-Ibáñez lopeziba...@gmail.com
wrote:
On 12 November 2014 22:41, Jakub Jelinek ja...@redhat.com wrote:
I think we had discussions on this topic, the important thing is that we
don't
On 13 November 2014 07:53, Jakub Jelinek ja...@redhat.com wrote:
Apart from that, I really cannot understand why someone would want the
options none, auto or always: none is equivalent to auto-if-env but
without the if-env escape route, and neither auto nor always allow
disabling the coloring
On 12 November 2014 15:54, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 12 November 2014 15:38, Marek Polacek pola...@redhat.com wrote:
On Wed, Nov 12, 2014 at 03:35:06PM +0100, Manuel López-Ibáñez wrote:
../../libcpp/line-map.c:667:65: error: suggest braces around empty body
h3 id=c-familyC family/h3
ul
+liThe code-fdiagnostics-color=/code option default is now
+configurable at GCC configury time using
+code--with-diagnostics-color=/code, can default to
+codeauto/code - the new default unless configured otherwise,
+where diagnostics is
On 14 November 2014 13:18, Jakub Jelinek ja...@redhat.com wrote:
Indeed, it does. So feel free to turn that into patch form.
This is what I committed. I also updated the Fortran part to add an
example and remove outdated info. Feel free to change it (or ask me to
change it).
---
On 15 November 2014 10:23, Tobias Burnus bur...@net-b.de wrote:
Especially since color diagnostic is now the default [1], it makes sense to
convert more gfortran diagnostics to use the common diagnostics.
For an example, see [1]. That also brings all the nice features like placing
the warning
For what is worth, the patch looks good to me, except that the form
EnabledBy(@var{opt} || @var{opt2} needs documentation in
doc/options.texi.
Perhaps it could be more condensed as (untested!):
Index: optc-gen.awk
===
---
Exactly what the subject says. I'm not sure if this is appropriate for
stage3, I'll leave that to the Fortran maintainers.
Bootstrapped regression tested on x86_64-linux-gnu.
Cheers,
Manuel.
gcc/fortran/ChangeLog:
2014-11-23 Manuel López-Ibáñez m...@gcc.gnu.org
PR fortran/44054
On 23 November 2014 at 10:27, Tobias Burnus bur...@net-b.de wrote:
This patch moves -Wtabs closer to the common diagnostics - and changed the
odd reversed logic of flags = 0 meaning off.
You may wish to update the documentation to reflect this change in
behavior (invoke.texi, lang.opt and
On 23 November 2014 at 21:21, Tobias Burnus bur...@net-b.de wrote:
This patch depends on Manuel's %L patch.
It converts the remaining fatal error calls to the common diagnostic
infrastructure and retires (removes) the old gfc_fatal_error_1.
I will build and regtest it after Manuel's commit.
Sorry to be pedantic, but I think this is not exactly right:
+if (cxx_dialect = cxx11)
+ {
+ if (pedantic)
+ pedwarn (input_location, OPT_Wpedantic,
+ ISO C++ forbids converting a string constant to %qT,
+ totype);
+ else
+ warning (OPT_Wwrite_strings,
+ ISO C++ forbids
On 25 November 2014 at 23:42, Tobias Burnus bur...@net-b.de wrote:
FX:
(a) those majority which might need buffering (gfc_error, gfc_warning);
Is there a plan for those in the longer term?
Well, the long-term solution is of course to support them. That requires
adding buffering+discarding
This is just a RFC so no Changelog yet. It bootstraps and passes the
testsuite. I have three major questions:
* Dodji: Do the common diagnostics part look reasonable? I tried to be
as least invasive as possible. If you have comments or suggestions
they are very welcome.
* Fortran devs: Is this
On 27 November 2014 at 20:28, Tobias Burnus bur...@net-b.de wrote:
I think the approach is fine. As the _now version overrides the buffer, one
might even do with a single buffer by clearing it, setting flush_p
temporarily to true and printing the message. It only might collide with
buffered
On 27 November 2014 at 22:33, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 27 November 2014 at 20:28, Tobias Burnus bur...@net-b.de wrote:
I think the approach is fine. As the _now version overrides the buffer, one
might even do with a single buffer by clearing it, setting flush_p
On 27 November 2014 at 23:58, Tobias Burnus bur...@net-b.de wrote:
Manuel López-Ibáñez wrote:
Sure, but I would like to test specifically triggering and discarding
the gfc_warning that I converted (or another single one that you
suggest), if this were possible.
Hmm, theoretically, it would
On 25 September 2014 11:34, Dodji Seketeli do...@redhat.com wrote:
When the caret line is disabled with -fno-diagnostics-show-caret, the
fix-it hint is printed as:
gcc/testsuite/g++.dg/template/crash83.C:5:21: error: an explicit
specialization must be preceded by 'template '
On 25 September 2014 13:39, Dodji Seketeli do...@redhat.com wrote:
2) In the Fortran FE, which gives quite precise location information
by tracking the characters that it wants to warn about instead of
relying on the line-map machinery.
So with this feature, the Fortran FE would then use the
I don't want to cause you more work Paolo, but perhaps this should be
documented in https://gcc.gnu.org/gcc-5/changes.html. ?
Something like:
* Excessive template instantiation depth is now a fatal error. This
prevents excessive diagnostics that usually do not help to identify
the problem.
for no good reason.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/ChangeLog:
2014-10-03 Manuel López-Ibáñez m...@gcc.gnu.org
* tree-pretty-print.c (dump_location): Make it extern. Dump also
the column.
* tree-pretty-print.h (dump_location): Declare.
* gimple
gcc/ChangeLog.jit:
* diagnostic.c (diagnostic_finish): Free the memory for
context-classify_diagnostic and context-printer, running the
destructor for the latter.
It would be easier to review and merge your branch if you directly
propose these self-contained and generally useful
new function is for errors instead of warnings. Perhaps
there are more places where these functions can be used.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/fortran/ChangeLog:
2014-10-03 Manuel López-Ibáñez m...@gcc.gnu.org
* gfortran.h (gfc_warning_cmdline): Add
On 3 October 2014 23:29, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
The following patch adds two new functions. One of them is an overload
of gfc_warning_cmdline() that takes an option. Thus now we get:
Don't review this one just yet. I must have messed up testing or new
testcases
automatically by the common options
machinery.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/fortran/ChangeLog:
2014-10-04 Manuel López-Ibáñez m...@gcc.gnu.org
* gfortran.h (gfc_warning_cmdline): Add overload that takes an
option.
(gfc_error_cmdline): Declare
A few cleanups in line-map code. Bootstrapped and regression tested on
x86_64-linux-gnu.
OK?
libcpp/ChangeLog:
2014-10-12 Manuel López-Ibáñez m...@gcc.gnu.org
* include/line-map.h (linemap_location_from_macro_expansion_p):
const struct line_maps * argument
of cxx_pretty_printer. It is the default anyway.
Bootstrapped and tested on x86_64-linux-gnu.
OK?
gcc/c/ChangeLog:
2014-10-12 Manuel López-Ibáñez m...@gcc.gnu.org
PR c++/53061
* c-objc-common.c (c_objc_common_init): Do not do diagnostics
initialization here
On 13 October 2014 10:52, Dodji Seketeli do...@redhat.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 216098)
+++ libcpp/line-map.c (working copy
On 13 October 2014 20:52, Jeff Law l...@redhat.com wrote:
On 10/13/14 05:11, Anthony Brandon wrote:
I updated the patch with a comment. Actually, Manuel handed me this
patch just to help me get familiar with the process of submitting and
testing.
Generating this one with git diff looks
You need to handle them in lto-opts.c and output them to the existing option
section. Not sure why they don't appear there already - ah, because of
/* Also drop all options that are handled by the driver as well,
which includes things like -o and -v or -fhelp for example.
on x86_64-linux-gnu.
OK?
gcc/fortran/ChangeLog:
2014-10-16 Manuel López-Ibáñez m...@gcc.gnu.org
PR fortran/44054
* gfortran.h (gfc_warning_cmdline): Rename as gfc_warning_now_2.
(gfc_error_cmdline): Rename as gfc_error_now_2.
* error.c (gfc_diagnostic_build_locus_prefix): Remove
that I wanted to get the basic infrastructure right.
Bootregtested on x86_64-linux-gnu.
OK?
libcpp/ChangeLog:
2014-10-16 Manuel López-Ibáñez m...@gcc.gnu.org
PR fortran/44054
* include/line-map.h (linemap_position_for_loc_and_offset):
Declare.
* line-map.c
The Right Thing is for -pedantic not to cause errors, only warnings
(-pedantic-errors being needed for an error). So rather than having this
conditional for whether to allow the extension at all, make the
conditional code do a pedwarn (if flag_isoc99, otherwise there will
already have been
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 and comment whether I got it right/wrong?
Yes
While writing the guidelines
https://gcc.gnu.org/wiki/Better_Diagnostics#guidelines , I noticed
that we never explain the precedence rules between conflicting
options. Also, the description of -pedantic-errors could be more
precise.
OK?
Index: invoke.texi
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
at:https://gcc.gnu.org/wiki/Better_Diagnostics#guidelines
On 17 October 2014 22:46, Joseph S. Myers jos...@codesourcery.com wrote:
@@ -3318,8 +3327,8 @@
@item -pedantic-errors
@opindex pedantic-errors
-Like @option{-Wpedantic}, except that errors are produced rather than
-warnings.
+This is equivalent to @option{-Werror=pedantic} plus making
On 18 October 2014 01:43, Joseph S. Myers jos...@codesourcery.com wrote:
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote:
The previous version also does not match your description. You are saying
that
-Wpedantic = warning(OPT_Wpedantic) + pedwarn(OPT_Wpedantic)
and -pedantic-errors
On 18 October 2014 02:13, Joseph S. Myers jos...@codesourcery.com wrote:
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote:
Can we make possibly in some other cases more concrete? Otherwise,
Cases where something about the code is not defined by the base standard,
but a diagnostic
On 18 October 2014 14:43, Anthony Brandon anthony.bran...@gmail.com wrote:
Never mind about functions.texi. I figured out how to do it.
Here is the new diff and changelog.
libiberty/ChangeLog:
2014-10-18 Anthony Brandon anthony.bran...@gmail.com
* filename_cmp.c (filename_eq): No
2014-10-18 23:07 GMT+02:00 Krzesimir Nowak qdl...@gmail.com:
Hello.
This is my first patch for GCC. I already started a paperwork for
copyright assignment (sent an email to fsf-records at gnu org) -
waiting for response.
So, about this patch - it basically removes column printing from In
On 23 April 2014 20:03, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote:
I didn't attach the patch, I am extremely sorry for the noise.
I am re-posting the mail.
This is a follow up mail to
http://gcc.gnu.org/ml/gcc-help/2014-04/msg00096.html
I have attached patch that prints the
, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote:
On Tue, Apr 29, 2014 at 2:07 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 23 April 2014 20:03, Prathamesh Kulkarni bilbotheelffri...@gmail.com
wrote:
I didn't attach the patch, I am extremely sorry for the noise.
I am re-posting
On 12/05/2014, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 12 May 2014, Matthias Klose wrote:
I didn't look close enough to the gfortran test results. PR driver/61126
is a
fix for the regression introduced with the fix for the above issue. With
this
patch proposed by Manuel,
On 12 May 2014 22:24, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 12 May 2014, Manuel López-Ibáñez wrote:
I will be very surprised if the common defaults are overriding a FE
default and it is not a bug in the FE.
Well, I think that needs justification, not just very surprised
On 14 May 2014 18:47, Jason Merrill ja...@redhat.com wrote:
When I was working on DR 1571, I noticed that our diagnostics weren't very
helpful for reference bindings (BZ 20332/21631) so I set out to treat
lvalue/rvalue mismatches and cv-qual loss as a bad conversion rather than no
conversion.
This patch makes it possible to suppress the function-name display in
a straightforward way: it adds a new global which the plugin can set
to declare the name of the dummy function.
This patch seems like a bit of a hack, but there didn't seem to be a
notably cleaner approach.
Can't you
On 12 June 2014 01:23, Peter Bergner berg...@vnet.ibm.com wrote:
On Wed, 2014-06-11 at 23:07 +, Joseph S. Myers wrote:
On Wed, 11 Jun 2014, Peter Bergner wrote:
I'd like to ping the following patch that fixes PR57653. This did
bootstrap and regtest with no regressions on
(revision 208669)
@@ -1,3 +1,11 @@
+2014-03-19 Manuel López-Ibáñez m...@gcc.gnu.org
+
+ PR c/55383
+ * gcc.dg/cast-qual-3.c: New.
+ Revert:
+ 2014-03-18 Manuel López-Ibáñez m...@gcc.gnu.org
+ * c-c++-common/Wcast-qual-1.c: More precise match text.
+
2014-03-18
of cxx_pretty_printer. It is the default anyway.
Bootstrapped and tested on x86_64-linux-gnu.
OK?
gcc/c/ChangeLog:
2014-10-12 Manuel López-Ibáñez m...@gcc.gnu.org
PR c++/53061
* c-objc-common.c (c_objc_common_init): Do not do diagnostics
initialization here
On 19 October 2014 18:08, Joseph S. Myers jos...@codesourcery.com wrote:
On Sat, 18 Oct 2014, Manuel López-Ibáñez wrote:
What about this version?
Give an error whenever the @dfn{base standard} (see @option{-Wpedantic})
requires a diagnostic, in cases where there is undefined behavior
IIRC, it took me several hours way back when to figure out how to just
run one specific testcase (as opposed to the whole suite), and I can
never remember the right incantation, so I wrote it up on the wiki page,
and now just go there when I find myself wondering the right incantation.
This
On 23 October 2014 21:10, Dodji Seketeli do...@redhat.com wrote:
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.
I don't see the
I committed this as https://gcc.gnu.org/r216720 following all your
comments except for:
On 23 October 2014 12:31, Dodji Seketeli do...@redhat.com wrote:
+
+/* Construct a C++-aware pretty-printer for CONTEXT. It is assumed
+ that CONTEXT-printer is an already constructed basic
linemap_assert when --enable-checking=yes and simply return loc when
--enable-checking=release, but I don't see how to do this in libcpp.
Bootregtested on x86_64-linux-gnu.
OK?
libcpp/ChangeLog:
2014-11-01 Manuel López-Ibáñez m...@gcc.gnu.org
PR fortran/44054
* include/line-map.h
On 23 October 2014 12:39, Dodji Seketeli do...@redhat.com wrote:
To take this further, I am thinking that these guidelines would be even
better served by standing on their own page. If nobody objects, I can
create a DiagnosticsGuidelines page in the wiki with the content that you
added.
expansion_point_location_if_in_system_header (source_location location)
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 217056)
+++ gcc/ChangeLog (revision 217057)
@@ -1,3 +1,8 @@
+2014-11-04 Manuel López-Ibáñez m...@gcc.gnu.org
On 4 November 2014 23:40, Jeff Law l...@redhat.com wrote:
On 10/25/14 04:20, Anthony Brandon wrote:
Hi,
Sorry for the delay. Here are the updated diff and changelog.
gcc/testsuite/ChangeLog:
2014-10-25 Anthony Brandon anthony.bran...@gmail.com
PR driver/36312
*
On 5 November 2014 21:57, Eric Botcazou ebotca...@adacore.com wrote:
2014-10-25 Anthony Brandon anthony.bran...@gmail.com
PR driver/36312
* diagnostic-core.h: Add prototype for fatal_error.
* diagnostic.c (fatal_error): New function fatal_error.
* gcc.c (store_arg): Remove
On 5 November 2014 23:39, Eric Botcazou ebotca...@adacore.com wrote:
Sorry for the breakage. I guess Anthony didn't configure with
--enable-languages=all,ada. It is a typical mistake I have myself done
in the past. Since the fix is not obvious to me and I'm not sure how
much time Anthony would
On 6 November 2014 00:33, Joseph Myers jos...@codesourcery.com wrote:
On Wed, 5 Nov 2014, Manuel López-Ibáñez wrote:
Sorry for the breakage. I guess Anthony didn't configure with
--enable-languages=all,ada. It is a typical mistake I have myself done
in the past. Since the fix is not obvious
On 5 November 2014 21:57, Eric Botcazou ebotca...@adacore.com wrote:
2014-10-25 Anthony Brandon anthony.bran...@gmail.com
PR driver/36312
* diagnostic-core.h: Add prototype for fatal_error.
* diagnostic.c (fatal_error): New function fatal_error.
* gcc.c (store_arg): Remove
on x86_64-linux-gnu.
OK?
libcpp/ChangeLog:
2014-11-07 Manuel López-Ibáñez m...@gcc.gnu.org
* include/line-map.h (linemap_position_for_loc_and_offset):
Declare.
* line-map.c (linemap_position_for_loc_and_offset): New.
gcc/c-family/ChangeLog:
2014-11-07 Manuel López-Ibáñez m
On 7 November 2014 18:57, Joseph Myers jos...@codesourcery.com wrote:
On Fri, 7 Nov 2014, Manuel López-Ibáñez wrote:
This patch allows format warnings to point within the format string
for simple strings. There are a few limitations:
* It does not handle 'const char *' because the location
On 7 November 2014 22:39, Joseph Myers jos...@codesourcery.com wrote:
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
/ChangeLog:
2014-11-08 Anthony Brandon anthony.bran...@gmail.com
Manuel López-Ibáñez m...@gcc.gnu.org
PR driver/36312
* gcc.misc-tests/output.exp: New test case for identical input and
output files.
include/ChangeLog:
2014-11-08 Anthony Brandon anthony.bran...@gmail.com
We had a request from a customer to add a warning to the C front end to
diagnose cases where bit-fields larger than an int are used in shift
expressions; confusingly, the operation is done in the precision of the
bit-field size rather than its declared type. This is a symptom of a larger
On 19 August 2014 00:06, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 12 Aug 2014, Marek Polacek wrote:
This then is the version with both issues fixed (and new test).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2014-08-12 Marek Polacek pola...@redhat.com
will try to
use the Enum() facility in the *.opt file if possible.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/ChangeLog:
2014-08-30 Manuel López-Ibáñez m...@gcc.gnu.org
* doc/options.texi: Document that Var and Init are required if CPP
is given.
* optc-gen.awk
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.
2) In the Fortran FE, which gives quite
a warning. For example, the C++ parser often
says 'x' expected before 'y' but adding x before y rarely fixes
anything.
gcc/ChangeLog:
2014-08-31 Manuel López-Ibáñez m...@gcc.gnu.org
PR c++/62314
* diagnostic.def (DK_FIXIT): New.
* diagnostic.c (adjust_column): New.
(adjust_line
.
Bootstrapped and regression tested on x86_64-linux-gnu
OK?
gcc/ChangeLog:
2014-09-05 Manuel López-Ibáñez m...@gcc.gnu.org
* doc/invoke.texi (Wnormalized=): Update.
libcpp/ChangeLog:
2014-09-05 Manuel López-Ibáñez m...@gcc.gnu.org
* include/cpplib.h (struct cpp_options): Declare
on top of the previous patch about Wnormalized= but
it is mostly independent of it.
Bootstrapped and regression tested on x86_64-linux-gnu
OK?
gcc/ChangeLog:
2014-09-05 Manuel López-Ibáñez m...@gcc.gnu.org
* opth-gen.awk: Generate mapping from cpp message reasons to the
options that enable
What happened with this? I don't see any libcc1 in the gcc repository
and this patch was never committed.
Cheers,
Manuel.
On 31 August 2014 17:12, Gerald Pfeifer ger...@pfeifer.com wrote:
Hi Jan,
On Fri, 8 Aug 2014, Jan Kratochvil wrote:
Jeff == Jeff Law l...@redhat.com writes:
Does this
Bootstrapped and regression tested on x86_64-linux-gnu. Committed as
obvious at r215272.
gcc/c-family/ChangeLog:
2014-09-15 Manuel López-Ibáñez m...@gcc.gnu.org
* c.opt (Wpsabi): Use LangEnabledBy.
* c-opts.c (c_common_handle_option): Do not handle here.
Index: gcc/c-family/c.opt
I haven't heard any complaints about the caret diagnostics being
enabled by default, so I am tempted to think it will stay like it is
for GCC 4.8. This patch documents that and also the new -Wpedantic.
OK?
Cheers,
Manuel.
caret.diff
Description: Binary data
OK to commit?
* htdocs/gcc-4.8/changes.html: Document -Wshadow change.
wshadow.diff
Description: Binary data
On 10 February 2013 08:45, Gerald Pfeifer ger...@pfeifer.com wrote:
On Sat, 9 Feb 2013, Manuel López-Ibáñez wrote:
OK to commit?
* htdocs/gcc-4.8/changes.html: Document -Wshadow change.
Thanks!
The only question I have is about unless the variable is a function.
How can a variable
Hi Christian,
You have to add the testcases from both PR52283 and PR37985, and an
appropriate Changelog, and bootstrap+regression test everything and
double-check that the new testcases don't fail and no old testcases
fail with the patch (by comparing with the testcases that fail without
the
On 4 April 2012 13:05, Christian Bruel christian.br...@st.com wrote:
The testscase was part of the attached patch, along with the ChangeLog
entries
You are right! Sorry, I may have been looking at the wrong place.
It was bootstrapped and regtested for C and C++ on x86 (that was in bugzilla
=all,ada and -m32/-m64.
OK to commit?
2012-04-05 Manuel López-Ibáñez m...@gcc.gnu.org
PR 24985
libstdc++-v3/
* testsuite/lib/prune.exp: Handle caret.
libmudflap/
* testsuite/lib/libmudflap.exp: Handle caret.
gcc/
* diagnostic.h (show_caret): Declare
On 6 April 2012 15:42, Mike Stump mikest...@comcast.net wrote:
On Apr 6, 2012, at 1:11 AM, Manuel López-Ibáñez wrote:
A simple implementation of caret diagnostics.
In the testsuite, pruning the caret output does not always work
because of several known deficiencies of DejaGNU, thus in some
On 7 April 2012 00:04, Jason Merrill ja...@redhat.com wrote:
On 04/06/2012 04:11 AM, Manuel López-Ibáńez wrote:
+++ gcc/testsuite/gcc.dg/torture/tls/tls.exp (working copy)
@@ -48,10 +48,10 @@ dg-init
torture-init
set-torture-options $TLS_TORTURE_OPTIONS {{}} $LTO_TORTURE_OPTIONS
#
contrib/compare_tests gets confused if the same message is printed for
the same line but with different status (PASS vs. XFAIL). Trivially
fixed by giving different labels to each test. Committed as obvious.
2012-04-08 Manuel López-Ibáñez m...@gcc.gnu.org
* g++.dg/warn/Wstrict-aliasing
On 7 April 2012 04:31, Jason Merrill ja...@redhat.com wrote:
On 04/06/2012 06:30 PM, Manuel López-Ibáñez wrote:
width if it's set; otherwise I would lean toward unlimited width. And I'm
not sure why we need a right margin at all.
The right margin is because:
[snip]
Ah, I read margin
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
I'll be happy to change it to whatever is more understandable. I think
in CSS is called padding.
That wouldn't be any clearer; my confusion was that I thought you were
padding
On 8 April 2012 17:14, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 7:06 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
I'll be happy
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
+getenv_columns (void)
I had been thinking to check COLUMNS once at the beginning of compilation; I
don't think the value can change while the compiler is running since we
don't
On 8 April 2012 18:35, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sun, Apr 8, 2012 at 11:13 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 8 April 2012 06:09, Jason Merrill ja...@redhat.com wrote:
On 04/07/2012 06:29 PM, Manuel López-Ibáńez wrote:
+getenv_columns (void
/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-04-08 Manuel López-Ibáñez m...@gcc.gnu.org
+
+ * tree-pretty-print.h: Update comment.
+
2012-04-08 Oleg Endo olege...@gcc.gnu.org
* config/sh/sh.md: Use braced string notation where applicable.
1 - 100 of 462 matches
Mail list logo
