Re: Using __sync_* builtins within libgcc code
Paolo Carlini wrote: Luke Dalessandro wrote: I'm making some modifications to exception handling inside of unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't seem to figure out how to correctly use builtins in the context of libgcc. I've tried a bunch of different things, but I consistently get the error bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined reference to `__sync_bool_compare_and_swap_4' Maybe you can usefully exploit the recently added __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros or add a few more along the same way... Thank you Paolo, this allows me to wrap cas in a function that falls back to a mutex for targets that don't support builtins. I was aware of the i386 restriction, but didn't realize that i686-* platforms still defaulted to i386. Thanks for everyone's help. Luke
C++ warnings vs. errors
Hi,
since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html
a lot of C++ code is now accepted on mainline (when compiling without
special flags like -fpermissive and -pedantic), that used to be rejected.
Instead of getting closer to the standard we get away from it, which is a
bad idea IMHO - especially since the standard should be widely adopted by
now, given that it's about 10 years old. So here's a collection of some
warnings that I'd rather see as errors:
* Scopes in for-loops:
void foo()
{
for (int i=0; i<10; ++i) {}
i = 0;
}
warn.cc: In function 'void foo()':
warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
warn.cc:3: warning: using obsolete binding at 'i'
Btw, because the compiler tries to be smart to track new scoping and old
scoping at once it rejects valid code, accepts invalid code and even
generates wrong code in some cases (see PR10852).
* Declaration with no type:
foo() {}
warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
Or even worse IMHO:
struct A
{
i;
};
warn.cc:3: warning: ISO C++ forbids declaration of 'i' with no type
* Invalid use of 'template':
struct A
{
static void foo();
};
template void bar()
{
A::template foo();
}
warn.cc: In function 'void bar()':
warn.cc:8: warning: 'A::foo()' is not a template
Btw, I don't know why we should accept this even with -fpermissive.
* Using 'struct' for a union:
union A {};
struct A a;
warn.cc:2: warning: 'struct' tag used in naming 'union A'
* Static members of local classes:
void foo()
{
struct A
{
static int i;
};
}
warn.cc: In function 'void foo()':
warn.cc:5: warning: local class 'struct foo()::A' shall not have static data
member 'int foo()::A::i'
* Return without value:
int foo()
{
return;
}
warn.cc: In function 'int foo()':
warn.cc:1: warning: return-statement with no value, in function returning
'int'
* Definition in wrong namespace:
struct A
{
void foo();
};
namespace N
{
void A::foo() {}
}
warn.cc:8: warning: definition of 'void A::foo()' is not in namespace
enclosing 'A'
* Operator new:
struct A
{
void* operator new(char);
};
warn.cc:3: warning: 'operator new' takes type 'size_t' ('unsigned int') as
first parameter
* Sizeof for function types:
void foo() { sizeof(foo); }
warn.cc: In member function 'void A::foo()':
warn.cc:1: warning: ISO C++ forbids applying 'sizeof' to an expression of
function type
What do you think?
Regards,
Volker
Re: C++ warnings vs. errors
Volker Reichelt <[EMAIL PROTECTED]> writes: > since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html > a lot of C++ code is now accepted on mainline (when compiling without > special flags like -fpermissive and -pedantic), that used to be rejected. > Instead of getting closer to the standard we get away from it, which is a > bad idea IMHO - especially since the standard should be widely adopted by > now, given that it's about 10 years old. So here's a collection of some > warnings that I'd rather see as errors: It sounds like you want to change some pedwarns to permerrors. Go for it. Ian
Re: RFC: Extend x86-64 psABI for 256bit AVX register
On Tue, Jun 10, 2008 at 05:48:57PM +0200, Jan Hubicka wrote:
> > On Tue, Jun 10, 2008 at 8:11 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > > On Tue, Jun 10, 2008 at 04:50:14PM +0200, Jan Hubicka wrote:
> > >> 1) make __m256 passed on stack on variadic functions and in registers
> > >> otherwse. Then we don't need to worry about varargs changes at all.
> > >> This will break unprototyped calls.
> > >> 2) extend rax to pass info about if __m256 registers are present and
> > >> upper half needs to be saved.
> > >> This will break passing __m256 arguments to functions with prologues
> > >> compiled with legacy compiler that will do wild jump. All other cases
> > >> should work
> > >> 3) Save upper halves whenever we want to save SSE registers. This will
> > >> break calling variadic functions compiled with __m256 support in.
> > >>
> > >> I guess either 1) or 2) is fine for me, as I told earlier, I am not big
> > >> fan of 3). I guess 1) is easier and probably make more sense?
> > >
> > > I vote for 1), though I think it should be passed on stack only for ...
> > > args. E.g. for
> > > void foo (__m256 x, ...);
> > > void bar (__m256 x, __m256 y, __m256 z)
> > > {
> > > foo (x, y, z);
> > > }
> > > the first argument would be passed in %ymm0, while the unnamed arguments
> > > y and z would be pushed to stack.
> > >
> >
> > I agree. We will add testcases for whatever psABI extension we have
> > chosen.
>
> I guess we all agree on passing variadic arguments on stack (that is
> only those belonging on ...) and rest in registers. It seems easiest in
> regard to future register set extensions too. Only negative thing is
> that calls to variadic functions will become bit longer, but I guess it
> is not big deal. (the fact that register passing conventions are shorter
> and variadic functions tends to be called many times was also original
> motivation to support register passing on pretty much everything for
> varargs in psABI)
>
There is no precedent for passing named parameters in registers but
unnamed parameters on the stack. On IA32 for the __m128 types, we
pass ALL __m128 parameters on the stack for varargs functions, not
just the unnamed ones. I think we should do the same for x86-64.
H.J.
Books suggestion
Hello I would like to suggest to books you have not mentionned on this page : http://gcc.gnu.org/readings.html Bes regards Titre : GCC : the complete reference Auteur(s) : Griffith, Arthur. Auteur Date(s) : cop. 2002 Langue(s) : anglais Pays : Etats-Unis Editeur(s) : New York ; Chicago ; San Francisco [etc.] : McGraw-Hill/Osborne, cop. 2002 Description : xxiii-647 p. ; 24 cm ISBN : 0-07-222405-3 (br.) Titre : The Definitive Guide to GCC Auteur(s) : Wall, Kurt. Auteur Von Hagen, William (19..-). Auteur Date(s) : cop. 2004 Langue(s) : anglais Pays : Etats-Unis Editeur(s) : New York : Apress, cop. 2004 Description : 1 vol. (XXVIII-519 p.) : ill. ; couv. ill. en coul. ; 24 cm Collection(s) : (The expert's voice) ISBN : 1-59059-109-7 (br.) : 52,70 EUR -- Tel : (33) 1 39 63 78 39 INRIA Rocquencourt, projet MATHFI
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney <[EMAIL PROTECTED]>
---
include/asm-mips/bitops.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 6427247..9a7274b 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
unsigned long *addr)
"2:b 1b \n"
" .previous \n"
: "=&r" (temp), "=m" (*m)
- : "ir" (bit), "m" (*m), "r" (~0));
+ : "i" (bit), "m" (*m), "r" (~0));
#endif /* CONFIG_CPU_MIPSR2 */
} else if (cpu_has_llsc) {
__asm__ __volatile__(
An old trick to get gcc to do the right thing. Basically at the stage when
gcc is verifying the constraints it may not yet know that it can optimize
things into an "i" argument, so compilation may fail if "r" isn't in the
constraints. However we happen to know that due to the way the code is
written gcc will always be able to make use of the "i" constraint so no
code using "r" should ever be created.
The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
and I would be happy if we could get rid of it without creating new problems.
Maybe a gcc hacker here can tell more?
It is not nice to lie to GCC.
CCing GCC and Richard in hopes that a wider audience may shed some light on the
issue.
David Daney
Re: Help requested on C++ template syntax (for Emacs development).
> "Alan" == Alan Mackenzie <[EMAIL PROTECTED]> writes: Alan> So, the question: is it possible to identify with 100% certainty, PURELY Alan> SYNTACTICALLY (i.e. without access to the compiler's symbol table), Alan> when "< ... >" is a pair of template (C++) or generic (Java) brackets? In Java, yes, if the source is error-free. Alan> I'm thinking of things like Alan> foo (a < b, c > d); Alan> I think this is unambiguously a function call with 2 parameters, the Alan> expressions "a < b" and "c > d". In Java this is a function call. If 'a' is a type, this is an error, since you can't declare 'd' here. So... if cc-mode assumes that the code it is looking at is syntactically correct, you can always guess. But, it is a lot nicer for the user if errors are flagged. That way lies the Eclipse approach :-) Alan> Another related question: although there is no maximum bound on how far Alan> apart template/generic brackets can be, I believe that in practice, they Alan> are never that far apart (a few hundred bytes max, perhaps). Is this, in Alan> fact, the case? For Java, yeah, generally speaking. There may be exceptions. And sometimes I think you may find surprising amounts of whitespace in there. For C++, I think you are just doomed. Even if you could get the compiler to emit perfect information, it would only emit information about the code it actually saw -- not stuff in ignored #if groups. Tom
Re: C++ warnings vs. errors
2008/6/11 Ian Lance Taylor <[EMAIL PROTECTED]>: > Volker Reichelt <[EMAIL PROTECTED]> writes: > >> since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html >> a lot of C++ code is now accepted on mainline (when compiling without >> special flags like -fpermissive and -pedantic), that used to be rejected. >> Instead of getting closer to the standard we get away from it, which is a >> bad idea IMHO - especially since the standard should be widely adopted by >> now, given that it's about 10 years old. So here's a collection of some >> warnings that I'd rather see as errors: > > It sounds like you want to change some pedwarns to permerrors. Go for > it. Absolutely. Thanks to Jonathan Wakely, we did change quite a few. However, right now, I don't have neither the free time nor the knowledge of the ISO C++ standard to go through all of them and evaluate whether they should be pedwarns or permerrors. So, just grep pedwarn gcc/cp/*.c and s/pedwarn/permerror/ as you see fit. A tip: if it is guarded by "if (pedantic)" it should probably stay as pedwarn. It doesn't make sense for a permerror to be guarded by the "pedantic" flag. Moreover, you will probably find things that we don't handle well when using fpermissive, so they should be just errors. Thanks, Manuel.
Re: C++ warnings vs. errors
On Wed, Jun 11, 2008 at 04:12:18PM +0200, Volker Reichelt wrote:
> * Scopes in for-loops:
>
> void foo()
> {
> for (int i=0; i<10; ++i) {}
> i = 0;
> }
>
> warn.cc: In function 'void foo()':
> warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
> warn.cc:3: warning: using obsolete binding at 'i'
>
> Btw, because the compiler tries to be smart to track new scoping and old
> scoping at once it rejects valid code, accepts invalid code and even
> generates wrong code in some cases (see PR10852).
That was originally there because, around the time the standard was
first adopted, there was a lot of old code that used the original
cfront scoping rule. But people have had a decade now to get their
code right. It might even be better to toss the support for the
alternative parsing entirely, so the compiler just reports the final
use of i as a reference to an undefined symbol.
Error with 'typedef' and 'long _Fract'
I am writing a new backend for GCC 4.3.1 and have run into the
following issue with GCC 4.3.1's support for the
fixed-point 'long _Fract' type when used in a 'typedef'.
I believe this issue is generic to GCC and not to the backend.
See the (very short) testcase below and the output from GCC.
Basically: when I use a 'typedef' for the 'long _Fract' type,
GCC generates an error but when I replace the typedef with
a #define that, at least in this case, leads to equivalent
code, GCC completes without error (and the resulting .s file
contains correct assembly).
It seems as if the typedef is not being handled correctly.
Or am I misunderstanding something?
% cat foo.c
#ifdef USE_TYPEDEF
/* Error occurs when this typedef is used */
typedef long _Fract fract32_t;
#else
/* Error does NOT occur when this define is used */
#define fract32_t long _Fract
#endif
fract32_t foo(fract32_t a)
{
return a + 0.25lr;
}
% gcc -DUSE_TYPEDEF -O3 foo.c
foo.c: In function 'foo':
foo.c:11: sorry, unimplemented: GCC cannot support operators with
integer types and fixed-point types that have too many integral and
fractional bits together
foo.c:11: error: invalid operands to binary + (have 'fract32_t' and
'long _Fract')
% gcc -O3 foo.c
[lto] function to DECL associations for WPA repackaging
Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the "Repackaging" section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. Ollie
Re: [lto] function to DECL associations for WPA repackaging
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: > Doug, > > Yesterday, we spoke briefly about the need to efficiently determine > the DECL's required by each function. Here's a more detailed > overview. During the WPA phase of WHOPR, we will be reading in a > collection of object files, performing analysis on call-graph/summary > data, and outputting repackaged object files. This is described more > fully in the "Repackaging" section at > http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the > output files are likely to mirror the input files with inlinable > function bodies appended. As our WPA implementation gets more > sophisticated, we will likely want to support more complex repackaging > schemes based on call-graph partitioning. > > In either case, we need a way to efficiently determine which DECL's > must accompany a given set of function bodies. DECL references are > currently stored as integral indexes within the serialized function > bodies. These need to be reproduced elsewhere. Right now, I'm > thinking the call-graph nodes are the best place for this. Kenny > might have some suggestions on this front. > > In the end, WPA should look something like this: > > 1) Read in call-graph nodes, DECL's, and summary data from the input files. > 2) Do some analysis. Partition the functions described in the call-graph > nodes. > 3) Scan each partition's call graph to determine which DECL's are needed. > 4) Write each partition's function bodies, DECL's, and call-graph > nodes to an output file. > > If you could work on the DECL association logic, that would be greatly > appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard.
gcc-4.2-20080611 is now available
Snapshot gcc-4.2-20080611 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080611/ 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 136682 You'll find: gcc-4.2-20080611.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080611.tar.bz2 C front end and core compiler gcc-ada-4.2-20080611.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080611.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080611.tar.bz2 C++ front end and runtime gcc-java-4.2-20080611.tar.bz2 Java front end and runtime gcc-objc-4.2-20080611.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080611.tar.bz2The GCC testsuite Diffs from 4.2-20080604 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: C++ warnings vs. errors
Hi Volker, thanks for picking these issues up. I told Manuel I'd
review the rest of the remaining pedwarns, but haven't had time to do
it either.
2008/6/11 Volker Reichelt:
> * Scopes in for-loops:
>
> void foo()
> {
>for (int i=0; i<10; ++i) {}
>i = 0;
> }
>
> warn.cc: In function 'void foo()':
> warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
> warn.cc:3: warning: using obsolete binding at 'i'
I suggest making this a permerror and changing the text slightly, see
http://gcc.gnu.org/ml/gcc/2008-01/msg00192.html
> * Declaration with no type:
>
> foo() {}
>
> warn.cc:1: warning: ISO C++ forbids declaration of 'foo' with no type
See the part about special handling of 'main' in
http://gcc.gnu.org/ml/gcc/2008-01/msg00189.html
> * Invalid use of 'template':
> * Using 'struct' for a union:
These two can both be fixed by changes in cp/parser.c - all cases of
pedwarn that are not guarded by testing 'pedantic' should be
permerrors.
I'm reviewing the mails linked above, as well as the other cases you
listed. I haven't updated my gcc tree in weeks, so it will take me a
while to bootstrap and test. If you get a patch ready first, please CC
me as I'm not subscribed to gcc-patches.
Thanks,
Jon
[lto] What is lto_file_vtable for?
>From what I can tell from grepping the lto source, the vtable entry in lto_file is set but never used. Is this old code that never got removed or the beginning of an idea that never got implemented? I'm inclined to remove it if it's not doing anything. Ollie
Re: [lto] What is lto_file_vtable for?
On Wed, Jun 11, 2008 at 4:38 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: > From what I can tell from grepping the lto source, the vtable entry in > lto_file is set but never used. Is this old code that never got > removed or the beginning of an idea that never got implemented? > > I'm inclined to remove it if it's not doing anything. It was needed when the LTO reader had to map DWARF2 sections. It is obsolete now. --Bill
Re: [lto] function to DECL associations for WPA repackaging
Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the "Repackaging" section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard. ollie is asking which global and static vars are referenced by each function, not the local variables. my sense is not to associate put this directly in the cgraph but to keep it as a side table that is indexed by something like the cgraph node id. The reason for leaning in this direction is that "what happens in the cgraph stays in the cgraph", and the infomation we are talking about here is is only really useful for the whopr repackaging. This is why i have resisted honza's wanting to associate other ipa local information in the cgraph. We have a pass that computes this info currently, the ipa_referenced vars, but i am considering blowing this pass away since the information is not currently being used in the compiler. I need to chat with danny about this next time we talk. However, the lto function body scanner/serializer can just as easily compute this when it serializes a function. We can then serialize this in a one section per compilation unit manner. kenny
Re: [lto] function to DECL associations for WPA repackaging
On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: >> >> On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: >> >>> >>> Doug, >>> >>> Yesterday, we spoke briefly about the need to efficiently determine >>> the DECL's required by each function. Here's a more detailed >>> overview. During the WPA phase of WHOPR, we will be reading in a >>> collection of object files, performing analysis on call-graph/summary >>> data, and outputting repackaged object files. This is described more >>> fully in the "Repackaging" section at >>> http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the >>> output files are likely to mirror the input files with inlinable >>> function bodies appended. As our WPA implementation gets more >>> sophisticated, we will likely want to support more complex repackaging >>> schemes based on call-graph partitioning. >>> >>> In either case, we need a way to efficiently determine which DECL's >>> must accompany a given set of function bodies. DECL references are >>> currently stored as integral indexes within the serialized function >>> bodies. These need to be reproduced elsewhere. Right now, I'm >>> thinking the call-graph nodes are the best place for this. Kenny >>> might have some suggestions on this front. >>> >>> In the end, WPA should look something like this: >>> >>> 1) Read in call-graph nodes, DECL's, and summary data from the input >>> files. >>> 2) Do some analysis. Partition the functions described in the call-graph >>> nodes. >>> 3) Scan each partition's call graph to determine which DECL's are needed. >>> 4) Write each partition's function bodies, DECL's, and call-graph >>> nodes to an output file. >>> >>> If you could work on the DECL association logic, that would be greatly >>> appreciated. >>> >> >> We have gimple_referenced_vars (cfun), which is a hashtable mapping the >> DECL_UID of every referenced variable in the function to its DECL. In the >> end this could be serialized as a bitmap of DECL_UIDs if you can associate >> DECL_UIDs with the proper DECL at repacking / de-serializing time. >> >> Richard. >> > > ollie is asking which global and static vars are referenced by each > function, not the local variables. Referenced_vars already includes all of these, efficiently indexed for you by UID. Not that it is necessarily the right answer, but it includes more than the local variables.
Re: [lto] function to DECL associations for WPA repackaging
Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the "Repackaging" section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard. ollie is asking which global and static vars are referenced by each function, not the local variables. Referenced_vars already includes all of these, efficiently indexed for you by UID. Not that it is necessarily the right answer, but it includes more than the local variables. but we do not serialize this, and we should not. we know what global vars each function references when we serialize it, it is not a big deal to keep track of that as we do so and write it into a separate section that the function body. kenny
Re: How to post to GCC lists?
On Thu, 2008-05-22 at 15:09 -0500, Omar Torres wrote: > 1- I noticed that when I reply to posts, the "References" are not > preserved, which leads to messages in the same threat not to be linked > together. I am using Thunderbird as my email client. When I go to > View>Headers>All the References field looks accurate. Is there a trick > to make this work? Should I use instead a different email client better > suit for GCC ML? I don't know what the problem is; Thunderbird should certainly observe References: headers. Whatever you do, please make sure it works. We have had list members use non-thread-aware mailers in the past and it's certianly going to irritate people. Welcome! Ben
