test ignore
testing ignore. -- Pinski
[ADMINISTRIVIA] lost email
I wanted to let everyone know that sourceware.org/gcc.gnu.org/cygwin.com experienced an email outage for a while starting at 2006/10/15 04:43 GMT to about 2006/10/15 18:46 GMT. During that time some email was lost. This was due to a typo that I added to one of the email filters to attempt to ward off some pending stock spam. Not all email was lost but, if you sent email to a mailing list and it has not yet appeared, then you are probably affected and will have to resend your mail. I apologize for this inconvenience. If you feel that you must reply to this message, please note that the distribution list is large and that the reply-to has been sent to the overseers mailing list since it is unlikely that any response to this message would be appropriate for all of the mailing lists mentioned in the To field. cgf
Re: GNAT, SJLJ and zero-cost exception handling
> I can confirm that gnat gcc 4.1.1 does *not* correctly handle SJLJ > exceptions, at least on MinGW where SJLJ is currently the only viable EH > mechanism. The 2 SJLJ mechanisms should be available there, so you could try to use GCC SJLJ instead of GNAT SJLJ (set ZCX_By_Default to True in system.ads). > Eric, how difficult would it be to backport a fix from 4.2 to 4.1? Too invasive I'd think. -- Eric Botcazou
Proposed semantics for attributes in C++ (and in C?)
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
If the attribute makes any substantive change to S (e.g., changes its
size, alignment, etc.) then bad things happen. For example, the member
functions of "S" have expectations about the layout of "S" that are not
satisfied if they are called with a "T". Depending on the attribute and
circumstances, we do all manner of bad things, including ICE, generate
wrong code, etc.
For a while now, I've been promising to propose semantics for these
constructs. Here is a sketch of the semantics that I think we should
have. (I say a sketch because I have not attempted to write standardese.)
All attributes must be classified as either "semantic" or "non-semantic"
attributes. A "semantic" attribute is one which might affect
code-generation in any way. A "non-semantic" attribute cannot affect
code-generation. For example, "used" and "deprecated" are non-semantic
attributes; there is no way to observe, by looking at an object file,
whether or not a class has been marked with one of these attributes. In
contrast, "packed" is a semantic attribute; the size of a class is
different depending on whether or not it is "packed".
Any attribute may be applied at the point of definition of a class.
These attributes (whether semantic or non-semantic) apply to the class.
For example, if the class is packed, then the member functions expect
the "this" pointer to point to the packed class.
A typedef declaration which adds only non-semantic attributes is always
valid. As with other typedefs, the typedef declaration creates a new
name for an existing type. The type referred to by that name is the
same type as the original type. However, the *name* has additional
properties, implied by the (non-semantic) attributes. For example,
using a "deprecated" name for a type results in a deprecation warning.
But, a function declared to take a parameter with the non-deprecated
name may be passed a parameter with the "deprecated" name.
A typedef declaration which adds semantic attributes to a class type,
other than POD classes with no explicitly declared members other than
data members, to arrays of such classes, to arrays of such arrays, etc.,
is invalid. (POD-ness alone is not satisfactory, as PODs may contain
function members, and I think dealing with static data members and
typedef members is not worth the trouble.)
A typedef declaration which adds semantic attributes to a POD class type
with no function members is valid, but creates an entirely new type,
different from all other types except others formed by adding the same
combination of semantic attributes to the same original class type. In
the example above, if the typedef adds a semantic attribute, you may not
pass an "S" to a function expecting a "T" or vice versa. Neither may
you pass an "S*" to a function expecting a "T*", without an explicit
reinterpret_cast. The name of "T", for linkage purposes, is "T", and
there is no implicit "T::S" type; instead, however, there is a "T::T"
type. (Various consequences follow; for example, typeid(T) gives you a
type_info object that indicates that the name of the type is "T".)
References to the original type from within the types of the members of
the class still refer to the original class. For example, in:
struct S {
char c;
S* next;
};
typedef __attribute__((packed)) S T;
the data member T::next has type "S*", not "T*".
A typedef declaration which adds semantic attributes to a non-class type
is valid, but again creates an entirely new type. (We might want a
special exception to the "entirely new type" rule for the "mode"
attribute, declaring that "typedef __attribute__((mode(DI))) int LL" is
equivalent to "typedef long long LL;" on platforms where "long long" has
DImode.) So,
typedef S* P;
typedef __attribute__((...)) P Q;
creates a type "Q" that is incompatible with "S*" if the attribute is
semantic. However, the type of "*Q" is still "S". It is invalid to do
anything that would require either type_info or a mangled name for "Q",
including using it as an argument to typeid, thowing an exception of a
type involving "Q", or declaring a template to take a parameter of a
type involving "Q". (We could relax some of these restrictions in
future, if we add mangling support for attributes.)
A variable declaration involving attributes, like:
__attribute__((...)) S v;
is treated as syntactic sugar for:
typedef __attribute__((...)) S T;
T v;
where T is some invented type name different from all others in the program.
For example given:
__attribute__((packed)) S v;
the type of "&v" is "__attribute__((packed)) S *", and cannot be passed
to a function expecting an "S*", but can of course be passed to a
function expecting an "__attribute__((packed)) S *", or a typedef
Re: Proposed semantics for attributes in C++ (and in C?)
On Sun, 15 Oct 2006, Mark Mitchell wrote:
> We have a number of C++ PRs open around problems with code like this:
>
> struct S {
> void f();
> virtual void g();
> };
>
> typedef __attribute__((...)) struct S T;
I was happy with the state before r115086 (i.e. with it being documented
that such attributes on typedefs are ignored). But given that we are now
attempting to honour them, the proposed semantics seem reasonable.
The proposal requires documentation for each (type) attribute of whether
it is semantic or non-semantic. In general the documentation of attribute
semantics needs cleaning up to make clear just when each attribute can be
used and what exactly it means (and the code needs cleaning up to follow
sensible documented semantics) - for example, attributes with
documentation split and duplicated because they apply to more than one of
functions, variables and types. (The syntax documentation is cleaner, and
I think accurate for C, but it does include some speculative future
possibilities that seemed nice when I first wrote it but I no longer think
would be a good idea.)
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: Proposed semantics for attributes in C++ (and in C?)
Joseph S. Myers wrote:
On Sun, 15 Oct 2006, Mark Mitchell wrote:
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
I was happy with the state before r115086 (i.e. with it being documented
that such attributes on typedefs are ignored). But given that we are now
attempting to honour them, the proposed semantics seem reasonable.
Yes, I would be happy to explicitly ignore semantic attributes in
typedefs as well, with a warning (or even an error). However, I had not
realized that we ever did that; I'm surprised that the change that
instituted this is so recent. I suppose that explains why we're
suddenly seeing a rash of such problems. Jason, as you made this
change, do you have any comments on the proposal?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Proposed semantics for attributes in C++ (and in C?)
On Oct 15, 2006, at 3:12 PM, Mark Mitchell wrote: A typedef declaration which adds semantic attributes to a POD class type with no function members is valid, but creates an entirely new type, different from all other types except others formed by adding the same combination of semantic attributes to the same original class type. In the example above, if the typedef adds a semantic attribute, you may not pass an "S" to a function expecting a "T" or vice versa. Neither may you pass an "S*" to a function expecting a "T*", without an explicit reinterpret_cast. The name of "T", for linkage purposes, is "T", and there is no implicit "T::S" type; instead, however, there is a "T::T" type. (Various consequences follow; for example, typeid(T) gives you a type_info object that indicates that the name of the type is "T".) Note that this is an ABI change for any code that uses these. I agree that it seems cleaner to just disallow this practice entirely, particularly if it is a recent invention. In any case, having the compiler reject code that does not or will not work is a much better position to be in than silently miscompiling code. -Chris
Re: Additional tree node questions.
Brendon Costa wrote: > Ian Lance Taylor wrote: >> Brendon Costa <[EMAIL PROTECTED]> writes: >> >>> For each FUNCTION_DECL node I find, I want to determine what its >>> exception specification list is. I.e. the throws() statement in its >>> prototype. >> Look at TYPE_RAISES_EXCEPTIONS (FNDECL). >> >> Ian > Aahh. I should have read the documentation more closely. TYPE_RAISES_EXCEPTIONS() requires a FUNCTION_TYPE node NOT a FUNCTION_DECL node. Thanks again for the pointer to the correct macro. Brendon.
__comp_ctor() functions
Hi again,
I have noticed in the C++ front end that classes have a few
__comp_ctor () functions. These functions do not have an
implementation that can be obtained with DECL_SAVED_TREE.
Looking further into it there are a number of identifiers for
functions like this added to cp_global_trees. I have searched the code
but cant find where the code for these functions is. Does anyone know
where i can get more information on the "implementation" of these
functions?
I can make some assumptions on what they do, like
Attribute::__comp_ctor () would call Attribute::Attribute() etc. But
is there somewhere I can get some more definitive information on these
functions?
Thanks,
Brendon.
Some examples of the sort of data I see are shown below
Attribute::Attribute()
Calls: None
Attribute::Attribute(Attribute const&)
Calls: None
Attribute::__comp_ctor(Attribute const&)
Calls: UNKNOWN
Attribute::__comp_ctor()
Calls: UNKNOWN
main()
Calls: Container::__comp_ctor()
Calls: Container::__comp_ctor(Container const&)
Container::Container()
Calls: Attribute::__comp_ctor()
Container::__comp_ctor()
Calls: UNKNOWN
Container::Container(Container const&)
Calls: Attribute::__comp_ctor(Attribute const&)
Container::__comp_ctor(Container const&)
Calls: UNKNOWN
-
class Attribute
{
public:
Attribute() {}
Attribute(const Attribute& right){}
};
class Container
{
public:
Attribute a;
};
int main()
{
Container c1;
Container c2(c1);
return 0;
}
Re: Proposed semantics for attributes in C++ (and in C?)
> If the attribute makes any substantive change to S (e.g., changes its > size, alignment, etc.) then bad things happen. For example, the member > functions of "S" have expectations about the layout of "S" that are not > satisfied if they are called with a "T". Depending on the attribute and > circumstances, we do all manner of bad things, including ICE, generate > wrong code, etc. > > For a while now, I've been promising to propose semantics for these > constructs. You might want to take a look at the Ada concept of "freeze point". That's one approach to a similar problem.
Re: Abt SIMD Emulation
Mohamed Shafi <[EMAIL PROTECTED]> writes: > I want to know what can be done in the back end of a target to indicate that > SIMD stuff should be emulated all the way. That should happen by default. > Is there any target macros or hooks available for that. > Will the target hook TARGET_VECTOR_MODE_SUPPORTED_P hep me to indicate that? You should only define that if the port is prepared to handle vector operations itself. You don't need to use it for emulation. Ian
-fschedule-insns problem with arm-linux-uclibc g++
Hi,
I found something strange I don't understand, but I
don't know if it's really a bug.
If I compile the following simple file x.cc:
class A
{
public:
A();
~A();
int a();
};
class B
{
public:
static int b();
};
int B::b()
{
A a;
return a.a();
}
I get the following assembler output for function B::b:
with
arm-linux-g++ -o x -g -O1 -fno-schedule-insns -fPIC -c x.cc
int B::b()
0: e1a0c00dmov ip, sp
4: e92ddff0stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp,
ip, lr, pc
}
8: ed2d420csfm f4, 4, [sp, #-48]!
c: e24cb004sub fp, ip, #4 ; 0x4
10: e24dd044sub sp, sp, #68 ; 0x44
14: e59f30bcldr r3, [pc, #188] ; d8 <.text+0xd8>
18: e7933003ldr r3, [r3, r3]
1c: e50b3078str r3, [fp, #-120]
20: e59f30b4ldr r3, [pc, #180] ; dc <.text+0xdc>
24: e0833003add r3, r3, r3
28: e50b3074str r3, [fp, #-116]
2c: e24b3058sub r3, fp, #88 ; 0x58
30: e50b3070str r3, [fp, #-112]
34: e59f30a4ldr r3, [pc, #164] ; e0 <.text+0xe0>
38: e0833003add r3, r3, r3
3c: e50b306cstr r3, [fp, #-108]
40: e50bd068str sp, [fp, #-104]
44: e24b0090sub r0, fp, #144; 0x90
48: ebfebl 0 <_Unwind_SjLj_Register>
with
arm-linux-g++ -o x -g -O1 -fschedule-insns -fPIC -c x.cc:
int B::b()
0: e1a0c00dmov ip, sp
4: e92ddff0stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp,
ip, lr, pc
}
8: ed2d420csfm f4, 4, [sp, #-48]!
c: e24cb004sub fp, ip, #4 ; 0x4
10: e24dd044sub sp, sp, #68 ; 0x44
14: e59f30bcldr r3, [pc, #188] ; d8 <.text+0xd8>
18: e7921003ldr r1, [r2, r3]
1c: e59f20b8ldr r2, [pc, #184] ; dc <.text+0xdc>
20: e0822002add r2, r2, r2
24: e59f30b4ldr r3, [pc, #180] ; e0 <.text+0xe0>
28: e0823003add r3, r2, r3
2c: e50b1078str r1, [fp, #-120]
30: e50b3074str r3, [fp, #-116]
34: e50b206cstr r2, [fp, #-108]
38: e24b3058sub r3, fp, #88 ; 0x58
3c: e50b3070str r3, [fp, #-112]
40: e50bd068str sp, [fp, #-104]
44: e24b0090sub r0, fp, #144; 0x90
48: ebfebl 0 <_Unwind_SjLj_Register>
Now I get a segfault in
18: e7921003ldr r1, [r2, r3]
when I compare this to the -fno-schedule-insns case I think that
this line should read:
18: e7921003ldr r1, [r3, r3]
which would yield the same result as with -fno-schedule-insns.
Since I'm no scheduling expert, I don't know if this is a bug
or just some arm weirdness.
some info:
arm-linux-uclibc-g++ -v
Using built-in specs.
Target: arm-linux-uclibc
Configured with:
/home/klimek/stuff/toolchains/st4000-gcc4.2/build/toolchain/buildroot2/toolchain_build_arm/gcc-4.2-20061007/configure
--prefix=/home/klimek/stuff/toolchains/st4000-gcc4.2/toolchain
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibc --enable-languages=c,c++ --enable-shared
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-threads --disable-multilib --disable-libstdcxx-pch
: (reconfigured)
/home/klimek/stuff/toolchains/st4000-gcc4.2/build/toolchain/buildroot2/toolchain_build_arm/gcc-4.2-20061007/configure
--prefix=/home/klimek/stuff/toolchains/st4000-gcc4.2/toolchain
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibc --enable-languages=c,c++ --enable-shared
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-threads --disable-multilib --disable-libstdcxx-pch
Thread model: posix
gcc version 4.2.0 20061007 (experimental)
arm-linux-uclibc-g++ -dumpmachine
arm-linux-uclibc
Cheers,
Manuel
