Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-20 Thread Dominique Dhumieres 
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: g++.dg/torture/pr51344.C  -O3 -fomit-frame-pointer  (test for excess 
errors)
FAIL: g++.dg/torture/pr51344.C  -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -Os  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)

Using the original test for the pr, i.e.,

--- ../_clean/gcc/testsuite/g++.dg/torture/pr51344.C2012-01-20 
00:02:03.0 +0100
+++ gcc/testsuite/g++.dg/torture/pr51344.C  2012-01-20 10:48:07.0 
+0100
@@ -1,4 +1,6 @@
 /* { dg-do compile } */
+class A;
+
 template class T
 class B
 {

the test passes.

TIA

Dominique

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-20 Thread Kai Tietz 
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: g++.dg/torture/pr51344.C  -O2  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O3 -fomit-frame-pointer  (test for excess 
 errors)
 FAIL: g++.dg/torture/pr51344.C  -O3 -g  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -Os  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fno-use-linker-plugin 
 -flto-partition=none  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fuse-linker-plugin 
 -fno-fat-lto-objects  (test for excess errors)

 Using the original test for the pr, i.e.,

 --- ../_clean/gcc/testsuite/g++.dg/torture/pr51344.C    2012-01-20 
 00:02:03.0 +0100
 +++ gcc/testsuite/g++.dg/torture/pr51344.C      2012-01-20 10:48:07.0 
 +0100
 @@ -1,4 +1,6 @@
  /* { dg-do compile } */
 +class A;
 +
  template class T
  class B
  {

 the test passes.

 TIA

 Dominique

Duh,  I will correct it ASAP.

Thanks,
Kai

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-20 Thread Kai Tietz 
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 for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O2  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O3 -fomit-frame-pointer  (test for excess 
 errors)
 FAIL: g++.dg/torture/pr51344.C  -O3 -g  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -Os  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fno-use-linker-plugin 
 -flto-partition=none  (test for excess errors)
 FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fuse-linker-plugin 
 -fno-fat-lto-objects  (test for excess errors)

 Using the original test for the pr, i.e.,

 --- ../_clean/gcc/testsuite/g++.dg/torture/pr51344.C    2012-01-20 
 00:02:03.0 +0100
 +++ gcc/testsuite/g++.dg/torture/pr51344.C      2012-01-20 
 10:48:07.0 +0100
 @@ -1,4 +1,6 @@
  /* { dg-do compile } */
 +class A;
 +
  template class T
  class B
  {

 the test passes.

 TIA

 Dominique

 Duh,  I will correct it ASAP.

 Thanks,
 Kai

Fixed.

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-19 Thread Kai Tietz 
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 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.
The issue I see by changing here do_friend and calls to
attribute-modifier is, that it easily causes side-effects, which are
escaping underdected for awhile.

Kai

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-19 Thread Jason Merrill 

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.


That's true, let's go ahead and put in your merging patch for now, we 
can fix it better in 4.8.


Jason

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-18 Thread Kai Tietz 
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 there?

 Jason

The approach to disable cplus_decl_attributes call in do_friend (as we
assume that prior grok* function it is calling it already) doesn't
work.
Eg the tests in g++.dg/ext/attribute-test-[34].C are failing for
c++11.  do_friend is called here via grokdeclarator for 'fTest' (test
3) and the attributes weren't applied before.  So removing here in
do_friend the call of cplus_decl_attributes seems wrong.
With my orginal patch those tests are passing.

Regards,
Kai

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-18 Thread Kai Tietz 
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,
Kai

Revised patch:

Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 183106)
+++ gcc/cp/decl2.c  (working copy)
@@ -1200,9 +1200,9 @@

   old_attrs = *q;

-  /* Place the late attributes at the beginning of the attribute
+  /* Merge the late attributes at the beginning with the attribute
  list.  */
-  TREE_CHAIN (tree_last (late_attrs)) = *q;
+  late_attrs = merge_attributes (late_attrs, *q);
   *q = late_attrs;

   if (!DECL_P (*decl_p)  *decl_p == TYPE_MAIN_VARIANT (*decl_p))

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-18 Thread Jason Merrill 
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

[patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Kai Tietz 
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

2012-01-17  Kai Tietz  kti...@redhat.com

PR c++/51344
* decl2.c (save_template_attributes): Don't chain late-attributes with
attribute-list, if they are same.

ChangeLog gcc/cp

2012-01-17  Kai Tietz  kti...@redhat.com

g++.dg/torture/pr51344.C: New test.

Bootstrapped and regression tested for x86_64-unknown-linux-gnu,
x86_64-w64-mingw32, and i686-w64-mingw32. Ok for apply?

Regards,
Kai

Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 183106)
+++ gcc/cp/decl2.c  (working copy)
@@ -1202,7 +1202,8 @@

   /* Place the late attributes at the beginning of the attribute
  list.  */
-  TREE_CHAIN (tree_last (late_attrs)) = *q;
+  if (late_attrs != *q)
+TREE_CHAIN (tree_last (late_attrs)) = *q;
   *q = late_attrs;

   if (!DECL_P (*decl_p)  *decl_p == TYPE_MAIN_VARIANT (*decl_p))

Index: gcc/gcc/testsuite/g++.dg/torture/pr51344.C
===
--- /dev/null
+++ gcc/gcc/testsuite/g++.dg/torture/pr51344.C
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+template class T
+class B
+{
+  friend __attribute__((cdecl)) A operator (A a, B b)
+  {
+return a;
+  }
+};

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Jason Merrill 

How does this happen?  Are we setting DECL_ATTRIBUTES twice?

Jason

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Kai Tietz 
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

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Jason Merrill 

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 begin_class_definition isn't for the function 
declaration, though.


Jason

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Kai Tietz 
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 'do_friend'.


 Surely the call from begin_class_definition isn't for the function
 declaration, though.

 Jason

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.  By this we chain up an
endless-recusion.

Kai

Re: [patch c++]: Fix for PR c++/51344 - cc1plus hangs when compiling

2012-01-17 Thread Jason Merrill 

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