[Bug macros/9748] macros containing __extension__ won't run

[Bug macros/9748] macros containing __extension__ won't run

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9748

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat
                   |                            |dot com

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-06-28 09:10:38 UTC ---
*** Bug 12941 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug macros/9748] macros containing __extension__ won't run

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9748

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |archer

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug macros/9748] macros containing __extension__ won't run

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2009-01-16 00:05 -------
Occasionally I fantasize about putting the GCC (or clang) parsers into
gdb and having a C interpreter environment.

For the specific case of gcc, I put this into the incremental branch's
gcc/gdbinit.in:

# Redefine any macro from tree.h that uses a statement expression.
# Last in case of failure.
macro define TREE_CHECK(T, CODE) (T)
macro define TREE_NOT_CHECK(T, CODE) (T)
macro define TREE_CHECK2(T, CODE1, CODE2) (T)
macro define TREE_NOT_CHECK2(T, CODE1, CODE2) (T)
macro define TREE_CHECK3(T, CODE1, CODE2, CODE3) (T)
macro define TREE_NOT_CHECK3(T, CODE1, CODE2, CODE3) (T)
macro define TREE_CHECK4(T, CODE1, CODE2, CODE3, CODE4) (T)
macro define NON_TREE_CHECK4(T, CODE1, CODE2, CODE3, CODE4) (T)
macro define TREE_CHECK5(T, CODE1, CODE2, CODE3, CODE4, CODE5) (T)
macro define TREE_NOT_CHECK5(T, CODE1, CODE2, CODE3, CODE4, CODE5) (T)
macro define CONTAINS_STRUCT_CHECK(T, STRUCT) (T)
macro define TREE_CLASS_CHECK(T, CLASS) (T)
macro define TREE_RANGE_CHECK(T, CODE1, CODE2) (T)
macro define OMP_CLAUSE_SUBCODE_CHECK(T, CODE) (T)
macro define OMP_CLAUSE_RANGE_CHECK(T, CODE1, CODE2) (T)
macro define EXPR_CHECK(T) (T)
macro define GIMPLE_STMT_CHECK(T) (T)
macro define NON_TYPE_CHECK(T) (T)
macro define TREE_VEC_ELT_CHECK(T, I) ((T)->vec.a[I])
macro define PHI_NODE_ELT_CHECK(T, I) ((T)->phi.a[I])
macro define OMP_CLAUSE_ELT_CHECK(T, I) ((T)->omp_clause.ops[I])
macro define TREE_OPERAND_CHECK(T, I) ((T)->exp.operands[I])
macro define TREE_OPERAND_CHECK_CODE(T, CODE, I) ((T)->exp.operands[I])
macro define GIMPLE_STMT_OPERAND_CHECK(T, I) ((T)->gstmt.operands[I])
macro define TREE_RTL_OPERAND_CHECK(T, CODE, I) ((T)->exp.operands[I])
macro define TREE_CHAIN(NODE) ((T)->common.chain)
macro define TREE_TYPE(NODE) ((T)->common.type)
# Another handy one.
macro define __builtin_offsetof(T, F) ((int) &(((T *) 0)->F))


In fact, this is why I implemented "macro define" :-)
Perhaps this should go on gcc trunk at some point.

Defining __extension__ wouldn't be completely crazy.
Maybe we need "set lang gnuc".

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=9748

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug macros/9748] macros containing __extension__ won't run

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-01-15 23:39 -------
Subject: Re:  macros containing __extension__ won't run

On Thursday 15 January 2009 21:40:25, drow at false dot org wrote:

> Also on statement expressions, which is what the __extension__ marker
> is for in the first place :-)

IIRC, the __extensions__ marker is for enabling
gnu-C-isms no matter the C dialect or e.g., if -pedantic is selected,
so it's for more things, but, yeah, missed that.  :-)

> I don't think statement expressions are likely to be implemented in
> GDB.  It currently has only a C expression parser, with no support for
> statements etc.

Stating the obvious, you can override the checked versions
in gdb expressions with:

 (gdb) macro define TREE_CHECK(T, CODE) (T)

If wanting to retain the checking ability when called from gdb,
perhaps the best would be to still override the whole TREE_CHECK macro
with macro define, retaining close enough semantics.  Say, add
something like this and similars to gcc:

 const_tree
 gdb_tree_check (const_tree __t, int code)
 {
   if (TREE_CODE (__t) != code)
     tree_check_failed (__t, "<gdb>", 0, "<nofunction>", code); // or call some other variant
   return __t;
 }

And this in .gdbinit:

 macro define TREE_CHECK(T, CODE) gdb_tree_check(T, CODE)



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9748

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug macros/9748] macros containing __extension__ won't run

[drow at false dot org]

------- Additional Comments From drow at false dot org  2009-01-15 21:40 -------
Subject: Re:  macros containing __extension__ won't run

On Thu, Jan 15, 2009 at 09:30:06PM -0000, pedro at codesourcery dot com wrote:
> I current gdb mainline, you could try defining __extension__ to empty:
> 
>  (gdb) macro define __extension__
> 
> ("macro define" was stubbed in yearlier versions of gdb, it
> has only recently been implemented)
> 
> I guess you'd need to do the same for __FILE__, __LINE__, etc, but I
> think you'll trip on __typeof.

Also on statement expressions, which is what the __extension__ marker
is for in the first place :-)

I don't think statement expressions are likely to be implemented in
GDB.  It currently has only a C expression parser, with no support for
statements etc.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9748

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug macros/9748] macros containing __extension__ won't run

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-01-15 21:30 -------
Subject: Re:  New: macros containing __extension__ won't run

On Thursday 15 January 2009 21:06:26, rearnsha at gcc dot gnu dot org wrote:
> Consider a macro, such as the following (from GCC):
> 
> #define TREE_CHECK(T, CODE) __extension__ ({ __typeof (T) const __t = (T); if
> (TREE_CODE (__t) != (CODE)) tree_check_failed (__t, __FILE__, __LINE__,
> __FUNCTION__, (CODE), 0); __t; })
> 
> if the object containing the macro is compiled with -g3, then the definition is
> available to GDB, but this doesn't help much...
> 
> (gdb) p TREE_CHECK (fntype, CALL_EXPR)
> No symbol "__extension__" in current context.
> 

I current gdb mainline, you could try defining __extension__ to empty:

 (gdb) macro define __extension__

("macro define" was stubbed in yearlier versions of gdb, it
has only recently been implemented)

I guess you'd need to do the same for __FILE__, __LINE__, etc, but I
think you'll trip on __typeof.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9748

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.