Hi,
I am trying to figure out how to get a typedef hierarchy from the C/C++
tree in GCC. Consider the following declarations:
struct s {};
typedef s s_t;
typedef s_t my_s_t;
my_s_t x;
Giveb 'x' VAR_DECL I can have this traversal using TYPE_MAIN_VARIANT():
x -> my_s_t -> s;
What I am trying t
Hi everybody,
i'm programming for embedded system and for work i use a code warrior
ide (for freescale microprocessor).
Our client has required to clean every warning in souce code. The
codewarrior compiler don't detect every warning and so the client said
to use a gcc -Wall and lint command.
In
On Tue, 19 Apr 2011, Diego Novillo wrote:
> This merge brings the branch up to rev 172662.
>
> There are some LTO failures which are ICEs induced by a new
> assertion I added in bp_pack_value. We discussed this in
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01115.html.
>
> The failure happen
On 20 April 2011 08:37, Boris Kolpackov wrote:
> Hi,
>
> I am trying to figure out how to get a typedef hierarchy from the C/C++
> tree in GCC. Consider the following declarations:
>
> struct s {};
>
> typedef s s_t;
> typedef s_t my_s_t;
I don't know if GCC keeps the information you want, but acc
Hi Jonathan,
Jonathan Wakely writes:
> I don't know if GCC keeps the information you want, but according to
> the language rules there is no hierarchy. There's a type, and zero or
> more alternative names for it. The example above makes my_s_t a
> synonym for s, not s_t.
Right. "Hierarchy" was
On 20 April 2011 10:10, Boris Kolpackov wrote:
>
>> What about std::size_t?
>
> This one is actually covered. In GCC AST std::size_t node is the same
> as ::size_t (i.e., GCC does not create new *_TYPE node for using-
> declarations).
My point is that libstdc++ does not use a using declaration for
Hi!
I'm willing to translate publication located at
http://www.gnu.org/software/gcc/egcs-1.1/ to the Belorussian language
(my mother tongue). What I'm asking for is your written permission, so
you don't mind after I'll post the translation to my blog. The
translation is intended only for web,
Boris Kolpackov writes:
> I am trying to figure out how to get a typedef hierarchy from the C/C++
> tree in GCC. Consider the following declarations:
>
> struct s {};
>
> typedef s s_t;
> typedef s_t my_s_t;
>
> my_s_t x;
>
> Giveb 'x' VAR_DECL I can have this traversal using TYPE_MAIN_VARIANT():
domenico margiotta writes:
> i'm programming for embedded system and for work i use a code warrior
> ide (for freescale microprocessor).
>
> Our client has required to clean every warning in souce code. The
> codewarrior compiler don't detect every warning and so the client said
> to use a gcc -W
Bohdan Zograf writes:
> I'm willing to translate publication located at
> http://www.gnu.org/software/gcc/egcs-1.1/ to the Belorussian language
> (my mother tongue). What I'm asking for is your written permission, so
> you don't mind after I'll post the translation to my blog. The
> translation i
Hi Ian,
Ian Lance Taylor writes:
> As far as I know this is not possible. A typedef name is just an alias
> for the underlying type. When you typedef T as TNAME, where T is itself
> a typedef, GCC records that TNAME is a name for the underlying type of
> T. It does not record an equivalence of
Boris Kolpackov writes:
> Ian Lance Taylor writes:
>
>> As far as I know this is not possible. A typedef name is just an alias
>> for the underlying type. When you typedef T as TNAME, where T is itself
>> a typedef, GCC records that TNAME is a name for the underlying type of
>> T. It does not
On 04/20/2011 03:16 AM, Jan Hubicka wrote:
On Tue, Apr 19, 2011 at 7:01 AM, Richard Guenther
I have been doing LTO bootstrap and reporting failures. The current
LTO bootstrap failure us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48671
This is FDO problem, not LTO problem and should be fix
On Wed, Apr 20, 2011 at 11:22 AM, Cary Coutant wrote:
>> This caused:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12689
>
> I've committed the following to fix this. Thanks!
>
> -cary
>
> PR gold/12689
> * archive.h (Incremental_archive_entry::Archive_member):
> Initi
[ Adding Jason and gcc@ ]
Jason,
On Tue, Apr 19, 2011 at 22:10, Lawrence Crowl wrote:
> For the testcase x1hardlookup.cc, we read in the following from
> the pph file.
>
> namespace :: {
> function_decl int (int, struct D) operator+
> type_decl struct D D
> var_decl int V
> type_
On 04/20/2011 11:38 AM, Diego Novillo wrote:
I don't know. I thought pushdecl_with_scope would be it. Jason, is
there any other bookkeeping routine we would need to be calling?
Maybe we need to set some global that points to the current namespace
before calling pushdecl_with_scope()? There is
> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
> Why doesn't 64bit GCC 4.2 warn it?
Good question. It seems that the difference is whether the compiler
generates a field-by-field copy or a call to memcpy(). According to
David, the trunk gcc in 32-bit mode doesn't call memcpy, b
On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant wrote:
>> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
>> Why doesn't 64bit GCC 4.2 warn it?
>
> Good question. It seems that the difference is whether the compiler
> generates a field-by-field copy or a call to memcpy(). According
The previous merge broke release checking builds because of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48652.
That was fixed in the very next rev after my merge, so I just
cherry picked rev 172663.
Lawrence, this should fix your builds.
Diego.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/20/11 13:06, Xinliang David Li wrote:
> On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant wrote:
>>> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
>>> Why doesn't 64bit GCC 4.2 warn it?
>>
>> Good question. It seems that the diff
20 matches
Mail list logo
