RE: I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
Thanx, this paper is helpful and shows what I expected. But I still have a problem about va-argument-passing. The MS compiler reserves stack space for all may va-callable methods register arguments. So far, good. This means for GCC setting up REG_PARM_STACK_SPACE to the value of a stack argument (8 bytes). But MS saves also space for all may argument registers on stack, not just for the used one - as gcc does. So is there allready a mechanism in gcc, by whom I can reserve for all methods simple space on stack for the 4 used register parameters, even if they are not used for argument passing ? Regards, i.A. Kai Tietz
RE: Auto Vectorizing help needed
[EMAIL PROTECTED] wrote on 26/02/2007 10:40:59: >I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector >instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit >additions, subtractions, multiplications & shift operations simultaneously. >I would like to use the Auto-Vectorizing capability to generate these >instructions. Is there an existing backend that I could look at for >something similar? Any help will be greatly appreciated. Maybe Dorit's lecture from the last HiPEAC GCC tutorial can help you: http://www.hipeac.net/system/files?file=4_Nuzman.ppt I think slides 14-18 are most relevant for you. Good luck, Tehila. >SD
Re: warning: source missing a mode?
Hello,
thanks for reply. I was reading and comparing machine description files
from other backends. Now I am using a template like this:
---snip---
(define_insn "call_value"
[(parallel [(set (match_operand 0 "" "")
(call (mem:QI (match_operand:QI 1 sym_ref_mem_operand"
""))
(match_operand:SI 2 "" "")))
(clobber (reg:SI 31))])]
""
"jal\\t%S0%("
[(set_attr "type" "jump")
(set_attr "mode" "none")])
---snap---
This pattern matches for function calls but unfortunately now I get a
segmentation fault during compilation of the following program:
---snip---
int odd(int i)
{
return i & 0x1;
}
int
foo(int i, int j)
{
int a;
a=odd(i+j);
return a;
}
---snap---
The segmentation fault occurs in the last line of the foo()-function.
Any suggestions?
Regards and thanks for any comments,
Markus
Richard Henderson wrote:
> On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote:
>
>>;; calls that return int in r1
>>;;
>>(define_insn "call_val_internal_return_r1"
>>[(parallel [(set (reg:SI 1)
>> (call (match_operand:QI 0 "sym_ref_mem_operand" "")
>
>
> Why would you have a specific pattern for (reg:SI 1) as
> the return value? I suggest you look at other ports for
> guidence here. Normal is something like
>
>
> (define_insn "*call_value_1"
> [(set (match_operand 0 "" "")
> (call (mem:QI (match_operand:SI 1 "call_insn_operand" "rsm"))
> (match_operand:SI 2 "" "")))]
> ...)
>
> where both the return value and the call have no mode specified.
>
>
>
> r~
>
--
Nichts ist so praktisch wie eine gute Theorie!
getting spam
Hi. These days I began to get spam in my mail box. I found, that my mail address ([EMAIL PROTECTED]) is published on : http://gcc.gnu.org/ml/gcc/2006-08/msg00227.html Please, remove it from there, thanks.
Re: RS6000 call pattern clobbers
> The patterns clobber and use the rs6000 link register as a match_scratch > with constraint of the link register class: > >(clobber (match_scratch:SI 0 "=l")) > > instead of clobbering the link register hard register directly in the > early insn generation. This style dates to the original rs6000 port. A > naked use that starts as a pseudo causes problems for dataflow. > > Do you remember why you wrote the call patterns this way? Was > there a problem with reload and clobbers of hard registers in a register > class containing a single register or some other historical quirk? I think the former. I no longer remember the details, but if you had a clobber of a hard reg, there were a number of things that such a hard reg couldn't be used for (this is where the details are murky) and in order to avoid that problem a match_scratch was used to delay the explicit hard register usage as long as possible.
Re: GCC 4.3 Stage 1 project survey
Hello, > I've been trying to keep the GCC_4.3_Release_Planning wiki page up to > date, and I'd like to be sure I haven't missed anything going in. I've > moved several projects to the Completed section, and if I've done > anything in error there, please correct it. > > So here's a survey of what's left: > > * PredictiveCommoning > > I can't tell for sure, as Zdenek commits so many patches ;-) It seems > that this one is not merged yet. the final version of the patch is at http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01385.html waiting for review. Zdenek
Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch
H. J. Lu wrote: We are working on complete data of SPEC CPU 2K/2006 on Core 2 Duo. It will take about a week. There are results' comparison I got for gcc 4.2 revisions 117890, 117891 and 121952 on SPEC CPU2K/2006 SPEC CPU2000: 117891 vs 117890 121952 vs 117890 164.gzip-0.1%0.0% 175.vpr -0.1%0.8% 176.gcc -0.1% -0.3% 181.mcf -0.4% -1.3% 186.crafty -0.8% -0.8% 197.parser -0.2% -0.1% 252.eon 0.5%0.2% 253.perlbmk -0.8%0.1% 254.gap -2.5% -0.7% 255.vortex -0.6% -0.2% 256.bzip2 -1.1%0.1% 300.twolf -0.5%0.0% SPECint_base2000-0.5% -0.2% 168.wupwise 0.0% -0.6% 171.swim 0.8%0.8% 172.mgrid0.0% -0.1% 173.applu0.5%2.6% 177.mesa-0.4%0.0% 178.galgel 0.0% -0.1% 179.art -0.4%0.1% 183.equake 0.0% -0.2% 187.facerec -0.1%0.1% 188.ammp 0.1%0.1% 189.lucas0.0%0.0% 191.fma3d -1.3% -2.3% 200.sixtrack-0.1%0.2% 301.apsi 0.1%0.3% SPECfp_base2000 -0.1%0.1% SPEC CPU2006 117891 vs 117890 121952 vs 117890 400.perlbench0.0% -0.6% 401.bzip20.7%0.0% 403.gcc 0.9%0.9% 429.mcf -0.7%0.0% 445.gobmk1.4%0.7% 456.hmmer1.0%1.0% 458.sjeng -1.4% -0.7% 462.libquantum -1.6%0.0% 464.h264ref -0.5%0.5% 471.omnetpp 0.9%0.9% 473.astar0.0% -1.0% 483.xalancbmk -0.1%0.4% SPECint_base2006 0.0%0.8% 410.bwaves 0.5%0.4% 416.gamess 0.0% -0.8% 433.milc 0.0%0.0% 434.zeusmp 0.0%0.0% 435.gromacs 0.1%0.0% 436.cactusADM -0.1% -0.1% 437.leslie3d -30.1% -30.3% 444.namd 0.0%0.0% 447.dealII 0.0% -1.4% 450.soplex 0.0%0.7% 453.povray -0.6% -2.5% 454.calculix 0.0% -0.4% 459.GemsFDTD -18.6% -18.7% 465.tonto -1.8% -0.9% 470.lbm 0.0%0.0% 481.wrf -0.6% -0.3% 482.sphinx3 0.0%0.0% SPECfp_base2006 -3.5% -3.5% Denis
Generate -zero RTX expression
Hello, I appreciate it if someone could tell me how I can create a -0 RTX expression (like CONST0_RTX)? Thanks, Revital
Re: getting spam
Alexander wrote: Hi. These days I began to get spam in my mail box. I found, that my mail address ([EMAIL PROTECTED]) is published on : http://gcc.gnu.org/ml/gcc/2006-08/msg00227.html Please, remove it from there, thanks. And now it is here also: http://gcc.gnu.org/ml/gcc/2007-02/msg00606.html But this time it is not mangled because you put it in the body of the message. These are public mailing lists. They are archived in many places. It is not possible to cancel/remove a message once it has been sent. David Daney
Re: I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
On Mon, Feb 26, 2007 at 09:40:59AM +0100, Kai Tietz wrote: > So is there allready a mechanism in gcc, by whom I can reserve for all > methods simple space on stack for the 4 used register parameters, even if > they are not used for argument passing ? See sparc.h. r~
Re: RS6000 call pattern clobbers
> > Do you remember why you wrote the call patterns this way? Was > > there a problem with reload and clobbers of hard registers in a register > > class containing a single register or some other historical quirk? > > I think the former. I no longer remember the details, but if you had > a clobber of a hard reg, there were a number of things that such a hard > reg couldn't be used for (this is where the details are murky) and in order > to avoid that problem a match_scratch was used to delay the explicit hard > register usage as long as possible. Actually, this depended on SMALL_REGISTER_CLASSES. If the target was not marked has having SMALL_REGISTER_CLASSES, any explicitly used hard register would not be used for register and/or spill allocations anywhere in the function.
Re: Running GCC tests on installed compiler
[ gcc -> gcc-patches ]
Dominique,
thanks a lot for your patch. I have tested this on i686-suse-linux,
comparing the output of contrib/test_installed both before and after
your patch and committed it with the following ChangeLog entry:
2007-02-26 Dominique Dhumieres <[EMAIL PROTECTED]>
* test_installed: Adjust to the move from g77 to gfortran.
Find the committed patch at the end of this message.
On Sat, 20 Jan 2007, Dominique Dhumieres wrote:
> If this is OK along with no copyright assignment, I can submit a PR.
> The copyright should probably extended to 2007. I think also than one
> should notify Alexandre Oliva.
You're right, I don't think this requires a copyright assignment. As
you indicated, I updated the coypright year and am also Cc:ing Alexandre.
>> The latter, I believe. Do you think you could provide a patch against
>> gcc/doc/install.texi? ;-) I'll be happy to work with you on this if
>> contributing to GCC is an option for you.
> This part is trickier. First I'll have to learn the basics of texi, since
> I have never used it. Second I am afraid to be writing challenged. Third
> I don't have much time to overcome these shortcomings.
> [...]
> My guess is that people interested by postinstall testing will be
> able to run the script from its comments and, if I am wrong, feedback will
> help to put the entry in better shape.
That's a good point. I'll see what I can do about the documentation
and try to carve up a patch.
Thanks for your help here!
Gerald
Index: test_installed
===
--- test_installed (revision 122322)
+++ test_installed (working copy)
@@ -1,6 +1,6 @@
#! /bin/sh
-# (C) 1998, 2000, 2002, 2003 Free Software Foundation
+# (C) 1998, 2000, 2002, 2003, 2007 Free Software Foundation
# Originally by Alexandre Oliva <[EMAIL PROTECTED]>
# This script is Free Software, and it can be copied, distributed and
@@ -16,12 +16,12 @@
# will be appended to the srcdir.
# You may specify where the binaries to be tested should be picked up
-# from. If you specify --prefix=/some/dir, gcc, g++ and g77 will be
+# from. If you specify --prefix=/some/dir, gcc, g++ and gfortran will be
# looked for at /some/dir/bin. Each one may be overridden by
# specifying --with-gcc=/pathname/to/gcc, --with-g++=/pathname/to/g++
-# and --with-g77=/pathname/to/g77. If you specify --without-gcc,
-# --without-g++ or --without-g77, the test for the specified program
-# will be skipped. By default, gcc, g++ and g77 will be searched in
+# and --with-gfortran=/pathname/to/gfortran. If you specify --without-gcc,
+# --without-g++ or --without-gfortran, the test for the specified program
+# will be skipped. By default, gcc, g++ and gfortran will be searched in
# the PATH.
# An additional argument may specify --tmpdir=/some/dir; by default,
@@ -50,16 +50,16 @@
--prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
- --with-g77=*) G77_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
+ --with-gfortran=*) GFORTRAN_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`;
shift;;
--without-gcc) GCC_UNDER_TEST=no; shift;;
--without-g++) GXX_UNDER_TEST=no; shift;;
- --without-g77) G77_UNDER_TEST=no; shift;;
+ --without-gfortran) GFORTRAN_UNDER_TEST=no; shift;;
--without-objc) OBJC_UNDER_TEST=no; shift;;
--tmpdir=*) tmpdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--help) cat <<\EOF
-Runs the testsuite for an installed version of gcc/g++/g77/objc
+Runs the testsuite for an installed version of gcc/g++/gfortran/objc
Copyright (C) 1998 Free Software Foundation
by Alexandre Oliva <[EMAIL PROTECTED]>
@@ -71,13 +71,13 @@
--srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
[deduced from shell-script pathname]
---prefix=/some/diruse gcc, g++ and g77 from /some/dir/bin [PATH]
+--prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin
[PATH]
--with-gcc=/some/dir/bin/gcc use specified gcc program [gcc]
--with-g++=/some/dir/bin/g++ use specified g++ program [g++]
---with-g77=/some/dir/bin/g77 use specified g77 program [g77]
+--with-gfortran=/some/dir/bin/gfortran use specified gfortran program
[gfortran]
--without-gcc do not run gcc testsuite
--without-g++ do not run g++ testsuite
---without-g77 do not run g77 testsuite
+--without-gfortrando not run gfortran testsuite
--without-objcdo not run objc testsuite
--tmpdir=/some/dircreate temporaries and leave failed programs
@@ -109,13 +109,13 @@
set CXXFLAGS ""
set GCC_UNDER_TEST "${GCC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
set GXX_UNDER_TEST "${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
-set G77_UNDER_TEST "${G77_UNDER_T
store_expr, expr_size, and C++
I am looking at PR target/30826 (an IA64 ABI bug) and have come up with a patch that basically involves turning off the CALL_EXPR_RETURN_SLOT_OPT optimization in some instances and forcing GCC to create a temporary for the (large aggragete) return value of a function and then copying that temporary value to the desired target. The problem I am running into is with C++ code in store_expr. I get to this if statement: if ((! rtx_equal_p (temp, target) || (temp != target && (side_effects_p (temp) || side_effects_p (target && TREE_CODE (exp) != ERROR_MARK /* If store_expr stores a DECL whose DECL_RTL(exp) == TARGET, but TARGET is not valid memory reference, TEMP will differ from TARGET although it is really the same location. */ && !(alt_rtl && rtx_equal_p (alt_rtl, target)) /* If there's nothing to copy, don't bother. Don't call expr_size unless necessary, because some front-ends (C++) expr_size-hook must not be given objects that are not supposed to be bit-copied or bit-initialized. */ && expr_size (exp) != const0_rtx) and I hit a gcc_assert when calling expr_size(). Even if I avoided this somehow I would hit it later when calling: emit_block_move (target, temp, expr_size (exp), (call_param_p ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL)); So my question is: is there a way to handle this copy/assignment in C++ without depending on expr_size. I noticed PR middle-end/30017 (turning memcpys into assignments) which seems to have some of the same issues of getting expr_size for C++ expressions but that defect is still open so it doesn't look like there is an answer yet. Anyone have some ideas on this problem? Steve Ellcey [EMAIL PROTECTED]
gcc-4.1-20070226 is now available
Snapshot gcc-4.1-20070226 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070226/ 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 122345 You'll find: gcc-4.1-20070226.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070226.tar.bz2 C front end and core compiler gcc-ada-4.1-20070226.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070226.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070226.tar.bz2 C++ front end and runtime gcc-java-4.1-20070226.tar.bz2 Java front end and runtime gcc-objc-4.1-20070226.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070226.tar.bz2The GCC testsuite Diffs from 4.1-20070219 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: I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
Kai Tietz writes: >But I still have a problem about va-argument-passing. The MS compiler >reserves stack space for all may va-callable methods register arguments. Passing arguments to functions with variable arguments isn't a special case here. According to Microsoft's documentation, you always need to allocate space for 4 arguments. The only thing different you need to do with functions taking variable arguments (and unprototyped functions) is to pass floating point values both in the integer and floating point registers for that argument. Ross Ridge
Re: store_expr, expr_size, and C++
On Mon, Feb 26, 2007 at 02:04:36PM -0800, Steve Ellcey wrote: > I am looking at PR target/30826 (an IA64 ABI bug) and have come up with > a patch that basically involves turning off the > CALL_EXPR_RETURN_SLOT_OPT optimization in some instances and forcing GCC > to create a temporary for the (large aggragete) return value of a > function and then copying that temporary value to the desired target. Which is simply not possible in general for C++. You can't solve the problem this way. I think the ABI requirement for 16-byte alignment for structs that don't ordinarily require them is a bit odd. You'll have to relax this for C++ non-POD data, as it simply cannot be provided in some cases. You can tell this with TREE_ADDRESSABLE set on the type node. For other cases, you may be able to promote a local temporary to 16 byte alignment rather than disable the return slot opt. r~
Re: RS6000 call pattern clobbers
> Actually, this depended on SMALL_REGISTER_CLASSES. If the target was not > marked has having SMALL_REGISTER_CLASSES, any explicitly used hard register > would not be used for register and/or spill allocations anywhere in the > function. That's one issue, but I'm not sure is the only one. Also note that the RS/6000 port predated SMALL_REGISTER_CLASS, though it would take some significant archeology to determine when the line in question was added.
Why use pentium4 for Pentium M?
Hi, -march=native choose pentium4 instead of pentium-m for Pentium M processors (see config/i386/driver-i386.c)? Is this intentional or a typo? -- Zuxy
Re: Porting GCC to new architecture
Alexandre Tzannes <[EMAIL PROTECTED]> writes: > I'm Alex Tzannes and I am porting GCC 4.0.2 to a new experimental parallel > architecture. Here's one issue I don't know how to go about. The ISA of > our machine is based on MIPS (so I made a copy of the MIPS back end and > have been modifying that). One conceptual difference is that the machine > can be either in serial mode or in parallel mode. The switch from serial > to parallel happens with a 'spawn' instruction, and the swich from > parallel to serial with a 'join' instruction. This is important because > the ISA instructions that can be used in serial and in parallel mode are > different ! > > For example let's say mvtg is an instruction that can only be used in > 'serial mode'. I currently have a template in the back end (.md file) that > generates that instruction when it is needed. The only thing I don't know > how to check is that it is only generated in serial mode. > > Instruction attributes do not seem like the solution because there seems > to be no other way to set them besides in the RTL rules in the .md file > (which is too late; I would want to read the information at that point). > > Is there a way to annotate each RTL instruction and to check that during > code generation ? Has a similar problem been solved in some other > back-end? I don't think I've ever seen a machine with these characteristics. One way to make this work would be to use the OPTIMIZE_MODE_SWITCHING support. You would need to add an attribute for each instruction indicating which mode it requires (presumably most instructions would use the default value). Then define MODE_NEEDED, etc., to indicate the mode. Use EMIT_MODE_SET to generate the spawn or join insn. You would have to make the spawn/join insn an UNSPEC_VOLATILE so that the scheduler would not move insns across them. Good luck. Ian
Re: Strange behavior for scan-tree-dump testing
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> /* { dg-final { scan-tree-dump "b4 = 6.3e+1" "gimple" } } */
Note that scan-tree-dump takes a regular expression. So you are
looking for '6' followed by any character followed by '3' followed by
one or more 'e's followed by '1'.
Ian
Re: Generate -zero RTX expression
Revital1 Eres <[EMAIL PROTECTED]> writes: > I appreciate it if someone could tell me how I can create a -0 RTX > expression (like CONST0_RTX)? The easy way is something along the lines of: simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode) Ian
Re: Why use pentium4 for Pentium M?
Zuxy Meng wrote: Hi, -march=native choose pentium4 instead of pentium-m for Pentium M processors (see config/i386/driver-i386.c)? Is this intentional or a typo? I think the reason is that Intel changed completely the microarchitecture (going back to something that actually is more similar to Pentium III's) without bumping the number returned by CPUID (or without going back to the P3's number, 6). Paolo
Re: Why use pentium4 for Pentium M?
On Tue, Feb 27, 2007 at 12:30:16PM +0800, Zuxy Meng wrote: > Hi, > > -march=native choose pentium4 instead of pentium-m for Pentium M processors > (see config/i386/driver-i386.c)? Is this intentional or a typo? > It is because Pentium M implements Pentium instructions. You should get: bash-3.00$ /usr/gcc-4.3/bin/gcc -march=native x.i -S -v ... /usr/gcc-4.3/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -fpreprocessed x.i -march=pentium4 -mtune=generic -quiet -dumpbase x.i -auxbase x -version -o x.s H.J.
