Re: RFA: pervasive SSE codegen inefficiency
So basically, pick a problem you see, and fix it. The RTL infrastructure is exceptionally good at doing some things, and exceptionally bad at doing some others. Sometimes, take into account the coding style and it is good and bad at the same time. :-( CSE, flow, etc. come to mind. All you can do is try to improve on the bad items and be careful not to cripple the good ones. FWIW, it's the same thing we have been doing with fwprop. After removing code from pre-existing RTL passes (which you don't need because the allocator is already crippled...), benchmark, fix regressions, and iterate from step 2. Paolo
Calling functions on x86
On x86 and GCC 3.4.2, the resulting asm code when leaving a stackframe is (in intel_syntax) mov esp,ebp pop ebp .(results in 0x89EC5D or 0x8BE55D) The AMD optimisation guide for AMD64 tells you not to use mov esp, ebp - pop ebp but to use "leave"(just 0xC9)! Perhaps using "enter x(16bit), imm8" is better than "push ebp - mov ebp, esp - sub esp, x" I hope you can improve performance with these optimisations. ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
RE: Calling functions on x86
Original Message
>From: patriciak784-gccmainling
>Sent: 20 September 2005 12:15
> On x86 and GCC 3.4.2, the resulting asm code when
> leaving a stackframe is (in intel_syntax)
> mov esp,ebp
> pop ebp
> .(results in 0x89EC5D or 0x8BE55D)
> The AMD optimisation guide for AMD64 tells you not to
> use mov esp, ebp - pop ebp but to use "leave"(just
> 0xC9)!
I don't have a 64bit version, but did you try using the appropriate
-march= option?
[EMAIL PROTECTED] /test/leave> cat foo.c
int foo (void)
{
return 9;
}
[EMAIL PROTECTED] /test/leave> gcc -O0 -S foo.c -o foo.s
[EMAIL PROTECTED] /test/leave> cat foo.s
.file "foo.c"
.text
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
pushl %ebp
movl%esp, %ebp
movl$9, %eax
popl%ebp
ret
[EMAIL PROTECTED] /test/leave> gcc -O0 -S -march=athlon-xp foo.c -o foo.s
[EMAIL PROTECTED] /test/leave> cat foo.s
.file "foo.c"
.text
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
pushl %ebp
movl%esp, %ebp
movl$9, %eax
leave
ret
[EMAIL PROTECTED] /test/leave>
cheers,
DaveK
--
Can't think of a witty .sigline today
Failure to build gcc cvs trunk on cygwin:
Well... I just happend to shoot off a test build on cygwin... and it barfs like this: if [ x"" != x ]; then \ /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I/usr/local/src/trunk/gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes /usr/local/src/trunk/gcc/libiberty/regex.c -o pic/regex.o; \ else true; fi /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I/usr/local/src/trunk/gcc/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes /usr/local/src/trunk/gcc/libiberty/regex.c -o regex.o /usr/local/src/trunk/gcc/libiberty/regex.c:130: warning: function declaration isn't a prototype /usr/local/src/trunk/gcc/libiberty/regex.c:130: warning: conflicting types for built-in function 'malloc' /usr/local/src/trunk/gcc/libiberty/regex.c:131: warning: function declaration isn't a prototype In file included from /usr/local/src/trunk/gcc/libiberty/regex.c:638: /usr/local/src/trunk/gcc/libiberty/regex.c: In function 'byte_regex_compile': /usr/local/src/trunk/gcc/libiberty/regex.c:2439: warning: implicit declaration of function 'free' /usr/local/src/trunk/gcc/libiberty/regex.c: In function 'byte_re_compile_fastmap': /usr/local/src/trunk/gcc/libiberty/regex.c:4835: warning: implicit declaration of function 'abort' /usr/local/src/trunk/gcc/libiberty/regex.c:4835: warning: incompatible implicit declaration of built-in function 'abort' /usr/local/src/trunk/gcc/libiberty/regex.c: In function 'byte_re_match_2_internal': /usr/local/src/trunk/gcc/libiberty/regex.c:7421: warning: incompatible implicit declaration of built-in function 'abort' /usr/local/src/trunk/gcc/libiberty/regex.c: In function 'xregerror': /usr/local/src/trunk/gcc/libiberty/regex.c:8078: warning: incompatible implicit declaration of built-in function 'abort' /usr/local/src/trunk/gcc/libiberty/regex.c: In function 'byte_regex_compile': /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: error: invariant not recomputed when ADDR_EXPR changed &_ctype_D.1917[1]; /usr/local/src/trunk/gcc/libiberty/regex.c:2285: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [regex.o] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [bootstrap-lean] Error 2 anyone else see this or am I just being stupid on my own here? -- Cheers, /ChJ
Re: RFA: pervasive SSE codegen inefficiency
Daniel Berlin <[EMAIL PROTECTED]> wrote: > For example, Kenny and I discovered during his prespilling work that the > liveness is actually calculated wrong. > > It's half-forwards (local), half-backwards (globally), instead of all > backwards, which is how liveness is normally calculated, so we > discovered that spilling registers wasn't actually changing the liveness > calculation due to the forwardness. I believe another short term project that could be done is to prepare a good test infrastructure for RTL passes. Currently, tree passes get away with checking their own dumps, and or scanning the resulting code after the pass. This is not "perfect" but it is surely good "enough". Instead, in RTL world, there are absolutely *no* unit tests, if we exclude some backend-specific pass (e.g. check "cmov" is generated in final assembly listing). Making an example out of Daniel's and Kenny's work, there is no way to test that liveness is calculated correctly. Or that it is correctly updated after prespilling. I'm not suprised that it turned out that spilling a register didn't change liveness, since there is no test for it. Also, I would not be surprised if 10 days after Kenny and Danny commit their work, someone else manages to break it again with a stupid typo somewhere, and nobody notices it for another 3-4 years. For instance, I remember Joern writing a simple reload unit-test module: it was a file that was able to setup reload, feed it with some hand-crafed RTL, and check if the output RTL was as expected. It was SH-only and incomplete, but it would be a good start. I don't think we can make much progress with RA, if people can break other people's work without even noticing. Another example could be Paolo's recent fwprop pass: it will be committed without a way to test that it is actually working. Now think if there was a way to feeds it with some RTL and check the generated output. That'd be useful! -- Giovanni Bajo
How set an iterator to NULL
Since last week this small program does no longer compile.
My question are:
Is this correct or should I file a bug report?
How is it possible to initialize an iterator to NULL?
Michael Cieslinski
#include
struct S { int x; };
std::list::iterator IT;
void Init()
{
IT = NULL;
}
g++ -c example.cpp
example.cpp: In function 'void Init()':
example.cpp:9: error: no match for 'operator=' in 'IT = 0l'
stl_list.h:112: note: candidates are: std::_List_iterator&
std::_List_iterator::operator=(const std::_List_iterator&)
Re: RFA: pervasive SSE codegen inefficiency
On Tue, 2005-09-20 at 15:44 +0200, Giovanni Bajo wrote: > Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > For example, Kenny and I discovered during his prespilling work that the > > liveness is actually calculated wrong. > > > > It's half-forwards (local), half-backwards (globally), instead of all > > backwards, which is how liveness is normally calculated, so we > > discovered that spilling registers wasn't actually changing the liveness > > calculation due to the forwardness. > > I believe another short term project that could be done is to prepare a good > test infrastructure for RTL passes. > > Currently, tree passes get away with checking their own dumps, and or > scanning the resulting code after the pass. This is not "perfect" but it is > surely good "enough". Instead, in RTL world, there are absolutely *no* unit > tests, if we exclude some backend-specific pass (e.g. check "cmov" is > generated in final assembly listing). > > Making an example out of Daniel's and Kenny's work, there is no way to test > that liveness is calculated correctly. Or that it is correctly updated after > prespilling. Actually, we have such a test. :) It will gcc_assert if this happens now. This could easily be made to print out to a dump file, etc.
Re: How set an iterator to NULL
Michael Cieslinski wrote: >Since last week this small program does no longer compile. >My question are: >Is this correct or should I file a bug report? >How is it possible to initialize an iterator to NULL? > > > A patch was recently submitted specifically to stop this working, as it shouldn't. there isn't a general way of setting iterators to NULL (some people believe there should be). The usual things to say are either a) don't create the iterators until you have somewhere to point them, or b) often (but not always) it is natural to use the iterator returned by list.end() as a "NULL" iterator. Chris
Re: Failure to build gcc cvs trunk on cygwin:
On Sep 20, 2005, at 7:47 AM, Christian Joensson wrote: Well... I just happend to shoot off a test build on cygwin... and it barfs like this: anyone else see this or am I just being stupid on my own here? This is PR 21766. -- Pinski
Re: fortran-testcase/dce question
On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote: We've had the testcase below in autovect-branch for a while, testing that the 3 loops get vectorized. On mainline the third loop now gets eliminated by DCE (.t44.dce3). Not sure I understand why... isn't the print loop enough to keep it alive? It should be but from the looks of it. For some reason in alias2, we don't say D.503_30 points to anyoffset in &e unlike before. You might be able to generate a C testcase for this too. Can you also file a bug? Thanks, Andrew Pinski
Re: fortran-testcase/dce question
On Sep 20, 2005, at 11:09 AM, Andrew Pinski wrote: On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote: We've had the testcase below in autovect-branch for a while, testing that the 3 loops get vectorized. On mainline the third loop now gets eliminated by DCE (.t44.dce3). Not sure I understand why... isn't the print loop enough to keep it alive? It should be but from the looks of it. For some reason in alias2, we don't say D.503_30 points to anyoffset in &e unlike before. You might be able to generate a C testcase for this too. I should mention that we have in alias2: D.503_30 = &e.d[D.502_29]; which points to anyoffset in &e. Thanks, Andrew Pinski
Re: Warning C vs C++
Tommy Vercetti wrote: > Fair enough. Still - thou - I would kindly request adding singness warning as > default in gcc. From security perspective, that's required. I would even > generate errors on those, if you ask me, but I know this isn't quite normal > for the rest of world. Frankly, I agree that -Wall is a poor name. Yes, people should read docmentation, but -Wall really does suggest that it should turn on all warnings. I understand why it doesn't, and it probably can't be changed, but that doesn't make it a great name. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: RFA: pervasive SSE codegen inefficiency
On Sep 19, 2005, at 9:15 PM, Richard Henderson wrote: On Mon, Sep 19, 2005 at 05:33:54PM -0700, Dale Johannesen wrote: Do you have any constructive suggestions for how the RA might be fixed, then? Short term? No. But I don't see this as a short term problem. OK. Unfortunately, it is a short term problem for Apple. I don't know how to fix it in the RA and it looks like nobody else does either, so I'll have to do something local, I guess. (Thanks Daniel and Giovanni, suggestions for incremental updates that don't address this problem are not really what I was looking for here.)
Re: installing problem
On Sep 19, 2005, at 11:07 PM, Hitha Nambiar wrote: i am installing gcc-4.0.1 in mandrake (k ) linux.actually i want to install apache server .for that gcc is neded.when i i start configuring gcc it is showing a message like configure:error:no acceptable cc found in $path sir plz help me to come out of this This is the wrong list to post such questions. You'll want to contact your OS vendor an ask them about where to get a C compiler. Chances are there is a package you can install that will contain one.
Build DDG from multiple BBs
Does GCC have a function to build a data dependence graph (DDG) across multiple basic blocks? I think sched-rgn.c has something similar, but I was hoping for a more general interface. Thanks, Chad
Re: Build DDG from multiple BBs
On Tue, 2005-09-20 at 13:50 -0400, [EMAIL PROTECTED] wrote: > Does GCC have a function to build a data dependence graph (DDG) across > multiple basic blocks? No. The best we have is create_ddg in ddg.c
Re: Array to Double.
On Sep 19, 2005, at 10:36 PM, N V Krishna wrote:
When I try to compile something like:
foo(){
int a[] = {1,2};
}
gcc is combining them into a double (DImode) and handling as such.
Is there a switch by which I can direct gcc not to do so? I am
using gcc 2.95.2.
Side note, we aren't going to support 2.95.2 much around here...
You didn't even tell us the target...
Base upon what you've said so far, the answer is no.
Also, you used the wrong like, gcc-help is the correct list to use.
Question on syntax in machine description files.
Quick question on syntax in md files as I'm not finding the documentation to explain it. If I see the following on an instruction definition: (set_attr "type" "*") What does * represent in this context as the value to assign to "type"? Thanks. Pete
Re: Question on syntax in machine description files.
> Peter Steinmetz writes: Peter> If I see the following on an instruction definition: Peter> (set_attr "type" "*") Peter> What does * represent in this context as the value to assign to "type"? The default value specified when the attr "type" is defined. David
Re: Array to Double.
Hi,
I am sorry for not specifying all the details. I am hacking gcc 2.95.2 for
ARM to include my own version of register allocator. Currently, I am
supporting only single registers. i.e. No register pairs - No DImode. For
this I am trying to see there are no pseudo registers with DImode. But I
am seeing that in the RTL generated there are uses of DImode. And that's
because the front end of gcc is translating this code to access 64 bits of
array 'a' using DImode.
For this reason, I am trying to see if there is a way to tell the front
end (by a switch or editing the code) not to do so.
Please let me know.
Warm regards,
Krishna.
On Tue, 20 Sep 2005, Mike Stump wrote:
# On Sep 19, 2005, at 10:36 PM, N V Krishna wrote:
# > When I try to compile something like:
# > foo(){
# > int a[] = {1,2};
# >
# >
# >
# > }
# >
# > gcc is combining them into a double (DImode) and handling as such.
# > Is there a switch by which I can direct gcc not to do so? I am
# > using gcc 2.95.2.
#
# Side note, we aren't going to support 2.95.2 much around here...
#
# You didn't even tell us the target...
#
# Base upon what you've said so far, the answer is no.
#
# Also, you used the wrong like, gcc-help is the correct list to use.
#
reg_used_between_p vs. CLOBBER
reg_used_between_p checks the CALL_INSN_FUNCTION_USAGE of a CALL_INSN for CLOBBERS. I think it shouldn't; we are interested in uses, not sets/ clobbers.
Segmentation Fault building GCC for i686-pc-mingw32
I'm getting a segmentation fault in the GCC build from today's CVS HEAD. I am building the suite for mingw using a cross compiler from Linux. This setup was working fine prior to updating to the latest CVS head today. My old sources, which were working correctly, were from 9/1/2005. In both cases, I had applied patch-rev4.diff from bug 21766 prior to building. If I disable optimizations by removing -O2 arguments and rerunning the command manually, the file compiles without error. Let me know if there is anything else that I can provide to help nail down this problem. Thanks. TJ - make[2]: Entering directory `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' /bin/sh ./libtool --mode=compile i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include -c -o mark_rts.lo /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I/home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -O2 -g0 -pipe -fexceptions -Iinclude -I././targ-include -I.//libc/include -c /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c -DDLL_EXPORT -DPIC -o .libs/mark_rts.o /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: In function 'GC_approx_sp': /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:379: warning: function returns address of local variable /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c: In function 'GC_add_roots_inner': /home/tlaurenzo/gcc_build/gcjhcross/src/gcc-4.1-head/boehm-gc/mark_rts.c:175: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [mark_rts.lo] Error 1 make[2]: Leaving directory `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tlaurenzo/gcc_build/gcjhcross/build/gcc-4.1-head-i686-pc-mingw32/i686-pc-mingw32/boehm-gc' make: *** [all-target-boehm-gc] Error 2 -
gcc-3.4-20050920 is now available
Snapshot gcc-3.4-20050920 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050920/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050920 You'll find: gcc-3.4-20050920.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050920.tar.bz2 C front end and core compiler gcc-ada-3.4-20050920.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050920.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050920.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050920.tar.bz2 Java front end and runtime gcc-objc-3.4-20050920.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050920.tar.bz2The GCC testsuite Diffs from 3.4-20050913 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: proposed Opengroup action for c99 command (XCU ERN 76)
Paul Eggert writes: > Would this weaker action pose an undue burden on GCC? My sense from > the discussion is "no", but I'd like to double-check with the experts I'd say "no", but I think the experts might see it as posing no burden at all on GCC. The burden would be on whomever wants to use GCC to implement the c99 command. Ross Ridge
Problem with gcc 4.0.1
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under "gcc version 3.4.3"
Any recommended work-arounds?
= code fragment==
#ifndef __LOC_PV_FACTORY_H__
#define __LOC_PV_FACTORY_H__
line 10 --> #include "pv_factory.h"
line 11 -->
line 12 --> class LOC_PV_Factory : public PV_Factory
line 13 --> {
line 14 --> public:
line 15 --> LOC_PV_Factory();
line 16 --> ~LOC_PV_Factory();
line 17 --> ProcessVariable *create(const char *PV_name);
line 18 --> private:
line 19 --> friend class LOC_ProcessVariable;
line 20 --> static void forget(LOC_ProcessVariable *pv);
line 21 --> };
=
Here is the error and it only happens under gcc 4.0.1:
-I/usr/X11R6/include/X11../loc_pv_factory.cc
../loc_pv_factory.h:20: error: ‘LOC_ProcessVariable’ has not been
declared
../loc_pv_factory.cc:118: error: prototype for ‘void
LOC_PV_Factory::forget(LOC_ProcessVariable*)’ does not match any in
class ‘LOC_PV_Factory’
../loc_pv_factory.h:20: error: candidate is: static void
LOC_PV_Factory::forget(int*)
../loc_pv_factory.cc: In destructor ‘virtual
LOC_ProcessVariable::~LOC_ProcessVariable()’:
../loc_pv_factory.cc:257: error: cannot call member function ‘void
LOC_PV_Factory::forget(LOC_ProcessVariable*)’ without object
make[1]: *** [loc_pv_factory.o] Error 1
make[1]: Leaving directory
`/ade/epics/supTop/extensions/src/edm/lib/O.linux-x86'
make: *** [install.linux-x86] Error 2
[EMAIL PROTECTED] lib]$
^
Thanks,
Ernesto
Final GCC 4.0.2 Code Freeze
As of now, the GCC 4.0 branch is completely frozen for the GCC 4.0.2 release. The release will be announced as soon as it has had time to propagate to the various FTP mirror sites. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Warning C vs C++
Per Abrahamsen wrote: > A -Weverything that turned on all boolean warnings would be nice. It > would be useless alone, but nice followed by a lot of > -Wno-somesillywarning -Wno-anothersillywarning arguments. I agree. I acknowledge that it would be useless in the general sense (you couldn't use it in Makefiles), but it would be nice to be able to use such an option for time to time to audit the code in the way that you might use lint(1). Ben
make distclean can not remove intl/config.cache
Make distclean can not remove intl/config.cache and fixincludes/config.cache. The configure commandline I used in GCC building is ../gcc-dfp-cvs-Aung-10/configure --enable-languages=c --enable-shared --enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit -with-cpu=default32 --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --with-as=/home/qiyao/binutils/binutils_build/gas/as-new --with-ld=/home/qiyao/binutils/binutils_build/ld/ld-new I think these two cache files should be removed when make distclean, but I am not sure about it, would anyone like to take some look? Any suggestion and comments are highly appreciated! May I code a patch on this? -- Regards, Yao Yao Qi
