Re: [Bug c++/45383] [4.5/4.6 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.

[Dodji Seketeli]

A candidate fix has been proposed at 
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01129.html

Re: [Bug debug/45024] wrong nesting for inner template class

[Dodji Seketeli]

Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01718.html

Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[Dodji Seketeli]

"manu at gcc dot gnu dot org"  writes:

>> 
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')


> Also, what are the column numbers pointing to? They don't make sense
> to me.

About this line:
>> While expanding macro OPERATE at test.c:2:8

which is about:
#define OPERATE(OPRD1, OPRT, OPRD2) \
 OPRD1 OPRT OPRD2;

Column 8 is the starting column of the OPRT token.

About this line:
>> While expanding macro SHIFTL at test.c:5:14

which is about:
#define SHIFTL(A,B) \
  OPERATE (A,<<,B)

Column 14 is the starting column of the '<<' token.

About this line:
>> While expanding macro MULT2 at test.c:8:3

which is about:
#define MULT2(A) \
  SHIFTL (A,1)

Column 3 is the starting column of the 'SHIFT' token.

> In any case, this is a huge step forward! Thanks for working on this. It would
> be an important marketing point if you manage to complete it for GCC
> 4.6.

No problem ;) Not sure it'll get into 4.6, but I'll try.

Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[Dodji Seketeli]

"manu at gcc dot gnu dot org"  writes:

> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.

I guess you are talking about the "automatic macro expansion" section of
that link?

>
> In fact, clang's output actually follows more closely what GCC already does
> with templates/inline functions.

Well, this is obviously a first step in that direction. I'd be more
interested in knowing what I can do at *this* step :-)

But yes, once I can bootstrap all the FEs with the macro location
tracking infrastructure in place with no regression, I guess I'll focus
more on the user visible output.

Re: [Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend of a builtin function

[Dodji Seketeli]

Indeed. I am testing the patch below.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 5eb389f..7c01ee2 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -104,6 +104,7 @@ static void store_parm_decls (tree);
 static void initialize_local_var (tree, tree);
 static void expand_static_init (tree, tree);
 static tree next_initializable_field (tree);
+static int decls_match_1 (tree, tree, bool);
 
 /* The following symbols are subsumed in the cp_global_trees array, and
listed here individually for documentation purposes.
@@ -899,6 +900,14 @@ push_local_name (tree decl)
 int
 decls_match (tree newdecl, tree olddecl)
 {
+  return decls_match_1 (newdecl, olddecl, /* newdecl_is_friend  */ false);
+}
+
+/* Subroutine of decls_match.  */
+
+static int
+decls_match_1 (tree newdecl, tree olddecl, bool newdecl_is_friend)
+{
   int types_match;
 
   if (newdecl == olddecl)
@@ -934,9 +943,11 @@ decls_match (tree newdecl, tree olddecl)
 
 #ifdef NO_IMPLICIT_EXTERN_C
   /* A new declaration doesn't match a built-in one unless it
-is also extern "C".  */
+is also extern "C". Friend function re-declarations retain the
+the linkage of the original declaration though.  */
   if (DECL_BUILT_IN (olddecl)
- && DECL_EXTERN_C_P (olddecl) && !DECL_EXTERN_C_P (newdecl))
+ && DECL_EXTERN_C_P (olddecl) && !DECL_EXTERN_C_P (newdecl)
+ && !newdecl_is_friend)
return 0;
 #endif
 
@@ -1122,7 +1133,7 @@ duplicate_decls (tree newdecl, tree olddecl, bool 
newdecl_is_friend)
   if (newdecl == olddecl)
 return olddecl;
 
-  types_match = decls_match (newdecl, olddecl);
+  types_match = decls_match_1 (newdecl, olddecl, newdecl_is_friend);
 
   /* If either the type of the new decl or the type of the old decl is an
  error_mark_node, then that implies that we have already issued an

Re: [Bug c++/40808] [4.4/4.5 regression] member template specialization causes ICE

[Dodji Seketeli]

Posted a patch at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01469.html

-- 
Dodji Seketeli
Red Hat

Re: [Bug c++/7932] Emit debug information about non-type template parameters

[Dodji Seketeli]

Le 01/09/2009 00:05, bangerth at gmail dot com a écrit :

> What does GDB currently say for the testcase shown in the initial report?

I think GDB doesn't know about the new type debug information added by gcc
yet. So it won't say anything. But I haven't test GDB HEAD. My reasoning
was that maybe we could open a GDB bug to track this there now that we
generate debug info for this case ? Or is there a GDB bug opened for this
already ?