Re: Notes from tinkering with the autovectorizer (4.1.1)
Hi, > I've been tinkering with the autovectorizer. It's really cool. > I particularly like the realignment support. > > I've noticed just a few things while tinkering with it (in 4.1.1): > thanks a lot for your comments! > > > 1) The definition of the realignment instruction doesn't match hardware for > instrution sets like ARM WMMX, where aligned amounts shift by 0 bytes > instead of VECSIZE byes. This makes it useless for vector realignment, > because in the case that the pointer happens to be aligned, we get the > wrong vector. Looks like the SPARC realignment hook does the same thing... > Indeed, it looks like Altivec is the only one to support it, and they do > some trickery with shifting the wrong (against endianness) way based on the > two's compliment of the source (a very clever trick). No other machine > (evidentally) can easily meet the description of the current realignment > mechanism. > > Of course, for safety reasons I guess we don't always get the next vector > (the one at address floor(ptr+VECSIZE)), which would allow us to use the > shift-style instructions. > > So, there may be a few options: > (1) > * Have a flag or hook where we can say it is always OK to read the next > element. This is probably a bad option; everyone who used the > vectorizer would have to know that they may need to pad their > arrays if they are in a protected memory environment. > (2) > * Conditionally fetch the next bundle, and don't do the fetch of the > next data the last time around if might not be safe. Probably > a bad idea for architectures without conditional execution. > (3) > * Currently we drop out of the loop when there are VEC_ELEMENTS - 1 > iterations or less. We could drop out when there are VEC_ELEMENTS > or less, and then we could always fetch the next aligned data. > (4) > * Some other clever trick I don't know about. :-) > (5) > * Or keep it the way it is, and leave out the machines that have the > shift-by-zero instead of the shift-by-VECSIZE behavior for > an aligned pointer. > We should probably implement (2) and (3) (and (4)... :-)) and let each target choose which alternative to take. > > 2) It seems like there may be some hooks that aren't documented. For > instance, there seems to be some kind of support for the "vcond" > standard name, but I can't seem to find it in the documentation. > I'll open PRs for both this (missed documentation) and the above (missed optimization). I'll try to address these soon. I've been meaning to add documentation on all the different idioms that one needs to define in order to enable the different vectorization features for a certain target. > > In general things work quite well, and it seems to play reasonably well with > things like the modulo scheduler. > thanks! dorit > Cheers, > > Erich > > -- > Why are ``tolerant'' people so intolerant of intolerant people?
Re: collect2 on AIX drags too many objects from archives ?
Ian Lance Taylor wrote: > Why do you need the double scan? Why can't you just consistently > ignore the frame tables? Because we need the tables associated with every "useful" object to be registered for exception handling to work, and what is registered is currently what collect2 finds while it scans. It turns out the double scan actually doesn't work because the eh tables of the "useful" object linked in are garbage collected by the native linker when they are not referenced, so they are just not there when the second scan proceeds :(
Re: collect2 on AIX drags too many objects from archives ?
Mike Stump wrote: > On Sep 26, 2006, at 2:36 AM, Olivier Hainque wrote: > > /* The AIX linker will discard static constructors in object files > > if nothing else in the file is referenced [...] */ > Darwin has this same sort of issue and solves it by not wiring up > ctors/dtors for all these things but instead have a separate > convention to register/unregister the tables, both for the statically > linked things, dlopen type things and shared library type things. > Essentially, upon load, they wonder symbol tables (ok, actually the > section table) and register based upon what they find. See crt1.o > (Csu/crt.c) and keymgr/keymgr.c for additional hints. Will have a look, thanks for the pointer.
How do I build C++ for xscale-elf?
When I try to build C++ for xscale-elf, I get this as the last message: configure: WARNING: No native atomic operations are provided for this platform. configure: WARNING: They cannot be faked when thread support is disabled. configure: WARNING: Thread-safety of certain classes is not guaranteed. configure: error: No support for this host/target combination. What version of gcc should I be trying to build? Here's the configure line I use: ./configure --with-included-gettext --target=xscale-elf --enable-languages=c,c++ I am trying to build gcc on a FreeBSD 6.1-STABLE system. If there's more information I can give you, please ask. Jack.
Re: Notes from tinkering with the autovectorizer (4.1.1)
> > 1) The definition of the realignment instruction doesn't match hardware for > instrution sets like ARM WMMX, where aligned amounts shift by 0 bytes > instead of VECSIZE byes. This makes it useless for vector realignment, > because in the case that the pointer happens to be aligned, we get the > wrong vector. Looks like the SPARC realignment hook does the same thing... > Indeed, it looks like Altivec is the only one to support it, and they do > some trickery with shifting the wrong (against endianness) way based on the > two's compliment of the source (a very clever trick). No other machine > (evidentally) can easily meet the description of the current realignment > mechanism. > Indeed on altivec we implement the 'mask_for_load(addr)' builtin using 'lvsr(neg(addr))', that feeds the 'realign_load' (which is a 'vperm' on altivec). I'm not too familiar with the ARM WMMX ISA, but couldn't you use a similar trick - i.e instead of using the low bits of the address for the shift amount that feeds the realign_load, use shift=(VECSIZE - neg(addr))? I think this should give shift amount VECSIZE for the aligned case (and hopefully the correct shift amounts for the unaligned cases). dorit
Re: How do I build C++ for xscale-elf?
Jack Twilley wrote:
When I try to build C++ for xscale-elf, I get this as the last message:
configure: WARNING: No native atomic operations are provided for this
platform.
configure: WARNING: They cannot be faked when thread support is disabled.
configure: WARNING: Thread-safety of certain classes is not guaranteed.
configure: error: No support for this host/target combination.
What version of gcc should I be trying to build?
Anything with the 'xscale-elf' support...
Here's the configure line I use:
../configure --with-included-gettext --target=xscale-elf
--enable-languages=c,c++
The '--with-newlib' is obligatory when using 'newlib' as the target C
library! If you
have your own custom/proprietary C library for 'xscale-elf', then that
should be
preinstalled before starting the configure&build! The '--with-newlib'
should remove
all the link tests against the existing target C library from the extra
'lib*' configures,
the 'libstdc++-v3' being one. Your error seems to come from the
libstdc++-v3
configure...
I am trying to build gcc on a FreeBSD 6.1-STABLE system. If there's
more information I can give you, please ask.
What was the GCC version tried? The new gcc-4.1.1 seems to require the
'--disable-shared'
for instance with ARM, otherwise it tries to link against the "created"
'libgcc_s.so.1' despite
of using the '--with-newlib'. A stupid bug and a stupid workaround
('newlib' neither the target,
'xscale-elf', don't support shared libraries). With the gcc-4.1.1 also
the '--disable-shared' is
obligatory...
explaination of trampoline
I was just investigating the trampoline implementation.I have defined
following macros in machine.h file.
#define TRAMPOLINE_SIZE (32 + GET_MODE_SIZE (ptr_mode) * 2)
#define TRAMPOLINE_ALIGNMENT GET_MODE_BITSIZE (ptr_mode)
#define INITIALIZE_TRAMPOLINE(ADDR, FUNC, CHAIN)\
{ \
rtx func_addr, chain_addr;\
\
func_addr = plus_constant (ADDR, 32); \
chain_addr = plus_constant (func_addr, GET_MODE_SIZE (ptr_mode)); \
emit_move_insn (gen_rtx_MEM (ptr_mode, func_addr), FUNC); \
emit_move_insn (gen_rtx_MEM (ptr_mode, chain_addr), CHAIN); \
\
}
The c code for which i'm observing the effect is as follows.
int foo(int (*f)()){
(*f)();
}
main(){
int g(){printf("hello");}
foo(g);
}
But if i comment out the body of macro INITIALIZE_TRAMPOLINE .Nothing
gets changed in the generated assembly file.
According to gcc internals INITIALIZE_TRAMPOLINE is responsible for
initialising the variable parts of a trampoline.
Would you please tell me when does the macros INITIALIZE_TRAMPOLINE
and TRAMPOLINE_TEMPLATE come in effect.Any practical expample will be
helpful.
RE: Interesting -iquote bug
On 27 September 2006 01:49, Ian Lance Taylor wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
>> and this can find a user limits.h in a directory named with -iquote
>> whenever -I- isn't used. The user wishes to not so find that file, as
>> it breaks / on the system.
>
> My understanding has always been that #include_next should find a
> version of the header file farther down the search path. So if gcc's
> limits.h was found via #include , then the #include_next
> should not find a #include "limits.h", it should find the next
> .
>
> And that is pretty much what the documentation says. And I don't
> think that behaviour should change in any way.
>
> So I don't understand what the issue is. Can you give an example?
Here's one: it doesn't involve -iquote, but I think it illustrates the same
problem.
pushd /tmp
mkdir -p source source/debug source/main
cat < source/main/main.cc
#include
int main (int argc, const char **argv)
{
std::cout << "Hello world." << std::endl;
}
EOT
touch source/debug/debug.h
g++ -I source source/main/main.cc -o main
One of the STL headers finds our user-appplication debug/debug.h instead of
./debug/debug.h, which is what it expects to find (umm, I don't really mean
"." in the $PWD sense, I mean it in the sense of the directory where the STL
header lives).
It used to be possible to work around this problem by using -I- to split the
path and relying on <> includes to only pick up on system files. That's not
always an option ever since the change that made -I- /also/ prevent include
files located side-by-side in the same directory from finding each other
without a full path. As it says in the manual,
" In addition, the `-I-' option inhibits the use of the current
directory (where the current input file came from) as the first
search directory for `#include "FILE"'. There is no way to
override this effect of `-I-'. With `-I.' you can specify
searching the directory which was current when the compiler was
invoked. That is not exactly the same as what the preprocessor
does by default, but it is often satisfactory. "
Heh, "not exactly the same". Not remotely the same, and as a consequence,
if you were relying on the search-the-same-dir-first behaviour, there is no
workaround (that I have been able to imagine) except to find any headers in
your project that happen to match private headers used by the standard system
headers and add a #include_next and have this horrible scheme of proxying an
STL header's #include of it's own private header via your own source tree.
Ugh!
It would resolve the issue if these two unrelated behaviours of -I- were
separated.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Re: IPA branch
Razya Ladelsky/Haifa/IBM wrote on 27/09/2006 14:27:18: > > > > > > Jan -- > > > > I'm trying to plan for GCC 4.3 Stage 1. The IPA branch project is > > clearly a good thing, and you've been working on it for a long time, so > > I'd really like to get it into GCC 4.3. However, I'm a little > > concerned, in reading the project description, that it's not all that > > far along. I'm hoping that I'm just not reading the description well, > > and that you can explain things in a way that makes it obvious to me > > that the work is actually almost done. > > > > The Wiki page says "first part of patches was already sent", but I can't > > tell how much that is, or how many of the "modifications required" steps > > are already done. Have you completed all the work on the IPA branch > > itself, so that it's just a problem of merging? How much of the merging > > have you actually done? What version of mainline corresponds to the > > root of the IPA branch? Have maintainers with appropriate write > > privileges reviewed the patches? > > Mark, > I intended to write the overview in a way to express that some work will > be needed. In general IPA branch infrastructure is done (and was done > for last version too, I just was traveling and doing scientific work > during almost whole stage 1) and the branch was synchronized with > mainline two weeks ago. It was also used for building SPEC/c++ > benchmarks on IA-64/x86 and by Haifa people on PPC so it received some > testing. There is some bitrot from long merging and little SVN problem I > got shortly after summit, but I plan to clean this up while reviewing > the whole diff next week. > > I think that rest of work needs to be done on-the-fly while merging as > there are involved interfaces that are touching plans of multiple people > > The patch I am referring to is > http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00567.html that is by far > the most noisy patch from the planned series. I am planning to merge > the branch incrementally (same way as I did for all my past work) - > first localizing the variables, then adding infrastructure for holding > multiple SSA forms, teaching inliner to handle both SSA and non-SSA and > finally switch to it. Then the optimizations from Haifa folks and my > inliner changes can go in independently. > Except for new optimizations, IPCP (currently on mainline) should also be transformed to SSA. IPCP in SSA code exists on IPA branch, and will be submitted to GCC4.3 after IPA branch is committed and some testsuite regressions failing with IPCP+versioning+inlining are fixed. Razya > I was trying to take care to keep the things organized in a way so the > merge should be relatively safe ie if we stop in middle - I hope we > won´t, we won´t end up with too much dead code or compiler ready for > complete revert) The non-SSA path needs to be preserved for -O0 > compilation and the inliner simply handles the SSA datastructures as > additional IL feature rather than having two different implementations > of same thing. > > What I am most concerned about is the second step as there are some > datastructure changes (in particular the annotations on variables needs > to be partly privatized as they are shared across multiple functions for > static variables). IPA branch does it in a somewhat kludgy way I > discussed with rth and Diego on the summit. (I simply keep the > annotations around for static variables for duration of whole > compilation but most of data are reset when new function is being > compiled, that is bit nonsential memory-wise) > > While we don't have much better answer (other posibility discussed with > rth is simply bring all annotations to on-side hashtable and modify the > single accestor function, that is cleaner in design but more exensive > way to get into same place). It is probably desirable to move away from > annotations, so I would like to have some time in stage1 to simply drop > off as much as possible making my kludge smaller. So the plan would be > to do incremental changes to move the pass local data present in > annotations (actually almost everything except for pointer analysis > information) into on-the-side datastructures that is now hopefully > official plan to reduce memory usage too. > > The inliner changes/passmanager changes should be all pretty much fine - > only problems I hit there is that inliner occasionally needs fixing > because it does more constant propagation than mainline (instead of > const declared variables, I do all direct uses of SSA name of incomming > parameter) and the constant propagation in inliner is a bit broken, > but most of fixes was pushed upstream and I didn't seen any for a longer > while. There was other issues with SSA updating across EH edges, but we > resolved it on the summit with rth. > > There was no reviews from maintainers so far (I hoped to get ones while > possibly merging the stuff to LTO branch), but I hope it will g
Re: explaination of trampoline
The c code for which i'm observing the effect is as follows.
int foo(int (*f)()){
(*f)();
}
main(){
int g(){printf("hello");}
foo(g);
}
This one does not need a trampoline, because there would not be any
difference if int g() was not a nested function -- g() has no static
chain argument. Try this one instead:
int foo(int (*f)()){
(*f)();
}
main(int argc, char **argv){
int g(){printf("hello, argc=%d\n", argc);}
foo(g);
}
You will see trampolines in all their beauty.
Paolo
COND_EXPRs in GIMPLE code and vectorizer
Hello, I have a question about the form of COND_EXPR nodes allowed in GIMPLE representation. By looking at what gimplify.c does (more precisely, at function gimplify_cond_expr (...) ), I understood that GIMPLE only allows a restricted form of COND_EXPR, in which both 'then' and 'else' operands are GOTO_EXPR nodes. However, when compiling with -ftree-vectorize command-line option, there are cases of COND_EXPR nodes generated and not gimplified (in the sense of my previous sentence). An example of this is gcc.dg/tree-ssa/pr23115.c from the testsuite, when compiled with '-O2 -ftree-vectorize'. Is it a known issue or is just my assumption about the restriction of COND_EXPRs in GIMPLE wrong? Cheers, Roberto
Re: COND_EXPRs in GIMPLE code and vectorizer
However, when compiling with -ftree-vectorize command-line option, there are cases of COND_EXPR nodes generated and not gimplified (in the sense of my previous sentence). An example of this is gcc.dg/tree-ssa/pr23115.c from the testsuite, when compiled with '-O2 -ftree-vectorize'. Is it a known issue or is just my assumption about the restriction of COND_EXPRs in GIMPLE wrong? These are produced by if-conversion. The vectorizer might then take them and convert them to VEC_COND_EXPR (which are the only case in which vector-type comparison operators are allowed -- this is about the semantics, not the grammar). But if the loop is not vectorized, the COND_EXPR remains. Paolo
4.1.1 spec files missing, FAQ misinformation
I'm trying to get around the "Some people have crappy NFS architectures so we're going to make GCC so braindead it can't even find its own libraries" problem. Can anyone tell me where the spec files in 4.1.1 are? From the FAQ: "Dynamic linker is unable to find GCC libraries" ... "However, if you feel you really need such an option to be passed automatically to the linker, you may add it to the GCC specs file. This file can be found in the same directory that contains cc1 (run gcc -print-prog-name=cc1 to find it). You may add linker flags such as -R or -rpath, depending on platform and linker, to the *link or *lib specs." 4.1.1:linus> gcc -print-prog-name=cc1 /afs/rcf/lang/gcc/@sys/4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1/cc1 4.1.1:linus> cd /afs/rcf/lang/gcc/@sys/4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1 4.1.1:linus> ls cc1*cc1plus*install-tools/ jvgenmain* cc1obj* collect2* jc1* 4.1.1:linus> ls install-tools/ fixinc.sh* fixincl*mkheaders* 4.1.1:linus> jblaine:linus> cd /afs/rcf/lang/gcc/sun4x_59/4.1.1/ 4.1.1:linus> find . -name \*spec\* ./lib/libgcj.spec ./include/c++/4.1.1/ext/codecvt_specializations.h ./include/c++/4.1.1/java/beans/IntrospectionException.h ./include/c++/4.1.1/java/beans/Introspector.h ./include/c++/4.1.1/java/security/spec ./include/c++/4.1.1/javax/crypto/spec 4.1.1:linus>
4.1.1 spec files missing, FAQ misinformation
I'm trying to get around the "Some people have crappy NFS architectures so we're going to make GCC so braindead it can't even find its own libraries" problem. Can anyone tell me where the spec files in 4.1.1 are? From the FAQ: "Dynamic linker is unable to find GCC libraries" ... "However, if you feel you really need such an option to be passed automatically to the linker, you may add it to the GCC specs file. This file can be found in the same directory that contains cc1 (run gcc -print-prog-name=cc1 to find it). You may add linker flags such as -R or -rpath, depending on platform and linker, to the *link or *lib specs." 4.1.1:linus> gcc -print-prog-name=cc1 /afs/rcf/lang/gcc/@sys/4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1/cc1 4.1.1:linus> cd /afs/rcf/lang/gcc/@sys/4.1.1/bin/../libexec/gcc/sparc-sun-solaris2.9/4.1.1 4.1.1:linus> ls cc1*cc1plus*install-tools/ jvgenmain* cc1obj* collect2* jc1* 4.1.1:linus> ls install-tools/ fixinc.sh* fixincl*mkheaders* 4.1.1:linus> jblaine:linus> cd /afs/rcf/lang/gcc/sun4x_59/4.1.1/ 4.1.1:linus> find . -name \*spec\* ./lib/libgcj.spec ./include/c++/4.1.1/ext/codecvt_specializations.h ./include/c++/4.1.1/java/beans/IntrospectionException.h ./include/c++/4.1.1/java/beans/Introspector.h ./include/c++/4.1.1/java/security/spec ./include/c++/4.1.1/javax/crypto/spec 4.1.1:linus>
Re: COND_EXPRs in GIMPLE code and vectorizer
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote: Hello, I have a question about the form of COND_EXPR nodes allowed in GIMPLE representation. By looking at what gimplify.c does (more precisely, at function gimplify_cond_expr (...) ), I understood that GIMPLE only allows a restricted form of COND_EXPR, in which both 'then' and 'else' operands are GOTO_EXPR nodes. This is true for the conditional form that appears as a statement However, when compiling with -ftree-vectorize command-line option, there are cases of COND_EXPR nodes generated and not gimplified (in the sense of my previous sentence). However, it is possible for them to also appear on the RHS of a MODIFY_EXPR in order to represent the results of if-conversion. IE a = b ? c : d In this form, I believe each arm is required to be an SSA_VAR_P The way to differentiate the two is that the first form *only* appears as a statement, and the second form *only* appears on the RHS of a MODIFY_EXPR. HTH, Dan
Re: COND_EXPRs in GIMPLE code and vectorizer
Daniel Berlin wrote: On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote: Hello, I have a question about the form of COND_EXPR nodes allowed in GIMPLE representation. By looking at what gimplify.c does (more precisely, at function gimplify_cond_expr (...) ), I understood that GIMPLE only allows a restricted form of COND_EXPR, in which both 'then' and 'else' operands are GOTO_EXPR nodes. This is true for the conditional form that appears as a statement However, when compiling with -ftree-vectorize command-line option, there are cases of COND_EXPR nodes generated and not gimplified (in the sense of my previous sentence). However, it is possible for them to also appear on the RHS of a MODIFY_EXPR in order to represent the results of if-conversion. IE a = b ? c : d In this form, I believe each arm is required to be an SSA_VAR_P The way to differentiate the two is that the first form *only* appears as a statement, and the second form *only* appears on the RHS of a MODIFY_EXPR. Thanks for the explanation. The COND_EXPRs I saw were indeed of this second form. What is a bit surprising at second sight (first sight was my point of view while writing the first message) is that gimplify pass expands the COND_EXPRs of the second form into control-flow. Therefore, it looks like the only ones that can be found after gimplification are those generated by a further pass. Cheers, Roberto
Re: Notes from tinkering with the autovectorizer (4.1.1)
Dorit Nuzman wrote: Indeed on altivec we implement the 'mask_for_load(addr)' builtin using 'lvsr(neg(addr))', that feeds the 'realign_load' (which is a 'vperm' on altivec). I'm not too familiar with the ARM WMMX ISA, but couldn't you use a similar trick - i.e instead of using the low bits of the address for the shift amount that feeds the realign_load, use shift=(VECSIZE - neg(addr))? I think this should give shift amount VECSIZE for the aligned case (and hopefully the correct shift amounts for the unaligned cases). On Altivec, which on all targets is apparently big endian, you would think you would want to shift elements left (lower addresses, more significant) in order to align them. Instead we shift right (higher addresses / less significant) the negative amount to be able to get the behavior the hook wants: 0 --> 0 (get more significant vector) 1 --> 15 2 --> 14 ... 15 --> 1 This works because Altivec can shift either way arbitrarily. But on WMMX, which is little endian only, we only have an instruction to shift towards lower addresses. This is of course the behavior you would expect on first glance; to obtain an aligned vector you: and r_floor,r,#-8 wldrd wr0,[r_floor] wldrd wr1,[r_floor+#8] walignr w2,w0,w1,r /* The "r" in the mnemonic is for "register" */ There is no align going the other way, because it would be strange, and (seemingly for the architects I guess) unnecessary if you are only ever little endian. Indeed, in your paper (grin) "Multi-platform Auto-vectorization" you define the functionality of realign load in terms of mis - the misalignment of the address (i.e., address&(VS)), as follows: The last VS-mis bytes of vector vec1 are concatenated to the first mis bytes of the vector vec2. This is what the walign instruction does, but it's not quite what we ended up with in GCC. In the case that mis is 0, the GCC hook wants to end up with vec2, not vec1. So for architectures that can align both ways, the current method is fine, but if the architecture is designed for one endian only we are going to have trouble exploiting the alignment feature. Thanks, Erich -- Why are ``tolerant'' people so intolerant of intolerant people?
Re: COND_EXPRs in GIMPLE code and vectorizer
On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: > On 9/27/06, Roberto COSTA <[EMAIL PROTECTED]> wrote: > >> Hello, >> I have a question about the form of COND_EXPR nodes allowed in GIMPLE >> representation. >> By looking at what gimplify.c does (more precisely, at function >> gimplify_cond_expr (...) ), I understood that GIMPLE only allows a >> restricted form of COND_EXPR, in which both 'then' and 'else' operands >> are GOTO_EXPR nodes. > > > This is true for the conditional form that appears as a statement > >> However, when compiling with -ftree-vectorize command-line option, there >> are cases of COND_EXPR nodes generated and not gimplified (in the sense >> of my previous sentence). > > > However, it is possible for them to also appear on the RHS of a > MODIFY_EXPR in order to represent the results of if-conversion. > > IE > a = b ? c : d > > In this form, I believe each arm is required to be an SSA_VAR_P > > The way to differentiate the two is that the first form *only* appears > as a statement, and the second form *only* appears on the RHS of a > MODIFY_EXPR. Thanks for the explanation. The COND_EXPRs I saw were indeed of this second form. What is a bit surprising at second sight (first sight was my point of view while writing the first message) is that gimplify pass expands the COND_EXPRs of the second form into control-flow. Therefore, it looks like the only ones that can be found after gimplification are those generated by a further pass. Yes. This is also true for a few other expressions. IIRC, the gimplifier expands MAX_EXPR into control flow, even though it is legal gimple. However, tree-loop-linear will generate them as part of computing loop bounds expressions, for example. The usual reason for this type of thing is that the ability to have them as the RHS of a MODIFY_EXPR was added much later than the gimplifier, and it was decided that in order to avoid possible performance regressions, the existing behavior of lowering wouldn't be changed. If, of course, there is some good reason to always use the data dependent form over the control dependent form, we're always willing to explore changing the gimplifier to not do the lowering.
-fvtable-gc
It should has been removed from c.opt in the patch: http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02660.html. But it's still in trunk and branches 3.4/4.0/4.1/4.2. Jie
Re: Interesting -iquote bug
"Dave Korn" <[EMAIL PROTECTED]> writes: > Here's one: it doesn't involve -iquote, but I think it illustrates the same > problem. The problem which Mike described had to do with #include_next. So I don't think this is the same problem. > One of the STL headers finds our user-appplication debug/debug.h instead of > ./debug/debug.h, which is what it expects to find (umm, I don't really mean > "." in the $PWD sense, I mean it in the sense of the directory where the STL > header lives). I would describe this as a bug in the libstdc++ header files. They do this: #include That is a bad idea because if the user uses a -I option which happens to point to a debug/debug.h file, the wrong debug.h file will be picked up. The libstdc++ header files should probably do this: #include "debug/debug.h" Then the search will start from the location of the libstdc++ header file, and the preprocessor will always find the right header file. This is a consistent issue throughout the libstdc++ header files. > It used to be possible to work around this problem by using -I- to split the > path and relying on <> includes to only pick up on system files. That's not > always an option ever since the change that made -I- /also/ prevent include > files located side-by-side in the same directory from finding each other > without a full path. Yes, and the -I- option has been deprecated because it doesn't do the right thing. Instead, we have -iquote. And we are currently missing -idisable-the-directory-of-the-including-file, which is a bug. Unfortunately, using -idisable-the-directory-of-the-including-file will break my suggestion of using #include "" in the libstdc++ header files. But using #include <> in those header files is also wrong. I'm not sure how to resolve that. Ian
Does PTHREAD_MUTEX_INITIALIZER needs to be fixed on x86_64?
Hello! Recently, there was a couple of patches posted on gcc-patches that should fix various problems with solaris #includes. I would like to point out, that there is similar problem on x86_64 with libc-2.3.5 (Fedora Core 4) --cut here-- GNU C Library development release version 2.3.5, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.0.0 20050525 (Red Hat 4.0.0-9). Compiled on a Linux 2.4.20 system on 2005-05-30. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton GNU Libidn by Simon Josefsson Thread-local storage support included. --cut here-- The problem causes a couple of warnings in gcc build, like this: /home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-svn/trunk/gcc -I../../gcc-svn/trunk/gcc/. -I../../gcc-svn/trunk/gcc/../include -I../../gcc-svn/trunk/gcc/../libcpp/include -I../../gcc-svn/trunk/gcc/../libdecnumber -I../libdecnumber -fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../../gcc-svn/trunk/gcc/unwind-dw2-fde-glibc.c -o libgcc/./unwind-dw2-fde-glibc.o In file included from ../../gcc-svn/trunk/gcc/unwind-dw2-fde-glibc.c:62: ../../gcc-svn/trunk/gcc/unwind-dw2-fde.c:53: warning: missing initializer ../../gcc-svn/trunk/gcc/unwind-dw2-fde.c:53: warning: (near initialization for ‘object_mutex.__data.__count’) I have produced a short testcase, where the problem can be shown: --cut here-- #include static pthread_mutex_t object_mutex = PTHREAD_MUTEX_INITIALIZER; --cut here-- Compiling this with 'gcc -W' produces: thread.c:3: warning: missing initializer thread.c:3: warning: (near initialization for ‘object_mutex.__data.__count’) I'm not familiar with fixincludes, but perhaps somebody will be interested in this problem. Uros.
The Linux binutils 2.17.50.0.5 is released
This is the beta release of binutils 2.17.50.0.5 for Linux, which is
based on binutils 2006 0927 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.5 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.5 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If you don't use
# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2
to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.
Changes from binutils 2.17.50.0.4:
1. Update from binutils 2006 0927.
2. Fix linker regressions of section address and section relative symbol
with empty output section. PR 3223/3267.
3. Fix "strings -T". PR 3257.
4. Fix "objcopy --only-keep-debug". PR 3262.
5. Add Intell iwmmxt2 support.
6. Fix an x86 disassembler bug. PR 3100.
Changes from binutils 2.17.50.0.3:
1. Update from binutils 2006 0924.
2. Speed up linker on .o files with debug info on linkonce sections.
PR 3111.
3. Added x86-64 PE support.
4. Fix objcopy/strip on .o files with section groups. PR 3181.
5. Fix "ld --hash-style=gnu" crash with gcc 3.4.6. PR 3197.
6. Fix "strip --strip-debug" on .o files generated with
"gcc -feliminate-dwarf2-dups". PR 3186.
7. Fix "ld -r" on .o files generated with "gcc -feliminate-dwarf2-dups".
PR 3249.
8. Add --dynamic-list to linker to make global symbols dynamic.
9. Fix magic number for EFI ia64. PR 3171.
10. Remove PT_NULL segment for "ld -z relro". PR 3015.
11. Make objcopy to perserve the file formats in archive elements.
PR 3110.
12. Optimize x86-64 assembler and fix disassembler for
"add32 mov xx,$eax". PR 3235.
13. Improve linker diagnostics. PR 3107.
14. Fix "ld --sort-section name". PR 3009.
15. Updated an x86 disassembler bug. PR 3000.
16. Various updates for PPC, ARM, MIPS, SH, Xtensa.
17. Added Score support.
Changes from binutils 2.17.50.0.2:
1. Update from binutils 2006 0715.
2. Add --hash-style to ELF linker with DT_GNU_HASH and SHT_GNU_HASH.
3. Fix a visibility bug in ELF linker (PR 2884).
4. Properly fix the i386 TLS linker bug (PR 2513).
5. Add assembler and dissassembler support for Pentium Pro nops.
6. Optimize x86 nops for Pentium Pro and above.
7. Add -march=/-mtune= to x86 assembler.
8. Fix an ELF linker with TLS common symbols.
9. Improve program header allocation in ELF linker.
10. Improve MIPS, M68K and ARM support.
11. Fix an ELF linker crash when reporting alignment change (PR 2735).
12. Remove unused ELF section symbols (PR 2723).
13. Add --localize-hidden to objcopy.
14. Add AMD SSE4a and ABM new instruction support.
15. Properly handle illegal x86 instructions in group 11 (PR 2829).
16. Add "-z max-page-size=" and "-z common-page-size=" to ELF linker.
17. Fix objcopy for .tbss sections.
Changes from binutils 2.17.50.0.1:
1. Update from binutils 2006 0526.
2
thesis on mix c++ and objective-c
Hi, I'm beginning a end study thesis on "mix" c++ end objective-c in gcc. I know there is already objective-c++ but I need all information I can have on the subject. What is already done and what is not (and why)? I also need documentation for people who want to "enter" in gcc and to know how gcc work and how to modify it. I want to know how objective-c is compiled (translated in c and then compiled?). For now I'm trying to have the most information I can have to know where I can go in this thesis . Thank you Côme Lonfils
Re: thesis on mix c++ and objective-c
On Wed, 2006-09-27 at 20:58 +0200, Come Lonfils wrote: > Hi, > I also need documentation for people who want to "enter" in gcc and to > know how gcc work and how to modify it. I want to know how objective-c > is compiled (translated in c and then compiled?). Objective-C is parsed and the front-end produces GCC trees directly from the source. The source is never translated into C before compiling, just like the C++ front-end (which is by the way the first direct compiling front-end for C++). Thanks, Andrew Pinski
Making your branches smaller for easier merges
I see occasional complaints about the size of mainline merges to branches Most people working on branches are only modifying a very small subset of the files that are in mainline, and certainly not the entire trunk tree. You guys should be aware that you can simply branch those files you want (or those subdir trees you want), and keep the rest at the same revision as the mainline. IE you can have /branches/my-branch-gccdir -> copy of only /trunk/gcc and use svn switch to switch just your gcc subdirectory to this, while keeping all the other subdirs as mainline. svn knows how to handle this, and will properly keep everything at the right revisions. svnmerge knows how to handle this case, and you will avoid having to do merges of large dirs like libjava, libstdc++, etc at all. If you are just writing a new pass, you can probably get away with branching only a few files, and switching those may be a lot better strategy than branching the entire trunk tree branch to modify 6 files in the gcc dir.
Re: explaination of trampoline
On Sep 27, 2006, at 3:39 AM, kernel coder wrote: Would you please tell me when does the macros INITIALIZE_TRAMPOLINE and TRAMPOLINE_TEMPLATE come in effect.Any practical expample will be helpful. A dejagnu testsuite run also would spot problems in how you define these things.
Re: 4.1.1 spec files missing, FAQ misinformation
Wrong list, you should use gcc-help for help. On Sep 27, 2006, at 6:03 AM, Jeff Blaine wrote: I'm trying to get around the "Some people have crappy NFS architectures so we're going to make GCC so braindead it can't even find its own libraries" problem. Can anyone tell me where the spec files in 4.1.1 are? The command you quoted tells you in what directory you can place the file, the name of the file is "specs", and the contents can be found with gcc -dumpspecs. Feel free to update the FAQ (if it's in wiki)...
Re: Making your branches smaller for easier merges
Daniel Berlin wrote on 09/27/06 16:37: > If you are just writing a new pass, you can probably get away with > branching only a few files, and switching those may be a lot better > strategy than branching the entire trunk tree branch to modify 6 files > in the gcc dir. > But this means that I'm at the mercy of mainline random breakage, right? Most of the time I would rather do controlled merges when I know mainline is in a usable state.
Re: 4.1.1 spec files missing, FAQ misinformation
Mike Stump <[EMAIL PROTECTED]> writes: > Wrong list, you should use gcc-help for help. > > On Sep 27, 2006, at 6:03 AM, Jeff Blaine wrote: > > I'm trying to get around the "Some people have crappy NFS > > architectures so we're going to make GCC so braindead it > > can't even find its own libraries" problem. > > > > Can anyone tell me where the spec files in 4.1.1 are? > > The command you quoted tells you in what directory you can place the > file, the name of the file is "specs", and the contents can be found > with gcc -dumpspecs. > > Feel free to update the FAQ (if it's in wiki)... Note that recent versions of gcc no longer install the specs file. But they will read it if it exists. Ian
Re: How do I build C++ for xscale-elf?
Kai Ruottu wrote:
Jack Twilley wrote:
I am trying to build gcc on a FreeBSD 6.1-STABLE system. If there's
more information I can give you, please ask.
What was the GCC version tried? The new gcc-4.1.1 seems to require the
'--disable-shared'
for instance with ARM, otherwise it tries to link against the "created"
'libgcc_s.so.1' despite
of using the '--with-newlib'. A stupid bug and a stupid workaround
('newlib' neither the target,
'xscale-elf', don't support shared libraries). With the gcc-4.1.1 also
the '--disable-shared' is
obligatory...
I tried gcc-4.1.1 from SVN (gcc_4_1_1_release) with the following
configure line:
It fails on compiling regex.c in xscale-elf/libiberty with a whole bunch
of errors about not bein able to find sys/types.h and strings.h and the
like.
I have installed binutils-2.17 from SVN (binutils-2_17) for xscale-elf.
Its version of libiberty installed into /usr/local/lib/ which makes me
wonder how many things I accidentally overwrote while building that, but
I'll rebuild FreeBSD later.
Should I have not built binutils? Was there something else I missed?
Jack.
Re: Making your branches smaller for easier merges
On 9/27/06, Diego Novillo <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote on 09/27/06 16:37: > If you are just writing a new pass, you can probably get away with > branching only a few files, and switching those may be a lot better > strategy than branching the entire trunk tree branch to modify 6 files > in the gcc dir. > But this means that I'm at the mercy of mainline random breakage, right? Yes Most of the time I would rather do controlled merges when I know mainline is in a usable state. Some of us like to live on the edge. Seriously though, it's a tradeoff between how much time you want to spend on branch maintenance vs how much mainline breakage you are willing to accept. I just wanted to throw it out there since some people may not know it's even possible
Re: Making your branches smaller for easier merges
On Wednesday 27 September 2006 21:37, Daniel Berlin wrote: > I see occasional complaints about the size of mainline merges to > branches Most people working on branches are only modifying a very > small subset of the files that are in mainline, and certainly not the > entire trunk tree. I'm kinda surprised this is still a problem. With svn even big merges should be fairly quick, and if you're only modifying a small part of the tree then everything else should merge without conflicts. Am I missing something? Paul
Re: thesis on mix c++ and objective-c
On Sep 27, 2006, at 11:58 AM, Come Lonfils wrote: I'm beginning a end study thesis on "mix" c++ end objective-c in gcc. I know there is already objective-c++ but I need all information I can have on the subject. What is already done and what is not (and why)? Objective-C++ is already done. Parts not done might include, Objective-C style exceptions interoperating with C++ style exceptions. Beyond that, just random bug fixes. I also need documentation for people who want to "enter" in gcc and to know how gcc work and how to modify it. I want to know how objective-c is compiled It is compiled just like C is compiled. Objective C++ is compiled just like C++ is compiled.
Re: Interesting -iquote bug
On Sep 26, 2006, at 5:48 PM, Ian Lance Taylor wrote: So I don't understand what the issue is. Can you give an example? mrs $ cat subdirectory/limits.h // // bogus limits.h header should never be included // #error "including limits.h from the wrong place" mrs $ gcc -iquotesubdirectory t.c In file included from /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/ syslimits.h:7, from /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/ include/limits.h:11, from t.c:1: subdirectory/limits.h:5:2: error: #error "including limits.h from the wrong place" mrs $ gcc -iquotesubdirectory -I- t.c -c cc1: note: obsolete option -I- used, please use -iquote instead mrs $ cat t.c #include Here, you can see the right limits.h file is included from t.c, as we'd expect, but that the wrong one is included from syslimits.h: $ gcc -iquotesubdirectory t.c -E # 1 "t.c" # 1 "" # 1 "" # 1 "t.c" # 1 "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h" 1 3 4 # 11 "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h" 3 4 # 1 "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/syslimits.h" 1 3 4 # 1 "subdirectory/limits.h" 1 3 4 # 8 "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/syslimits.h" 2 3 4 # 12 "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/limits.h" 2 3 4 # 1 "t.c" 2 Side note, this stuff makes my head hurt. Maybe it is just a trivial bug in some logic somewhere, and these aren't the desired/documented semantics.
Re: Making your branches smaller for easier merges
On 27/09/06, Daniel Berlin <[EMAIL PROTECTED]> wrote: On 9/27/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote on 09/27/06 16:37: > > > If you are just writing a new pass, you can probably get away with > > branching only a few files, and switching those may be a lot better > > strategy than branching the entire trunk tree branch to modify 6 files > > in the gcc dir. > > > But this means that I'm at the mercy of mainline random breakage, right? Yes Why? Perhaps I am entirely wrong but can't you just don't update (svn up) those directories that are switched until mainline is in an usable state? Cheers, Manuel.
Re: Making your branches smaller for easier merges
Manuel López-Ibáñez wrote on 09/27/06 17:38: > Why? Perhaps I am entirely wrong but can't you just don't update (svn > up) those directories that are switched until mainline is in an usable > state? > If a pristine directory needs changes from the directory I branched, I'm in trouble.
Re: Making your branches smaller for easier merges
On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: Manuel López-Ibáñez wrote on 09/27/06 17:38: > Why? Perhaps I am entirely wrong but can't you just don't update (svn > up) those directories that are switched until mainline is in an usable > state? > If a pristine directory needs changes from the directory I branched, I'm in trouble. Why? Sorry, I think I don't understand what you mean.
Google group for generic System V Application Binary Interface
I created a Google group to discuss generic ABI: http://groups.google.com/group/generic-abi It is by membership only. Let me know if you are interested. Thanks. H.J.
Re: Making your branches smaller for easier merges
Manuel López-Ibáñez wrote on 09/27/06 18:25: > On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> If a pristine directory needs changes from the directory I branched, I'm >> in trouble. >> > > Why? Sorry, I think I don't understand what you mean. > Say I branch gcc/gcc and keep all the runtime libraries pristine. Now suppose that a new change in mainline introduces changes in gcc/libgomp which require a new compiler option. Since I branched gcc/gcc I'm out of sync with mainline and now libgomp doesn't build, forcing me to merge my branched directory.
Re: Making your branches smaller for easier merges
> > On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > > Manuel López-Ibáñez wrote on 09/27/06 17:38: > > > > > Why? Perhaps I am entirely wrong but can't you just don't update (svn > > > up) those directories that are switched until mainline is in an usable > > > state? > > > > > If a pristine directory needs changes from the directory I branched, I'm > > in trouble. > > > > Why? Sorry, I think I don't understand what you mean. For an example, an extension is added to the C++ front-end and a change to the libstdc++ library that now require this extension. Now you have a mix match between the library and the compiler as you are using a pristine libstdc++ from the mainline but a branched C++ front-end. -- Pinski >
Re: Making your branches smaller for easier merges
> Why? Perhaps I am entirely wrong but can't you just don't update (svn > up) those directories that are switched until mainline is in an usable > state? That's only feasible if you're the only person working on that branch, and you only ever use one checkout on one machine. I guess you could use numbered trunk revisions, but that seems like harder work than just creating a full branch and doing the merge. Paul
Re: Making your branches smaller for easier merges
On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: Manuel López-Ibáñez wrote on 09/27/06 18:25: > On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> If a pristine directory needs changes from the directory I branched, I'm >> in trouble. >> > > Why? Sorry, I think I don't understand what you mean. > Say I branch gcc/gcc and keep all the runtime libraries pristine. Now suppose that a new change in mainline introduces changes in gcc/libgomp which require a new compiler option. Since I branched gcc/gcc I'm out of sync with mainline and now libgomp doesn't build, forcing me to merge my branched directory. Hum, no? You can either don't update libgomp (or update back to a previous revision). Anyway, feel free to end this conversation as soon as you wish since Paul Brook is right: given fast internet and plenty harddrive, all this is pointless. But if you wish to continue, please be my guest :-) Manuel.
Re: Making your branches smaller for easier merges
Manuel López-Ibáñez wrote on 09/27/06 18:50: > On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: >> Manuel López-Ibáñez wrote on 09/27/06 18:25: >>> On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: >>> If a pristine directory needs changes from the directory I branched, I'm in trouble. >>> Why? Sorry, I think I don't understand what you mean. >>> >> Say I branch gcc/gcc and keep all the runtime libraries pristine. Now >> suppose that a new change in mainline introduces changes in gcc/libgomp >> which require a new compiler option. >> >> Since I branched gcc/gcc I'm out of sync with mainline and now libgomp >> doesn't build, forcing me to merge my branched directory. > > Hum, no? You can either don't update libgomp (or update back to a > previous revision). > No, you cannot count on that. The machines I have doing automated check-outs and builds of my branch will get corrupted trees. Somebody else getting a copy of the branch will also get a broken tree. > Anyway, feel free to end this conversation as soon as you wish since > Paul Brook is right: given fast internet and plenty harddrive, all > this is pointless. > Precisely. It's much simpler to branch the whole thing. SVN ought to be smart enough to do COW versioning (I understand it does).
Re: Making your branches smaller for easier merges
On 27/09/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On 27/09/06, Diego Novillo <[EMAIL PROTECTED]> wrote: > > Manuel López-Ibáñez wrote on 09/27/06 17:38: > > > > > Why? Perhaps I am entirely wrong but can't you just don't update (svn > > > up) those directories that are switched until mainline is in an usable > > > state? > > > > > If a pristine directory needs changes from the directory I branched, I'm > > in trouble. > > > > Why? Sorry, I think I don't understand what you mean. For an example, an extension is added to the C++ front-end and a change to the libstdc++ library that now require this extension. Now you have a mix match between the library and the compiler as you are using a pristine libstdc++ from the mainline but a branched C++ front-end. Sorry, I still don't see where is the problem. You either want the extension in your branch, so you merge it and simply update libstdc++, or you don't want the extension just yet, so you just don't update libstdc++ (or update back to your previous revision). If you had branched libstdc++ you would have a similar situation: to merge or not to merge the extension to both.
Re: Making your branches smaller for easier merges
> > > Sorry, I still don't see where is the problem. You either want the > extension in your branch, so you merge it and simply update libstdc++, > or you don't want the extension just yet, so you just don't update > libstdc++ (or update back to your previous revision). That means you have to follow what is going on the mainline closer than you would if you just branched the whole sources. Yes changes like this has happened for 4.2.0 even. Since you branched the GCC directory for non front-end changes like say a new opimization, you don't want to follow what is happening on the C++ front-end side that closely .Also you don't know if it was too late to update until you actually did it. -- Pinski
Re: Making your branches smaller for easier merges
On 28/09/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > Sorry, I still don't see where is the problem. You either want the > extension in your branch, so you merge it and simply update libstdc++, > or you don't want the extension just yet, so you just don't update > libstdc++ (or update back to your previous revision). That means you have to follow what is going on the mainline closer than you would if you just branched the whole sources. Yes changes like this has happened for 4.2.0 even. Since you branched the GCC directory for non front-end changes like say a new opimization, you don't want to follow what is happening on the C++ front-end side that closely .Also you don't know if it was too late to update until you actually did it. I don't see what is the difference between "merging your branched dir and updating everything else" and "branch and merge everything". In both cases you may need to review the changes and in both cases you can go back to before the merge. The only difference is that in the first case you don't merge changes for the directories that are not branched, just update (or not). Anyway, I may be misunderstanding the whole issue, so I drop the ball here. I have the awful feeling that I have hichjacked Daniel's thread. Manuel.
New DejaGNU parsing and comparison scripts in contrib
I've committed some code for parsing DejaGNU log/sum files and doing three-way comparisons to contrib. dglib.pm is a perl module which implements a "parseLogFile" function. parseLogFile will take a DejaGNU log or sum file and return a detailed parse of the file. Tests will be broken into groups, and multi-phase (compile/link/execute) test results will be combined for instance: FAIL: gcc.dg/c-torture/link/2105-1.c -O0 (test for excess errors) will become something like: gcc.dg c-torture compile/link/execute 2105-1.c -O0 (test for excess errors) where 2105-1.c is a test group, which is inside the "compile/link/ execute" test group, which is inside the "c-torture" test group, which is inside the "gcc.dg" test group. "-O0 (test for excess errors)" is the test name. It will have the result "FAIL", and it will have a 'result detail' of "link phase". It will also associate non-result lines in the log file with their respective results. compareSumTests3 is a script written on top of this which can do a three-way comparison between DejaGNU .sum (or .log) files. It's designed for doing a merge of branch A into branch B, where you have two "old" compilers (the pre-merge compiler on branch A, 'old1', and the pre-merge compiler on branch B, 'old2') and one "new" compiler (the post-merge compiler.) It will tell you things like "these tests were working in both old compilers but are broken after the merge", or "these tests only worked in old1." I hope people find them useful. Feel free to contact me with questions, comments, &c. -- Matthew Sachs <[EMAIL PROTECTED]> [AIM: MattSachs] Compiler Quality Engineer, Apple Computer
representation of struct field offsets
I've been having a heck of a time figuring out how to translate the offsets for struct fields from the DWARF encoding back to GCC's internal encoding for the LTO project. I've got a handle on the DWARF encoding and how to do the necessary big/little endian conversions, but for the GCC side, there doesn't seem to be any documentation about the relevant macros in the manual, and the comments in tree.h don't seem to reflect what is actually going on in the representation. For example, DECL_FIELD_OFFSET is supposed to be "the field position, counting in bytes, of the byte containing the bit closest to the beginning of the structure", while DECL_FIELD_BIT_OFFSET is supposed to be "the offset, in bits, of the first bit of the field from DECL_FIELD_OFFSET". So I'm quite puzzled why, for fields that are not bit fields and that are aligned on byte boundaries, the C front end is generating a DECL_FIELD_OFFSET that points to some byte that doesn't contain any part of the field, and a non-zero DECL_FIELD_BIT_OFFSET instead. If I make the LTO front end do what the comments in tree.h describe, then dwarf2out.c produces incorrect offsets that don't match those from the original C file. I see in stor-layout.c that there are routines to "perform computations that convert between the offset/bitpos forms and byte and bit offsets", but what exactly are these forms and which values are the ones that I should actually be storing inside the FIELD_DECL object? Is it possible to compute the DECL_OFFSET_ALIGN value somehow, given that it's not encoded in the DWARF representation? Trying to reverse-engineer dwarf2out.c isn't turning out to be very productive :-P -Sandra
