[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #10 from dodji at gcc dot gnu dot org 2009-01-13 16:50 --- Subject: Re: [4.2/4.3/4.4 Regression] template parameter does not hide class name jakub at gcc dot gnu dot org a écrit : > --- Comment #9 from jakub at gcc dot gnu dot org 2009-01-12 23:00 --- > The 4.3 version seems to be the old one, with is_* prefixes and macro, while > trunk/4.2 are the new ones. Oops, right. Fixing that now. Thanks. Dodji. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-21 22:37 ---
Subject: Re: [4.4 Regression] Revision 143546 failed to bootstrap
hjl dot tools at gmail dot com a écrit :
> --- Comment #6 from hjl dot tools at gmail dot com 2009-01-21 22:34
> ---
> A small testcase:
>
> [...@gnu-6 pr38930]$ cat x.cc
> class _Jv_Linker
> {
> private:
> typedef unsigned int uaddr __attribute__ ((mode (pointer)));
>
> };
> [...@gnu-6 pr38930]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -O2 -g x.cc -S -o x.s
> -m32
> x.cc:3: internal compiler error: in gen_typedef_die, at dwarf2out.c:14665
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> [...@gnu-6 pr38930]$
Is that with my patchlet ?
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38930
[Bug c++/40684] ICE in tsubst
--- Comment #2 from dodji at gcc dot gnu dot org 2009-07-09 13:21 --- Subject: Re: ICE in tsubst -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The patch was submitted for review at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00491.html . -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpV7n8ACgkQPejI7lrem2FcOQCfT7Fugugl7RggRNEquSTzUvSq i90An1sHpvnjNJIRRmFnUDD8AYldOWym =eQuh -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40684
[Bug debug/39706] namespaces represented incorrectly in debug_pubnames
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-27 20:43 --- Subject: Re: New: namespaces represented incorrectly in debug_pubnames I am regression testing this patchlet that seems to fix the problem in trunk ... --- Comment #2 from dodji at gcc dot gnu dot org 2009-07-27 20:43 --- Created an attachment (id=18260) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18260&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
[Bug debug/39706] namespaces represented incorrectly in debug_pubnames
--- Comment #3 from dodji at gcc dot gnu dot org 2009-07-28 12:39 --- Subject: Re: New: namespaces represented incorrectly in debug_pubnames Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01579.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
[Bug debug/39705] enum constants don't appear in debug_pubnames
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-29 12:40 --- Subject: Re: New: enum constants don't appear in debug_pubnames Le 10/04/2009 01:42, tromey at gcc dot gnu dot org a écrit : > enum constants don't appear in .debug_pubnames. > It seems like perhaps they should, because they are global (in a sense). The attached patchlet seems to be doing the trick. The entry in the .debug_pubname for a given enum constant points to the corresponding DW_TAG_enumerator DIE representing the enum constant in the .debug_info section. Is this what you meant ? --- Comment #2 from dodji at gcc dot gnu dot org 2009-07-29 12:40 --- Created an attachment (id=18267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18267&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39705
[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure
--- Comment #8 from dodji at gcc dot gnu dot org 2009-08-07 13:16 --- Subject: Re: [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure Le 07/08/2009 12:06, mikpe at it dot uu dot se a écrit : > --- Comment #5 from mikpe at it dot uu dot se 2009-08-07 10:06 --- > The test case doesn't appear to be in the repository. Oops, correct. Sorry. I have just added it. Thanks for noticing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-07 13:20 --- Subject: Re: New: [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504 Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00428.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 07:54 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : > --- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 --- > Created an attachment (id=17469) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469&action=view) > gcc44-pr39471.patch > > Untested patch. Dodji, any reason why you started emitting > DW_TAG_imported_declaration for this instead of DW_TAG_imported_module? I think this was just a confusion on my part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #5 from dodji at gcc dot gnu dot org 2009-03-17 07:59 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
> So this patch instead? C++ will never need non-NULL DECL_NAME on
> IMPORTED_DECL,
> as it doesn't have the ability to rename imports like Fortran does.
Hmmh, I think the non null name there is useful for namespace aliases in
C++, e.g.
namespace A {
int foo;
}
void
f ()
{
namespace B = A;
}
That namespace alias will be represented by a
DW_TAG_imported_declaration which DW_AT_name set to "B" and which
DW_AT_import is set to a reference to namespace A.
FWIW, the DWARF3 spec says at 3.2.3:
"A C++ namespace alias may be represented by an imported declaration
entry with a name attribute whose value is a null-terminated string
containing the alias name as it appears in the source program and an
import attribute whose value is a reference to the applicable original
namespace or namespace extension entry."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #6 from dodji at gcc dot gnu dot org 2009-03-17 08:08 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) dodji at redhat dot com a écrit : > Hmmh, I think the non null name there is useful for namespace aliases in > C++ Ah, no. We won't be going through the USING_STMT code path in case of namespace aliases, sorry. My last comment was irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #8 from dodji at gcc dot gnu dot org 2009-03-17 10:02 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : > --- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 --- > Created an attachment (id=17472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472&action=view) > gcc44-local-imported-decl.patch > > Incremental patch to emit DW_TAG_imported_declaration DIEs (other than > namespace aliases) in the right lexical blocks. > I am wondering what happens when cp_emit_debug_info_for_using is called for a using declaration that appears at global scope. Once we are in the USING_STMT case of cp_gimplify_expr, will there be an enclosing GIMPLE_BIND for the USING_STMT generated for the global using declaration ? For the record, cp_parser_using_declaration calls either do_local_using_decl or do_toplevel_using_decl, depending on if we are at local or global scope. Both do_local_using_decl and do_toplevel_using_decl end up calling cp_parser_using_declaration. > > Concerning: > "We won't be going through the USING_STMT code path in case of We won't be > going through the USING_STMT code path in case of namespace aliases, sorry. My > last comment was irrelevant." > we really should be going through USING_STMT or something similar for > namespace > aliases as well, see PR37890. Given that namespace aliases are just emitted > using gen_namespace_die, perhaps just adding the NAMESPACE_DECL to BLOCK_VARS Yeah I should try something like that in cp_gimplify_expr whenever we are handed BIND_EXPR. In that case, I can wall the BIND_EXPR_VARS of the of the BIND_EXPR and add any NAMESPACE_DECL to the BLOCK_VARS of the matching block. Would that make sense ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug c++/39444] ICE caused by default template argument
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 22:10 ---
Subject: Re: New: ICE caused by default template argument
FWIW, on gcc 4.3.2, I get the error:
test.cc: In function 'void breakMe()':
test.cc:17: error: a cast to a type other than an integral or
enumeration type cannot appear in a constant-expression
test.cc:17: error: template argument 2 is invalid
test.cc:17: error: invalid type in declaration before ';' token
The source listing annotated with line numbers is:
1 #include
2 #include
3
4 template
5 class Filter
6 {
7 public:
8 virtual const std::string& getFilterName() const
9 {
10static const std::string name = filterName;
11return name;
12 }
13 };
14
15 void breakMe()
16 {
17 Filter boo;
18 }
19
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39444
[Bug c++/39679] Some absent attributes in the tree-dump should be added
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-08 09:53 --- Subject: Re: Some absent attributes in the tree-dump should be added pinskia at gcc dot gnu dot org a écrit : > --- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-07 18:28 > --- > this dump file is only supposed to be used to debug gcc. True. For what it is worth, you might want to post your patch to gcc-patc...@gcc.gnu.org so that it has more exposure and triggers more discussion. For patches, the gcc-patches mailing list tends to get more exposure to the GCC hackers than the bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
[Bug c++/39684] GCC accepts template keyword where Comeau rejects it.
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-08 16:43 --- Subject: Re: GCC accepts template keyword where Comeau rejects it. bangerth at gmail dot com a écrit : > --- Comment #2 from bangerth at gmail dot com 2009-04-08 13:11 --- > The testcase is indeed invalid. We should reject it. Sorry, could you explain why the test case is invalid ? I am not sure if it is invalid or not actually :) The C++ spec in 14.2 [temp.names], point 5 says: "If a name prefixed by the keyword template is not the name of a template, the program is ill-formed." In our case, the name "search" is the name of a template. The same point 5 later says: "As is the case with the typename prefix, the template prefix is allowed in cases where it is not strictly necessary; i.e., when the nested-name-specifier or the expression on the left of the -> or . is not dependent on a template-parameter, or the use does not appear in the scope of a template." So, I would be inclined to think that we are in a case where the 'template' keyword is not is necessary. But does that make its use invalid ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39684
[Bug c++/39699] No error reporting when function and variable have the same name
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-10 11:46 ---
Subject: Re: No error reporting when function and variable
have the same name
alpha dot super-one at laposte dot net a écrit :
> --- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
> 04:47 ---
So I compiled this program:
1 class toto
2 {
3enum e {a,b};
4e test_example();
5e test_example;
6 };
7
8 toto t;
with the -Wall option of g++ 4.3.2, I got:
test.cc:5: error: declaration of 'toto::e toto::test_example'
test.cc:4: error: conflicts with previous declaration 'toto::e
toto::test_example()'
So that does what you want I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
[Bug c++/41187] g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64
--- Comment #1 from dodji at gcc dot gnu dot org 2009-08-29 21:15 ---
Subject: Re: New: g++.dg/debug/dwarf2/namespace-1.C failed
on Linux/ia64
Le 29/08/2009 22:57, hjl dot tools at gmail dot com a écrit :
> On Linux/ia64, I got
>
> FAIL: g++.dg/debug/dwarf2/namespace-1.C scan-assembler-times .ascii "T.0"[
>
> ]+# DW_AT_name 1
>
> The assembly output has
>
> .ascii "T\0"// DW_AT_name
>
> There is no trailing '1'.
I think the problem is more that there is a "//" before DW_AT_name, instead
of a #. The 1 is the second argument to scan-assembler-times, and as such,
is not part of the regular expression.
In the file g++.dg/debug/dwarf2/namespace-1.C , If you replace the line:
// { dg-final { scan-assembler-times "\.ascii \"T.0\"\[\t \]+# DW_AT_name"
1 } }
with:
// { dg-final { scan-assembler-times "\.ascii \"T.0\"\[\t \]+. DW_AT_name"
1 } }
Does it fix the problem to you ? If yes, I'll commit the patch under the
obvious rule.
Sorry, I don't have an ia64 box at hand to test myself.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41187
[Bug c++/41187] g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-29 21:25 ---
Subject: Re: New: g++.dg/debug/dwarf2/namespace-1.C failed
on Linux/ia64
I think the correct line should rather be:
// { dg-final { scan-assembler-times "\.ascii \"T.0\"\[\t \]+.*?DW_AT_name"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41187
[Bug c++/41187] g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64
--- Comment #5 from dodji at gcc dot gnu dot org 2009-08-29 21:31 --- Subject: Re: g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64 Le 29/08/2009 23:29, hjl dot tools at gmail dot com a écrit : > Do we need ".*?"? Shouldn't it be just ".*"? I tend to use .*? because .* can be too greedy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41187
[Bug c++/7932] Emit debug information about non-type template parameters
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-31 22:14 --- Subject: Re: Emit debug information about non-type template parameters 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 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7932
[Bug debug/41272] FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times \(DIE \(.*?\) DW_TAG_in lined_subroutine 6
--- Comment #5 from dodji at gcc dot gnu dot org 2009-09-07 10:26 --- Subject: Re: FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times \(DIE \(.*?\) DW_TAG_in lined_subroutine 6 Le 05/09/2009 12:05, rguenth at gcc dot gnu dot org a écrit : > They are platform dependent in that non-register operations are accounted > according to their move cost. Thus if at all it is > > int* a = 0; > a[0] = var3; > > that makes the difference. You can either increase optimization level > or the inlining parameters. Thanks Richard. So, would adding __attribute__((always_inline)) to those function be acceptable ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41272
[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend of a builtin function
--- Comment #8 from dodji at gcc dot gnu dot org 2009-10-23 18:19 ---
Subject: Re: [4.5 Regression] Can't declare an extern "C"
friend of a builtin function
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend of a builtin function
--- Comment #9 from dodji at gcc dot gnu dot org 2009-10-23 19:32 --- Subject: Re: New: Can't declare an extern "C" friend. Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01486.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41785] [4.5 Regression] [C++0x] ICE on canonical types with variadic templates and CRTP
--- Comment #5 from dodji at gcc dot gnu dot org 2009-10-25 17:47 ---
Subject: Re: New: ICE on canonical types with variadic
templates and CRTP
During the instantiation of the base class of "derived" we are trying to
instantiate derived in the argument list of base.
lookup_template_class should find the specialization derived
in the type_specialization hash table because that specialization has been
hashed when we encountered the "derived instance;" declaration in main.
But the specialization is not found, leading to another derived type being
created and inserted into the type_specialization - which causes type
comparison issues later.
The reason why the derived specialization is not found by
lookup_template_class has to do with ARGUMENT_PACK_SELECT nodes.
At some point during pack expansion substituting in tsubst_pack_expansion
the pack argument "a" is temporarily replaced by an ARGUMENT_PACK_SELECT node.
So in type_specialization, the argument we have for the "derived"
specialization
is no more the TYPE_ARGUMENT_PACK "a", but an ARGUMENT_PACK_SELECT node that
references that TYPE_ARGUMENT_PACK.
But then we indirectly hit lookup_template_class from within
tsubst_pack_expansion
asking for the specialization of "derived" with the "a" argument. We
fail to find the specialization because we compare the TYPE_ARGUMENT_PACK "a"
with the ARGUMENT_PACK_SELECT present in the hash table.
I am testing the patch below which seems to address the issue.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 084ad1c..e80bc30 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5818,6 +5818,18 @@ template_args_equal (tree ot, tree nt)
return 0;
return 1;
}
+ else if (ot && TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
+{
+ /* We get here probably because we are in the middle of substituting
+ into the pattern of a pack expansion. In that case the
+ARGUMENT_PACK_SELECT temporarily replaces the pack argument we are
+interested in. So we want to use the initial pack argument for
+the comparison. */
+ ot = ARGUMENT_PACK_SELECT_FROM_PACK (ot);
+ if (nt && TREE_CODE (nt) == ARGUMENT_PACK_SELECT)
+ nt = ARGUMENT_PACK_SELECT_FROM_PACK (nt);
+ return template_args_equal (ot, nt);
+}
else if (TYPE_P (nt))
return TYPE_P (ot) && same_type_p (ot, nt);
else if (TREE_CODE (ot) == TREE_VEC || TYPE_P (ot))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses
--- Comment #10 from dodji at gcc dot gnu dot org 2009-10-28 15:42 ---
Subject: Re: [4.3/4.4/4.5 regression] ICE using offsetof
with pointer and array accesses
I am testing the patch below.
I am not sure the approach is the right one though. Comments welcome.
diff --git a/gcc/c-common.c b/gcc/c-common.c
index 8a6d15b..54e551f 100644
--- a/gcc/c-common.c
+++ b/gcc/c-common.c
@@ -8341,6 +8341,32 @@ fold_offsetof_1 (tree expr, tree stop_ref)
case NOP_EXPR:
case INDIRECT_REF:
+ if (TREE_CODE (expr) == INDIRECT_REF)
+ {
+ tree r = TREE_OPERAND (expr, 0);
+
+ if ((TREE_CODE (r) == NON_LVALUE_EXPR
+ && TREE_CODE (TREE_TYPE (r)) == POINTER_TYPE)
+ ||
+ (TREE_CODE (r) == POINTER_PLUS_EXPR))
+ {
+ /* We are trying something like:
+struct A
+{
+ char *p;
+};
+void f ()
+{
+ __builtin_offsetof(struct A, p[1]);
+}
+But the C spec says that if t is of type A, then
+ &(t.p[1])" should evaluate to a constant address.
+ And &(t.p[1]) does not evaluate to a constant address here.
+*/
+ error ("cannot apply % to a non constant address");
+ return error_mark_node;
+ }
+ }
base = fold_offsetof_1 (TREE_OPERAND (expr, 0), stop_ref);
gcc_assert (base == error_mark_node || base == size_zero_node);
return base;
@@ -8361,6 +8387,16 @@ fold_offsetof_1 (tree expr, tree stop_ref)
size_int (tree_low_cst (DECL_FIELD_BIT_OFFSET (t),
1)
/ BITS_PER_UNIT));
+ /* Check if we the offset goes beyond the bound of the struct. */
+ if (int_cst_value (off)
+ >= (int_cst_value (TYPE_SIZE (TREE_TYPE (TREE_OPERAND (expr, 0
+ / BITS_PER_UNIT))
+ {
+ error_at (EXPR_LOCATION (t),
+ "expression %qE denotes an offset greater than size of
%qT",
+ t, TREE_TYPE (TREE_OPERAND (expr, 0)));
+ return error_mark_node;
+ }
break;
case ARRAY_REF:
@@ -8376,6 +8412,17 @@ fold_offsetof_1 (tree expr, tree stop_ref)
}
t = convert (sizetype, t);
off = size_binop (MULT_EXPR, TYPE_SIZE_UNIT (TREE_TYPE (expr)), t);
+
+ /* Check if we the indice of the array goes beyond the bound. */
+ if (int_cst_value (off)
+ >= (int_cst_value (TYPE_SIZE (TREE_TYPE (TREE_OPERAND (expr, 0
+ / BITS_PER_UNIT))
+ {
+ error_at (EXPR_LOCATION (expr),
+ "indice %ld denotes an offset greater than size of %qT",
+ int_cst_value (t), TREE_TYPE (TREE_OPERAND (expr, 0)));
+ return error_mark_node;
+ }
break;
case COMPOUND_EXPR:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
[Bug testsuite/41856] g++.dg/lookup/extern-c-redecl[3,4] .C should be target specific
--- Comment #12 from dodji at gcc dot gnu dot org 2009-11-02 20:20 ---
Subject: Re: g++.dg/lookup/extern-c-redecl[3,4] .C
scan-assembler fails on darwin
Sorry for my late reply.
Could you please test this patch on darwin ?
Thanks.
diff --git a/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C
b/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C
index 00ff4a9..56dcefa 100644
--- a/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C
+++ b/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C
@@ -1,8 +1,9 @@
// Contributed by Dodji Seketeli
// Origin: PR c++/41020
+// { dg-options "" }
// { dg-do compile }
-// { dg-final { scan-assembler-not "call\[\t \]+_Z4forkv" } }
-// { dg-final { scan-assembler "call\[\t \]+fork" } }
+// { dg-final { scan-assembler-not "call\[\t \]+\[^\$\]*?_Z4forkv" { target
i?86-*-* x86_64-*-* } } }
+// { dg-final { scan-assembler "call\[\t \]+_?fork" { target i?86-*-*
x86_64-*-* } } }
extern "C" int fork (void);
diff --git a/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C
b/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C
index 9dfa54d..c385ea7 100644
--- a/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C
+++ b/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C
@@ -1,10 +1,9 @@
// Contributed by Dodji Seketeli
// Origin: PR c++/41020
-// Avoid the "-ansi -pedantic" option
// { dg-options "" }
// { dg-do compile }
-// { dg-final { scan-assembler "call\[\t \]+_Z4forkv" } }
+// { dg-final { scan-assembler "call\[\t \]+\[^\$\]*?_Z4forkv" { target
i?86-*-* x86_64-*-* } } }
class frok
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41856
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #9 from dodji at gcc dot gnu dot org 2010-02-27 21:14 --- Subject: Re: [4.5 Regression] ICE in tsubst, at cp/pt.c:9923 > Hi, I have reduced the testcase in around half of its size and delta > is still running. Once it is finished, I will upload it. You mean half of the size of the reduced testcase I did attach? That's interesting as delta was claiming it couldn't reduce it further for me. Thank you for doing this, Manu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #6 from dodji at gcc dot gnu dot org 2010-03-30 11:44 --- Subject: Re: const variable requires initializer / no explicitly declared default constructor > I'm working on this bug Could you please assign it to yourself then? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug c++/40239] Aggregate initialization requires copy constructor
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-13 09:21 --- Subject: Re: Aggregate initialization requires copy constructor On Tue, Jan 12, 2010 at 11:33:56PM -, paolo dot carlini at oracle dot com wrote: > Since we are talking of etiquette, and with the obvious caveats that my mother > language is italian + all the caveats about metaphorical uses of language, I > would also suggest keeping to a minimum the uses of "pissing" ;) Sorry, Paolo. I will avoid using that wording in the future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40239
[Bug c++/42697] ice-on-legal-code: template class template function local objects
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 11:25 --- Subject: Re: ice-on-legal-code: template class template function local objects > Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new > regressions? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
[Bug debug/45024] wrong nesting for inner template class
--- Comment #2 from dodji at gcc dot gnu dot org 2010-07-22 09:46 --- Subject: Re: wrong nesting for inner template class Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01718.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45024
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-14 06:41 --- Subject: Re: wrong location description for DW_AT_vtable_elem_location > Dodji, want to look at this? Sure. Like, Jakub said, we need to synchronize with GDB. I'll test Jakub's patch ASAP and push the change when GDB is ready to consume it then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
[Bug bootstrap/44302] [4.6 Regression] Failed to bootstrap
--- Comment #5 from dodji at gcc dot gnu dot org 2010-05-28 00:39 ---
Subject: Re: [4.6 Regression] Failed to bootstrap
"hjl dot tools at gmail dot com" writes:
> --- Comment #3 from hjl dot tools at gmail dot com 2010-05-27 23:01
> ---
> This one avoids one extra is_naming_typedef_decl call:
>
> ---
> Index: dwarf2out.c
> ===
> --- dwarf2out.c (revision 159943)
> +++ dwarf2out.c (working copy)
> @@ -19401,6 +19401,7 @@ gen_typedef_die (tree decl, dw_die_ref c
>else
> {
>tree type;
> + bool naming_typedef_decl = is_naming_typedef_decl (decl);
>
>add_name_and_src_coords_attributes (type_die, decl);
>if (DECL_ORIGINAL_TYPE (decl))
> @@ -19427,13 +19428,14 @@ gen_typedef_die (tree decl, dw_die_ref c
> generate that DIE right away. add_type_attribute
> called below will then pick (via lookup_type_die) that
> anonymous struct DIE. */
> - gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE);
> + if (naming_typedef_decl)
> + gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE);
> }
>
>add_type_attribute (type_die, type, TREE_READONLY (decl),
> TREE_THIS_VOLATILE (decl), context_die);
>
> - if (is_naming_typedef_decl (decl))
> + if (naming_typedef_decl)
> /* We want that all subsequent calls to lookup_type_die with
>TYPE in argument yield the DW_TAG_typedef we have just
>created. */
These hunks are not enough to prevent the Ada breakage PR44188. I am
afraid I will need to dig into this a bit further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44302
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #27 from dodji at gcc dot gnu dot org 2010-06-09 14:23 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants "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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #28 from dodji at gcc dot gnu dot org 2010-06-09 14:32 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants "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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #31 from dodji at gcc dot gnu dot org 2010-06-14 14:13 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants "manu at gcc dot gnu dot org" writes: >> Next stop is to disable this feature by default, and enable it with a >> -ftrack-macro-expansion flag, and update the regressions tests of the C FE. > > Great but... you should just prune the output in the general case (extending > prune.exp) and only bother to handle the extra output in cases where it makes > sense to specifically test it. This is what we do for the "inlined from" > messages and it makes sense to do the same for this kind of message. Indeed. Thanks for the reference to prune.exp. Though, one of the reasons why I want to be able to disable the feature and fall back to the previous behaviour is the memory consumption and speed penalty that *could* arise from the patch. This bug report http://llvm.org/bugs/show_bug.cgi?id=5610 gives an idea of what I am talking about. I agree that I need to make the C++ FE work with the patch before really worrying about this, but I felt I could do the work right now and be done with it. As for prune.exp, I think I will eventually prune at least some parts of the output when time comes. > > I see now the sense in the column numbers, I think it is the order that > confused me (and not seeing the code clearly). I would prefer a different > output like: > > test.c:13:3: in expansion of macro MULT2 > test.c:5:14: in expansion of macro SHIFTL > test.c:8:3: in expansion of macro OPERATE > test.c:2:8: error: invalid operands to binary << (have 'double' and > 'int') Ah, okay. Thanks for the comment I'll consider doing this when polishing the error messages. > > But this is bike-shedding at this stage and it is more important to get the > internals working. > Nah. Quite the contrary. I think this is a valuable comment. > BTW, do we also keep the information about the macro arguments? If so, after > your patch goes in we could even go as far as to print macro arguments: > > test.c:13:3: in expansion of macro MULT2 [with A=1.0] > test.c:5:14: in expansion of macro SHIFTL [with A=1.0, B=1] > test.c:8:3: in expansion of macro OPERATE [with OPRD1=1.0, OPTR=<<, OPTRD2=1] > test.c:2:8: error: invalid operands to binary << (have 'double' and 'int') > Not yet. We only keep track of the location of the token accross macro expansion. We don't keep track of the the kind of information you are talking about. But I guess this is something we could do. My TODO list is growing :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
