[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function

2006-07-11 Thread reichelt at igpm dot rwth-aachen dot de


--- Comment #8 from reichelt at igpm dot rwth-aachen dot de  2006-07-11 
09:15 ---
Subject: Re:  [4.0/4.1 regression] ICE with struct definition in
 argument of template function

On 10 Jul, sje at cup dot hp dot com wrote:
 
 
 --- Comment #7 from sje at cup dot hp dot com  2006-07-10 20:46 ---
 I have checked in a patch for ToT and on the 4.1 branch.  My inclination is to
 not fix this on the 4.0 branch because the patch doesn't apply automatically. 
 The same change is probably needed somewhere else for 4.0, but I don't think 
 it
 is worth the trouble to find out where.

Well, with some trivial changes (whitespace, different number of
parameters for pushdecl_with_scope) the patch applies to the 4.0 branch:

===
--- gcc/gcc/cp/name-lookup.c(revision 115324)
+++ gcc/gcc/cp/name-lookup.c(working copy)
@@ -4666,7 +4666,11 @@ pushtag (tree name, tree type, tag_scope
pushdecl_class_level (decl);
}
  else if (b-kind != sk_template_parms)
-   decl = pushdecl_with_scope (decl, b);
+   {
+ decl = pushdecl_with_scope (decl, b);
+ if (decl == error_mark_node)
+   POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, decl);
+   }

  /* FIXME what if it gets a name from typedef?  */
  if (ANON_AGGRNAME_P (name))
===

Would you mind testing this on the 4.0 branch? Or should I do that?

 Should I close this out as  fixed in 4.1.2?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114



[Bug c/27489] [4.1/4.2 regression] ICE on broken switch condition

2006-05-15 Thread reichelt at igpm dot rwth-aachen dot de


--- Comment #6 from reichelt at igpm dot rwth-aachen dot de  2006-05-15 
14:31 ---
Subject: Re:  [4.1/4.2 regression] ICE on broken switch condition

On 14 May, mmitchel at gcc dot gnu dot org wrote:
 --- Comment #5 from mmitchel at gcc dot gnu dot org  2006-05-14 22:35 
 ---
 Is there a URL for the patch posted for this bug?

http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00337.html

It's just a RFA and not a complete patch, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27489




[Bug c/25301] [3.4 regression] ICE for sizeof of incomplete type

2005-12-07 Thread reichelt at igpm dot rwth-aachen dot de


--- Comment #3 from reichelt at igpm dot rwth-aachen dot de  2005-12-07 
20:47 ---
Subject: Re:  [3.4 regression] ICE for sizofe of incomplete type

On  7 Dec, gdr at integrable-solutions dot net wrote:

 In general, there is a type problem in both C and C++ front ends.
 The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as
 opposed to an IDENTIFIER_NODE.  However, at various occasions I found
 that a TYPE_NAME would return an IDENTIFIER_NODE.  That is a clear bug
 in both front ends ans should be hunt.  Obviously, you have identified a
 place where instead of correcting the problem the pretty-printer had
 assumed that TYPE_NAME will always return an IDENTIFIER_NODE --
 despite the documentation.  I believe a proper PR should be filled so
 that both front ends are cured from that confusion. 
 
 -- Gaby

Would you mind filing this PR then?

Thanks,
Volker


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301



[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code

2005-11-29 Thread reichelt at igpm dot rwth-aachen dot de


--- Comment #6 from reichelt at igpm dot rwth-aachen dot de  2005-11-29 
18:44 ---
Subject: Re:  [4.0/4.1/4.2 Regression] ICE on throw code

On 29 Nov, janis at gcc dot gnu dot org wrote:
 Andrew, are you sure about 3.4.0 crashing for this testcase?  I tried mainline
 as far back as 2003-03-08 at regular intervals and saw no failures before the
 tree-ssa merge.

I can see the failure in 3.4.0 on i686-pc-linux-gnu and
x86_64-unknown-linux-gnu. This is a segfault, however, and
therefore probably caused a different problem.

Regards,
Volker


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996



[Bug c/24455] [gomp] Trouble with threadprivate and extern

2005-10-20 Thread reichelt at igpm dot rwth-aachen dot de


--- Comment #3 from reichelt at igpm dot rwth-aachen dot de  2005-10-20 
16:50 ---
Subject: Re:  [gomp] Trouble with threadprivate and extern

On 20 Oct, dnovillo at redhat dot com wrote:
 
 
 --- Comment #1 from dnovillo at redhat dot com  2005-10-20 16:45 ---
 Subject: Re:   New: [gomp] Trouble with threadprivate and extern
 
 On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
 
 I'd expect that i is threadprivate in file1.c and file2.c.

 But you have to mark it so in both places.
 
 Am I misreading the OpenMP spec or is this a bug in the frontends?

 I think you're misreading the spec, in 2.8.2. page 69, lines 4-6:
 
 If a variable is specified in a threadprivate directive in one translation 
 unit, it must be specified in a threadprivate directive in every 
 translation unit in which it is declared.

Doesn't translation unit cover the include file?

But anyway. How should I mark it threadprivate in file2.c?
Adding #pragma omp threadprivate (i) before or after int i;
doesn't work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24455



[Bug translation/21768] [3.4 regression] ICE in error message due to violation of coding conventions

2005-08-31 Thread reichelt at igpm dot rwth-aachen dot de

--- Additional Comments From reichelt at igpm dot rwth-aachen dot de  
2005-08-31 15:39 ---
Subject: Re:  [3.4 regression] ICE in error message due
   to violation of coding conventions

On 31 Aug, bonzini at gcc dot gnu dot org wrote:
 This ought to use ngettext.

That's not necessary.
The trickery with the plural s that would have made ngettext necessary
was a violation of the coding conventions, anyway. This is already fixed
by using a different error message.

We are just waiting for a new .po file with a suitable translation.
This won't arrive until close to the release, however.
This PR is just a reminder to test whether the translation really got
fixed before spinning the release.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21768


[Bug rtl-optimization/21015] [3.3/3.4 Regression] Bad loop optimization with -O2

2005-04-14 Thread reichelt at igpm dot rwth-aachen dot de

--- Additional Comments From reichelt at igpm dot rwth-aachen dot de  
2005-04-14 09:25 ---
Subject: Re:  [3.3/3.4 Regression] Bad loop
 optimization with -O2

On 14 Apr, bonzini at gcc dot gnu dot org wrote:
 Does the patch there fix it?

Alas not.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21015


[Bug c++/12807] [tree-ssa] ICE on variable sized array in class

2003-10-28 Thread reichelt at igpm dot rwth-aachen dot de
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12807



--- Additional Comments From reichelt at igpm dot rwth-aachen dot de  2003-10-28 
10:45 ---
Subject: Re:  [tree-ssa] ICE on variable sized array in class

On 28 Oct, falk dot hueffner at student dot uni-tuebingen dot de wrote:
 PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12807
 
 
 
 --- Additional Comments From falk dot hueffner at student dot uni-tuebingen dot 
 de  2003-10-28 10:31 ---
 Subject: Re:  [tree-ssa] ICE on variable sized array in class
 
 reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
 
 Oops, the code seems to be valid.
 
 No, since the static member is not initialized with a const
 expression.  Otherwise, gcc wouldn't know sizeof() of the class.

Well, I think it's an instance of the variable sized array extension.
You just have a pointer there, as far as I understand it. The memory is
allocated in a different location at runtime. So there should be no
problem to compute sizeof().

Btw, all versions since 3.0 accept the code - and since 3.3.1 they
reject it if -pedantic is specified.



--- Additional Comments From reichelt at igpm dot rwth-aachen dot de  2003-10-28 
10:45 ---
Subject: Re:  [tree-ssa] ICE on variable sized array in class

On 28 Oct, falk dot hueffner at student dot uni-tuebingen dot de wrote:
 PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12807
 
 
 
 --- Additional Comments From falk dot hueffner at student dot uni-tuebingen dot 
 de  2003-10-28 10:31 ---
 Subject: Re:  [tree-ssa] ICE on variable sized array in class
 
 reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
 
 Oops, the code seems to be valid.
 
 No, since the static member is not initialized with a const
 expression.  Otherwise, gcc wouldn't know sizeof() of the class.

Well, I think it's an instance of the variable sized array extension.
You just have a pointer there, as far as I understand it. The memory is
allocated in a different location at runtime. So there should be no
problem to compute sizeof().

Btw, all versions since 3.0 accept the code - and since 3.3.1 they
reject it if -pedantic is specified.



--- Additional Comments From reichelt at igpm dot rwth-aachen dot de  2003-10-28 
10:45 ---
Subject: Re:  [tree-ssa] ICE on variable sized array in class

On 28 Oct, falk dot hueffner at student dot uni-tuebingen dot de wrote:

 --- Additional Comments From falk dot hueffner at student dot uni-tuebingen dot 
 de  2003-10-28 10:31 ---
 Subject: Re:  [tree-ssa] ICE on variable sized array in class
 
 reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
 
 Oops, the code seems to be valid.
 
 No, since the static member is not initialized with a const
 expression.  Otherwise, gcc wouldn't know sizeof() of the class.

Well, I think it's an instance of the variable sized array extension.
You just have a pointer there, as far as I understand it. The memory is
allocated in a different location at runtime. So there should be no
problem to compute sizeof().

Btw, all versions since 3.0 accept the code - and since 3.3.1 they
reject it if -pedantic is specified.