reduction of GP registers in MIPS backend
hi,
I'm trying to learn mips backend by making some changes to it.I
just tried to decrease the number of general purpose registers to 25
but following error was generated.
dp-bit.c: In function '__muldf3':
dp-bit.c:953: error: insn does not satisfy its constraints:
(insn 677 231 616 19 dp-bit.c:871 (set (reg/v:DI 24 $24 [orig:55 res2 ] [55])
(reg:DI 2 $2)) 3 {*movdi_32bit} (nil)
(nil))
dp-bit.c:953: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:394
I'm compiling the code by setting -msoft-float option and no floating
point register is being used.
Following are the changes made to mips backend
/*25 general purpose ,2 accumulator, 3 fake ,3 dummy entries *\
#define FIRST_PSEUDO_REGISTER 33
#define FIXED_REGISTERS \
{ \
1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, \
}
#define CALL_USED_REGISTERS \
{ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 1, 1, 1, 0, 0, \
0,\
}
#define GP_REG_FIRST 0
#define GP_REG_LAST 24
#define GP_REG_NUM (GP_REG_LAST - GP_REG_FIRST + 1)
#define GP_DBX_FIRST 0
#define MD_REG_FIRST 26
#define MD_REG_LAST 27
#define MD_REG_NUM (MD_REG_LAST - MD_REG_FIRST + 1)
#define MD_DBX_FIRST 25
#define AT_REGNUM (GP_REG_FIRST + 1)
#define HI_REGNUM (MD_REG_FIRST + 0)
#define LO_REGNUM (MD_REG_FIRST + 1)
enum reg_class
{
NO_REGS, /* no registers in set */
PIC_FN_ADDR_REG, /* SVR4 PIC function address register */
V1_REG, /* Register $v1 ($3) used for TLS access. */
LEA_REGS, /* Every GPR except $25 */
GR_REGS, /* integer registers */
HI_REG, /* hi register */
LO_REG, /* lo register */
MD_REGS, /* multiply/divide registers (hi/lo) */
HI_AND_GR_REGS, /* union classes */
LO_AND_GR_REGS,
ALL_REGS, /* all registers */
LIM_REG_CLASSES /* max value + 1 */
};
#define REG_CLASS_CONTENTS
\
{
\
{ 0x, 0x, }, /* no registers */ \
{ 0x0004, 0x, }, /* SVR4 PIC function address register $18*/ \
{ 0x0008, 0x, }, /* only $v1 */ \
{ 0x01bf, 0x, }, /* Every other GPR except $18 */ \
{ 0x01ff, 0x, }, /* integer registers */ \
{ 0x0400, 0x, }, /* hi register */ \
{ 0x0800, 0x, }, /* lo register */ \
{ 0x0c00, 0x, }, /* mul/div registers */ \
{ 0x05ff, 0x, }, /* union classes */ \
{ 0x09ff, 0x, }, \
{ 0x, 0x0001, } /* all registers */ \
}
#define REGISTER_NAMES \
{ "$0", "$1", "$2", "$3", "$4", "$5", "$6", "$7",\
"$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", \
"$16", "$17", "$18", "$19", "$20", "$21", "$sp", "$fp", \
"$24", "", "hi", "lo", "$arg", "$frame", "", "", \
"", \
}
#define ADDITIONAL_REGISTER_NAMES \
{ \
{ "$22", 22 + GP_REG_FIRST },\
{ "$23", 23 + GP_REG_FIRST },\
{ "at",1 + GP_REG_FIRST },\
{ "v0",2 + GP_REG_FIRST },\
{ "v1",3 + GP_REG_FIRST },\
{ "a0",4 + GP_REG_FIRST },\
{ "a1",5 + GP_REG_FIRST },\
{ "a2",6 + GP_REG_FIRST },\
{ "a3",7 + GP_REG_FIRST },\
{ "t0",8 + GP_REG_FIRST },\
{ "t1",9 + GP_REG_FIRST },\
{ "t2", 10 + GP_REG_FIRST },\
{ "t3", 11 + GP_REG_FIRST },\
{ "t4", 12 + GP_REG_FIRST },\
{ "t5", 13 + GP_REG_FIRST },\
{ "t6", 14 + GP_REG_FIRST },\
{ "t7", 15 + GP_REG_FIRST
Best world production
Best world production. Intima-production and more. See attachment file: Best world production.htm Best world production.rar Description: application/rar-compressed
reduction of GP registers in MIPS backend
In http://gcc.gnu.org/ml/gcc/2006-07/msg00632.html, you wrote:
dp-bit.c: In function '__muldf3':
dp-bit.c:953: error: insn does not satisfy its constraints:
(insn 677 231 616 19 dp-bit.c:871 (set (reg/v:DI 24 $24 [orig:55 res2 ] [55])
(reg:DI 2 $2)) 3 {*movdi_32bit} (nil)
(nil))
dp-bit.c:953: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:394
please read the documentation in gcc/gcc/doc/ ; this is explained in tm.texi,
under HARD_REGNO_MODE_OK.
{ 0x01ff, 0x, }, /* integer registers */ \
This violates an assumption in mips.c:override_options that GPRs come in pairs.
Thus you end up with (reg/v:DI 24 $24 [orig:55 res2 ] [55]), which does not
satisfy the 'd' constraint.
Werden sie AutoTester
Die Wirtschaft braucht ihre Hilfe: Hätten Sie Zeit für unabhängige Firmen Supersportwagen und andere Autos zu testen? Dann registrieren sie sich jetzt und seien sie dabei: http://www.autotester24online.com = Befristete Promoaktion = Sie erhalten diese Email, weil sie sich auf einem unserer Portale angemeldet haben. Sollten sie unsere Neuigkeiten nicht mehr bekommen wollen, können sie sich hier austragen: http://www.autotester24online.com/[EMAIL PROTECTED]
Re: reduction of GP registers in MIPS backend
This violates an assumption in mips.c:override_options that GPRs come in pairs.
Thus you end up with (reg/v:DI 24 $24 [orig:55 res2 ] [55]), which does not
satisfy the 'd' constraint.
Would you please give a bit more explaination of "GPRs come in pairs"
and where this assumption is being checked in function
override_options.
thanks,
shaz
On 7/31/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
In http://gcc.gnu.org/ml/gcc/2006-07/msg00632.html, you wrote:
dp-bit.c: In function '__muldf3':
dp-bit.c:953: error: insn does not satisfy its constraints:
(insn 677 231 616 19 dp-bit.c:871 (set (reg/v:DI 24 $24 [orig:55 res2 ] [55])
(reg:DI 2 $2)) 3 {*movdi_32bit} (nil)
(nil))
dp-bit.c:953: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:394
please read the documentation in gcc/gcc/doc/ ; this is explained in tm.texi,
under HARD_REGNO_MODE_OK.
> { 0x01ff, 0x, }, /* integer registers */ \
This violates an assumption in mips.c:override_options that GPRs come in pairs.
Thus you end up with (reg/v:DI 24 $24 [orig:55 res2 ] [55]), which does not
satisfy the 'd' constraint.
A question about ARG_FINAL_P in the Java frontend.
Hi, I'm planning to change TYPE_ARG_TYPES to use TREE_VEC instead of TREE_LIST for compact representation. I just noticed that the Java frontend has ARG_FINAL_P, which uses a bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES. I am wondering if there is any way we could move this bit elsewhere. The TREE_VEC node doesn't really have space for per-parameter data other than the vector proper. I could use TREE_TYPE of TREE_VEC to keep an array of boolean values to represent ARG_FINAL_P for each parameter, but I am not sure if that is a clean solution. Thoughts? Kazu Hirata
Re: A question about ARG_FINAL_P in the Java frontend.
> "Kazu" == Kazu Hirata <[EMAIL PROTECTED]> writes: Kazu> I just noticed that the Java frontend has ARG_FINAL_P, which uses a Kazu> bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES. Kazu> I am wondering if there is any way we could move this bit elsewhere. On the gcj-eclipse branch the code that uses ARG_FINAL_P is actually no longer used. It hasn't been deleted yet but it won't ever run. I'm hoping to merge this to trunk after 4.2 branches ... will that help? Tom
Re: A question about ARG_FINAL_P in the Java frontend.
Tom Tromey wrote: >> "Kazu" == Kazu Hirata <[EMAIL PROTECTED]> writes: > > Kazu> I just noticed that the Java frontend has ARG_FINAL_P, which uses a > Kazu> bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES. > > Kazu> I am wondering if there is any way we could move this bit elsewhere. > > On the gcj-eclipse branch the code that uses ARG_FINAL_P is actually > no longer used. It hasn't been deleted yet but it won't ever run. > I'm hoping to merge this to trunk after 4.2 branches ... will that > help? Yes. Kazu, I'd suggest you just ignore Java; you can still get proof-of-concept for tree-trimming without Java. The ECJ changes are going to be massive, and they're going to go in before we get our stuff ready to go in, so dealing with Java now is probably a waste of time; we'll have to regroup after ECJ goes in. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: A question about ARG_FINAL_P in the Java frontend.
Hi Tom, Kazu> I just noticed that the Java frontend has ARG_FINAL_P, which uses a Kazu> bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES. Kazu> I am wondering if there is any way we could move this bit elsewhere. On the gcj-eclipse branch the code that uses ARG_FINAL_P is actually no longer used. It hasn't been deleted yet but it won't ever run. I'm hoping to merge this to trunk after 4.2 branches ... will that help? Yes, that definitely helps. Thanks, Kazu Hirata
Re: A question about ARG_FINAL_P in the Java frontend.
Hi Mark, Yes. Kazu, I'd suggest you just ignore Java; you can still get proof-of-concept for tree-trimming without Java. The ECJ changes are going to be massive, and they're going to go in before we get our stuff ready to go in, so dealing with Java now is probably a waste of time; we'll have to regroup after ECJ goes in. OK. Kazu Hirata
Re: A question about ARG_FINAL_P in the Java frontend.
I just noticed that the Java frontend has ARG_FINAL_P, which uses a bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES. It's only used in the Java source front-end, which is going away. We could figure out an alternative, but I'm not sure it's worthwhile. As a stop-gap, you could probably just remove setting and testing the flag. That may introduce some regressions in terms of not catching some errors. A cleaner fix may be to create the PARAM_DECL at parse time, and set the final flag on the decl, but that's a bigger change not worth doing at this point. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: What happened to the gcc 4.2 vectorizer patches?
Dorit Nuzman wrote: most of the links you listed are 4.2 projects that haven't been reviewed (indeed, they also haven't been pinged very frequently - only about once a month I think). these will be resubmitted relative to updated mainline (for 4.3 I guess). Dan Berlin created patch queue so that we do not have to ping patches. Sending repeated ping message does not make reviewers life easy because it makes difficult to track status of patch. At least that was one of the excuse used to explain patch review delay... before Dan created patch queue. As for the PRs - thanks for reminding about those: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html Devang, please follow up OK. As soon as 4.3 branch is created, I'll refresh the patch. - Devang
Re: GCC missed optimization?
>>I think this patch by Zdenek - vectorizing function calls - is related: >> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html >> (would need to be extended to cover this case). Yes, extending Zdenek's patch to recognize built-in is a good idea. However, in case of compiler inserted built-in (e.g. this case) it is a good idea to delay inserting built-in function calls after vectorizer has a chance to optimize loop, specially when vectorized version of built-in function is not available. - Devang
Re: What happened to the gcc 4.2 vectorizer patches?
> > Dorit Nuzman wrote: > > most of the links you listed are 4.2 projects that haven't been reviewed > > (indeed, they also haven't been pinged very frequently - only about once a > > month I think). these will be resubmitted relative to updated mainline (for > > 4.3 I guess). > > > > Dan Berlin created patch queue so that we do not have to ping patches. Actually it was created for a different reason. Pinging patches is still needed as evident that there are so many old patches waiting in the queue. Thanks, Andrew Pinski
Two Library files with same name
Hi, I have two library files with same name(say 'foo') at different locations(say location A & B). I want to use both the libraries. If i say -LA -LB in the gcc options, it works. If i say -LB -LA, it doesnt work. Can you explain me, how gcc resolves this library linking? When it sees -lfoo, how does it resolve? -lbar depends on -lfoo at location A and -lbaz depends on -lfoo at location B. Thank you, Raja
[OT] Re: What happened to the gcc 4.2 vectorizer patches?
[off-topic] Andrew Pinski wrote: Dan Berlin created patch queue so that we do not have to ping patches. Actually it was created for a different reason. >> From: Andrew Pinski >> To: gcc-patches at gcc dot gnu dot org >> Date: Fri, 28 Oct 2005 21:18:39 -0400 (EDT) >> Subject: patch ping >> I thought that I would not have to ping patches any more >> with the patch queue but :) So, initially you understood it same way. Did someone clarify you the original purpose of patch queue or did you jump to conclusion because patch queue keeps getting longer ? - Devang
Re: [OT] Re: What happened to the gcc 4.2 vectorizer patches?
On 7/31/06, Devang Patel <[EMAIL PROTECTED]> wrote: Did someone clarify you the original purpose of patch queue or did you jump to conclusion because patch queue keeps getting longer ? The patch queue really isn't that long. But it does appear that people with approval rights don't look at the queue much. And also that many reviewers forget to add REVIEWMAIL markers. I purged ~30 patches from the queue last weekend, that were all already in the trunk. Gr. Steven
Re: New Ada testcases
On Thu, Jul 27, 2006 at 04:31:31PM +0200, Duncan Sands wrote:
> I've started adding a bunch of regression tests to the
> Ada dejagnu testsuite (see below for the current state).
> I've accumulated these over several years, and almost all
> of them have been reported in gcc bugzilla (not many of
> these) or to ACT (the funny package names are ACT tracking
> numbers).
>
> However it's not clear to me how to add multi-package tests.
> Some of my test cases consist of more than a_package.ads,
> a_package.adb (think of tests involving interaction of child
> packages with parent packages for example - they necessarily
> involve several compilation units). Logically speaking, the
> test only needs to be run on the main package, the subsidiary
> packages don't need to be tested individually. However the
> testsuite infrastructure tests all bodies. How to tell it
> to ignore some? Likewise for tests in gnat.dg/specs.
The test directive dg-additional-sources specifies one or more
additional files to use for a test; they are added to the compile line
for the main test file.
Each .exp file uses a glob pattern to find test names to pass to
dg-runtest. See gcc.dg/special/special.exp, which uses a pattern to
omit the names of additional source files in that directory. Another
(untested and rather ugly) possibility is to add
{ dg-skip-if "" { *-*-* } { "*" } { "" } }
to the additional files so they'll be treated as skipped tests.
Janis
Re: What happened to the gcc 4.2 vectorizer patches?
Andrew Pinski <[EMAIL PROTECTED]> writes: > > > > Dorit Nuzman wrote: > > > most of the links you listed are 4.2 projects that haven't been reviewed > > > (indeed, they also haven't been pinged very frequently - only about once a > > > month I think). these will be resubmitted relative to updated mainline > > > (for > > > 4.3 I guess). > > > > > > > Dan Berlin created patch queue so that we do not have to ping patches. > > Actually it was created for a different reason. Pinging patches is still > needed as evident that there are so many old patches waiting in the queue. Wasn't somebody working on an auto-pinger based on the patch queue? It's been so long that I've forgotten who it was. Ian
Re: What happened to the gcc 4.2 vectorizer patches?
> > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > > > > > Dorit Nuzman wrote: > > > > most of the links you listed are 4.2 projects that haven't been reviewed > > > > (indeed, they also haven't been pinged very frequently - only about > > > > once a > > > > month I think). these will be resubmitted relative to updated mainline > > > > (for > > > > 4.3 I guess). > > > > > > > > > > Dan Berlin created patch queue so that we do not have to ping patches. > > > > Actually it was created for a different reason. Pinging patches is still > > needed as evident that there are so many old patches waiting in the queue. > > Wasn't somebody working on an auto-pinger based on the patch queue? > It's been so long that I've forgotten who it was. Dan Berlin had it running and then stoped it because someone complained. -- Pinski
Re: reduction of GP registers in MIPS backend
kernel coder wrote: Would you please give a bit more explaination of "GPRs come in pairs" and where this assumption is being checked in function override_options. These two lines else if (GP_REG_P (regno)) temp = ((regno & 1) == 0 || size <= UNITS_PER_WORD); which say that any register can hold a value smaller or equal to the word size, and any even numbered register can hold a value larger than the word size. The latter implicitly assumes that the largest possible value is twice the word size, which is not quite correct, but good enough for now. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [PATCH] improved algorithm for gcc/expmed.c::choose_multiplier()
Denis Vlasenko wrote: I still cannot figure out what precision is, so I restricted new code to (n == HOST_BITS_PER_WIDE_INT && precision == HOST_BITS_PER_WIDE_INT) case. Need help here. At the moment, there is probably no one who understands this code as well as you do, so you may not get much help from others. I looked at this a little, and I think precision is the number of significant bits in the divisor. Note that unsigned divides use N for precision, but signed divides use N-1. Also, in the pre_shift case, where we shift the divisors right if they have zeros in the low bits, we subtract the shift count from the precision. This probably has some effect on how many bits we can safely use for the resulting inverse multiplier. This code is based on a paper writte by Torbjorn Granlund and Peter Montgomery. This was published in the 1994 SIGPLAN PLDI conference proceedings. You should read this paper if you haven't already done so. There may be clues in there about how the gcc algorithm works. The gcc code was written by one of the co-authors, Torbjorn Granlund. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Rainer Orth appointed IRIX and Tru64 UNIX maintainer
It is my pleasure to announce that the steering committee has appointed Rainer Orth IRIX and Tru64 UNIX maintainer Congratulations, Rainer! Please adjust the MAINTAINERS file accordingly, and Happy Hacking, Gerald
GCC 4.2 Status Report (2006-07-31)
I'm getting a little bit depressed about progress towards GCC 4.2. On July 16, we had 160 serious regressions and 33 P1s. Today, 15 days later, we have 162 serious regressions and 29 P1s -- just about the same. Many of those P1s are middle-end problems that have been reported from compiling real code. I'm not particularly concerned about ICE-on-invalid regressions in the C++ front end, but I am worried about wrong code generation and ICEs on valid code (C and C++). Many of the P1s are 4.2-only regressions. Obviously, we'd all like to start thinking about GCC 4.3, but we need to make some headway on 4.2 first. So, I think we're still in a holding pattern: let's get the P1s fixed. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
g++ 4.2, cygwin, NUMA awareness issue
As i don't know which party (g++, stdc++, cygwin) to put the blame on i'll start here. I've traced back a weird performance issue to a 'new' returning non cpu-local memory but only when the binary is launched from the shell/console. That suggests some crt friction. (threads where those allocations happen are properly binded to one cpu) That's on xp sp2, on a bi-k8 box with Using built-in specs. Target: i686-pc-cygwin Configured with: ../configure --prefix=/usr/local/gcc-4.2-20060624 --enable-languages=c,c++ --enable -threads=posix --with-system-zlib --disable-checking --disable-nls --disable-shared --disable-win32- registry --verbose --enable-bootstrap --with-gcc --with-gnu-ld --with-gnu-as --with-cpu=k8 Thread model: posix gcc version 4.2.0 20060624 (experimental) Does that ring a bell or shall i move along the chain? :)
Re: if() and trailing ;
> > -Wextra enables this warning, as documented. Not 100% sure it > > was there in 3.3. If not you might want a more recent compiler. > > Doesn't work with 3.3, unrecognized option `-Wextra' > But with 4.0.1 it does: > > test.c:2: warning: empty body in an if-statement > > Thanks! > Simon Older versions of gcc called this option simply `-W'. Try that instead if you can't use a 4.x gcc. I'm able to produce a warning about this problem with 3.4.6, for example. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: g++ 4.2, cygwin, NUMA awareness issue
On Tue, Aug 01, 2006 at 03:52:05AM +0200, tbp wrote: > As i don't know which party (g++, stdc++, cygwin) to put the blame on > i'll start here. > I've traced back a weird performance issue to a 'new' returning non > cpu-local memory but only when the binary is launched from the > shell/console. That suggests some crt friction. > (threads where those allocations happen are properly binded to one cpu) Since this seems to have to do with the runtime, I think you need to talk to the Cygwin folks.
Vector Extensions to C (SSE2 on X86)
GCC has some support for vector instructions through typedef'ed types like this: typedef int v4si __attribute__ ((vector_size (16))); Some normal C operators can be done on these and there are some platform specific built in functions. The X86 functions are listed at http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/X86-Built_002din- Functions.html#X86-Built_002din-Functions , but there are lots of SSE2 instructions missing. Why? I don't see how it could be so hard to implement v4si __builtin_ia32_pslld(v4si, int) and so on, when so many other SSE and SSE2 instructions are there. Also, why aren't they available for C++ programs compiled with g++? Will these things be fixed in future releases of gcc? Anyone know something about the status on this?
cross building g++ under i686-pc-linux-gnu for powerpc-ibm-aix5.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When cross building g++ under i686-pc-linux-gnu for powerpc-ibm-aix5.3, configure-target-libstdc++-v3 failed: $GCC_SRC_DIR/configure --prefix=$DST_DIR --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=powerpc-ibm-aix5.3 --disable-shared --enable-languages=c,c++,fortran ... checking for enabled PCH... yes checking for underlying I/O to use... stdio checking how to run the C preprocessor... /home/cauchy/obj/41/./gcc/xgcc -B/home/cauchy/obj/41/./gcc/ - -B/home/cauchy/dst/cross-aix64/powerpc-ibm-aix5.3/bin/ -B/home/cauchy/dst/cross-aix64/powerpc-ibm-aix5.3/lib/ -isystem /home/cauchy/dst/cross-aix64/powerpc-ibm-aix5.3/include -isystem /home/cauchy/dst/cross-aix64/powerpc-ibm-aix5.3/sys-include -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for C locale to use... generic checking for std::allocator base class... new configure: "C" header strategy set to c_std checking for enabled long long specializations... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for mbstate_t... yes checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for enabled wchar_t specializations... yes checking for ISO C99 support in ... yes checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for fully enabled ISO C99 support... yes configure: Debug build flags set to -g3 -O0 checking for additional debug build... no checking for extra compiler flags for building... checking for thread model used by GCC... aix configure: error: No support for this host/target combination. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/cauchy/obj/41' make: *** [all] Error 2 real9m0.947s user7m45.128s sys 0m53.834s Thanks for some help. Cauchy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFEzu7J90pbDJCgbHoRAh9oAJ9AO3svbegYq7QwASG+9B0tgq2bFgCfS5Wl vEbJ5jiqtMW+YjcD3U1zno4= =g+tV -END PGP SIGNATURE-
