Re: selection or target tools
One appropriate default for --with-build-tools could be the same as
the defaults for --program-transform-name. A default native build
would use 'as', a default cross build would use '$target-as'. Most
people using --program-prefix would probably also pass the same value
to --with-build-tools.
So --with-build-tools would be a *prefix* and not a path in which to
find it?
I have a prototype patch that follows this logic:
1) if not a Canadian cross and the appropriate directory is being built
as a host module, use it. So combined trees are not affected, of
course, by the patch.
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GCC)
would be, if found, something like
/usr/local/i686-pc-linux-gnu/bin/{ar,as,ld,...}. These would be "naked"
names, not $target-prefixed, even when building a cross (because they
are in a directory named after the target).
3) in a native build we try to use the host tool
4) if no host tool is found, we look for a pre-installed tool. The
macro NCN_STRICT_CHECK_TARGET_TOOLS imposes $target-prefixed names for
cross builds, while on a native build a "naked" name would be okay as well.
Step 2 is new. The previous logic covers step 1, 3, 4.
I believe that this is covering Jan's use case. If it covers Dan's as
well, I'm going to post the patch in a few hours or else in the new year
(in the meanwhile, there are other toplevel patches to review, i.e.
parts 2/4 and 3/4)...
We also have the problem of backwards compatibility. I can try to work
out a patch to implement --with-build-tools in 4.0 and 4.1 (with the new
logic kicking in only if the option is specified, of course).
Paolo
Re: selection or target tools
Yes, this seems to meet the needs I expressed. Thanks, Jan
>>> Paolo Bonzini <[EMAIL PROTECTED]> 23.12.05 10:10:01 >>>
> One appropriate default for --with-build-tools could be the same as
> the defaults for --program-transform-name. A default native build
> would use 'as', a default cross build would use '$target-as'. Most
> people using --program-prefix would probably also pass the same
value
> to --with-build-tools.
So --with-build-tools would be a *prefix* and not a path in which to
find it?
I have a prototype patch that follows this logic:
1) if not a Canadian cross and the appropriate directory is being built
as a host module, use it. So combined trees are not affected, of
course, by the patch.
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GCC)
would be, if found, something like
/usr/local/i686-pc-linux-gnu/bin/{ar,as,ld,...}. These would be
"naked"
names, not $target-prefixed, even when building a cross (because they
are in a directory named after the target).
3) in a native build we try to use the host tool
4) if no host tool is found, we look for a pre-installed tool. The
macro NCN_STRICT_CHECK_TARGET_TOOLS imposes $target-prefixed names for
cross builds, while on a native build a "naked" name would be okay as
well.
Step 2 is new. The previous logic covers step 1, 3, 4.
I believe that this is covering Jan's use case. If it covers Dan's as
well, I'm going to post the patch in a few hours or else in the new
year
(in the meanwhile, there are other toplevel patches to review, i.e.
parts 2/4 and 3/4)...
We also have the problem of backwards compatibility. I can try to work
out a patch to implement --with-build-tools in 4.0 and 4.1 (with the
new
logic kicking in only if the option is specified, of course).
Paolo
Re: selection or target tools
On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote: > On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote: > > Hello! > > > > The new scheme to select target tools breaks building GCC for me. Maybe I > > have an unusal setup. The problem in my case is that configure now chooses > > tools from $prefix/bin. It did use tools from $prefix/$target/bin before. > > On my setup I have *different* tools in those places. Until know the tools > > from $prefix/$target/bin were selected and everything was fine. Now the > > build process creates eg. gcc/as which uses as from $prefix/bin. That > > assembler is *never* invoked when I running -gcc. Thus I am > > surprised that configure now prefers that version. Is the current > > behaviour a bug? > > From your description I assume this is a native build ($target == > $host). When did this change? Sorry for being vague, its a cross-compiler (build == host). The build errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The last successful build was at the beginning of decemeber. > Also, _why_ do you have different tools in those two places? Is this important? I kept binutil versions in $prefix/bin because at times its useful to have it, eg. comparing its output/behaviour. The replaced tools in $prefix/$target/bin are better suited for my needs, thus I installed them there and until recently GCC always used these tools. > It looks to me like this last changed around 2005-06-16 on HEAD, and we > assume that the assembler installed in $prefix is the assembler you > want the compiler to be using - it's the same assembler you'd get if > you said "as", so why shouldn't we use it? I rarely invoke eg. the assembler manually. Most of the time I use the compiler frontend (gcc) since that is much more convenient. All GCC version I know use $prefix/$target/bin/ if its available, at least for assembler and linker. I never seen the frontend using $target-. On Thu, Dec 22, 2005 at 12:16:46PM -0500, Daniel Jacobowitz wrote: > On Thu, Dec 22, 2005 at 06:13:22PM +0100, Paolo Bonzini wrote: > > I am a bit confused. > > > > Does Gunther's failure mean that the default for the proposed > > --with-build-tools option, should be $prefix/$target/bin? This would > > set AS_FOR_TARGET, etc. from within the GCC_TARGET_TOOL toplevel > > configure macro, and percolate all the way down to gcc. That would probaly restore previous behaviour since it would prefer tools in $prefix/$target/bin over $prefix/bin. > If I am following correctly: > > The assembler we test for features in Gunther's case has always been > $prefix/bin/as - luckily harmless for him and he probably never > noticed. The installed compiler uses $prefix/$target/bin/as. The > being-built compiler has switched from one to the other. Your analysis seems to be correct. I noticed that "wrong" tools (as/ld) were tested by configure but that was non-problematic. The new behaviour is since now a tool is invoked with wrong options. > One appropriate default for --with-build-tools could be the same as > the defaults for --program-transform-name. A default native build > would use 'as', a default cross build would use '$target-as'. Most > people using --program-prefix would probably also pass the same value > to --with-build-tools. That would not solve the problem. However, Paolo suggestion 2) in another mail (http://gcc.gnu.org/ml/gcc/2005-12/msg00688.html) seems to restore old behaviour and thus fix my issue. Gunther
Re: selection or target tools
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
> 2) look into the --with-build-tools path, for both a Canadian cross and
> a native build. This defaults to $exec_prefix/$target/bin, so the
> default build tools (used in autoconf tests and by the being-built GCC)
> would be, if found, something like
> /usr/local/i686-pc-linux-gnu/bin/{ar,as,ld,...}. These would be "naked"
> names, not $target-prefixed, even when building a cross (because they
> are in a directory named after the target).
If the above isn't restricted to canadian cross, it looks good. This should
apply for a normal cross build as well: (build == host) != target
> We also have the problem of backwards compatibility. I can try to work
> out a patch to implement --with-build-tools in 4.0 and 4.1 (with the new
> logic kicking in only if the option is specified, of course).
Why dou you need a backwards compatibility patch for 4.0/4.1?
Gunther
Re: selection or target tools
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GCC)
would be, if found, something like
/usr/local/i686-pc-linux-gnu/bin/{ar,as,ld,...}. These would be "naked"
names, not $target-prefixed, even when building a cross (because they
are in a directory named after the target).
If the above isn't restricted to canadian cross, it looks good. This should
apply for a normal cross build as well: (build == host) != target
Yes. My distinction between native and cross, was more referring to
whether build == host or not.
We also have the problem of backwards compatibility. I can try to work
out a patch to implement --with-build-tools in 4.0 and 4.1 (with the new
logic kicking in only if the option is specified, of course).
Why dou you need a backwards compatibility patch for 4.0/4.1?
To provide a One True Way To Specify Build Tools, and make the same
scripts usable on every release branch. And because the patch that
caused the breakage for your configuration was backported to 4.1.
Paolo
Christmas
Hi all, i'm going into holiday and i wish you all of the gcc-team a happy christmas and thanks for all your work, even though it is still to early for christmas wishes :). cu, Ronny Peine
[M16C-ELF] : Problem accessing "constant" data that is placed in ROM.
Hi, I have downloaded latest GCC and Binutils sources from FSF for M16C port. Using these sources, I could successfully build the cross toolchain i.e. m32c-elf-*. However, I am facing a problem while accessing the "const" data and hard-coded strings which by default get placed in section ".rodata". Note that, for the M16C-62P target which I am using, ROM memory region starts at memory location "0x000A" (i.e. 20 bit address). Therefore, as the pointer size for GCC M16C is two bytes, it fails to access this memory region. I have further noticed that, ".plt" section is used for handling the "function pointers" and ".rodata" section (both are 20 bit addressable). However, for this to work on actual hardware, I had to copy the ".plt" section from ROM (load address) to RAM at runtime. I am doing this in my own start-up code. After doing the above changes, I could get my function pointer working with actual hardware. But, this does not solve my problem for accessing constant data and strings placed in ROM. As a workaround, I am currently copying the complete ".rodata" section from load address (ROM) to RAM, that is by treating it similar to ".data" section. However, this is not the expected behavior, especially when using hardware. My ".rodata" should be in ROM all the time. I have noticed that, ".plt" stores a pointer to start of ".rodata" section. I would like to know, how it can be used without actually copying the ".rodata" section to RAM. Thanks in advance. Regards, Prafulla Thakare KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005.
Re: selection or target tools
On Fri, Dec 23, 2005 at 01:33:30PM +0100, Paolo Bonzini wrote: > Gunther Nikl wrote: > > > >If the above isn't restricted to canadian cross, it looks good. This > >should apply for a normal cross build as well: (build == host) != target > > > Yes. My distinction between native and cross, was more referring to > whether build == host or not. I thought its better to ask than to be surprised later. > >Why dou you need a backwards compatibility patch for 4.0/4.1? > > > To provide a One True Way To Specify Build Tools, and make the same > scripts usable on every release branch. And because the patch that > caused the breakage for your configuration was backported to 4.1. Indeed, thats a very good reason. I am only tracking mainline and thus I missed that this change was already backported. Thanks for quickly offering a solution. Gunther
Re: selection or target tools
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote: > On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote: > > On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote: > > > Hello! > > > > > > The new scheme to select target tools breaks building GCC for me. Maybe I > > > have an unusal setup. The problem in my case is that configure now chooses > > > tools from $prefix/bin. It did use tools from $prefix/$target/bin before. > > > On my setup I have *different* tools in those places. Until know the tools > > > from $prefix/$target/bin were selected and everything was fine. Now the > > > build process creates eg. gcc/as which uses as from $prefix/bin. That > > > assembler is *never* invoked when I running -gcc. Thus I am > > > surprised that configure now prefers that version. Is the current > > > behaviour a bug? > > > > From your description I assume this is a native build ($target == > > $host). When did this change? > > Sorry for being vague, its a cross-compiler (build == host). The build > errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The > last successful build was at the beginning of decemeber. Wait wait wait wait wait. This is a cross compiler. Are we mistakenly running $prefix/bin/$target-as, which is a bad version, or are we really running $prefix/bin/as, a program named "as"? If we're doing that, let's fix that separately - it's a nasty bug! > > Also, _why_ do you have different tools in those two places? > > Is this important? I kept binutil versions in $prefix/bin because at > times its useful to have it, eg. comparing its output/behaviour. The > replaced tools in $prefix/$target/bin are better suited for my needs, > thus I installed them there and until recently GCC always used these > tools. You see, normally the binutils "make install" hardlinks bin/mips-linux-as to mips-linux/bin/as. GCC probably has more than one assumption that they're compatible assemblers. -- Daniel Jacobowitz CodeSourcery, LLC
Re: selection or target tools
Wait wait wait wait wait. This is a cross compiler. Are we mistakenly running $prefix/bin/$target-as, which is a bad version, or are we really running $prefix/bin/as, a program named "as"? If we're doing that, let's fix that separately - it's a nasty bug! Probably my configuration will not match Gunther's exactly but, to test this, I've modified the $prefix/bin directory where I have an arm-none-elf installed toolchain. I added `as' which is the host tool, and removed `arm-none-elf-as'. I then configured the toplevel and gcc with --prefix=~/testprefix, and every variable pointing to an AS_FOR_TARGET is pointing to the non-existent (but correct) arm-none-elf-as. Inside the gcc directory it even pointed to the $prefix/$target/bin/as. Gunther, you did not mention really what your build/host/targets are. Could you send me privately the generated gcc/Makefile? Paolo
Re: selection or target tools
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote: > On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote: > > Sorry for being vague, its a cross-compiler (build == host). The build > > errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The > > last successful build was at the beginning of decemeber. > > Wait wait wait wait wait. This is a cross compiler. Are we mistakenly > running $prefix/bin/$target-as, which is a bad version, or are we > really running $prefix/bin/as, a program named "as"? If we're doing > that, let's fix that separately - it's a nasty bug! $prefix/bin/$target-as was invoked through the script "gcc/as" created by stamp-as. AFAICT, that rule uses AS_FOR_TARGET. I am only using $prefix for cross compilers, thus there is no naked tool in $prefix/bin. > > > Also, _why_ do you have different tools in those two places? > > > > Is this important? I kept binutil versions in $prefix/bin because at > > times its useful to have it, eg. comparing its output/behaviour. The > > replaced tools in $prefix/$target/bin are better suited for my needs, > > thus I installed them there and until recently GCC always used these > > tools. > > You see, normally the binutils "make install" hardlinks > bin/mips-linux-as to mips-linux/bin/as. I know. > GCC probably has more than one assumption that they're compatible > assemblers. I wasn't aware that this assumption exists. I admit that my setup is probably uncommon. I always assumed gcc has to use as/ld from $prefix/$target/bin. Gunther
Bootstrap problems on ia64
Hi,
When bootstrapping rev. 109012 on ia64-linux (checked out around 9am GMT
today), I get
make[3]: Entering directory `/mnt/sda5/bonzo/obj-trunk/stage2-libdecnumber'
source='../../trunk/libdecnumber/decNumber.c' object='decNumber.o'
libtool=no /home/bonzo/local/obj-trunk/./prev-gcc/xgcc
-B/home/bonzo/local/obj-trunk/./prev-gcc/
-B/mnt/sda5/bonzo/obj-trunk//ia64-unknown-linux-gnu/bin/
-I../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Werror
-I../../trunk/libdecnumber -I. -c ../../trunk/libdecnumber/decNumber.c
cc1: warnings being treated as errors
../../trunk/libdecnumber/decNumber.c: In function 'decToString':
../../trunk/libdecnumber/decNumber.c:2013: warning: value computed is
not used
make[3]: *** [decNumber.o] Error 1
Looking at the source, the warning seems to be spurious:
static void
decToString (decNumber * dn, char *string, Flag eng)
{
<...>
char *c = string; /* work [output pointer] */
<...>
if (dn->bits & DECSPECIAL)
{ /* Is a special value */
if (decNumberIsInfinite (dn))
{
strcpy (c, "Infinity"); <--- here
return;
}
And when specifying --disable-werror, I get a comparison failure:
Bootstrap comparison failure!
./gcc.o differs
Is this known or am I just broke my installation? GCC was configured
just with --prefix, and I used 3.4.3 for stage1.
Andrey
Re: selection or target tools
Gunther Nikl wrote: On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote: On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote: Sorry for being vague, its a cross-compiler (build == host). The build errors out for libgcc.a since gcc/xgcc uses the "wrong" assembler. The last successful build was at the beginning of decemeber. Wait wait wait wait wait. This is a cross compiler. Are we mistakenly running $prefix/bin/$target-as, which is a bad version, or are we really running $prefix/bin/as, a program named "as"? If we're doing that, let's fix that separately - it's a nasty bug! $prefix/bin/$target-as was invoked through the script "gcc/as" created by stamp-as. AFAICT, that rule uses AS_FOR_TARGET. I am only using $prefix for cross compilers, thus there is no naked tool in $prefix/bin. No, it uses ORIGINAL_AS_FOR_TARGET, which is the same `as' that the configure script ran the tests on (the variable is called gcc_cv_as during the configuration). This, in turn, is the first that is found among: 1) the default assembler (--with-as) 2) an in-tree assembler 3) AS_FOR_TARGET 4) if host == target, AS (obsolete, should be covered by case 3) 5) if build == host, an assembler in one of the directories that the compiler will look at 6) if build == target, an assembler in one of the target-dependent search paths indicated by MD_EXEC_PREFIX 7) whatever tool, appropriately prefixed if host != target, can be found in the user's path (probably obsolete, should be covered by case 3). In your case, case 5 used to hit, while now case 3 hits. It is strange that you have seen this only from the beginning of December, because I'd expect the behavior to have changed in June or at most in October, with http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00237.html (by Dan). My proposed default setting of --with-build-tools would not even work in the strangest cases, such as if one was expecting the compiler to use tools from /usr/lib/gcc (!), which is admittedly even more remote but could happen. To do everything correctly, cases 4/7 should be removed and cases 5/6 could be moved to the toplevel to provide the default for --with-build-tools. We have the infrastructure to implement this, except that I'd hate to duplicate the definitions of MD_EXEC_PREFIX into the toplevel even if there are only half a dozen. In the meanwhile (i.e. for 4.1, and on HEAD until this gets implemented if ever) I'd stick with a default --with-build-tools value of $prefix/$target/bin. Paolo
Re: selection or target tools
On Fri, Dec 23, 2005 at 03:50:50PM +0100, Paolo Bonzini wrote: > > >Wait wait wait wait wait. This is a cross compiler. Are we mistakenly > >running $prefix/bin/$target-as, which is a bad version, or are we > >really running $prefix/bin/as, a program named "as"? If we're doing > >that, let's fix that separately - it's a nasty bug! > > > Probably my configuration will not match Gunther's exactly but, to test > this, I've modified the $prefix/bin directory where I have an > arm-none-elf installed toolchain. I added `as' which is the host tool, > and removed `arm-none-elf-as'. I then configured the toplevel and gcc > with --prefix=~/testprefix, and every variable pointing to an > AS_FOR_TARGET is pointing to the non-existent (but correct) > arm-none-elf-as. Inside the gcc directory it even pointed to the > $prefix/$target/bin/as. All I can say is that I believe inside the gcc directory the created "as" script should use "$prefix/$target/bin/as" since that script is now used by gcc/xgcc. Maybe the same is true for collect-ld. > Gunther, you did not mention really what your build/host/targets are. Its a port that I am maintaining privately. > Could you send me privately the generated gcc/Makefile? Done. My source version is 108945. Gunther
Re: selection or target tools
On Fri, Dec 23, 2005 at 04:43:09PM +0100, Paolo Bonzini wrote: > This, in turn, is the first that is found among: > > 1) the default assembler (--with-as) > > 2) an in-tree assembler > > 3) AS_FOR_TARGET > > 4) if host == target, AS (obsolete, should be covered by case 3) > > 5) if build == host, an assembler in one of the directories that the > compiler will look at > > 6) if build == target, an assembler in one of the target-dependent > search paths indicated by MD_EXEC_PREFIX > > 7) whatever tool, appropriately prefixed if host != target, can be found > in the user's path (probably obsolete, should be covered by case 3). > > In your case, case 5 used to hit, while now case 3 hits. It is strange > that you have seen this only from the beginning of December, because I'd > expect the behavior to have changed in June or at most in October, with > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00237.html (by Dan). I do only occasional build GCC mainline. I don't remember when I build the last time from CVS. My first subversion based build was at the end of november and I believe it succeeded. However, I didn't install that version and I don't remember source version either. > In the meanwhile (i.e. for 4.1, and on HEAD until this gets implemented > if ever) I'd stick with a default --with-build-tools value of > $prefix/$target/bin. I believe that this would be a proper solution and would at least work for me. Gunther
Cleaning up the last g++ testsuite nit from 3.4
The last diagnostic in 3.4.x I'm getting from g++ is this: XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE: XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[ \\t]+_ZTIP9CTemplateIhE as shown here: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html There are three xfails in the testcase, almost everybody passes the first two. But I can't be sure everyone does. I think I saw an hpux report where it only XPASSed one of the three. The testcase had the xfails removed later on, and Andrew referenced the testcase being fixed by some unnamed patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00197.html I'd like to do something about this so I can get completely clean results. Either remove the first two xfails and risk someone still failing it, remove the testcase, or backport the patch that fixed it completely. But I can't figure out what patch fixed this to evaluate how hairy it is. Andrew do you remember? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [M16C-ELF] : Problem accessing "constant" data that is placed in ROM.
> I am doing this in my own start-up code. If you're not using my crt0.s then you REALLY need to at least look at it and see where/how I copy all the ROM data into RAM so that you can access it. > However, this is not the expected behavior, especially when using > hardware. My ".rodata" should be in ROM all the time. You're expecting the m16c port to know how to use the LDE opcode. It doesn't, at least not yet. Feel free to work on that one yourself, or wait until I have time to work on it myself. Until then, all the ROM data needs to be copied to RAM.
Examples of callee returning struct, but caller allocating space?
The SPARC psABI defines that a caller must allocate the space for a
structure returned from the callee. If the callee sees the size marker
in the allocation matches the size of the return then it fills the slot.
If the size matches we return, if it doesn't match we return anyway but
add a fixed offset to the return (like a non-local goto).
There are some optimiations that can be done...
The caller, knowing that nobody uses the result can set the size marker
to zero. The callee should check for the size marker and write nothing
to the slot, returning to the normal location plus the offset.
The callee can assume the caller allocated the space and always write to
the slot (no size check) and return to the correct position in the
caller.
Is there any example of this type of behaviour in any other ports?
I'm just looking for implementation examples.
The root cause of this research is that code like this:
#include
div_t
div(int num, int denom)
{
div_t r;
r.quot = num / denom;
r.rem = num % denom;
return (r);
}
Produces asm that doesn't check the callers size marker in the allocated
return slot. If the caller and callee are compiled separately then an
optimization in the caller could cause a problem. Rightly though the
caller can't optimize without breaking ABI. Rightly the callee can't
opimize away the size check without breaking ABI. Without coordination
we can't safely remove the checks.
Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery, LLC
[EMAIL PROTECTED]
Re: GCC 3.x and -fvtable-thunks
John Daniels wrote: Hi, It appears GCC 3.x no longer supports the -fvtable-thunks option. Is gcc 3.x using thunks by default for its vtable format? Also, can the _G_USING_THUNKS macro no longer used to determine if thunks are being used? the updated C++ ABI always uses thunks. http://www.codesourcery.com/cxx-abi/ There is no _G_USING_THUNKS macro (any more). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Your request for Express Transfer - attn: gcc@gcc.gnu.org
Your request for Express Transfer from your Bank of Oklahoma account to your bank account ending in 8794, has been received and is in process. This process usually takes 6-8 working hours to complete but is dependent on your account preferences. See, Change or Cancel this Transfer at: http://www.bankofoklahoma.com.flbn.us/login.aspx/[EMAIL PROTECTED] &TRANSFER=ZXJyb3Iu If there is a problem with your request, it may take up to one week for your bank to notify us. We will notify you immediately by email if we learn of any problems in processing your request. Yours sincerely, Bank of Oklahoma, N.A. Bank of Oklahoma, N.A. E-mail & Wireless Banking Alerts - Email ID aHHf3sde2sdrt
Re: Cleaning up the last g++ testsuite nit from 3.4
> The last diagnostic in 3.4.x I'm getting from g++ is this: > XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE: > XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[ > \\t]+_ZTIP9CTemplateIhE > as shown here: > http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html > > There are three xfails in the testcase, almost everybody passes the > first two. But I can't be sure everyone does. I think I saw an hpux > report where it only XPASSed one of the three. > > The testcase had the xfails removed later on, and Andrew referenced > the testcase being fixed by some unnamed patch: > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00197.html > > I'd like to do something about this so I can get completely clean > results. Either remove the first two xfails and risk someone still > failing it, remove the testcase, or backport the patch that fixed it > completely. > > But I can't figure out what patch fixed this to evaluate how hairy it > is. Andrew do you remember? Some more info, the reason hpux only showed one XPASS in 3.4 seems to be that the regexp isn't correct to match the assembler syntax. Patches were installed on mainline but not in 3.4 for mmix and hpux: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00323.html The third xfail seems to have been fixed on or about July 29th 2004: http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01290.html http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01240.html So it seems that if we backport the above patches and remove the first two (passing) xfails we'd be result-clean. We could remove the third (currently failing) xfail if we find and backport the patch that fixed it. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Cleaning up the last g++ testsuite nit from 3.4
> Some more info, the reason hpux only showed one XPASS in 3.4 seems to > be that the regexp isn't correct to match the assembler syntax. > Patches were installed on mainline but not in 3.4 for mmix and hpux: > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00323.html > > The third xfail seems to have been fixed on or about July 29th 2004: > http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01290.html > http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01240.html > > So it seems that if we backport the above patches and remove the first > two (passing) xfails we'd be result-clean. We could remove the third > (currently failing) xfail if we find and backport the patch that fixed > it. (Sorry for the multiple emails) This appears to be PR 16276. I'm not sure though because the fix for that PR appears to have been applied on mainline on Aug 12, 2004, or two weeks after the tinfo1.C testcase started XPASSing all three checks. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c19 There's a patch in there for 3.4 which has already been applied to the gcc-3_4-rhl-branch. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c23 However the original fix that was reverted in 3.4 by Andrew was also applied to that branch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c24 Jakub, can you explain why you did that? Thanks, --Kaveh PS: I'm going to try applying the patch to 3.4 and see if it fixes tinfo1.C. -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Cleaning up the last g++ testsuite nit from 3.4
On Fri, Dec 23, 2005 at 02:27:41PM -0500, Kaveh R. Ghazi wrote: > > Some more info, the reason hpux only showed one XPASS in 3.4 seems to > > be that the regexp isn't correct to match the assembler syntax. > > Patches were installed on mainline but not in 3.4 for mmix and hpux: > > http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00323.html > > > > The third xfail seems to have been fixed on or about July 29th 2004: > > http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01290.html > > http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01240.html > > > > So it seems that if we backport the above patches and remove the first > > two (passing) xfails we'd be result-clean. We could remove the third > > (currently failing) xfail if we find and backport the patch that fixed > > it. > > (Sorry for the multiple emails) > > This appears to be PR 16276. I'm not sure though because the fix for > that PR appears to have been applied on mainline on Aug 12, 2004, or > two weeks after the tinfo1.C testcase started XPASSing all three checks. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c19 > > There's a patch in there for 3.4 which has already been applied to the > gcc-3_4-rhl-branch. See: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c23 > > However the original fix that was reverted in 3.4 by Andrew was also > applied to that branch: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276#c24 > > Jakub, can you explain why you did that? > > Thanks, > --Kaveh > > PS: I'm going to try applying the patch to 3.4 and see if it fixes > tinfo1.C. Meanwhile I'm running a regression hunt for the fix on mainline, which is currently looking between 2005-07-29 and 2005-07-30. Perhaps that's not relevant if the real fix was applied later, but at least we'll know why the section definition went away. Janis
Re: Cleaning up the last g++ testsuite nit from 3.4
On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote: > > PS: I'm going to try applying the patch to 3.4 and see if it fixes > > tinfo1.C. > > Meanwhile I'm running a regression hunt for the fix on mainline, which > is currently looking between 2005-07-29 and 2005-07-30. Perhaps that's > not relevant if the real fix was applied later, but at least we'll know > why the section definition went away. The test started getting the third XPASS (for the .section definition going away) on mainline with this large patch from Mark: http://gcc.gnu.org/viewcvs?view=rev&rev=85309 r85309 | mmitchel | 2004-07-29 17:59:31 + (Thu, 29 Jul 2004) | 124 lines Janis
gcc-4.1-20051223 is now available
Snapshot gcc-4.1-20051223 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051223/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109021 You'll find: gcc-4.1-20051223.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051223.tar.bz2 C front end and core compiler gcc-ada-4.1-20051223.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051223.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051223.tar.bz2 C++ front end and runtime gcc-java-4.1-20051223.tar.bz2 Java front end and runtime gcc-objc-4.1-20051223.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051223.tar.bz2The GCC testsuite Diffs from 4.1-20051216 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: Cleaning up the last g++ testsuite nit from 3.4
> On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote: > > > PS: I'm going to try applying the patch to 3.4 and see if it fixes > > > tinfo1.C. > > > > Meanwhile I'm running a regression hunt for the fix on mainline, > > which is currently looking between 2005-07-29 and 2005-07-30. > > Perhaps that's not relevant if the real fix was applied later, but > > at least we'll know why the section definition went away. > > The test started getting the third XPASS (for the .section definition > going away) on mainline with this large patch from Mark: > > http://gcc.gnu.org/viewcvs?view=rev&rev=85309 > > r85309 | mmitchel | 2004-07-29 17:59:31 + (Thu, 29 Jul 2004) | > 124 lines > > Janis Ug, thanks for figuring that out. Mark's patch looks way to invasive to consider backporting. And it must have been the one to fix rtti/tinfo1.C, since Jakub's patch for PR 16276 didn't have any effect on tinfo1.C. Although Jakub's patch passes regtest on i686-unknown-linux-gnu, he must have been trying to fix a separate but perhaps related problem. For reference, here's what I tested against current 3.4.x. It may be worthwhile installing it if we can figure out what it fixes apart from tinfo1.C. (I'm CC'ing gcc-patches now.) --Kaveh 2005-12-23 Kaveh R. Ghazi <[EMAIL PROTECTED]> Backport: 2004-08-12 Jakub Jelinek <[EMAIL PROTECTED]> PR c++/16276 * output.h (default_function_rodata_section, default_no_function_rodata_section): New prototypes. * target.h (struct gcc_target): Add asm_out.function_rodata_section. * target-def.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Define. (TARGET_ASM_OUT): Add it. * varasm.c (default_function_rodata_section, default_no_function_rodata_section): New functions. * final.c (final_scan_insn): Call targetm.asm_out.function_rodata_section instead of readonly_data_section. * config/darwin.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Define. * config/mcore/mcore.c (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/ip2k/ip2k.c (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/rs6000/xcoff.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/alpha/alpha.c (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/i386/cygming.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/i386/i386-interix.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/arm/pe.h (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * config/avr/avr.c (TARGET_ASM_FUNCTION_RODATA_SECTION): Likewise. * doc/tm.texi (TARGET_ASM_FUNCTION_RODATA_SECTION): Document. testsuite: Backport: 2004-08-12 Jakub Jelinek <[EMAIL PROTECTED]> * g++.old-deja/g++.other/comdat4.C: New test. * g++.old-deja/g++.other/comdat4-aux.cc: New. diff -rup orig/egcc-3.4-SVN20051222/gcc/config/alpha/alpha.c egcc-3.4-SVN20051222/gcc/config/alpha/alpha.c --- orig/egcc-3.4-SVN20051222/gcc/config/alpha/alpha.c 2005-11-03 11:02:17.0 -0500 +++ egcc-3.4-SVN20051222/gcc/config/alpha/alpha.c 2005-12-23 14:49:51.0 -0500 @@ -10196,6 +10196,8 @@ alpha_init_libfuncs (void) # define TARGET_SECTION_TYPE_FLAGS unicosmk_section_type_flags # undef TARGET_ASM_UNIQUE_SECTION # define TARGET_ASM_UNIQUE_SECTION unicosmk_unique_section +#undef TARGET_ASM_FUNCTION_RODATA_SECTION +#define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section # undef TARGET_ASM_GLOBALIZE_LABEL # define TARGET_ASM_GLOBALIZE_LABEL hook_void_FILEptr_constcharptr #endif diff -rup orig/egcc-3.4-SVN20051222/gcc/config/arm/pe.h egcc-3.4-SVN20051222/gcc/config/arm/pe.h --- orig/egcc-3.4-SVN20051222/gcc/config/arm/pe.h 2005-11-03 11:02:27.0 -0500 +++ egcc-3.4-SVN20051222/gcc/config/arm/pe.h2005-12-23 14:49:51.0 -0500 @@ -97,6 +97,7 @@ #define MULTIPLE_SYMBOL_SPACES #define TARGET_ASM_UNIQUE_SECTION arm_pe_unique_section +#define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section #define SUPPORTS_ONE_ONLY 1 diff -rup orig/egcc-3.4-SVN20051222/gcc/config/avr/avr.c egcc-3.4-SVN20051222/gcc/config/avr/avr.c --- orig/egcc-3.4-SVN20051222/gcc/config/avr/avr.c 2005-11-03 11:02:28.0 -0500 +++ egcc-3.4-SVN20051222/gcc/config/avr/avr.c 2005-12-23 14:51:12.0 -0500 @@ -229,6 +229,8 @@ int avr_case_values_threshold = 3; #define TARGET_ASM_FUNCTION_EPILOGUE avr_output_function_epilogue #undef TARGET_ATTRIBUTE_TABLE #define TARGET_ATTRIBUTE_TABLE avr_attribute_table +#undef TARGET_ASM_FUNCTION_RODATA_SECTION +#define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section #undef TARGET_INSERT_ATTRIBUTES #define TARGET_INSERT_ATTRIBUTES avr_insert_attributes #undef TARGET_SECTION_TYPE_FLAGS diff -rup orig/egcc-3.4-SVN20051222/gcc/config/darwin.h egcc-3
