Re: [10 PATCHES] inline functions to avoid stack overflow
On Wed, 25 Jun 2008, Helge Hafting wrote:
Mikulas Patocka wrote:
Hi
Here I'm sending 10 patches to inline various functions.
To give you some understanding of sparc64, every function there uses big
stack frame (at least 192 bytes). 128 bytes are required by architecture
(16 64-bit registers), 48 bytes are there due to mistake of Sparc64 ABI
designers (calling function has to allocate 48 bytes for called function)
and 16 bytes are some dubious padding.
I guess there is no way around those 128 bytes required by hardware - but
is it necessary to allocate the 48 bytes of "mistake" and the dubious
padding?
Linux kernel functions don't call any outside functions, and are not called
from
outside either. So violating the ABI should be ok - there is nothing else to
be compatible to. Similiar to how x86 experimented with --mregparm to get
a little more performance from changing the kernel calling convention.
Helge Hafting
So, ask gcc developers to do kernel-specific ABI with only 128-byte stack
frame.
BTW. could some gcc developer explain the reason for additional 16-bytes
on stack on sparc64? 64-bit ABI mandates 176 bytes, but gcc allocates 192
bytes.
Even worse, gcc doesn't use these additional bytes. If you try this:
extern void f(int *i);
void g()
{
int a;
f(&a);
}
, it allocates additional 16 bytes for the variable "a" (so there's total
208 bytes), even though it could place the variable into 48-byte
ABI-mandated area that it inherited from the caller or into it's own
16-byte padding that it made when calling "f".
Mikulas
gcc-in-cxx: Garbage Collecting STL Containers
Could someone point me towards what is necessary to add STL containers
to the garbage collector?
One big problem with garbage collecting in C++ is the need to run
destructors. If the (I believe very reasonable) decision is made to
require that running destructors is not necessary for garbage
collected types, then my experience is doing gc is very easy, and for
garbage collection it's easy to just look at the internal members
which all behave "sensibly".
Stripping away all the C++isms, and assuming that we use the default
allocator which uses malloc, then a std::vector is just a struct
struct vector
{
T* begin;
T* finish;
T* end_of_storage;
};
Where we increment finish whenever we add something to the vector,
until finish = end_of_storage, at which point new memory is allocated,
the data is copied across, and then the old memory is freed. I can't
think of any other (or any simpler) way to construct a variable sized
container, in either C or C++.
Other containers are similar.
Chris
Re: CFA expression failure
On Wed, Jun 25, 2008 at 10:02:40AM +0800, Ye, Joey wrote: > Daniel, > > We generate following DWARF2 instructions for stack alignment prologue. > Basically we use expression to calculate CFA. But it run into some > segfault in libmudflap and libjava. Do you have any hints what's wrong? The only thing I could see was that this is wrong: > DW_CFA_advance_loc: 7 to 000c > DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0) >b: 55 push %ebp >c: 89 e5 mov%esp,%ebp At eip == 0xc then %ebp is not yet set, so saved %ebp is not at 0(%ebp) yet. That's true at 0xe; at 0xc the saved location of %ebp is harder to describe. But that won't explain your crashes. The debug info looks unusual, but correct. -- Daniel Jacobowitz CodeSourcery
Re: CFA expression failure
On Tue, Jun 24, 2008 at 08:40:18PM -0700, H.J. Lu wrote: > I think the problem is in uw_update_context_1. REG_SAVED_EXP > and REG_SAVED_VAL_EXP may use other registers as shown above: > >DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8) > > They should be handle last. I am testing this patch. Does it > make senses? I think that rather than delaying such expressions, you need to evaluate into a temporary context. DW_OP_breg5 means the current frame's %ebp; DW_CFA_expression: r5 describes the location of the previous frame's %ebp. They're different registers. Otherwise this is going to be too order-sensitive. -- Daniel Jacobowitz CodeSourcery
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
Hans-Peter Nilsson wrote: >> Date: Tue, 24 Jun 2008 10:36:15 +0100 >> From: Andrew Haley <[EMAIL PROTECTED]> > >> I thought cast-through-pointer-to-union didn't work and was already >> disallowed; we've been around all this already. > > We also bless assignments through unions, and this could be > argued as assigning through a union, albeit casted. > >> This patch of yours >> already documents uncontroversial behaviour. > > That's what I hope, but the existence of that code together in > an *else* clause of #ifdef YES_ALIAS by a well-known author > makes it de-facto controversial IMHO. Note also that another > maintainer thought the code to be valid; see the PR. So I see. I'm pretty sure that the compiler's alias analysis won't think it's valid, but I haven't checked. Do we actually document anywhere that a C++-style type pun along the lines of reinterpret_cast(x) will not work? I'm guessing it probably won't, and that the union trick is the only thing we do support. Andrew.
Re: gcc-in-cxx: Garbage Collecting STL Containers
Chris Jefferson wrote:
Could someone point me towards what is necessary to add STL containers
to the garbage collector?
One big problem with garbage collecting in C++ is the need to run
destructors. If the (I believe very reasonable) decision is made to
require that running destructors is not necessary for garbage
collected types, then my experience is doing gc is very easy, and for
garbage collection it's easy to just look at the internal members
which all behave "sensibly".
Stripping away all the C++isms, and assuming that we use the default
allocator which uses malloc, then a std::vector is just a struct
struct vector
{
T* begin;
T* finish;
T* end_of_storage;
};
Where we increment finish whenever we add something to the vector,
until finish = end_of_storage, at which point new memory is allocated,
the data is copied across, and then the old memory is freed. I can't
think of any other (or any simpler) way to construct a variable sized
container, in either C or C++.
Other containers are similar.
I fully agree on that point. To summarize: most of the classes in the
gcc-in-cxx should have no destructor at all, or a trivial destructor
which only destroys the data inside.
However, I am not sure this applies to std::string etc..
In addition, this raise several questions:
Does complex static data (i.e. statically allocated instances of complex
classes) is allowed in gcc-in-cxx?
Do we intend to have a wide forest of classes in gcc-in-cxx? I would
prefer a tree of classes (with only single inheritance) sharing a common
root class.
At last, C++ permits interesting ways of writing garbage collectors,
because it can help to make easier the boxing of GC-ed values on the stack.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 9:04 AM, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> Chris Jefferson wrote:
>>
>> Could someone point me towards what is necessary to add STL containers
>> to the garbage collector?
>>
>> One big problem with garbage collecting in C++ is the need to run
>> destructors. If the (I believe very reasonable) decision is made to
>> require that running destructors is not necessary for garbage
>> collected types, then my experience is doing gc is very easy, and for
>> garbage collection it's easy to just look at the internal members
>> which all behave "sensibly".
>>
>> Stripping away all the C++isms, and assuming that we use the default
>> allocator which uses malloc, then a std::vector is just a struct
>>
>> struct vector
>> {
>> T* begin;
>> T* finish;
>> T* end_of_storage;
>> };
>>
>> Where we increment finish whenever we add something to the vector,
>> until finish = end_of_storage, at which point new memory is allocated,
>> the data is copied across, and then the old memory is freed. I can't
>> think of any other (or any simpler) way to construct a variable sized
>> container, in either C or C++.
>>
>> Other containers are similar.
>
> I fully agree on that point. To summarize: most of the classes in the
> gcc-in-cxx should have no destructor at all, or a trivial destructor which
> only destroys the data inside.
I would expect GCC to provide its own allocators (GC, obstacks, etc.)
when using
STL containers. Consequently I believe the above is too strong a requirement.
I suspect what you really want is not to have destructors with semantics
interference with GC. For example, it would be OK to have
vector as long as BasicBlock itself has GC_Alloc'd members
or has semantically uninteresting destructor.
Also, I would expect C++ idiomatic constructs such as RAII for managing local
resources, or monitoring function calls, etc.
Or, forget STL containers and embrace NIH.
-- Gaby
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <[EMAIL PROTECTED]> wrote: > Hans-Peter Nilsson wrote: >>> Date: Tue, 24 Jun 2008 10:36:15 +0100 >>> From: Andrew Haley <[EMAIL PROTECTED]> >> >>> I thought cast-through-pointer-to-union didn't work and was already >>> disallowed; we've been around all this already. >> >> We also bless assignments through unions, and this could be >> argued as assigning through a union, albeit casted. >> >>> This patch of yours >>> already documents uncontroversial behaviour. >> >> That's what I hope, but the existence of that code together in >> an *else* clause of #ifdef YES_ALIAS by a well-known author >> makes it de-facto controversial IMHO. Note also that another >> maintainer thought the code to be valid; see the PR. > > So I see. I'm pretty sure that the compiler's alias analysis won't > think it's valid, but I haven't checked. Right. It happily "mis-"optimizes it. And on a second thought I agree the construct is invalid. > Do we actually document anywhere that a C++-style type pun along the lines > of > > reinterpret_cast(x) > > will not work? I'm guessing it probably won't, and that the union trick > is the only thing we do support. This is not a "pun", it only re-interprets the pointer _value_, not what it points to. Richard.
Re: gcc-in-cxx: Garbage Collecting STL Containers
> "Chris" == Chris Jefferson <[EMAIL PROTECTED]> writes: Chris> Could someone point me towards what is necessary to add STL Chris> containers to the garbage collector? I think most of the needed changes will be in gengtype. If you aren't familiar with what this does, read gcc/doc/gty.texi. The first thing to look at is syntax. Right now a hash table of trees is defined: static GTY((param_is (union tree_node))) htab_t type_hash_table; In C++, ideally, gengtype would understand template parameters and so we would not need a new GTY argument. E.g.: static GTY(()) std::set *type_hash_table; Next, you'd have to modify gengtype to emit mark functions for these types. Continuing the above example, right now gengtype emits a loop that directly references fields fields in the hash table (see build/gcc/gtype-desc.c:gt_ggc_m_P9tree_node4htab). For C++, this iteration should just be done with ordinary iterators. There may be some problems marking container-class-private GC-allocated data structures, if any such exist. Finally, the gengtype mechanism is also used for PCH. So, you will need to figure out how to serialize STL containers to PCH and then read them back in. This might be hard. Tom
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: > I think most of the needed changes will be in gengtype. If you aren't > familiar with what this does, read gcc/doc/gty.texi. Also - I may regret saying this but - doesn't gengtype have a simplistic C parser in it? How upset is it likely to get on C++ input? -- Daniel Jacobowitz CodeSourcery
Re: gcc-in-cxx: Garbage Collecting STL Containers
> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes: >> On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: >> I think most of the needed changes will be in gengtype. If you aren't >> familiar with what this does, read gcc/doc/gty.texi. Daniel> Also - I may regret saying this but - doesn't gengtype have a Daniel> simplistic C parser in it? How upset is it likely to get on C++ Daniel> input? Yeah, it does -- see gengtype-parse.c. I haven't done extensive hacking there; I don't really know how upset it will be. I assume it won't work the first time :) Tom
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
Richard Guenther wrote:
> On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> Hans-Peter Nilsson wrote:
Date: Tue, 24 Jun 2008 10:36:15 +0100
From: Andrew Haley <[EMAIL PROTECTED]>
I thought cast-through-pointer-to-union didn't work and was already
disallowed; we've been around all this already.
>>> We also bless assignments through unions, and this could be
>>> argued as assigning through a union, albeit casted.
>>>
This patch of yours
already documents uncontroversial behaviour.
>>> That's what I hope, but the existence of that code together in
>>> an *else* clause of #ifdef YES_ALIAS by a well-known author
>>> makes it de-facto controversial IMHO. Note also that another
>>> maintainer thought the code to be valid; see the PR.
>> So I see. I'm pretty sure that the compiler's alias analysis won't
>> think it's valid, but I haven't checked.
>
> Right. It happily "mis-"optimizes it. And on a second thought I
> agree the construct is invalid.
>
>> Do we actually document anywhere that a C++-style type pun along the lines
>> of
>>
>> reinterpret_cast(x)
>>
>> will not work? I'm guessing it probably won't, and that the union trick
>> is the only thing we do support.
>
> This is not a "pun", it only re-interprets the pointer _value_,
Which pointer? x is not of pointer type, and neither is T.
> not what it points to.
The C++ standard calls this a type pun, so -- with all due respect -- I'm
going to believe it! The question is whether this will fall foul of gcc's
aliasing in the same way that a pointer cast does, and I think it will,
Anyway, I just checked, and we do warn, but only at -O2:
#include
int
main(char argc, char **argv)
{
double d = 99;
long m = reinterpret_cast(d);
p.cc:7: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Not a problem, then.
Andrew.
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>> On Wed, Jun 25, 2008 at 4:04 PM, Andrew Haley <[EMAIL PROTECTED]> wrote:
>>> Hans-Peter Nilsson wrote:
> Date: Tue, 24 Jun 2008 10:36:15 +0100
> From: Andrew Haley <[EMAIL PROTECTED]>
> I thought cast-through-pointer-to-union didn't work and was already
> disallowed; we've been around all this already.
We also bless assignments through unions, and this could be
argued as assigning through a union, albeit casted.
> This patch of yours
> already documents uncontroversial behaviour.
That's what I hope, but the existence of that code together in
an *else* clause of #ifdef YES_ALIAS by a well-known author
makes it de-facto controversial IMHO. Note also that another
maintainer thought the code to be valid; see the PR.
>>> So I see. I'm pretty sure that the compiler's alias analysis won't
>>> think it's valid, but I haven't checked.
>>
>> Right. It happily "mis-"optimizes it. And on a second thought I
>> agree the construct is invalid.
>>
>>> Do we actually document anywhere that a C++-style type pun along the lines
>>> of
>>>
>>> reinterpret_cast(x)
>>>
>>> will not work? I'm guessing it probably won't, and that the union trick
>>> is the only thing we do support.
>>
>> This is not a "pun", it only re-interprets the pointer _value_,
>
> Which pointer? x is not of pointer type, and neither is T.
>
>> not what it points to.
>
> The C++ standard calls this a type pun, so -- with all due respect -- I'm
The C++ standard does not actually call it a type pun, but I think I
understand what you mean.
The mapping used by reinterpret_cast is implementation defined.
But really, reinterpret_cast(e) is almost close to C's crudest
cast (T)e. So, people expect reinterpret_cast(integer) and
reinterpret_cast(pointer) to work in reasonable
ways. If we guarantee the meaning of
float f = 1.3f;
int = *(int*)&f;
then we should guarantee the meaning of reinterpret_cast(f),
and vice-versa.
We should also guarantee the pointer mapping hinted at by Richard in a previous
mail. Other than that, I'm not convinced yet that we need to add more
guarantees by extrapolating from the exceptional union case.
> going to believe it! The question is whether this will fall foul of gcc's
> aliasing in the same way that a pointer cast does, and I think it will,
>
> Anyway, I just checked, and we do warn, but only at -O2:
>
> #include
>
> int
> main(char argc, char **argv)
> {
> double d = 99;
> long m = reinterpret_cast(d);
>
> p.cc:7: warning: dereferencing type-punned pointer will break strict-aliasing
> rules
Note that the above construct is turned (by the C++ front-end) into
*(long*)(&d)
which elicits the typepunning warning. But I agree that we don't
want to guarantee this is a defined behaviour.
>
> Not a problem, then.
Yep.
>
> Andrew.
>
Re: gcc-in-cxx: Garbage Collecting STL Containers
Maybe at some point then we should just stop using gengtype and just hand-write the walkers once. One of the reasons gengtype exists is because you can't easily have an abstract interface with member functions that you can force people to implement in C. In C++, we can. This is of course, a large change, but i'm not sure how much more work it really is than trying to understand gengtype and rewrite it to properly parse C++/support STL containers. On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: >> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > >>> On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: >>> I think most of the needed changes will be in gengtype. If you aren't >>> familiar with what this does, read gcc/doc/gty.texi. > > Daniel> Also - I may regret saying this but - doesn't gengtype have a > Daniel> simplistic C parser in it? How upset is it likely to get on C++ > Daniel> input? > > Yeah, it does -- see gengtype-parse.c. > I haven't done extensive hacking there; I don't really know how upset > it will be. I assume it won't work the first time :) > > Tom >
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 5:34 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Maybe at some point then we should just stop using gengtype and just > hand-write the walkers once. > > One of the reasons gengtype exists is because you can't easily have an > abstract interface with member functions that you can force people to > implement in C. > > In C++, we can. > > This is of course, a large change, but i'm not sure how much more work > it really is than trying to understand gengtype and rewrite it to > properly parse C++/support STL containers. Hmmm, does C++0x add some type-reflection? ;) Richard.
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
Gabriel Dos Reis wrote: > On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >> Richard Guenther wrote: >> The C++ standard calls this a type pun, so -- with all due respect -- I'm > > The C++ standard does not actually call it a type pun, but I think I > understand what you mean. ISO/IEC 14882:2003 (2nd. ed.), Bottom of Page 76, footnote 67, "This is sometimes referred to as a _type pun_." So there! Andrew.
Re: RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example
On Wed, Jun 25, 2008 at 10:43 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: > Gabriel Dos Reis wrote: >> On Wed, Jun 25, 2008 at 9:49 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >>> Richard Guenther wrote: > >>> The C++ standard calls this a type pun, so -- with all due respect -- I'm >> >> The C++ standard does not actually call it a type pun, but I think I >> understand what you mean. > > ISO/IEC 14882:2003 (2nd. ed.), > Bottom of Page 76, footnote 67, "This is sometimes referred to as a _type > pun_." > So there! I stand corrected! And I should be reading footnotes more often (even if they tend to distract.) Thanks. > > Andrew. >
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 8:38 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > Hmmm, does C++0x add some type-reflection? ;) Yes but I don't see how we can use it in C++03/C++98 code. Compiling GCC 4.5 (or 5.0) with only 4.3 will be a pain. In fact C++0x has changed the definition of auto so you don't even need a way to specific a type for a variable, the compiler will figure it out by the initializer. This is why I suggest we also stay away from the TR1 STL. Thanks, Andrew Pinski
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 10:48 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Wed, Jun 25, 2008 at 8:38 AM, Richard Guenther > <[EMAIL PROTECTED]> wrote: >> Hmmm, does C++0x add some type-reflection? ;) > > Yes but I don't see how we can use it in C++03/C++98 code. Compiling > GCC 4.5 (or 5.0) with only 4.3 will be a pain. > In fact C++0x has changed the definition of auto so you don't even > need a way to specific a type for a variable, the compiler will figure > it out by the initializer. > > This is why I suggest we also stay away from the TR1 STL. I believe C++98 or C++03 should be enough for GCC. Naturally, I think we should use the STL; along with Dan Berlin's suggestion of taking the leap to dump gengtype. We would want, for the most part not to have to depend on C++0x for obvious bootstrapping requirements. > > Thanks, > Andrew Pinski >
RE: CFA expression failure
It might due to DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8) DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12) After defining reg via CFA instead of r5, we got less failure. Thanks - Joey -Original Message- From: Daniel Jacobowitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 10:00 PM To: H.J. Lu Cc: Ye, Joey; gcc@gcc.gnu.org; Guo, Xuepeng Subject: Re: CFA expression failure On Tue, Jun 24, 2008 at 08:40:18PM -0700, H.J. Lu wrote: > I think the problem is in uw_update_context_1. REG_SAVED_EXP > and REG_SAVED_VAL_EXP may use other registers as shown above: > >DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8) > > They should be handle last. I am testing this patch. Does it > make senses? I think that rather than delaying such expressions, you need to evaluate into a temporary context. DW_OP_breg5 means the current frame's %ebp; DW_CFA_expression: r5 describes the location of the previous frame's %ebp. They're different registers. Otherwise this is going to be too order-sensitive. -- Daniel Jacobowitz CodeSourcery
Re: gcc-in-cxx: Garbage Collecting STL Containers
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes: Dan> Maybe at some point then we should just stop using gengtype and just Dan> hand-write the walkers once. Yeah, we could do that for the containers. GTY markers serve three purposes though: they explain the meanings of fields (this part we can handle by hand using templates and specializations), they mark roots, and they mark things for PCH. I can see how we could eliminate GTY for roots if we don't mind static constructors -- but I don't like those. Is there another way? PCH, IMO, remains the problem child. Dan> This is of course, a large change, but i'm not sure how much more work Dan> it really is than trying to understand gengtype and rewrite it to Dan> properly parse C++/support STL containers. Yeah. The cleaner the result, the better... and a prize for whoever manages to remove gengtype entirely. Tom
Successfully built and installed GCC 4.3.1
FYI jazzy 315 % ./config.guess i686-pc-linux-gnu jazzy 316 % /usr/local/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /tmp/gcc-4.3.1/configure --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran,objc,java --enable-shared --enable-bootstrap --with-gmp-include=/cs/local/include --with-mpfr-include=/cs/local/include --with-gmp-lib=/cs/local/lib --with-mpfr-lib=/cs/local/lib Thread model: posix gcc version 4.3.1 (GCC) jazzy 317 % cat /etc/issue CentOS release 4.6 (Final) Kernel \r on an \m jazzy 318 % uname -a Linux jazzy 2.6.9-67.0.15.EL.CSE.smp #1 SMP Mon May 12 14:06:12 EDT 2008 i686 i686 i386 GNU/Linux jazzy 319 % rpm -q glibc glibc-2.3.4-2.39
Re: gcc-in-cxx: Garbage Collecting STL Containers
On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: >> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > >>> On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: >>> I think most of the needed changes will be in gengtype. If you aren't >>> familiar with what this does, read gcc/doc/gty.texi. > > Daniel> Also - I may regret saying this but - doesn't gengtype have a > Daniel> simplistic C parser in it? How upset is it likely to get on C++ > Daniel> input? > > Yeah, it does -- see gengtype-parse.c. > I haven't done extensive hacking there; I don't really know how upset > it will be. I assume it won't work the first time :) It turns out that we already have a parser capable of handling C++... why not just build gengtype on top of the C++ front end? - Doug
Re: gcc-in-cxx: Garbage Collecting STL Containers
Daniel Berlin wrote: Maybe at some point then we should just stop using gengtype and just hand-write the walkers once. One of the reasons gengtype exists is because you can't easily have an abstract interface with member functions that you can force people to implement in C. In C++, we can. This is of course, a large change, but i'm not sure how much more work it really is than trying to understand gengtype and rewrite it to properly parse C++/support STL containers. I might be the only person out there who likes GTY annotations. The fact that gengtype has a separate parser is highly inconvenient. Why not use the GCC C/C++ parser on gengtype? It seems that with some refactoring, it should be possible to bootstrap just the C++ parser( without memory management or maybe some minimal handwritten stuff). Then the parser could parse the headers to extract GTY annotations with full semantic info. For my plugin stuff I use a macro to convert GTY stuff to GNU attributes(patch is coming as soon as I get the paperwork done) which allows me to do some trivial metaprogramming to produce useful things such generate most of the code for a JavaScript binding to GIMPLE gcc plugin(http://developer.mozilla.org/en/docs/Treehydra). Overall I think the the GTY annotations make the structs more understandable and the fact that they allow for generating structure-aware code is awesome. I think there may be other automation benefits to be reaped from GTY-style annotations elsewhere in the code, so the system should be improved, not canned. Taras On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes: On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: I think most of the needed changes will be in gengtype. If you aren't familiar with what this does, read gcc/doc/gty.texi. Daniel> Also - I may regret saying this but - doesn't gengtype have a Daniel> simplistic C parser in it? How upset is it likely to get on C++ Daniel> input? Yeah, it does -- see gengtype-parse.c. I haven't done extensive hacking there; I don't really know how upset it will be. I assume it won't work the first time :) Tom
Re: gcc-in-cxx: Garbage Collecting STL Containers
Daniel Berlin wrote: Maybe at some point then we should just stop using gengtype and just hand-write the walkers once. One of the reasons gengtype exists is because you can't easily have an abstract interface with member functions that you can force people to implement in C. In C++, we can. This is of course, a large change, but i'm not sure how much more work it really is than trying to understand gengtype and rewrite it to properly parse C++/support STL containers. I might be the only person out there who likes GTY annotations. The fact that gengtype has a separate parser is highly inconvenient. Why not use the GCC C/C++ parser on gengtype? It seems that with some refactoring, it should be possible to bootstrap just the C++ parser( without memory management or maybe some minimal handwritten stuff). Then the parser could parse the headers to extract GTY annotations with full semantic info. For my plugin stuff I use a macro to convert GTY stuff to GNU attributes(patch is coming as soon as I get the paperwork done) which allows me to do some trivial metaprogramming to produce useful things such generate most of the code for a JavaScript binding to GIMPLE gcc plugin(http://developer.mozilla.org/en/docs/Treehydra). Overall I think the the GTY annotations make the structs more understandable and the fact that they allow for generating structure-aware code is awesome. I think there may be other automation benefits to be reaped from GTY-style annotations elsewhere in the code, so the system should be improved, not canned. Taras On Wed, Jun 25, 2008 at 10:49 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes: On Wed, Jun 25, 2008 at 08:35:41AM -0600, Tom Tromey wrote: I think most of the needed changes will be in gengtype. If you aren't familiar with what this does, read gcc/doc/gty.texi. Daniel> Also - I may regret saying this but - doesn't gengtype have a Daniel> simplistic C parser in it? How upset is it likely to get on C++ Daniel> input? Yeah, it does -- see gengtype-parse.c. I haven't done extensive hacking there; I don't really know how upset it will be. I assume it won't work the first time :) Tom
Re: gcc-in-cxx: Garbage Collecting STL Containers
Taras wrote:
I might be the only person out there who likes GTY annotations. The fact
that gengtype has a separate parser is highly inconvenient. Why not use
the GCC C/C++ parser on gengtype? It seems that with some refactoring,
it should be possible to bootstrap just the C++ parser( without memory
management or maybe some minimal handwritten stuff).
It is even simpler (and I do similar tricks in the MELT branch).
If we do use the GCC parser in replacement of gengtype (I also wish that
change) we just have to permanently store the generated stuff into our
SVN repository. (where configure scripts are also big generated stuff).
I do exactly this in my MELT branch:
the warm-basilys-0.c is machine generated (and is compiled into
warm-basilys-0.so plugin at build time) and inside the SVN repository.
It is probably the biggest C file there...
the warm-basilys-1.c is produced from warm-basilys.bysl using
warm-basilys-0.so at build time and compiles to warm-basilys-1.so
Likewise, warm-basilys-2.c produced from warm-basilys.bysl using
warm-basilys-1.so
And so forth, for warm-basilys-3.c (using warm-basilys-2.so)
warm-basilys-4.c & warm-basilys-5.c
a special make target (upgrade-warm-basilys) copies warm-basilys-4.c
into warm-basilys-0.c in the source tree.
Right now, I am splitting warm-basilys.bysl into several files, to have
several (but each smaller) generated files.
So to use GCC for replacement of gengtype:
the somehow hard part is to code the stuff (perhaps a plugin?) taking
the role on gengtype.
No particular bootstrap problem, just store the generated file in the
repository (like configure scripts are already).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Length-Changing Prefixes problem with the x86 Backend
Hello, I came across a problem with the x86 backend of gcc (3.3 - 4.1). When I compile code which access a lookup table of size 65536, gcc generates code which uses 16bit opcodes. The intel architecture optimization guide warns that 16bit opcodes should be avoided whenever possible due to Length-Changing Prefixes (LCP). The recommendation is: ""If imm16 is needed, load equivalent imm32 into a register and use the word value in the register instead. "" I would expect gcc to use a 32bits register and mask it, if needed. Even when I use 32bits registers and mask them ( & 0x), gcc detects correctly that my variable is effectively only 16bits and it generates 16bits code. I modified the generated assembly to use 32bit registers and it ran much faster. -- Cheers, Nadav
Re: [10 PATCHES] inline functions to avoid stack overflow
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
> Even worse, gcc doesn't use these additional bytes. If you try this:
>
> extern void f(int *i);
> void g()
> {
> int a;
> f(&a);
> }
>
> , it allocates additional 16 bytes for the variable "a" (so there's total
> 208 bytes), even though it could place the variable into 48-byte
> ABI-mandated area that it inherited from the caller or into it's own
> 16-byte padding that it made when calling "f".
The extra 16 bytes of space allocated is so that GCC can perform a
secondary reload of a quad floating point value. It always has to be
present, because we can't satisfy a secondary reload by emitting yet
another reload, it's the end of the possible level of recursions
allowed by the reload pass.
GCC could be smart and eliminate that slot when it's not used, but
such a thing is not implemented yet.
It would also require quite a bit of new code to determine cases
like you mention above, where the incoming arg slots from the
caller are unused, assuming this would be legal.
And that legality is doubtful. We'd need to be careful because I
think the caller is allowed to assume that those slots are untouched
by the callee, and thus can be assumed to have whatever values the
caller put there even after the callee returns.
Re: how can I contribute ?
2008/6/25 Diego Novillo <[EMAIL PROTECTED]>: > On Wed, Jun 25, 2008 at 03:36, Fabien Chêne <[EMAIL PROTECTED]> wrote: > >> How can I process ? Do I need GNU copyright assignment ? Do I >> need SVN right access after approval ? Otherwise, can I send the >> patch on gcc-patches so that someone else will commit it for me ? > > I suggest reading the introductory material in > http://gcc.gnu.org/wiki/GettingStarted/ > > That page will point you to the legal prerequisites for contributing. > Essentially, you need to assign your copyright to the FSF unless you > are working for an institution that already has an assignment in > place. Well, can someone please send me the paper to fill, in order to have copyright assignment for all future changes ? Thanks ! -- Fab
gcc-4.2-20080625 is now available
Snapshot gcc-4.2-20080625 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080625/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 137124 You'll find: gcc-4.2-20080625.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080625.tar.bz2 C front end and core compiler gcc-ada-4.2-20080625.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080625.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080625.tar.bz2 C++ front end and runtime gcc-java-4.2-20080625.tar.bz2 Java front end and runtime gcc-objc-4.2-20080625.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080625.tar.bz2The GCC testsuite Diffs from 4.2-20080618 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: how can I contribute ?
I will send it privately. David
Re: gcc-in-cxx branch created
Ivan Levashew <[EMAIL PROTECTED]> writes: >> Your comment makes little sense in context. Nobody could claim that >> the existing gengtype code is simple. Not many people understand how >> it works at all. In order to support STL containers holding GC >> objects, it will need to be modified. > > I'm sure there is a library of GC-managed components in C++. I'm sure there is too. In gcc we use the same data structures to support both GC and PCH. Switching to a set of C++ objects is likely to be a complex and ultimately unrewarding task. >> I don't know what you mean by your reference to the Cyclone variant of >> C, unless you are trying to say something about gcc's use of garbage >> collection. >> > > Cyclone has many options for memory management. I don't know for sure > if there is a need for GC in GCC at all. I would prefer it if gcc didn't use GC, but it does, and undoing that decision will be a long hard task which may never get done. > Cyclone has a roots not only in C, but also ML. Some techniques like > pattern matching, aggregates, variadic arrays, tuples looks to be more > appropriate here than their C++'s metaprogrammed template analogues. I guess I don't know Cyclone. If you are suggesting that we use Cyclone instead of C++, I think that is a non-starter. We need to use a well-known widely-supported language, and it must be a language which gcc itself supports. Ian
Re: Should we remove java from the default bootstrap languages?
Andrew Haley wrote: But, I am actually ok with having it be disabled by default, provided that regressions affect gcj are treated seriously: fixed in a timely way by the person causing the regression, or, if not, letting gcj maintainers start the patch-reversion clock. If we make this change I'll set up an auto-tester on the compile farm that builds gcj along with everything else. I think this would provide a pretty reasonable compromise. I agree. I also agree that if someone breaks Java, they should be required to fix the problem. In fact, we could have the rule that the Java maintainers get to revert a patch summarily based merely on the fact that there exists a Java post-patch failure that does not occur pre-patch. That does shift the testing burden to the Java maintainers, but it also means that there is no risk that Java is completely hosed. I am a huge fan of testing, but I do think that right now we're running too much testing for not enough return. It's not that the testing is bad, or that more testing doesn't prevent bugs; it's that the marginal cost of bug-prevention from the Java testing seems too high to me, given that after-the-fact auto-testing can delivery much of the same value. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Length-Changing Prefixes problem with the x86 Backend
On Wed, Jun 25, 2008 at 11:11 PM, Nadav <[EMAIL PROTECTED]> wrote: > I came across a problem with the x86 backend of gcc (3.3 - 4.1). When I > compile code which access a lookup table of size 65536, gcc generates code > which uses 16bit opcodes. > > The intel architecture optimization guide warns that 16bit opcodes should be > avoided whenever possible due to Length-Changing Prefixes (LCP). The > recommendation is: ""If imm16 is needed, load equivalent imm32 into a > register and use the word value in the register instead. "" > > I would expect gcc to use a 32bits register and mask it, if needed. > Even when I use 32bits registers and mask them ( & 0x), gcc detects > correctly that my variable is effectively only 16bits and it generates > 16bits code. > I modified the generated assembly to use 32bit registers and it ran much > faster. Please file a bugreport following instructions at http://gcc.gnu.org/bugs.html. Please also add a runtime test that can be used to analyze the problem. Thanks, Uros.
Re: [10 PATCHES] inline functions to avoid stack overflow
On Thu, Jun 26, 2008 at 12:09 AM, David Miller <[EMAIL PROTECTED]> wrote:
> From: Mikulas Patocka <[EMAIL PROTECTED]>
> Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
>
>> Even worse, gcc doesn't use these additional bytes. If you try this:
>>
>> extern void f(int *i);
>> void g()
>> {
>> int a;
>> f(&a);
>> }
>>
>> , it allocates additional 16 bytes for the variable "a" (so there's total
>> 208 bytes), even though it could place the variable into 48-byte
>> ABI-mandated area that it inherited from the caller or into it's own
>> 16-byte padding that it made when calling "f".
>
> The extra 16 bytes of space allocated is so that GCC can perform a
> secondary reload of a quad floating point value. It always has to be
> present, because we can't satisfy a secondary reload by emitting yet
> another reload, it's the end of the possible level of recursions
> allowed by the reload pass.
Is there any floating-point code present in the Linux kernel ? Would
it be a good idea to add an option to gcc that tells gcc that the
compiled code does not contain floating-point instructions, such that
gcc knows that no space has to be provided for a quad floating point
value ?
Bart.
