Re: C++ parsing regression?
On Mon, 2 Jan 2006, Mark Mitchell wrote:
> Richard Guenther wrote:
> > g++ no longer parses
> >
> > ScalarCode >(CflFunctor(omrot, vis_f))(scratch,
> > I, cs, nue, v);
> >
> > correctly, but issues
> >
> > tramp3d-v4.cpp:53573: error: invalid declarator
> >
> > which can be fixed by putting parantheses around the decl. Was this
> > change intended?
>
> I'm not sure; please send me preprocessed source, and I will look into
> it. It's certainly possible that those changes broke something.
>
> What do you think the above code is supposed to mean? Are you declaring
> a constructor for CflFunctor, or an unnamed variable of type
> ScalarCode > or ?
It's
{
CflFunctor tmp1(omrot, vis_f);
ScalarCode > tmp2(tmp1);
tmp2.operator()(scratch, I, cs, nue, v);
}
i.e. instantiating ScalarCode > using the constructor
that takes an argument of type CflFunctor that is constructed
with the two params omrot and vis_f and then calling operator() on
the constructed object.
Source is from http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.cpp.gz
A reduced testcase looks like
template
struct ScalarCode
{
ScalarCode(const T&);
template
void operator()(const A&, const B&);
};
template
struct CflFunctor
{
CflFunctor(bool omrot, bool vis_f);
};
struct Bar {};
void foo(bool omrot, bool vis_f, const Bar& x, const Bar& y)
{
ScalarCode >(CflFunctor<3>(omrot, vis_f))(x, y);
}
Richard.
Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?
> Jim Blandy wrote: > On 1/2/06, Paul Schlie wrote: >> - at the most basic level, I feel like I've too often needlessly wasted >> time debugging programs at one level of optimization, to only see a >> different behavior needlessly expressed at a different level of >> optimization (which I understand means something isn't portable, but >> isn't the correct way to inform one of non-portable code, but is one >> hell of a way to unknowingly interject bugs into a program which didn't >> exist at a different level of optimization); however if a compiler >> supported the means by which a target could define the semantics left >> undefined by a language, an optimizing compiler could then both satisfy >> the formal constrains of language, while simultaneously enabling target >> specific semantics to be supported, and preserved through optimization. >> (which seems like a win-win to me) > > Okay, this makes sense to me now. If there were a switch that changed > the language from ISO C to a very similar language that actually > specified a fixed behavior for all the behaviors that ISO C says are > unspecified or undefined, then you'd have a language that might not be > possible to compile as efficiently in some cases, but in which every > program had a unique correct behavior. (Setting aside inherently > unpredictable things like threads and signals.) For example, the > language would actually have to specify some default value for all > variables, or require them to be assigned before their first use in a > way that the compiler could statically verify (as in Java). > > This is what the Java folks were shooting for, if you ignore the > non-determinism introduced by threads. Standard ML also specifies a > particular result for all programs. If my copies of both those specs > weren't still packed, I think I could actually find quotes from each > where they state being fully defined as a goal. So I think it's clear > there are a lot of people who think this is a worthwhile principle. > > Paul is combining this suggestion with the further idea that the > unspecified and undefined behaviors could be tied down in a way > comfortable for the particular target. I guess he's trying to reduce > the performance impact. That concession would allow the changes in > behavior that annoy him now when he switches optimization levels to > re-appear when one switches targets. The opposite extreme to Paul's > concession would be to eliminate all target-dependent characteristics > from the language, including type size differences and alignment > requirements, yielding a language which specified a unique correct > result for all programs (again, setting aside threads and signals) on > all targets. As ML and Java do. > Or, there could be a middle ground: you could specify some > characteristics (say, integral type sizes and wrap-around on overflow) > for all targets, but leave others (say, pointer size and alignment) > target-specific. Yes.
Re: Thumb optimization question
On Mon, 2005-12-26 at 21:41, Ivan Petrov wrote:
> I have one question. So... have small sample programm.
>
> [code]
> int bar( int );
>
> int foo( int a, int b )
> {
>return bar( a + b );
> }
> [/code]
>
> If I compille it with out -thumb parameter, i have very clean code.
>
> add r0, r1, r0
> bx lr
>
> But with -thumb parameter have unopimized code.
>
> add r1, r1, r0
> mov r0, r1
> bx lr
>
> All diff of it outrage on '*.27.combine' (key -da) optimization step. But I
> long time can't understad how it work.
> Can anybody help me with it?
It's because the register allocator is stupid.
R.
Re: Xscale big endian tool-chain (how to build it?)
On Sat, 2005-12-31 at 20:26, Karel Gardas wrote: > /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: > > ERROR: > /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o) > > uses hardware FP, whereas hello.xg2 uses software FP > [] > > if I understand it correctly, then libgcc.a provided in > /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a is > build with -mhard-float, while my application with -msoft-float. > > Question: any idea how to build GCC tool-chain with soft-float's libgcc.a for > big-endian Xscale? -- here I assume I'm right with my conclusion above, if > this > is not the case please correct me. > You get this error if you try to use -msoft-float with a gcc configuration that already defaults to -msoft-float. This is because the default object files are marked incorrectly in this case. The easiest way to work around it is to not use the -msoft-float option for these configurations. R.
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Sat, 2005-12-31 at 20:26, Karel Gardas wrote: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o) uses hardware FP, whereas hello.xg2 uses software FP [] if I understand it correctly, then libgcc.a provided in /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a is build with -mhard-float, while my application with -msoft-float. Question: any idea how to build GCC tool-chain with soft-float's libgcc.a for big-endian Xscale? -- here I assume I'm right with my conclusion above, if this is not the case please correct me. You get this error if you try to use -msoft-float with a gcc configuration that already defaults to -msoft-float. This is because the default object files are marked incorrectly in this case. The easiest way to work around it is to not use the -msoft-float option for these configurations. OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame and options used to build my app are: -mbig-endian -O2 -g hello.c -o hello.xg -L../lib -nostdlib -Ttarget.ld Anyway, could you be so kind and please have a look at my reply to gcc-help, where I've described my suspicion about this issue? http://gcc.gnu.org/ml/gcc-help/2006-01/msg00015.html http://gcc.gnu.org/ml/gcc-help/2006-01/msg00016.html My major doubts are about the build of soft-float libgcc when -msoft-float is not used at all. Thanks! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: > OK, if I understand you well, then I should not use -msoft-float for both: > compiling of eCos lib and then for compiling my eCos-based app. The > problem is that this is not right way how to workaround this issue. I've > checked that I'm not using -msoft-float neither for building eCos lib nor > for building eCos-based app. I've saved typescript of `make' so I'm sure > build does not use -msoft-float anywhere and the issue is still the same. > > FYI: Options used for eCos lib build are: > -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall > -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 > -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame Try taking -Wa,-mfpu=softfpa out as well. That will probably have the same adverse effect on the object files generated. R.
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame Try taking -Wa,-mfpu=softfpa out as well. That will probably have the same adverse effect on the object files generated. OK, I've removed this and got this one now: silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib -nostdlib -Ttarget.ld /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /tmp/ccKN8dgp.o /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) uses FPA instructions, whereas hello.xg does not Anyway, I've now compared fpu and common libgcc and found that really fpu (which should be hard-float) is different from the common lib in be subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a), so my assumption about building hard-float libgcc by default is not true neither. Do you have any idea how to proceed with this? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, Jan 02, 2006 at 10:35:40PM -0500, Hans-Peter Nilsson wrote: > I was just bitten by the same behavior for define_split. > Should the same go for define_splits ... Um, sure. > and maybe also as a guard test for combine? That would be silly, since the note doesn't exist that early. r~
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, Jan 02, 2006 at 08:10:21PM -0800, Ian Lance Taylor wrote: > And flow2 calls split_all_insns before the > prologue and epilogue insns are threaded. When did the bogus split > happen? There are at least 3 post-reload split points. r~
Re: RTL alias analysis
On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote: > ... the real > solution is to transfer the information that the stack space sharing > knows into some simple set form, and use *that directly* in alias.c, and > check it *first*, so that if they have the same stack slot, we say there > is a dependence, even if the memory expressions/types/etc look > different. ... And that doesn't work for the test case, because we've carefuly thrown away any information that might have given us any information wrt the stack slots. I'll have to give this some thought. r~
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 2006-01-03 at 15:52, Karel Gardas wrote: > On Tue, 3 Jan 2006, Richard Earnshaw wrote: > > > On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: > > > >> OK, if I understand you well, then I should not use -msoft-float for both: > >> compiling of eCos lib and then for compiling my eCos-based app. The > >> problem is that this is not right way how to workaround this issue. I've > >> checked that I'm not using -msoft-float neither for building eCos lib nor > >> for building eCos-based app. I've saved typescript of `make' so I'm sure > >> build does not use -msoft-float anywhere and the issue is still the same. > >> > >> FYI: Options used for eCos lib build are: > >> -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall > >> -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 > >> -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame > > > > Try taking -Wa,-mfpu=softfpa out as well. That will probably have the > > same adverse effect on the object files generated. > > OK, I've removed this and got this one now: > > silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ > arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib > -nostdlib -Ttarget.ld > /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: > > ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not > /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: > > failed to merge target specific data of file /tmp/ccKN8dgp.o > /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: > > ERROR: > /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) > uses FPA instructions, whereas hello.xg does not > > > Anyway, I've now compared fpu and common libgcc and found that really fpu > (which should be hard-float) is different from the common lib in be > subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a), > so my assumption about building hard-float libgcc by default is not true > neither. > > Do you have any idea how to proceed with this? Ug, this would appear to be a bundle of different options plus a build-process that ends up with everything conflicting[1] with itself... ;-( First of all, you can't in general just copy in the old version of t-arm-elf into a later version of GCC and expect it to work correctly. Compare the gcc-4.0.x version against the sample one from the website and then uncomment the relevant bits to suit your needs (this is for the multilibs stuff). You probably won't need everything, but if you closely mimic what's been done before you should have fewer problems. The options are generally grouped, so if you uncomment one option, make sure you uncomment the entire group. Next, I suggest you add --with-cpu=xscale when configuring GCC. You can then drop the -mcpu=xscale when compiling (this should also give you better libraries for your system). However, beware that you libraries will now only run on ARMv5 or later processors. R. [1] If you want the gory details, then I think they are as follows: - With no CPU specified the assembler assumes -msoft-fpa as a default, but it incorrectly marks the objects as being hard-fpa - With -mcpu=xscale the assembler defaults to -msoft-vfp and correctly marks the objects as such. - There's then no way to switch back to 'soft-fpa, but with the hard-fpa marking used by the default configuration.
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: First of all, you can't in general just copy in the old version of t-arm-elf into a later version of GCC and expect it to work correctly. Compare the gcc-4.0.x version against the sample one from the website and then uncomment the relevant bits to suit your needs (this is for the multilibs stuff). Just a note. I'm using/building gcc-4.0.1 and I'm using/hacking t-arm-elf from the gcc-4.0.1 release. Anyway, thanks for your kind explanation and advice which I'm going to follow to see if it solves my issue. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
inconsistency in location of static and shared libraries on sparc64-sun-solaris*
I've just built gcc with sparc64 as build target (64-bit gcc binary that generates 64-bit code by default, much like Linux amd64 does). I've noticed one inconsistency how libraries are installed. For shared libraries (lib*.so), the 32-bit version is installed in prefix/lib, while 64-bit version is installed in prefix/lib/sparcv9. For static libraries (lib*.a archives), it is the other way around. The 64-bit version is installed in prefix/lib, while 32-bit version is installed in prefix/lib/sparcv7!? Just wondering if this was by design, and/or if there was some good reason for this? Looking at the system libraries (/lib, /usr/lib), the lib/lib*.a are 32-bit, there is no sparcv7 directory anywhere in sight. There's almost no static 64-bit libs either (with exception of two, libadt_jni.a and libldfeature.a, and they are in lib/sparcv9 as expected). A bit off topic. While configure script for gcc creates makefiles that generate both 32-bit and 64-bit libraries, I noticed that configure script in all other GNU packages doesn't. Even more, when building on sparc64 target, the libraries (which are 64-bit) get installed in prefix/lib (not in prefix/lib/sparcv9). Hmmm... kind of annoying. Is this generic configure script problem, or libtool problem, or developers not caring about Solaris 32/64 bit specifics, or something else? Any good way to go around that? I've used --libdir $prefix/lib/sparcv9, but that has side effect of placing data files in sparcv9 with some packages (while only 64-bit libs should go there). Gettext is an example of such package where using --libdir has not desired side-effects. This message was sent using IMP, the Internet Messaging Program.
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:52, Karel Gardas wrote: On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame Try taking -Wa,-mfpu=softfpa out as well. That will probably have the same adverse effect on the object files generated. OK, I've removed this and got this one now: silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib -nostdlib -Ttarget.ld /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /tmp/ccKN8dgp.o /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) uses FPA instructions, whereas hello.xg does not Anyway, I've now compared fpu and common libgcc and found that really fpu (which should be hard-float) is different from the common lib in be subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a), so my assumption about building hard-float libgcc by default is not true neither. Do you have any idea how to proceed with this? Ug, this would appear to be a bundle of different options plus a build-process that ends up with everything conflicting[1] with itself... ;-( First of all, you can't in general just copy in the old version of t-arm-elf into a later version of GCC and expect it to work correctly. Compare the gcc-4.0.x version against the sample one from the website and then uncomment the relevant bits to suit your needs (this is for the multilibs stuff). You probably won't need everything, but if you closely mimic what's been done before you should have fewer problems. The options are generally grouped, so if you uncomment one option, make sure you uncomment the entire group. Next, I suggest you add --with-cpu=xscale when configuring GCC. You can then drop the -mcpu=xscale when compiling (this should also give you better libraries for your system). However, beware that you libraries will now only run on ARMv5 or later processors. I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The failure happen during compilation of gcc and it looks like: /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ -nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem /tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem /tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include -B/home/karel/usr/local/arm-elf1/arm-elf/bin/ -B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem /home/karel/usr/local/arm-elf1/arm-elf/include -isystem /home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. -I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include -mhard-float -DL_addsubdf3 -xassembler-with-cpp -c ../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages: ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor does not support `ldfd f0,[sp],#8' make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1 make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make: *** [all-gcc] Error 2 First of all, I've thought this is because of my original binutils binaries configured with out --with-cpu=xscale, but even if I add this configure switch and rebuild them, the issue is still the same. Perhaps, my bintutils config is still wrong? But I'm short of ideas what to do n
keeping branch up to date with mainline
All, I've recently opened a new branch for treegion (tree-region) scheduling. I'm new at this and was just wondering if someone could tell me how to keep my branch updated with the mainline? Thanks, Chad Rosier
Re: keeping branch up to date with mainline
On Tuesday 03 January 2006 12:17, [EMAIL PROTECTED] wrote: > how to keep my branch updated with the mainline? > The easiest way is using svnmerge.py (included in SVN's contrib directory). There's documentation in the GCC wiki: http://gcc.gnu.org/wiki/SvnBranch
Re: HARD_REGNO_MODE_OK_FOR_CLASS Might Be Nice (tm)
In http://gcc.gnu.org/ml/gcc/2005-12/msg00642.html, Bernd Jendrissek wrote: > Which leads me to the subject. Would it be a win to have a macro > HARD_REGNO_MODE_OK_FOR_CLASS (REGNO, MODE, CLASS) which would be the > authoritative test for this loop in find_reg()? On my port, and I > imagine on many others too, I think a default > > #ifndef HARD_REGNO_MODE_OK_FOR_CLASS > #define HARD_REGNO_MODE_OK_FOR_CLASS(REGNO, MODE, CLASS) \ > HARD_REGNO_MODE_OK ((REGNO), (MODE)) > #endif > > would be okay. It's not that simple. For example, consider multi-word integer arithmetic. If you want to allocate a 32 bit integer register on your 16 bit x86, all the integer registers are suitable as parts of the allocation. However, if you start with the last integer register, the second part will end up in a hard register which is not an integer register. So to make this work, you's have to say that the last integer register is not suitable for SImode, SFmode or CHImode, the last three ones are not suitable for DImode, DFmode, CSImode or SCmode etc.
Re: Bootstrap failure on Linux/i686 in Ada
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > Hi Rainer, this is PR24994: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > And is under investigation: > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html Still under investigation. Very little happened over the last week. I'm back on it though :-) jeff
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 2 Jan 2006, Ian Lance Taylor wrote: > When did the bogus split > happen? Sorry, I didn't answer this question and now the gdb session is gone. Hopefully the answer isn't that important given RTH's comment? I'd guess reorg. brgds, H-P
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 2006-01-03 at 17:15, Karel Gardas wrote: > I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The > failure happen during compilation of gcc and it looks like: > > /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ > -nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem > /tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem > /tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include > -B/home/karel/usr/local/arm-elf1/arm-elf/bin/ > -B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem > /home/karel/usr/local/arm-elf1/arm-elf/include -isystem > /home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC > -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include > -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED > -Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. > -I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include > -mhard-float -DL_addsubdf3 -xassembler-with-cpp -c > ../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o > ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages: > ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor > does not support `mvfeqd f0,#0.0' > ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor > does not support `mvfeqd f0,#0.0' > ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor > does not support `ldfd f0,[sp],#8' > make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1 > make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' > make[1]: *** [stmp-multilib] Error 2 > make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' > make: *** [all-gcc] Error 2 > > First of all, I've thought this is because of my original binutils > binaries configured with out --with-cpu=xscale, but even if I add this > configure switch and rebuild them, the issue is still the same. Perhaps, > my bintutils config is still wrong? But I'm short of ideas what to do > now... > > Thanks! > Karel > PS: in gcc/config/arm/t-arm-elf I only uncommented those options to get BE > build: > > MULTILIB_OPTIONS += mlittle-endian/mbig-endian > MULTILIB_DIRNAMES+= le be > MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle > > MULTILIB_OPTIONS+= mhard-float/msoft-float > MULTILIB_DIRNAMES += fpu soft > MULTILIB_EXCEPTIONS += *mthumb/*mhard-float* > > MULTILIB_OPTIONS+= mno-thumb-interwork/mthumb-interwork > MULTILIB_DIRNAMES += normal interwork You don't need the hard/soft float variants. Just comment them out (the middle group). R.
Re: Bootstrap failure on Linux/i686 in Ada
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > Hi Rainer, this is PR24994: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > And is under investigation: > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html Hmmm, I'm still having trouble disabling this (*&@#$ address space randomization, more so than I've had in the past. Dorking around with exec-shield and randomize_va_space doesn't seem to do the right thing on any box I've got around here. This is, err, (*&@#$ annoying. I really need a stable VM layout so that I can set some watchpoints on the mmap'd space. G. jeff
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
> I've noticed one inconsistency how libraries are installed. For shared > libraries (lib*.so), the 32-bit version is installed in prefix/lib, while > 64-bit version is installed in prefix/lib/sparcv9. > > For static libraries (lib*.a archives), it is the other way around. The > 64-bit version is installed in prefix/lib, while 32-bit version is > installed in prefix/lib/sparcv7!? How many libraries do you have in prefix/lib/sparcv7? Which one(s)? -- Eric Botcazou
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
Quoting Eric Botcazou <[EMAIL PROTECTED]>: I've noticed one inconsistency how libraries are installed. For shared libraries (lib*.so), the 32-bit version is installed in prefix/lib, while 64-bit version is installed in prefix/lib/sparcv9. For static libraries (lib*.a archives), it is the other way around. The 64-bit version is installed in prefix/lib, while 32-bit version is installed in prefix/lib/sparcv7!? How many libraries do you have in prefix/lib/sparcv7? Which one(s)? Only one so far, libiberty.a. The lib/sparcv7/libiberty.a contains 32-bit object files, while lib/libiberty.a contains 64-bit object files. Actually, looking more closely, the libiberty.a is the only one installed that way (from the gcc sources). All others (for example libstdc++.a) seem to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? This message was sent using IMP, the Internet Messaging Program.
Re: Bootstrap failure on Linux/i686 in Ada
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > Hi Rainer, this is PR24994: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > And is under investigation: > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html Finally! To stop the annoying VM randomization you need to turn on the old style VM layout in the kernel. Grrr. I'm making progress now, believe it or not, I'm actually focused on a possible latent bug in the SRA code... Jeff
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
> Actually, looking more closely, the libiberty.a is the only one installed > that way (from the gcc sources). All others (for example libstdc++.a) seem > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? Bingo. :-) http://gcc.gnu.org/PR16513 -- Eric Botcazou
Re: Bootstrap failure on Linux/i686 in Ada
Jeffrey A Law writes: > On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > > Hi Rainer, this is PR24994: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > > > And is under investigation: > > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html > Finally! > > To stop the annoying VM randomization you need to turn on > the old style VM layout in the kernel. Grrr. I'm > making progress now, believe it or not, I'm actually focused > on a possible latent bug in the SRA code... Please, post instructions about how to turn on the old style VM layout in the kernel. Sooner or later, many of us on this list will need to know... Andrew.
Re: Bootstrap failure on Linux/i686 in Ada
On Tuesday 03 January 2006 14:47, Andrew Haley wrote: > Please, post instructions about how to turn on the old style VM layout > in the kernel. Sooner or later, many of us on this list will need to > know... > Adding this to /etc/sysctl.conf works for me: # Do not randomize memory addresses kernel.randomize_va_space = 0 After that, run 'sysctl -p' as root to update the kernel without rebooting.
Re: Bootstrap failure on Linux/i686 in Ada
On Tue, 2006-01-03 at 14:51 -0500, Diego Novillo wrote: > On Tuesday 03 January 2006 14:47, Andrew Haley wrote: > > > Please, post instructions about how to turn on the old style VM layout > > in the kernel. Sooner or later, many of us on this list will need to > > know... > > > Adding this to /etc/sysctl.conf works for me: > > # Do not randomize memory addresses > kernel.randomize_va_space = 0 > > After that, run 'sysctl -p' as root to update the kernel without rebooting. No, this is not sufficient. You also need to: /sbin/sysctl -w vm.legacy_va_layout=1 Otherwise you still get randomizations. Jeff
Re: Bootstrap failure on Linux/i686 in Ada
On Tuesday 03 January 2006 14:57, Jeffrey A Law wrote: > No, this is not sufficient. > *shrug* that works for me without the legacy_va_layout setting. $ sysctl vm.legacy_va_layout vm.legacy_va_layout = 0 (On 2.6.14-1.1653_FC4smp)
Re: Bootstrap failure on Linux/i686 in Ada
On Tue, 2006-01-03 at 15:02 -0500, Diego Novillo wrote: > On Tuesday 03 January 2006 14:57, Jeffrey A Law wrote: > > > No, this is not sufficient. > > > *shrug* that works for me without the legacy_va_layout setting. > > $ sysctl vm.legacy_va_layout > vm.legacy_va_layout = 0 > > (On 2.6.14-1.1653_FC4smp) That definitely wasn't sufficient for me -- on effectively virgin FC4 and FC5T1 systems. Jeff
Re: Xscale big endian tool-chain (how to build it?)
Richard Earnshaw wrote: Next, I suggest you add --with-cpu=xscale when configuring GCC. You can then drop the -mcpu=xscale when compiling (this should also give you better libraries for your system). However, beware that you libraries will now only run on ARMv5 or later processors. IMHO using the separate 'xscale-elf' target template in the 'gcc/config.gcc', this defining its own things, instead of the generic ARM files, could sound being the most clean solution : xscale-*-elf) tm_file="arm/xscale-elf.h dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/aout.h arm/arm.h" tmake_file=arm/t-xscale-elf out_file=arm/arm.c md_file=arm/arm.md extra_modes=arm/arm-modes.def use_fixproto=yes ;; This was taken from gcc-3.4.5 sources but I would assume gcc-4.x keeping the separate 'xscale-*' targets. Anyway when the primary target is XScale, those 'xscale-*' target names should be the first to try, not the 'arm-*'.
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 17:15, Karel Gardas wrote: I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The failure happen during compilation of gcc and it looks like: /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ -nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem /tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem /tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include -B/home/karel/usr/local/arm-elf1/arm-elf/bin/ -B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem /home/karel/usr/local/arm-elf1/arm-elf/include -isystem /home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. -I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include -mhard-float -DL_addsubdf3 -xassembler-with-cpp -c ../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages: ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor does not support `ldfd f0,[sp],#8' make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1 make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make: *** [all-gcc] Error 2 First of all, I've thought this is because of my original binutils binaries configured with out --with-cpu=xscale, but even if I add this configure switch and rebuild them, the issue is still the same. Perhaps, my bintutils config is still wrong? But I'm short of ideas what to do now... Thanks! Karel PS: in gcc/config/arm/t-arm-elf I only uncommented those options to get BE build: MULTILIB_OPTIONS += mlittle-endian/mbig-endian MULTILIB_DIRNAMES+= le be MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle MULTILIB_OPTIONS+= mhard-float/msoft-float MULTILIB_DIRNAMES += fpu soft MULTILIB_EXCEPTIONS += *mthumb/*mhard-float* MULTILIB_OPTIONS+= mno-thumb-interwork/mthumb-interwork MULTILIB_DIRNAMES += normal interwork You don't need the hard/soft float variants. Just comment them out (the middle group). And this makes the job! Thank you very much for your help! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Bootstrap failure on Linux/i686 in Ada
On Tue, 2006-01-03 at 12:42 -0700, Jeffrey A Law wrote: > On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > > Hi Rainer, this is PR24994: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > > > And is under investigation: > > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html > Finally! > > To stop the annoying VM randomization you need to turn on > the old style VM layout in the kernel. Grrr. I believe detailed instructions on the ways to disable VM randomization in the GCC wiki would be a welcomed addition by many GCC hackers :). Laurent
Re: Bootstrap failure on Linux/i686 in Ada
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote: > Hi Rainer, this is PR24994: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994 > > And is under investigation: > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html > So, here's what appears to be happening. 1. A statement is recorded into the EH throw statement hash table. 2. SRA replaces the statement in the IL, but does not remove the statement from the EH throw statement table. This is our bug. 3. remove_cfg_annotations removes annotations from all the statements in the IL, but note that it does not walk the EH throw table (a reasonable thing since statements in the EH table ought to appear in the IL). 4. Eventually the RTL optimizers run and remove the block referenced by the bogus statement in the EH hash table. 5. Even later GC runs, walks the EH throw statement table, the bogus statement within the table, then the bogus statement's annotation, then the block in the annotation, which was expunged and unlinked leading to dereferencing a null pointer. It'll take until tomorrow or so before I can get all the bootstrapping and regression testing done, but I'm pretty sure all we need to do is add remove_stmt_from_eh_region (orig_stmt); into the appropriate location within bsi_replace. jeff
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: > > Actually, looking more closely, the libiberty.a is the only one installed > > that way (from the gcc sources). All others (for example libstdc++.a) seem > > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? > > Bingo. :-) http://gcc.gnu.org/PR16513 I wonder how many more examples like that we need before we impose testing after install and not in tree... Only consequence for the few who configure with --prefix=/usr from their tree will be to change to --prefix=/some/user/dir so install doesn't break the system if the tested compiler is not up to the task. Benefit will be that we can get rid of some Makefile and script code and we'll at last test what we ship and not a random subset of it. Quick poll: who does configure for some system dir when doing development? Laurent
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
Quick poll: who does configure for some system dir when doing development? I do. Doesn't mean I have to keep doing it that way, of course, but that's not what you asked.
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: > > > Actually, looking more closely, the libiberty.a is the only one installed > > > that way (from the gcc sources). All others (for example libstdc++.a) > > > seem > > > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > > > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? > > > > Bingo. :-) http://gcc.gnu.org/PR16513 > > I wonder how many more examples like that we need before we impose > testing after install and not in tree... > > Only consequence for the few who configure with --prefix=/usr from their > tree will be to change to --prefix=/some/user/dir so install doesn't > break the system if the tested compiler is not up to the task. We can do this without touching --prefix, in fact, via DESTDIR and relocatable installs. It's just a bit disruptive to the workflow, so I wanted to wait until toplevel bootstrap was settled first. -- Daniel Jacobowitz CodeSourcery
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
On Tue, 2006-01-03 at 15:54 -0500, Richard Kenner wrote: > Quick poll: who does configure for some system dir when doing > development? > > I do. Doesn't mean I have to keep doing it that way, of course, but that's > not what you asked. I assume linux (and GCC) distributors also do it at some point in their chain (but already have a controlled environment to do so :), but I'm curious to know how many GCC developpers prefer to use /usr for their dev builds. Laurent
Re: Installing GCC 4.1-20051223 on FreeBSD 6 failed
On Fri, 30 Dec 2005, Jon Brisbin wrote: > I'm trying to install the GCC 4.1 snapshot from Dec 23, 2005 on my > FreeBSD box. I'm trying to try out gcj. The installation fails, > complaining about not enough virtual memory. I just added another 2GB > swap file on this box. I now have 1GB of physical RAM and 4GBs of swap. > And that's not enough?! > > What do I need to do to get gcj and libjava to install? Is this a > problem with GNU make or GCC? As Joe Wilson indicated, this may be related to FreeBSD's malloc. However, there is a general problem in GNU make (which uses too much memory, H.J. Lu proposed a patch) and libgcj (the Makefile dependencies suffer from combinatorial explosion). Gerald
Testing GCC install (was: inconsistency in location of static and shared libraries on sparc64-sun-solaris*)
On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote: > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: > > > > Actually, looking more closely, the libiberty.a is the only one > > > > installed > > > > that way (from the gcc sources). All others (for example libstdc++.a) > > > > seem > > > > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > > > > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? > > > > > > Bingo. :-) http://gcc.gnu.org/PR16513 > > > > I wonder how many more examples like that we need before we impose > > testing after install and not in tree... > > > > Only consequence for the few who configure with --prefix=/usr from their > > tree will be to change to --prefix=/some/user/dir so install doesn't > > break the system if the tested compiler is not up to the task. > > We can do this without touching --prefix, in fact, via DESTDIR and > relocatable installs. I assume DESTDIR will suffer a lot of recurrent breakage if we still test in tree when it goes in. > It's just a bit disruptive to the workflow, so I > wanted to wait until toplevel bootstrap was settled first. Yes, another impact of testing after install is that many small dev scripts will have to be changed to make check after make install and not before. Laurent
Re: Testing GCC install (was: inconsistency in location of static and shared libraries on sparc64-sun-solaris*)
On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote: > On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote: > > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote: > > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote: > > > > > Actually, looking more closely, the libiberty.a is the only one > > > > > installed > > > > > that way (from the gcc sources). All others (for example > > > > > libstdc++.a) seem > > > > > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). > > > > > Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? > > > > > > > > Bingo. :-) http://gcc.gnu.org/PR16513 > > > > > > I wonder how many more examples like that we need before we impose > > > testing after install and not in tree... > > > > > > Only consequence for the few who configure with --prefix=/usr from their > > > tree will be to change to --prefix=/some/user/dir so install doesn't > > > break the system if the tested compiler is not up to the task. > > > > We can do this without touching --prefix, in fact, via DESTDIR and > > relocatable installs. > > I assume DESTDIR will suffer a lot of recurrent breakage if we still > test in tree when it goes in. > > > It's just a bit disruptive to the workflow, so I > > wanted to wait until toplevel bootstrap was settled first. > > Yes, another impact of testing after install is that > many small dev scripts will have to be changed to > make check after make install and not before. No, you've missed my point. DESTDIR support (which we already have, and people use constantly) allows us to install a tree somewhere different than its configured --prefix. Relocatable toolchains (ditto) allow the toolchain to work when run from an address different than the configured --prefix. "make check", or even "make all", can finish with "make install DESTDIR=$top_objdir/install". That will generate an installed toolchain which behaves just like the final installed toolchain. -- Daniel Jacobowitz CodeSourcery
Re: insv vs one-bit fields
Revisiting an old thread... > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: > > So... why is it illegal to put a constant into a single bit field? > > Probably because it was more efficient to use some other pattern > for some other target. That's a bad reason to put it in the MI code, since the target could simply reject those requests itself. Does anyone remember which target needed this? If not, can we remove that test? > But there's absolutely zero chance you can reliably use a volatile > bit field to emit a given insn sequence necessary for accessing a > hardware register. I don't need reliable, I'm working on optimal. If/when the compiler can detect that a single "bit insert" opcode can be used instead of a read/change/write opcode sequence, it's a big win. The fact that the bitfield is volatile means that a lot of other optimizations get bypassed, the only way to get it in there is to use insv.
Ben Elliston appointed libdecnumber maintainer
Ben -- The GCC SC has appointed you as a maintainer of libdecnumber. Please add yourself to MAINTAINERS. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-3.4-20060103 is now available
Snapshot gcc-3.4-20060103 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060103/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 109291 You'll find: gcc-3.4-20060103.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20060103.tar.bz2 C front end and core compiler gcc-ada-3.4-20060103.tar.bz2 Ada front end and runtime gcc-g++-3.4-20060103.tar.bz2 C++ front end and runtime gcc-g77-3.4-20060103.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20060103.tar.bz2 Java front end and runtime gcc-objc-3.4-20060103.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20060103.tar.bz2The GCC testsuite Diffs from 3.4-20051227 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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: Testing GCC install (was: inconsistency in location of static and shared libraries on sparc64-sun-solaris*)
On Tue, 2006-01-03 at 16:41 -0500, Daniel Jacobowitz wrote: > DESTDIR support (which we already have, and people use constantly) > allows us to install a tree somewhere different than its configured > --prefix. Relocatable toolchains (ditto) allow the toolchain to work > when run from an address different than the configured --prefix. A precision from Daniel: <> (that was the source of my misunderstanding) so the change will indeed imply testing make install during regular make bootstrap or make; make -k check. cross with already filled prefix should work too. Looks great! Laurent
Re: Bootstrap failure on Linux/i686 in Ada
On Jan 3, 2006, at 11:54 AM, Laurent GUERBY wrote: To stop the annoying VM randomization you need to turn on the old style VM layout in the kernel. Grrr. I believe detailed instructions on the ways to disable VM randomization in the GCC wiki would be a welcomed addition by many GCC hackers :). Done. http://gcc.gnu.org/wiki/DebuggingGCC seemed like the best place to put it, the node is: http://gcc.gnu.org/wiki/Randomization if you want to jump directly there.
Re: RTL alias analysis
On Tuesday 03 January 2006 17:27, Richard Henderson wrote: > I'll have to give this some thought. Heh, like many before you... Hope you can come up with an answer. This is now bug 25654 in Bugzilla. Gr. Steven
Re: insv vs one-bit field
> DJ Delorie wrote > Revisiting an old thread... >> > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote: >> > So... why is it illegal to put a constant into a single bit field? >> >> Probably because it was more efficient to use some other pattern >> for some other target. > > That's a bad reason to put it in the MI code, since the target could > simply reject those requests itself. Does anyone remember which > target needed this? If not, can we remove that test? > >> But there's absolutely zero chance you can reliably use a volatile >> bit field to emit a given insn sequence necessary for accessing a >> hardware register. > > I don't need reliable, I'm working on optimal. If/when the compiler > can detect that a single "bit insert" opcode can be used instead of a > read/change/write opcode sequence, it's a big win. The fact that the > bitfield is volatile means that a lot of other optimizations get > bypassed, the only way to get it in there is to use insv. If of any significance, as the AVR aliases GPR's and I/O registers into low order memory addresses, and supports limited bit operations on a subset of those registers; it's therefore possible to consider the AVR as being capable of correspondingly directly manipulating bits mapped into a limited subset of low-order memory addresses; although truly representing I/O ports, not generalized memory per-se.
Accessing the file scope C++ data structs in GIMPLE
Hello, I want to dump out all the c++ classes/structs and global data structures defined in a given file scope or transaltion unit, as part of the debug dumps in C-like syntax, from GIMPLE data structs. Is there a TREE_VEC or BIND_EXPR_VARS that I can traverse through and get all these ? Thanks a lot for the help provided in the past as well. Thanks, Prateek.
about REG_DEP_OUTPUT dependence
Hi,
Can someone help me explain that why there's an REG_DEP_OUTPUT (write
after write dependence) between jump_insn 547 and insn 82?
(insn 82 543 478 3 (set (mem/s:SI (reg/f:SI 6 r6 [224]) [4 W S4 A32])
(reg:SI 2 r2 [95])) 8 {movsi_internal} (insn_list 81 (nil))
(expr_list:REG_DEAD (reg:SI 2 r2 [95])
(nil)))
(insn 478 82 547 3 (set (reg/f:SI 6 r6 [224])
(plus:SI (reg/f:SI 6 r6 [224])
(const_int 4 [0x4]))) 20 {addsi3} (insn_list:REG_DEP_ANTI
65 (insn_list:REG_DEP_ANTI 66 (insn_list:REG_DEP_ANTI 73
(insn_list:REG_DEP_ANTI 80 (insn_list:REG_DEP_ANTI 82 (nil))
(nil))
(jump_insn 547 478 93 3 (set (pc)
(if_then_else (ne:SI (reg/v:SI 7 r7 [orig:270 i ] [270])
(const_int 0 [0x0]))
(label_ref 88)
(pc))) 61 {*cbranch} (insn_list 543
(insn_list:REG_DEP_OUTPUT 82 (nil)))
(expr_list:REG_BR_PROB (const_int 9844 [0x2674])
(nil)))
Regards,
Haibin
Re: Patches for RDOS (version 4.1 of GCC)
>2005-12-28 Leif Ekblad [EMAIL PROTECTED] > > * gcc/config.gcc: Added support for target RDOS > * gcc/config/i386/rdos.h: Added rdos.h file for RDOS definitions Patches should be sent to gcc-patches. Thanks. Ben
Re: test for excess errors
> Could you tell me what it means for 'test for excess errors'? I run > make check-gcc RUNTESTFLAGS='dg.exp' on my machine, and got many > failed tests for these errors on my porting gcc. The dg.exp tests can instruct DejaGnu to look for specific warnings/errors in diagnostics. The final test is called "test for excess errors", which decides if any additional errors were produced (ie. excess ones). > Do I need to setup something in order to run these testsuites for my > port? Besides DejaGnu and Tcl. No, that's all. Ben
Re: about REG_DEP_OUTPUT dependence
Liu Haibin <[EMAIL PROTECTED]> writes:
> Can someone help me explain that why there's an REG_DEP_OUTPUT (write
> after write dependence) between jump_insn 547 and insn 82?
>
> (insn 82 543 478 3 (set (mem/s:SI (reg/f:SI 6 r6 [224]) [4 W S4 A32])
> (reg:SI 2 r2 [95])) 8 {movsi_internal} (insn_list 81 (nil))
> (expr_list:REG_DEAD (reg:SI 2 r2 [95])
> (nil)))
> (insn 478 82 547 3 (set (reg/f:SI 6 r6 [224])
> (plus:SI (reg/f:SI 6 r6 [224])
> (const_int 4 [0x4]))) 20 {addsi3} (insn_list:REG_DEP_ANTI
> 65 (insn_list:REG_DEP_ANTI 66 (insn_list:REG_DEP_ANTI 73
> (insn_list:REG_DEP_ANTI 80 (insn_list:REG_DEP_ANTI 82 (nil))
> (nil))
> (jump_insn 547 478 93 3 (set (pc)
> (if_then_else (ne:SI (reg/v:SI 7 r7 [orig:270 i ] [270])
> (const_int 0 [0x0]))
> (label_ref 88)
> (pc))) 61 {*cbranch} (insn_list 543
> (insn_list:REG_DEP_OUTPUT 82 (nil)))
> (expr_list:REG_BR_PROB (const_int 9844 [0x2674])
> (nil)))
The scheduler must not move the memory write after the conditional
jump. The dependency code models this by adding a REG_DEP_OUTPUT
dependency from any conditional jump to any memory write for which
there is no other dependency. See the JUMP_P code in
sched_analyze_insn.
Ian
