jue*sts6sjuest
密?要保存好。 1cb http://koso.co.kr u2h 密?：ok wqr http://koso.co.kr/dhcp gdk 密?:ok oh2
Build report for gcc 4.1.1 on hppa2.0w
Output from gcc -v Using built-in specs. Target: hppa2.0w-hp-hpux11.00 Configured with: ../gcc-4.1.1/configure --prefix=/opt/local --with-local-prefix=/opt/local --with-gnu-as=/opt/local/bin/as --with-gmp=/opt/local Thread model: single gcc version 4.1.1 Languages built: c,c++,fortran,java,objc Host/Target specific notes: 1. The current host/target-specific notes state that gcc 2.95.x cannot be used to compile gcc 3.0 and up. However, I successfully bootstrapped gcc-4.1.1 using gcc-2.95.2. 2. I used gmp-4.2.1 and mpfr-2.2.0 (patch 16). On this platform mpfr-2.2.0 additionally needs a patched mpfr-longlong.h, otherwise 'make check' fails. This has been kindly provided on the mpfr download pages. Future versions will include the correction. 3. The gnu linker is not supported on this platform, but the gnu assembler is. So gcc has to be built --with-gnu-as but the standard HP linker. 4. If makeinfo is missing from the system, 'make install' fails in the fastjar/ subdirectory. You need to 'touch fastjar/fastjar.info' to continue. Regards, -- [EMAIL PROTECTED]
Volatile / TREE_THIS_VOLATILE question
Hi,
if I dump the tree of the following C program,
int main() { volatile int i; i = 5; return 0; }
I get (-tree-original):
{
volatile int i;
volatile int i;
i = 5;
return 0;
}
However, if I apply my volatile-in-Fortran patch [1] and compile
integer, volatile :: i; i = 5; end
then the dumped tree contains:
{
int4 i;
_gfortran_set_std (70, 127, 0);
i = 5;
}
I use in my patch:
+ if (sym->attr.volatile_)
+ TREE_THIS_VOLATILE (decl) = 1;
Question:
- Is TREE_THIS_VOLATILE the right thing to do?
- How do I see (tree dump etc.) whether I did the right change?
Tobias
PS: I sneaked at g95 and there Andy also uses TREE_THIS_VOLATILE; g95
-fdump-tree-original has also no "volatile".
[1] http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01601.html
Re: Abt RTL expression - Optimization
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> The relevant part of RTL dump of fgcse pass is given below:
>
> (insn 13 12 50 0 (set (reg:CC 21 cc)
> (compare:CC (reg:SI 29 [ n ])
> (const_int 30 [0x1e]))) 68 {*cmpsi_internal} (nil)
> (nil))
>
> (insn 50 13 53 0 (parallel [
> (set (reg/f:SI 38)
> (symbol_ref:SI ("p") ))
> (clobber (reg:CC 21 cc))
> ]) 22 {movsi_long_const} (nil)
> (nil))
>
> (insn 53 50 14 0 (parallel [
> (set (reg/f:SI 39)
> (symbol_ref:SI ("k") ))
> (clobber (reg:CC 21 cc))
> ]) 22 {movsi_long_const} (nil)
> (nil))
>
> (jump_insn 14 53 16 0 (set (pc)
> (if_then_else (gtu:CC (reg:CC 21 cc)
> (const_int 0 [0x0]))
> (label_ref 27)
> (pc))) 41 {*branch_true} (nil)
> (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
> (nil)))
>
> 1. In Insn 13, the compiler uses the CC Reg instead of "h". Then the
> compiler inserted to movsi_long_const inbetween the compare and the
> if_then_else. BUT the movsi_long_const destroys the condition code
> register CC .As the optimizer considers CC dead due to the
> clobber(reg:CC 21 cc)) it removes the first pattern actually setting
> CC. It gets deleted later.
Thanks for finally giving the complete program and the RTL.
I think you said earlier that this is a private target, not a standard
gcc target. On that basis, I would say that the problem appears to be
that you have a cc0 machine of a type which gcc does not handle
naturally.
If your comparison instructions set a fixed hard register, and simple
register to register moves clobber that hard register, then you must
handle comparison instructions specially before reload. You must emit
a combined compare_and_branch instruction, which does the comparison
and the branch in a single insn. Then you may write a define_split
which runs after reload and splits the instruction back into its
components for the second scheduling pass.
You've encountered a somewhat subtle way in which gcc fails if you
don't do this. There a much more obvious it will fail: reload will
wind up clobbering the condition register every time it has to load or
store a register.
Writing the patterns to avoid using the fixed condition register
before reload is tedious but typically not difficult. Writing the
define_splits which run after reload is typically more complicated.
Note that in general the define_splits are only useful if scheduling
helps your processor.
The C4X is an example of a standard target which has some of these
issues.
(In fairness I should say that there is an alternative, which is to
use (cc0) for the condition register. But I do not recommend this, as
support for (cc0) may be removed from the compiler at some point in
the future.)
Ian
Re: Volatile / TREE_THIS_VOLATILE question
Tobias Burnus <[EMAIL PROTECTED]> writes: > I use in my patch: > + if (sym->attr.volatile_) > + TREE_THIS_VOLATILE (decl) = 1; I think you will also want to give DECL a type which is volatile-qualified: build_qualified_type (original_type, TYPE_QUAL_VOLATILE) Ian
Re: Mapping NAN to ZERO / When does gcc generate MOVcc and FCMOVcc instructions?
Michael James wrote: Hello, I am trying to get gcc to optimize an inner math loop. The first part of the loop computes a single precision float expression (which may or may not be NAN), and the second part sums all of these results into a double precision total: Conceptually, the code is: double sum = 0; for(i=0; i Forcing NANs to be zero may sound like a good idea, but it's better to force it to a small value. Some studies have shown that using zero tends to create more NANs in computations as results get closer and closer to zero, while substituting a small value results in convergence to representable values. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: regenerating configure in gcc
On Nov 1, 2006, at 7:56 AM, Jack Howarth wrote: autoreconf -I ../config In general, you will want to check the Makefile and see what it uses to run aclocal. In java for example, they use: ACLOCAL_AMFLAGS = -I . -I .. -I ../config So, in fact, I think you regenerated the file incorrectly. You will either want to --enable-maintainer-mode and use make to regenerate them or be careful in how you regenerate them (if you check in regenerated files). Each directory is randomly different. Side note, if you need config, then, you'd want to ensure that you add - I ../config to ACLOCAL_AMFLAGS if it doesn't already have it, so that the next person to regenerate the file doesn't `remove' your patches.
Re: Splay Tree
The original author of this patch said he sent his copyright assignment. I only did minor modification to his work so I don't I think I should send it too. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html I already did a bootstrap and check to be sure it worked right when I first sent my modifications. But now I did it against current head and I get this: # diff summary-log-normal summary-log-patched 108,110d107 < FAIL: PR27908 execution - source compiled test < FAIL: PR27908 -O3 execution - bytecode->native test < FAIL: SyncTest execution - gij test 114,115c111 < # of expected passes 7000 < # of unexpected failures 3 --- # of expected passes 7006 117c113 < # of untested testcases 11 --- # of untested testcases 8 # diff summary-log-normal2 summary-log-patched 100d99 < FAIL: libgomp.fortran/omp_parse3.f90 -O0 execution test 104,105c103 < # of expected passes 1543 < # of unexpected failures 1 --- # of expected passes 1544 110,111d107 < FAIL: SyncTest execution - gij test < FAIL: SyncTest execution - gij test 115,116c111 < # of expected passes 7002 < # of unexpected failures 2 --- # of expected passes 7006 118c113 < # of untested testcases 10 --- # of untested testcases 8 Results are better with this patch, but I dont think the improving its related. On Mon, 30 Oct 2006, DJ Delorie wrote: Could this patch be applied now? http://gcc.gnu.org/ml/gcc/2006-07/msg00210.html Assuming it's been bootstrapped with no regressions, and the legal paperwork is in place, yes.
Re: Mapping NAN to ZERO / When does gcc generate MOVcc and FCMOVcc instructions?
On 11/2/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
This testcase (similar to yours, but it actually compiles):
Hello,
Uros, thank you for the attention to my problem. I upgraded gcc to 4.2
and have been using -march=i686 instead of -march=pentium4 for my
tests now. gcc 4.2 resolved some but not all of my concerns. Please
see below.
double test(int n, double a)
{
double sum = 0.0;
int i;
for(i=0; i
I was unable to replicate your results with gcc 4.0.3, so I installed
gcc 4.2.0 20061103 (prerelease) from SVN. Using that, I am able to
replicate the loop above exactly with
-O2 -march=i686. It looks like gcc 4.2 is willing to do this
optimization; gcc 4.0 would not. :-)
logf() function will be inlined by specifying
-funsafe-math-optimizations, this flag also enables implicit
float->double extensions for x87 math. As you probably don't need math
errno from log(), -fno-math-errno should be added.
Those two flags produce IMO optimal loop:
.L5:
pushl %eax
fildl (%esp)
addl$4, %esp
fldln2
fxch%st(1)
fyl2x
fucomi %st(0), %st
fldz
fcmovnu %st(1), %st
fstp%st(1)
addl$1, %eax
cmpl%edx, %eax
faddp %st, %st(1)
jne .L5
I have been unable to replicate this result. Still, gcc 4.0.3 and gcc
4.2.0 completely omit the fucomi test and the associated semantics
with testing for NAN:
I compiled exactly the verbatim test case above, and compile using these flags:
-O2 -march=i686 -funsafe-math-optimizations -fno-math-errno
The loop I get is:
.L5:
pushl %eax
addl$1, %eax
fildl (%esp)
addl$4, %esp
cmpl%edx, %eax
fldln2
fxch%st(1)
fyl2x
faddp %st, %st(1)
jne .L5
Now, for this particular code, that loop may be considered a valid
optimization because log can not produce NAN from a non-negative
parameter. To be sure, I then modified the code as follows:
double test(int i0, int n, double a)
{
double sum = 0.0;
int i;
for(i=i0; i,
. I get the same results either way.
Again, help is appreciated. -- Thanks.
Regards,
Michael James
Why doesn't libgcc define _chkstk on MinGW?
This may be a FAQ, but I was unable to find the answer on the web, so I hope people will forgive me asking it here. I recently tried to use a MinGW GCC (built from FSF sources) to link with a .lib file that had been compiled with MSVC, and got link-time errors about _chkstk. After some searching, I understand what this function is for (it's a stack-probing thing that MSVC generates when allocating big stack frames), and that GCC has an equivalent in libgcc (called _alloca). There also seems to be widespread belief that in fact the libgcc routine is compatible with _chkstk. And, there are lots of people that have reported link failures involving _chkstk. So, my (perhaps naive) question is: why don't we define _chkstk as an alias for _alloca in MinGW, so that we can link with these MSVC libraries? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Mapping NAN to ZERO / When does gcc generate MOVcc and FCMOVcc instructions?
Michael James wrote:
And recompiled with the same flags. The assembly code for the loop
portion is identical to the one I posted above. Now though the code is
actually capable of producing NANs.
Just to be sure, I also tested this on my modified loop:
int main(void) {
printf("test(4, 6, 0) = %f\n", test(4,6,0));
printf("test(0, 2, 0) = %f\n", test(0,2,0));
printf("test(-2, 3, 0) = %f\n", test(-2,3,0));
return 0;
}
[EMAIL PROTECTED]:~/project/cf/util$ /home/james/local/gcc/bin/gcc -O2
-march=i686 -funsafe-math-optimizations -fno-math-errno uros-test.c -o
test
[EMAIL PROTECTED]:~/project/cf/util$ ./test
test(4, 6, 0) = 2.995732
test(0, 2, 0) = -inf
test(-2, 3, 0) = nan
[EMAIL PROTECTED]:~/project/cf/util$ /home/james/local/gcc/bin/gcc -O2
-march=i686 uros-test.c -o test -lm
[EMAIL PROTECTED]:~/project/cf/util$ ./uros
test(4, 6, 0) = 2.995732
test(0, 2, 0) = -inf
test(-2, 3, 0) = -inf
[EMAIL PROTECTED]:~/project/cf/util$ /home/james/local/gcc/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4-2/configure --prefix=/home/james/local/gcc
Thread model: posix
gcc version 4.2.0 20061103 (prerelease)
Perhaps I have not replicated your working environment closely enough,
or you have a different macro in place of the isnan call. I compiled
all code above both with and without include headers ,
. I get the same results either way.
No, I'm working with gcc version 4.3.0 20061103 (experimental), and the
results are as expected:
gcc -O2 -funsafe-math-optimizations -fno-math-errno -march=i686
-mfpmath=387 -m32 mj.c
[-m32 is not needed on 32bit compiler]
test(4, 6, 0) = 2.995732
test(0, 2, 0) = -inf
test(-2, 3, 0) = -inf
This is the exact testcase I used:
--cut here--
double test(int i0, int n, double a)
{
double sum = 0.0;
int i;
for(i=i0; iInspecting the code, there is fucomi insn present just after "log" insn
sequence.
Unfortunatelly, I have no 4.2 installed here, but it looks like a bug to
me. Perhaps could you open a bugreport for this issue?
Thanks,
Uros.
gcc-4.1-20061103 is now available
Snapshot gcc-4.1-20061103 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061103/ 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 118465 You'll find: gcc-4.1-20061103.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20061103.tar.bz2 C front end and core compiler gcc-ada-4.1-20061103.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20061103.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20061103.tar.bz2 C++ front end and runtime gcc-java-4.1-20061103.tar.bz2 Java front end and runtime gcc-objc-4.1-20061103.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20061103.tar.bz2The GCC testsuite Diffs from 4.1-20061027 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: Why doesn't libgcc define _chkstk on MinGW?
Mark Mitchell wrote: >So, my (perhaps naive) question is: why don't we define _chkstk as an >alias for _alloca in MinGW, so that we can link with these MSVC libraries? It defines __chkstk as an alias for _alloca instead. My guess is that this is a mistake. There are other MSC library functions that MinGW doesn't provide, so other libraries may not link even with a _chkstk alias. Ross Ridge
Re: Why doesn't libgcc define _chkstk on MinGW?
Ross Ridge wrote: There are other MSC library functions that MinGW doesn't provide, so other libraries may not link even with a _chkstk alias. Got a list? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Why doesn't libgcc define _chkstk on MinGW?
[Resend] From: Mark Mitchell Sent: Saturday, 4 November 2006 9:28 a.m. > > I recently tried to use a MinGW GCC (built from FSF sources) to link > with a .lib file that had been compiled with MSVC, and got link-time > errors about _chkstk. After some searching, I understand what this > function is for (it's a stack-probing thing that MSVC generates when > allocating big stack frames), and that GCC has an equivalent > in libgcc > (called _alloca). There also seems to be widespread belief > that in fact > the libgcc routine is compatible with _chkstk. That's what my experience indicates. And, there > are lots of > people that have reported link failures involving _chkstk. > > So, my (perhaps naive) question is: why don't we define _chkstk as an > alias for _alloca in MinGW, so that we can link with these > MSVC libraries? > I have also run into converse problem -- using GCC-compiled static libs in MSVC projects and getting an undefined reference to libgcc's _alloca. Now there is an _alloca exported from win32api libs, but it really is alloca rather than a helper function _alloca_probe/_chkstk, so libgcc's symbol does have an unfortunate name. I see no reason why we can't use more MSVC-compatible aliases. Danny > Thanks, > > -- > Mark Mitchell
