Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O2 (test for excess errors)
FAIL:
2012/1/20 Dominique Dhumieres domi...@lps.ens.fr:
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test for excess errors)
FAIL:
2012/1/20 Kai Tietz ktiet...@googlemail.com:
2012/1/20 Dominique Dhumieres domi...@lps.ens.fr:
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test
2012/1/18 Jason Merrill ja...@redhat.com:
I still think the problem is that we're applying the attributes more than
once, and we should only apply them once. If we fix that, we don't need to
merge them.
Jason
Well, I will try to search for it a bit more. Nevertheless is the
chaining at
On 01/19/2012 03:36 AM, Kai Tietz wrote:
Well, I will try to search for it a bit more. Nevertheless is the
chaining at this place IMHO a pretty bad idea. The merging of
attributes looks more sane. Also is this merging patch pretty less
invasive and would be fine for older branches, too.
2012/1/17 Jason Merrill ja...@redhat.com:
On 01/17/2012 02:41 PM, Kai Tietz wrote:
Right, but in second call we get for cplus_decl_attributes's
late_attrs (as result of splice_template_attributes) the same value as
already stored in decl_p's attributes.
Right, but why is it already stored
I noticed that the previous patch still had issues about more then one
attribute added. The underlying issue seems here that we shouldn't
chain attributes simply, but we should merge them.
I did full bootstrap for it and ran regression tests for
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
I still think the problem is that we're applying the attributes more
than once, and we should only apply them once. If we fix that, we don't
need to merge them.
Jason
Hello,
this hang is caused by an end-less loop in private_lookup_attribute
caused by double-chaining of attributes in decl2.c's
save_template_attributes function. In save_template_attributes we
need to check that attribute-list isn't equal to late_attrs before
chaining them.
ChangeLog gcc/cp
How does this happen? Are we setting DECL_ATTRIBUTES twice?
Jason
2012/1/17 Jason Merrill ja...@redhat.com:
How does this happen? Are we setting DECL_ATTRIBUTES twice?
Jason
Yes, we call it for this example twice. One time in
'begin_class_definition'. and second time in 'do_friend'.
Kai
On 01/17/2012 02:30 PM, Kai Tietz wrote:
2012/1/17 Jason Merrillja...@redhat.com:
How does this happen? Are we setting DECL_ATTRIBUTES twice?
Yes, we call it for this example twice. One time in
'begin_class_definition'. and second time in 'do_friend'.
Surely the call from
2012/1/17 Jason Merrill ja...@redhat.com:
On 01/17/2012 02:30 PM, Kai Tietz wrote:
2012/1/17 Jason Merrillja...@redhat.com:
How does this happen? Are we setting DECL_ATTRIBUTES twice?
Yes, we call it for this example twice. One time in
'begin_class_definition'. and second time in
On 01/17/2012 02:41 PM, Kai Tietz wrote:
Right, but in second call we get for cplus_decl_attributes's
late_attrs (as result of splice_template_attributes) the same value as
already stored in decl_p's attributes.
Right, but why is it already stored there?
Jason
14 matches
Mail list logo
