On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose d...@ubuntu.com wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic
On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli do...@redhat.com wrote:
Jason Merrill ja...@redhat.com writes:
Oops, thought I had sent this before.
No problem. Thank you for replying now×
On 11/17/2012 10:23 AM, Dodji Seketeli wrote:
- if (cp_parser_parse_definitely (parser))
+
On Fri, Dec 7, 2012 at 7:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose d...@ubuntu.com wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base
On Fri, Dec 7, 2012 at 10:06 AM, Dodji Seketeli do...@redhat.com wrote:
Here is what I am committing to trunk.
Thank you!
-- Gaby
On Tue, Dec 11, 2012 at 4:14 AM, Richard Biener rguent...@suse.de wrote:
This brings the build-requirements up-to-date with us now requiring
a C++ host compiler. I optimistically increased the minimum required
GCC version listed from 2.95 to 3.4 as that is the earliest version
that could
On Fri, Dec 21, 2012 at 1:59 AM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this patch fixes some remaining issues with pointer-sizes for llp64
abi in libstdc++.
See comments below.
ChangeLog
2012-12-21 Kai Tietz
* config/os/mingw32/os_defines.h (_GLIBCXX_LLP64): Define if
On Fri, Dec 21, 2012 at 3:48 AM, Kai Tietz ktiet...@googlemail.com wrote:
2012/12/21 Paolo Carlini paolo.carl...@oracle.com:
On 12/21/2012 10:36 AM, Kai Tietz wrote:
well, issue isn't that 'long' is always 'ptrdiff_t'.
But then, if we just change the type without paying attention to size
The example is valid, but I am not sure I understand your explanation...
-- Gaby
On Fri, Dec 21, 2012 at 10:25 AM, Dodji Seketeli do...@redhat.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
The example is valid, but I am not sure I understand your
explanation...
Ah, sorry. I realize just now that I haven't mentioned the initial
erratic behaviour
On Sat, Dec 22, 2012 at 9:53 AM, Dodji Seketeli do...@redhat.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
Thank you very much for the explanation; your previous message
makes sense to me now.
You are welcome.
The question I have is why are we using TREE_TYPE
On Sun, Dec 23, 2012 at 11:04 PM, Jason Merrill ja...@redhat.com wrote:
On 12/21/2012 07:35 AM, Dodji Seketeli wrote:
else if (TREE_TYPE (t)
INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))
- !TREE_CONSTANT (t))
+ !TREE_CONSTANT (t)
+ /* Class
On Tue, Jan 8, 2013 at 7:58 AM, Dodji Seketeli do...@redhat.com wrote:
Hello,
Consider the example of the problem report
1 template typename
2 constexpr bool the_truth () { return true; }
3
4 template bool
5struct Takes_bool { };
6
7
On Wed, Jan 9, 2013 at 9:30 AM, Dodji Seketeli do...@redhat.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
We already have various predicates to test for constant
expressions so I am uneasy to add yet another one.
I understand. I got lost in the number of existing
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli do...@redhat.com wrote:
Also, I am not sure if this patch would be appropriate for commit, now
that we are in 'regression-only' mode. But seeing this alias-template
related thing not working hurts me. :) So at worst I'll schedule the
patch
On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli do...@redhat.com wrote:
But during the instantiation of the *members* of testint, we try to
instantiate Aliasthe_truthint, without coercing (and thus without
folding) the argument {the_truthint}. We do this using
instantiate_alias_template,
by
+ a href=mailto:g...@gcc.gnu.org;Gabriel Dos Reis/a./dd
+
/dl
h3 id=distrobranchesDistribution Branches/h3
On Fri, Feb 15, 2013 at 3:04 AM, Richard Biener
richard.guent...@gmail.com wrote:
Note that there is no such thing as a middle-end or back-end type.
but we do conceptually have them.
-- Gaby
On Wed, Mar 16, 2011 at 9:32 PM, Jason Merrill ja...@redhat.com wrote:
In a normal constexpr function, we treat *this as a potential constant
expression. But in a constexpr constructor it isn't, since we're still in
the process of initializing the object.
Hi Jason,
I believe the patch is too
On Wed, Mar 16, 2011 at 10:02 PM, Jason Merrill ja...@redhat.com wrote:
On 03/16/2011 10:43 PM, Gabriel Dos Reis wrote:
The real problem is that the data member of the object is not initialized.
Fully constructed subobjects in constexpr constructor are still
be potential constant expressions
On Thu, Mar 17, 2011 at 10:41 AM, Jason Merrill ja...@redhat.com wrote:
On 03/16/2011 11:44 PM, Gabriel Dos Reis wrote:
I am not sure we need more infrastructure or more complexity
in the implementation. The (C++98) language already requires
us to initialize subobjects in their order
On Mon, Mar 21, 2011 at 3:33 AM, Kai Tietz ktiet...@googlemail.com wrote:
2011/3/18 Jason Merrill ja...@redhat.com:
OK.
Jason
Applied first part at rev. 171209. Second part at rev. 171210.
thanks.
On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold ging...@adacore.com wrote:
Hi,
DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
extension that is difficult to work-around as it is used in the system
headers: varargs without named argument. It makes sense on VMS
On Mon, Sep 26, 2011 at 7:33 PM, Jason Merrill ja...@redhat.com wrote:
cxx_eval_logical_expression was assuming that a folded first operand of
would be either boolean_true_node or boolean_false_node, but in fact it can
be a constant with a typedef of bool, which doesn't compare equal with ==.
On Sun, Oct 2, 2011 at 7:37 AM, Jason Merrill ja...@redhat.com wrote:
On 10/01/2011 08:05 PM, Gabriel Dos Reis wrote:
It is weird though that GCC does not maintain a properly typed
internal representation.
Huh? Different typedefs need to be compared with same_type_p rather than
==. I
On Sun, Oct 2, 2011 at 11:51 AM, Jason Merrill ja...@redhat.com wrote:
On 10/02/2011 12:10 PM, Gabriel Dos Reis wrote:
The comment wasn't about comparison of typedefs -- the patch did not
compare
typedefs.
*Value* representations should not change just because a type name was
introduced
On Mon, Oct 3, 2011 at 8:16 AM, Tristan Gingold ging...@adacore.com wrote:
On Sep 30, 2011, at 5:19 PM, Joseph S. Myers wrote:
On Fri, 30 Sep 2011, Tristan Gingold wrote:
If you prefer a target hook, I'm fine with that. I will write such a patch.
I don't think it must be restricted to
On Tue, Oct 4, 2011 at 4:59 AM, Pedro Alves pe...@codesourcery.com wrote:
On Monday 03 October 2011 21:23:43, Joseph S. Myers wrote:
On Mon, 3 Oct 2011, Douglas Rupp wrote:
On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
On Fri, 30 Sep 2011, Tristan Gingold wrote:
If you prefer a
On Tue, Oct 4, 2011 at 5:46 AM, Pedro Alves pe...@codesourcery.com wrote:
On Tuesday 04 October 2011 11:16:30, Gabriel Dos Reis wrote:
Do we need to consider ABIs that have calling conventions that
treat unprototyped and varargs functions differently? (is there any?)
Could you elaborate
On Tue, Oct 4, 2011 at 1:24 PM, Douglas Rupp r...@gnat.com wrote:
On 10/3/2011 8:35 AM, Gabriel Dos Reis wrote:
unnamed variadic functions sounds as if the function itself is
unnamed, so not good.
-funnamed-variadic-parameter
How about
-fvariadic-parameters-unnamed
there's already
On Mon, Oct 10, 2011 at 7:47 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/10/2011 02:13 PM, Paolo Carlini wrote:
. looks like we want to do something else, not printing the number at all.
See audit trail.
An option, for 4.7 at least, would be, instead of just closing 33067 as a
On Mon, Oct 10, 2011 at 12:16 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
On 10/10/2011 07:13 PM, Gabriel Dos Reis wrote:
on this particular input, '6' looks OK. However, the question is why '6'?
Why can't we retain the original number spelling from the source code and
use that instead
On Mon, Oct 10, 2011 at 12:30 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
On 10/10/2011 07:28 PM, Gabriel Dos Reis wrote:
A GCC user not interested in numerics probably won't care. However, I do
not think that extends to people who do care about numerics and have
literals
On Mon, Oct 10, 2011 at 1:07 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote:
Yes, I suspect the max_digits10 patch would be definitely an improvement.
Good. It's at the beginning of this thread, passes testing. Please have a
closer look.
I
On Tue, Oct 11, 2011 at 10:32 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
The problem comes down to an expression with the difference of two
pointers being cast to int on a 64-bit system, resulting in
convert_to_integer moving the conversions inside the subtraction.
(These
On Tue, Oct 11, 2011 at 9:47 AM, Jason Merrill ja...@redhat.com wrote:
That looks pretty good, but do you really need to build up a separate data
structure to search? You seem to be searching it in the same order that
it's built up, so why not just walk the expansion chain directly when
On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
in this simple documentation PR, Tom noticed that we have a (very long
standing) inconsistency between the default value of -fmessage-length for
C++ as documented and as implemented: in fact it's 0 in
On Sun, Oct 16, 2011 at 5:42 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, Oct 16, 2011 at 12:31 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
On 10/16/2011 12:28 PM, Gabriel Dos Reis wrote:
On Sun, Oct 16, 2011 at 5:03 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
FWIW, I still believe that tweaking the documentation to match the long
standing reality, would be a small improvement. I'm not going to further
insist, anyway.
It isn't improvement.
The improvement would be to
On Mon, Oct 17, 2011 at 5:25 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 17, 2011 at 11:42 AM, Paolo Carlini
paolo.carl...@oracle.com wrote:
FWIW, I still believe that tweaking the documentation to match the long
standing reality, would be a small improvement. I'm not
On Mon, Oct 17, 2011 at 5:28 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 17, 2011 at 12:26 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini paolo.carl...@oracle.com
wrote:
FWIW, I still believe that tweaking
On Mon, Oct 17, 2011 at 5:53 AM, Richard Guenther rguent...@suse.de wrote:
On Mon, 17 Oct 2011, Paolo Carlini wrote:
On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
FWIW, I still believe that tweaking
On Mon, Oct 17, 2011 at 5:38 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
FWIW, I still believe that tweaking the documentation to match the long
standing
On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther rguent...@suse.de wrote:
The initial patch, split between rev. 31343 and 31999 indeed added
Thanks for helping tracking history.
+ /* Enable automatic line wrapping by default */
+ set_message_length (72);
to C++ lang_decode_option.
On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
Thus clearly the documentation is wrong ;)
;-)
Not necessarily. Paolo does not say why that line was added.
I don't remember adding that line to change the default
On Mon, Oct 17, 2011 at 6:14 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/17/2011 01:08 PM, Richard Guenther wrote:
The initial patch, split between rev. 31343 and 31999 indeed added
+ /* Enable automatic line wrapping by default */
+ set_message_length (72);
to C++
On Mon, Oct 17, 2011 at 6:19 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/17/2011 01:16 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
Thus clearly the documentation
On Mon, Oct 17, 2011 at 6:29 AM, Richard Guenther rguent...@suse.de wrote:
On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther rguent...@suse.de wrote:
The initial patch, split between rev. 31343 and 31999 indeed added
Thanks for helping tracking
On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
I would **strongly** oppose any change to 72 not strongly
motivated at least by a comparison with other high quality front-ends
I love it when you make arguments like this. It makes me smile, and
I like smiling when
On Mon, Oct 17, 2011 at 6:48 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/17/2011 01:44 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
I would **strongly** oppose any change to 72 not strongly
motivated at least
On Mon, Oct 17, 2011 at 8:32 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
here submitter requests a more accurate error message for X.Y where X is a
pointer to class type. Thus the below, tested x86_64-linux.
Ok for mainline?
s/is of pointer type/has pointer type/g
Thanks,
On Mon, Oct 17, 2011 at 12:31 PM, Jason Merrill ja...@redhat.com wrote:
On 10/17/2011 07:48 AM, Paolo Carlini wrote:
And please help
re-assessing the situation wrt the other front-ends *today* not in the
stone age.
EDG always wraps diagnostics at ~80 columns.
I did not mention the name of
On Tue, Oct 18, 2011 at 10:19 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Tue, 18 Oct 2011, David Edelsohn wrote:
Hey, Dodji,
Your patch broke bootstrap on AIX because of the typedef loc_t
introduced in tree-diagnostics.c. The typedef conflicts with a
typedef in an AIX 5.3 header
On Wed, Oct 19, 2011 at 4:34 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
in these two twin PRs filed by Ian and Gerald, it is pointed out that cases
like:
struct C {
int f() { return 1; }
};
int f(Cc) {
return ( 1 == c.f );
}
where the user actually forgot
On Wed, Oct 19, 2011 at 6:36 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/20/2011 12:32 AM, Jason Merrill wrote:
Surely we should only make this change for function members.
Thanks Gaby and Jason. So, what about the below?
I believe the effect of your new patch is that if will
On Wed, Oct 19, 2011 at 7:09 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote:
I believe the effect of your new patch is that if will
always emit the suggest did you forget ()? for member functions,
even in the case where the current suggestion
On Wed, Oct 19, 2011 at 7:47 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Wed, Oct 19, 2011 at 7:09 PM, Paolo Carlini paolo.carl...@oracle.com
wrote:
On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote:
I believe the effect of your new patch is that if will
always emit
On Fri, Oct 21, 2011 at 12:52 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
Hi again,
Another acceptable fix is to
-- leave the current diagnostic as is if -fms-extensions
-- suggest '()' is member function
-- otherwise suggest ''.
Thanks for your help Gaby, in particular about
On Fri, Oct 21, 2011 at 5:22 PM, Mike Stump mikest...@comcast.net wrote:
On Oct 21, 2011, at 12:52 PM, Jason Merrill wrote:
On 10/21/2011 03:11 PM, Marc Glisse wrote:
Note that at least clang now defines __cplusplus to its new C++11 value
(in experimental C++0X mode only). Apparently they
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazou ebotca...@adacore.com wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors for config/i386/i386.c on my x86-64 machine. But are we
sure that we want to warn on
static unsigned HOST_WIDE_INT unknown[4] = {
On Sun, Oct 23, 2011 at 4:28 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/23/2011 11:05 PM, Gabriel Dos Reis wrote:
On Sun, Oct 23, 2011 at 3:45 PM, Eric Botcazouebotca...@adacore.com
wrote:
Anyway, the below appears to work for me. Eric shall I commit it?
I have other errors
On Sun, Oct 23, 2011 at 8:48 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 10/24/2011 03:30 AM, Gabriel Dos Reis wrote:
We do not use -W or -Wno- to suppressed *required* diagnostics. So, when
-std=c++0x, -Wno-narrowing should not have any effect.
Personally, I have no problem
On Sun, Oct 23, 2011 at 9:16 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 10/24/2011 04:10 AM, Gabriel Dos Reis wrote:
Before the patch, -std=c++0x effectively put off -Wc++0x-compat because we
are compiling c++98/c++03 code, so we can only *warn* about possible
compatibility conflict
On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes -W) and also, as requested
by Gaby, preventing -Wno-narrowing from suppressing the
On Mon, Oct 24, 2011 at 7:18 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On Mon, Oct 24, 2011 at 6:47 AM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
Hi,
the below is a new variant removing -Wc++0x-compat from -Wall (cannot be
added to -Wextra either because bootstrap passes
On Mon, Oct 24, 2011 at 8:06 AM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 07:47 AM, Paolo Carlini wrote:
[...]
and also, as
requested by Gaby, preventing -Wno-narrowing from suppressing the
warning in C++0x mode (if the user really needs to silence it,
-Wno-c++0x-compat works). I
On Mon, Oct 24, 2011 at 8:29 AM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 09:26 AM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 8:06 AM, Jason Merrillja...@redhat.com wrote:
No. I added -Wno-narrowing specifically to suppress the diagnostic in
C++0x
mode; see c++/49793
On Mon, Oct 24, 2011 at 9:10 AM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 09:49 AM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 8:29 AM, Jason Merrillja...@redhat.com wrote:
Right, -Wno-long-long is only useful in C++03 and C90. But it does in
fact
suppress a standard
On Mon, Oct 24, 2011 at 9:53 AM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 10:39 AM, Gabriel Dos Reis wrote:
Hmm, the narrowing semantics also affects SFINAE, not just simple
declaration.
If we want a flag that can also affect the outcome of overload
resolution, it should one
On Mon, Oct 24, 2011 at 12:46 PM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 01:21 PM, Gabriel Dos Reis wrote:
On Mon, Oct 24, 2011 at 9:53 AM, Jason Merrillja...@redhat.com wrote:
So, if you make -Wno-narrowing meaningful in C++11 mode then how can
it not affect sfinae (case 1.b
On Mon, Oct 24, 2011 at 1:17 PM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 02:13 PM, Gabriel Dos Reis wrote:
The problem is with C++11 codes. There is no reason for them to be
subjected
to the inconsistency, especially for codes in header files that are
upgraded (beyond control
On Mon, Oct 24, 2011 at 2:05 PM, Jason Merrill ja...@redhat.com wrote:
On 10/24/2011 02:47 PM, Gabriel Dos Reis wrote:
What about (testcase)
int f(char);
double f(...);
const int n = sizeof f({257});
?
The narrowing conversion would be marked as 'bad' and therefore
On Thu, Oct 27, 2011 at 6:02 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
tested x86_64-linux (with _GLIBCXX_USE_C99_COMPLEX_TR1 manually set to zero
for the affected function), committed to mainline. Will go in 4.6.3 too.
Hmm, why is the test of the form x 0.0, and not testing the
On Thu, Oct 27, 2011 at 8:19 AM, Paolo Carlini pcarl...@gmail.com wrote:
Hi,
On Thu, Oct 27, 2011 at 6:02 AM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Hi,
tested x86_64-linux (with _GLIBCXX_USE_C99_COMPLEX_TR1 manually set to zero
for the affected function), committed to mainline.
On Thu, Oct 27, 2011 at 8:21 AM, Paolo Carlini pcarl...@gmail.com wrote:
Hi again,
Hmm, why is the test of the form x 0.0, and not testing the sign of x?
Actually, we can as well use the std::abs, no?
Paolo
The point of using sign is so that signed zero is not
mischaracterized,
On Thu, Oct 27, 2011 at 10:19 AM, Paolo Carlini pcarl...@gmail.com wrote:
Hi,
I am surprised by your comment. You do not care and that is why you
are eager to
commit the patch without checking first with fellow area maintainers?
Yes, probably my comment wan't clear enough: my point was
On Thu, Oct 27, 2011 at 2:10 PM, Dodji Seketeli do...@redhat.com wrote:
Hello,
This patch adds support for the alias-declaration feature of the c++11
specification, introduced by the paper N2258[1] and voted into in the
standard. It's a derivative work of a preliminary patch attached by
On Sun, Apr 8, 2012 at 11:10 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
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
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)
I had been thinking to check COLUMNS once at the beginning of compilation;
On Sun, Apr 8, 2012 at 11:52 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
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
On Mon, Apr 9, 2012 at 5:12 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
This patch cleans up the diagnostic initialization of the C-family
FEs. It keeps the default of no line-wrapping. It moves together all
initializations and deletes code that has no effect.
Bootstrapped and
On Mon, Apr 9, 2012 at 6:19 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 9 April 2012 12:43, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Mon, Apr 9, 2012 at 5:12 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
* c-common.h (c_common_initialize_diagnostics
On Tue, Apr 10, 2012 at 10:25 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
It is a C-family FE function, not sure how it ended up in stmt.c.
OK to commit?
OK.
On Tue, Apr 10, 2012 at 11:46 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 10 April 2012 00:28, Jason Merrill ja...@redhat.com wrote:
On 04/09/2012 04:01 PM, Manuel López-Ibáńez wrote:
* It uses the default cutoff as max_width, whatever it is (as
controlled by -fmessage-length).
On Tue, Apr 10, 2012 at 5:23 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 10, 2012, at 11:52 AM, Gabriel Dos Reis wrote:
On Tue, Apr 10, 2012 at 11:46 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 10 April 2012 00:28, Jason Merrill ja...@redhat.com wrote:
On 04/09/2012 04:01
On Tue, Apr 10, 2012 at 7:54 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 10, 2012, at 4:37 PM, Gabriel Dos Reis wrote:
You should check the environment first
I don't think we should have a knob for this.
This is fully mystifying to me and I still do not understand what it is all
On Tue, Apr 10, 2012 at 2:37 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 10 April 2012 20:52, Gabriel Dos Reis g...@integrable-solutions.net
wrote:
On Tue, Apr 10, 2012 at 11:46 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 10 April 2012 00:28, Jason Merrill ja
the value directly. But I will remove it.
On 04/10/2012 02:52 PM, Gabriel Dos Reis wrote:
There is a novelty in this new version that I don't think we discussed
before: automatic expansion of tabs to 8 hard space characters. That
number should not be hardcoded as there is no reason to believe a tab
On Wed, Apr 11, 2012 at 3:46 AM, Dodji Seketeli do...@redhat.com wrote:
There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null). NULL is defined as a
macro in a system header, so calling warning or warning_at on a virtual
location of NULL
On Wed, Apr 11, 2012 at 3:59 AM, Dodji Seketeli do...@redhat.com wrote:
Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location
On Thu, Apr 12, 2012 at 11:53 AM, Tom Tromey tro...@redhat.com wrote:
Gaby == Gabriel Dos Reis g...@integrable-solutions.net writes:
Manuel So, in fact, libcpp is buggy for not implementing this (as can be seen
Manuel in emacs). If/When libcpp is fixed, the column info will be correct
Manuel
On Mon, Apr 16, 2012 at 12:42 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect, then print
the caret pointing to the symbol in question; otherwise (b) print the
symbol
On Mon, Apr 16, 2012 at 8:31 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On Mon, Apr 16, 2012 at 12:42 AM, Marc Glissemarc.gli...@inria.fr
wrote:
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect
Do no use 'char' as the type of a flag. Prefer 'unsigned int'.
On Sat, Apr 21, 2012 at 8:57 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
As noticed by Jason in PR 2485. The current output with caret
diagnostics is a bit verbose in some cases:
wa2.C: In function ‘int main()’:
On Sat, Apr 21, 2012 at 9:41 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
Hi Gabriel,
I hope you meant to send this OK also to gcc-patches.
Indeed.
Cheers,
Manuel.
On 21 April 2012 16:25, Gabriel Dos Reis g...@integrable-solutions.net
wrote:
OK.
On Sat, Apr 21, 2012 at 9:06
On Sat, Apr 21, 2012 at 9:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Apr 21, 2012 at 04:26:32PM +0200, Manuel López-Ibáñez wrote:
On 21 April 2012 16:22, Gabriel Dos Reis g...@integrable-solutions.net
wrote:
Do no use 'char' as the type of a flag. Prefer 'unsigned int'.
Thanks
I don't think the proper fix is to copy Clang.
Clang isn't the gold standard and we shouldn't
act as if it was.
When caret is not enable, the diagnostic should mention
clearly the elements in the input expressions that are problematic
without getting obtuse or elliptic -- two extremes easy to
On Sun, Apr 22, 2012 at 10:50 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
This patch makes Wpedantic the canonical form of -pedantic. This makes
-Wno-pedantic, -Werror=pedantic, #pragma diagnostics and other parts
of the diagnostic machinery that expect warning options to start with
On Sun, Apr 22, 2012 at 11:00 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
As described by Linus here:
Interestingly, the C++ FE does not warn for this case, but it is not
very clear to me where this decision is taken.
C++'s type system does not make it very likely to get into the
On Sun, Apr 22, 2012 at 2:15 PM, Jason Merrill ja...@redhat.com wrote:
On 04/22/2012 02:42 PM, Manuel López-Ibáńez wrote:
Which seems to suggest that we add an option name for each pedwarn
enabled by default. Is this also what you suggest?
I agree with this, and I think that's also what
On Sun, Apr 22, 2012 at 2:38 PM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
For example, -Wmain is enabled by default but also by -Wall and
-pedantic. However, -Werror=all does not enable -Werror=main. Is this
a bug or the desired behaviour?
this particular one is a bug.
1 - 100 of 570 matches
Mail list logo
