Hi Paolo,
On 9 Aug 2013, at 16:47, Paolo Carlini wrote:
> On 08/09/2013 05:22 PM, David Edelsohn wrote:
>> Exactly. What is the common factor on AIX, Darwin and Solaris that is
>> different from Linux? A difference in system types? How can we help?
> Thanks David, all, for your kind offers.
>
>
Hi,
On 08/09/2013 05:22 PM, David Edelsohn wrote:
Exactly. What is the common factor on AIX, Darwin and Solaris that is
different from Linux? A difference in system types? How can we help?
Thanks David, all, for your kind offers.
As I said the issue is weird, I think the only way in practice
On Fri, Aug 9, 2013 at 7:35 AM, Iain Sandoe wrote:
>
> On 9 Aug 2013, at 12:12, Paolo Carlini wrote:
>
>> On 08/09/2013 12:52 PM, domi...@lps.ens.fr wrote:
>>> On x86_64-apple-darwin10, g++.dg/lookup/typedef2.C fails with
>>>
>>> FAIL: g++.dg/lookup/typedef2.C -std=c++11 (test for excess errors)
>
.. reverted.
Paolo.
Iain Sandoe writes:
> On 9 Aug 2013, at 12:12, Paolo Carlini wrote:
>
>> On 08/09/2013 12:52 PM, domi...@lps.ens.fr wrote:
>>> On x86_64-apple-darwin10, g++.dg/lookup/typedef2.C fails with
>>>
>>> FAIL: g++.dg/lookup/typedef2.C -std=c++11 (test for excess errors)
>>> Excess errors:
>>> /opt/gcc/
On 9 Aug 2013, at 12:12, Paolo Carlini wrote:
> On 08/09/2013 12:52 PM, domi...@lps.ens.fr wrote:
>> On x86_64-apple-darwin10, g++.dg/lookup/typedef2.C fails with
>>
>> FAIL: g++.dg/lookup/typedef2.C -std=c++11 (test for excess errors)
>> Excess errors:
>> /opt/gcc/work/gcc/testsuite/g++.dg/look
On 08/09/2013 12:52 PM, domi...@lps.ens.fr wrote:
On x86_64-apple-darwin10, g++.dg/lookup/typedef2.C fails with
FAIL: g++.dg/lookup/typedef2.C -std=c++11 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12: error: using
typedef-name 'Foo1::Bar' afte
On x86_64-apple-darwin10, g++.dg/lookup/typedef2.C fails with
FAIL: g++.dg/lookup/typedef2.C -std=c++11 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12: error: using
typedef-name 'Foo1::Bar' after 'struct'
/opt/gcc/work/gcc/testsuite/g++.dg/lookup
Hi
Jason Merrill ha scritto:
>Probably the same reason that subtle changes in the testcase changed
>whether the bug appeared on x86_64-linux. I guess we should figure
>that
>out instead of just saying "hunh, that's odd."
For sure. Let's see if I can in a reasonable amount of time on x86_64-l
On Thu, Aug 8, 2013 at 8:24 PM, Jason Merrill wrote:
> On 08/08/2013 02:31 PM, Paolo Carlini wrote:
>>
>> On 08/08/2013 08:18 PM, David Edelsohn wrote:
>>>
>>> Why does the patch and fix have any architecture or OS-dependency?
>
>
> Probably the same reason that subtle changes in the testcase chan
On 08/08/2013 02:31 PM, Paolo Carlini wrote:
On 08/08/2013 08:18 PM, David Edelsohn wrote:
Why does the patch and fix have any architecture or OS-dependency?
Probably the same reason that subtle changes in the testcase changed
whether the bug appeared on x86_64-linux. I guess we should figur
On 08/08/2013 08:31 PM, Paolo Carlini wrote:
On 08/08/2013 08:18 PM, David Edelsohn wrote:
Why does the patch and fix have any architecture or OS-dependency?
It's tricky, but it depends on the way are internally stored and
handled *multiple* TYPE_DECL for essentially the same typedef. The
clas
On 08/08/2013 08:18 PM, David Edelsohn wrote:
Why does the patch and fix have any architecture or OS-dependency?
It's tricky, but it depends on the way are internally stored and handled
*multiple* TYPE_DECL for essentially the same typedef. The class layout
must involve both such typedef and a
Why does the patch and fix have any architecture or OS-dependency?
- David
On Thu, Aug 8, 2013 at 1:57 PM, Paolo Carlini wrote:
> On 08/08/2013 07:35 PM, David Edelsohn wrote:
>>
>> I'm now seeing a new testsuite failure:
>>
>> FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors)
>
On 08/08/2013 07:35 PM, David Edelsohn wrote:
I'm now seeing a new testsuite failure:
FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12:
error: using typedef-name 'Foo1::Bar' after 'struct'
/nas
I'm now seeing a new testsuite failure:
FAIL: g++.dg/lookup/typedef2.C -std=c++98 (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/lookup/typedef2.C:8:12:
error: using typedef-name 'Foo1::Bar' after 'struct'
/nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/looku
Hi,
On 08/07/2013 01:08 AM, Jason Merrill wrote:
On 08/06/2013 06:14 PM, Paolo Carlini wrote:
Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the new testcase?
Sure.
Thanks. Thus after a further round of testing I'm going to apply the below.
Thanks,
P
On 08/06/2013 06:14 PM, Paolo Carlini wrote:
Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the new testcase?
Sure.
Jason
Hi,
On 08/06/2013 11:19 PM, Jason Merrill wrote:
I mean something like
class Foo
{
int u, v, w;//, x;
typedef struct Bar { } Bar;
int Bar;
virtual void foo(void) {
struct Bar bar;
}
};
Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the ne
On 08/06/2013 05:26 AM, Paolo Carlini wrote:
That's strange. I would expect that to mean that we don't properly
give an error for a Bar data member declared after the typedef.
You mean something like this?
class Foo
{
int u, v, w;//, x;
typedef struct Bar { } Bar;
Bar bar;
virtua
... today I did the following: commented out the error at issue
(decl.c:11828) and ran the testsuite. The attached js.txt is the list of
fails. Wanted to make sure that we have enough coverage.
I'm also attaching here the complete patch + testcase which passes boot
& test.
Thanks!
Paolo.
//
Hi,
On 08/06/2013 04:57 AM, Jason Merrill wrote:
On 08/05/2013 06:46 PM, Paolo Carlini wrote:
and after this comment, both pairs of qualify_lookup are called in that
order. Thus I started seriously suspecting that something may be wrong
in the if-else above, that is, that we really want somethi
On 08/05/2013 06:46 PM, Paolo Carlini wrote:
and after this comment, both pairs of qualify_lookup are called in that
order. Thus I started seriously suspecting that something may be wrong
in the if-else above, that is, that we really want something with
iter->type *before* iter->value there too:
Hi,
I have been investigating this very old and very weird issue where we
wrongly reject:
class Foo
{
int u, v, w, x;
typedef struct Bar { } Bar;
virtual void foo(void) {
struct Bar bar;
}
};
46206.C: In member function ‘virtual void Foo::foo()’:
46206.C:6:12: error: using typedef-name ‘Foo::
24 matches
Mail list logo
