On 04/07/14 14:22, Jason Merrill wrote:
On 04/07/2014 03:39 AM, Nathan Sidwell wrote:
Jason, I shall leave it to your discretion as to whether we should
continue with this patch, or revert the original one (for 4.9).
This is OK. Post 4.9 we might try removing the warn_ecpp check and see how t
On 04/07/2014 03:39 AM, Nathan Sidwell wrote:
Jason, I shall leave it to your discretion as to whether we should
continue with this patch, or revert the original one (for 4.9).
This is OK. Post 4.9 we might try removing the warn_ecpp check and see
how that is received.
Jason
On 2014.04.07 at 08:39 +0100, Nathan Sidwell wrote:
> On 04/06/14 10:50, Markus Trippelsdorf wrote:
> > On 2014.04.06 at 09:13 +0100, Nathan Sidwell wrote:
> >> On 04/04/14 18:33, Nathan Sidwell wrote:
> >>
> >>> I'm testing a patch that makes the test in the loop:
> >>>
> >>> if (TREE_PUBL
On 04/06/14 10:50, Markus Trippelsdorf wrote:
On 2014.04.06 at 09:13 +0100, Nathan Sidwell wrote:
On 04/04/14 18:33, Nathan Sidwell wrote:
I'm testing a patch that makes the test in the loop:
if (TREE_PUBLIC (base_binfo)
Hm, binfo's aren't noted that way, it's encoded in BINFO_ACCES
On 2014.04.06 at 09:13 +0100, Nathan Sidwell wrote:
> On 04/04/14 18:33, Nathan Sidwell wrote:
>
> > I'm testing a patch that makes the test in the loop:
> >
> >if (TREE_PUBLIC (base_binfo)
>
> Hm, binfo's aren't noted that way, it's encoded in BINFO_ACCESS and
> SET_BINFO_ACCESS in sear
On 04/04/14 18:33, Nathan Sidwell wrote:
I'm testing a patch that makes the test in the loop:
if (TREE_PUBLIC (base_binfo)
Hm, binfo's aren't noted that way, it's encoded in BINFO_ACCESS and
SET_BINFO_ACCESS in search.c. We'd need to move those back to cp.h or expose an
interface in
On 04/04/14 18:19, Jason Merrill wrote:
I also notice that the opt_storage destructor is implicitly declared and
trivial; it seems excessive to warn in that case.
I disagree, I think that's exactly a case that should be warned about -- because
it's easy to overlook.
I'm also somewhat skep
On 2014.04.04 at 18:04 +0100, Nathan Sidwell wrote:
> On 04/04/14 17:54, Markus Trippelsdorf wrote:
>
> > markus@x4 tmp % g++ -Wnon-virtual-dtor -std=c++11 -c test.ii
> > test.ii: In instantiation of ‘class A<>’:
> > test.ii:12:16: required from here
> > test.ii:9:26: warning: base class ‘class
On 04/04/2014 01:04 PM, Nathan Sidwell wrote:
On 04/04/14 17:54, Markus Trippelsdorf wrote:
markus@x4 tmp % g++ -Wnon-virtual-dtor -std=c++11 -c test.ii
test.ii: In instantiation of ‘class A<>’:
test.ii:12:16: required from here
test.ii:9:26: warning: base class ‘class opt_storage<0>’ has
acc
On 04/04/14 17:54, Markus Trippelsdorf wrote:
markus@x4 tmp % g++ -Wnon-virtual-dtor -std=c++11 -c test.ii
test.ii: In instantiation of ‘class A<>’:
test.ii:12:16: required from here
test.ii:9:26: warning: base class ‘class opt_storage<0>’ has accessible
non-virtual destructor [-Wnon-virtual-
On 2014.04.04 at 17:48 +0100, Nathan Sidwell wrote:
> On 04/04/14 17:38, Markus Trippelsdorf wrote:
>
> > I'm not sure that this is a good idea. This changes the existing
> > behavior of -Wnon-virtual-dtor and causes hundreds of new warnings when
> > building LLVM. Wouldn't it make more sense to m
On 04/04/14 17:38, Markus Trippelsdorf wrote:
I'm not sure that this is a good idea. This changes the existing
behavior of -Wnon-virtual-dtor and causes hundreds of new warnings when
building LLVM. Wouldn't it make more sense to move the 3rd ed Weffc++
behavior to the -Weffc++ flag alone?
IIUC
On 2014.03.31 at 14:03 +0100, Nathan Sidwell wrote:
> This patch fixes some unexpected behaviour of the Weffc++ and
> Wnon-virtual-dtor
> flags. The documentation for the latter says it's also enabled by Weffc++,
> but
> that's untrue.
>
> The current behaviour of Weffc++ is to warn about any
13 matches
Mail list logo
