Keyword _Imaginary in C99 standard and in GCC
Hi, everyone, I have looked through C99 standard, in 6.4.1 Keywords, "_Imaginary" is mentioned as a keyword in this standard. However, it seems that GCC can not recognize it, report error: '_Imaginary' undeclared. I also search it in GCC info, there is no spot mentioned that. Maybe GCC does not include it as a keyword, I am not sure about that, am I missing something? Maybe someone of you could clarify for me. Thanks in advance. Best Regards ---- Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Keyword _Imaginary in C99 standard and in GCC
From: Andrew Pinski <[EMAIL PROTECTED]> To: "Yao qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: Re: Keyword _Imaginary in C99 standard and in GCC Date: Thu, 18 Aug 2005 23:07:49 -0400 On Aug 18, 2005, at 11:04 PM, Yao qi wrote: Hi, everyone, I have looked through C99 standard, in 6.4.1 Keywords, "_Imaginary" is mentioned as a keyword in this standard. However, it seems that GCC can not recognize it, report error: '_Imaginary' undeclared. I also search it in GCC info, there is no spot mentioned that. Maybe GCC does not include it as a keyword, I am not sure about that, am I missing something? Maybe someone of you could clarify for me. Thanks in advance. _Imaginary types are not implemented yet in GCC. -- Pinski Thanks. That means GCC has not fully support C99, just partialy, am I right? I want to continue a question further, could you tell me where can I find a document about GCC's coverage in C99, if any? If there is no such document, I just have to collect these information by hand. Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Keyword _Imaginary in C99 standard and in GCC
Hi,Pinski, Got it! Thanks. Best Regards Yao Qi Bejing Institute of Technology From: Andrew Pinski <[EMAIL PROTECTED]> To: "Yao qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: Re: Keyword _Imaginary in C99 standard and in GCC Date: Thu, 18 Aug 2005 23:30:06 -0400 On Aug 18, 2005, at 11:25 PM, Yao qi wrote: Thanks. That means GCC has not fully support C99, just partialy, am I right? I want to continue a question further, could you tell me where can I find a document about GCC's coverage in C99, if any? http://gcc.gnu.org/c99status.html Note there is a DR report about _Imaginary types: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_207.htm -- Pinski _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: how to compile gcc
From: drizzle drizzle <[EMAIL PROTECTED]> To: Rafael Ávila de Espíndola <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: how to compile gcc Date: Sat, 20 Aug 2005 09:48:56 -0400 If you are objective is to debug gcc, then all the necessary setup is already done...Check this documentation http://gcc.gnu.org/wiki/DebuggingGCC. I have tried this method on wiki about GCC debugging. I am not sure about that and mail the procedure here to verify it, maybe someone of you could clarify for me. Thanks in advance. Here goes the my procedure on GCC debugging. 1 Generate preprocessed source code wiht option -E and redirect to a file named a.c.expand. 2 Debug cc1 by GDB with the arguments "-c a.c.expand" to cc1 Is this a reasonable procedure to debug GCC? Any suggestion and comments are highly appreciated! dz On 8/20/05, Rafael Ávila de Espíndola <[EMAIL PROTECTED]> wrote: > http://gcc.gnu.org/install/configure.html > look at --enable-checking > and > http://gcc.gnu.org/install/build.html > There are more cflags... > > The gcc/Makefile.in is also a good reference :) > > > Thanks, > > > > -Jiang > > > Rafael > Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: how to compile gcc
From: drizzle drizzle <[EMAIL PROTECTED]> To: Rafael Ávila de Espíndola <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: how to compile gcc Date: Sat, 20 Aug 2005 09:48:56 -0400 If you are objective is to debug gcc, then all the necessary setup is already done...Check this documentation http://gcc.gnu.org/wiki/DebuggingGCC. I have tried this method on wiki about GCC debugging. I am not sure about that and mail the procedure here to verify it, maybe someone of you could clarify for me. Thanks in advance. Here goes the my procedure on GCC debugging. 1 Generate preprocessed source code wiht option -E and redirect to a file named a.c.expand. 2 Debug cc1 by GDB with the arguments "-c a.c.expand" to cc1 Is this a reasonable procedure to debug GCC? Any suggestion and comments are highly appreciated! dz On 8/20/05, Rafael Ávila de Espíndola <[EMAIL PROTECTED]> wrote: > http://gcc.gnu.org/install/configure.html > look at --enable-checking > and > http://gcc.gnu.org/install/build.html > There are more cflags... > > The gcc/Makefile.in is also a good reference :) > > > Thanks, > > > > -Jiang > > > Rafael > Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: help on compile error (4.0.1)
Jiang Long wrote: Hello, I am compiling GCC-4.0.1 with the following : ../gcc-4.0.1/configure --enable-tree-browser=yes --prefix=/home/jiang/DEV/gcc-dev/trunk/install --enable-languages=c,c++ --enable-maintainer-mode=yes After a while I got the following errors with : Adding multilib support to Makefile in ../../../gcc-4.0.1/libmudflap multidirs= with_multisubdir= config.status: executing depfiles commands make[1]: Entering directory `/home/jiang/DEV/gcc-dev/trunk/obj/i686-pc-linux-gnu /libmudflap' cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4. 0.1/missing --run aclocal-1.9 -I .. -I ../config cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4 .0.1/missing --run automake-1.9 --foreign cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4. 0.1/missing --run autoconf /bin/sh ./config.status --recheck running /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4.0.1/libmudflap/configure -- cache-file=./config.cache --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --e nable-multilib --enable-tree-browser=yes --prefix=/home/jiang/DEV/gcc-dev/trunk/ install --with-cflags=-g3 -O0 --enable-maintainer-mode=yes --with-gcc-version-tr igger=/home/jiang/DEV/gcc-dev/trunk/gcc-4.0.1/gcc/version.c --enable-languages=c ,c++ --program-transform-name=s,y,y, --srcdir=../../../gcc-4.0.1/libmudflap --wi th-target-subdir=i686-pc-linux-gnu CPPFLAGS= build_alias=i686-pc-linux-gnu host_ alias=i686-pc-linux-gnu --no-create --no-recursion configure: loading cache ./config.cache configure: error: `target_alias' was not set in the previous run configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over make[1]: *** [config.status] Error 1 make[1]: Leaving directory `/home/jiang/DEV/gcc-dev/trunk/obj/i686-pc-linux-gnu/ libmudflap' make: *** [all-target-libmudflap] Error 2 Any suggestions? -Jiang I have met the same question. My solution to this is just to remove ./config.cache in every sub-directories and try again. This solution is effective although I am not sure about it. Anyone could confirm or deny this. I think "make distclean" should be done before ./configure if the option of configure is changed. -- Regards, Yao Yao Qi <[EMAIL PROTECTED]>
var_args for rs6000 backend
I am working on variable arguments on rs6000 backend and I have browsed gcc/config/rs6000/rs6000.c for several times, I found there are some functions relavtive to this issue, they are setup_incoming_varargs, rs6000_build_builtin_va_list ,rs6000_va_start ,rs6000_gimplify_va_arg . I could not know what they do just by source code. Could anybody tell me the relationship among these routines? I think it is important for me to understand the mechnism of GCC backend. Any comments or advice are highly appreciate. I do not know what is the precondation if I want to do it? May I need to know the architecture of PowerPC and ABI for it? Any one could clarify it for me. Thanks in advance! Best Regards Yao Qi Bejing Institute of Technology _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
A questions about NaN and Infinity in GCC
I am work on a floating points test according to IEEE754 and IEEE754 specifies
that seven invalid arithmetic operations shall deliver a NaN unless they are
trapped:
sqrt(Negative), 0*Infinity, 0.0/0.0, Infinity/Infinity, REMAINDER(Anything,0.0),
REMAINDER(Infinity, Anything), Infinity - Infinity.
I write a small case to verify part of this, and I list the source code here for
your reference,
1 #include
2
3 int main()
4 {
5 /* INF - INF => NaN. */
6 if ((__builtin_inf() - __builtin_inf()) != __builtin_nan(""))
7 printf("error 1\n");
8 /* 0 * INF => NaN. */
9 if ((0*__builtin_inf()) != __builtin_nan(""))
10 printf("error 2\n");
11 /* INF/INF => NaN. */
12 if ((__builtin_inf()/__builtin_inf()) != __builtin_nan(""))
13 printf("error 3\n");
14 /* INF + INF => INF. */
15 if ((__builtin_inf() + __builtin_inf()) != __builtin_inf())
16 printf("error 4\n");
17 if (0.0/0.0 != __builtin_nan(""))
18 printf("error 5\n");
19
20 return 0;
21 }
And I compile it like this:
[qiyao@ qiyao]$ gcc -o nan-3 nan-3.c
And run it,
[qiyao@ qiyao]$ ./nan-3
error 1
error 2
error 3
error 5
It seems that the result do not obey IEEE754. I am not so sure about it, Anyone
could confirm or deny this? Thanks in advance!
--
Regards, Yao
Yao Qi
RE: var_args for rs6000 backend
From: "Meissner, Michael" <[EMAIL PROTECTED]> To: "Yao Qi qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: RE: var_args for rs6000 backend Date: Wed, 7 Sep 2005 13:11:50 -0400 There was also a PowerPC NT ABI at one point, but since Windows NT on PowerPC was stillborn, it was removed. My point was if you are working on the ABI functions, you need to make sure that the other ABIs (AIX, Darwin) don't get broken by any changes you make (presumably you will make sure that you don't break the ABI you are working on). There are some subtle differences by the way between the System V (aka Linux) and eABI as well (stack alignment, number of registers for small data area), but most of those don't show in the ABI functions you are looking at. Do you mean the System V ABI and eABI is same on the aspect of variable parameters passing? Thanks for your reminding me. I will take care of it and try to avoid breaking other ABIs. Best Regards Yao Qi Bejing Institute of Technology _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Re: var_args for rs6000 backend
From: Ian Lance Taylor To: "Yao Qi qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: Re: var_args for rs6000 backend Date: 07 Sep 2005 09:14:49 -0700 "Yao Qi qi" <[EMAIL PROTECTED]> writes: It might help if you give a brief overview of what you are trying to do (maybe you already have, and I forgot). Also, I assume you are working with mainline gcc. I am sorry for unclear discription in last mail and I will try to clarify it now. I am working on GCC dfp branch for *only* one month. Three new data types are added into GCC for the consideration of precision. These three new data types works well in argument passing and value return, but can not deal with variable argument passing with macros va_arg,va_start, and va_end in stdarg.h well. The value got from va_arg is always wrong on PowerPC. Do you think I am on a right way to describe a problem clearly in this community? If not, feel free to tell me. Are you saying that you have new types which have variable length? Those are certainly trickier to handle. Standard C and C++ do not pass any variable length types as arguments, so it's not surprising that it will take some work. PowerPC argument passing is significantly different from x86 argument passing because on the x86 all arguments are passed on the stack (modulo the -mregparm option which you are probably not using). On Yes, I have not tasted this option. When I specify this option, there are more failures than before, but this options has nothing to do with variable argument passing. That case can run well with and without this option respectively. the PowerPC arguments are mostly passed in registers, overflowing to the stack, and you need to worry about three different types of registers: general registers, floating point registers, and vector registers. Yes, I have browsed the 64-bit PowerPC ELF ABI Supplement, and IMO,this issue is only relative to floating point registers, because all the new data types are new floating-point types. There aren't any particularly helpful debugging options here. You should know that this code often interacts with the function prologue code, which is not inserted until the flow2 pass, so to see those instructions in RTL you need -dw. This optins is great! The rtl file I dumped out is more informative than what I have done before with -dr and I can map it to assembly easily. However, I am not sure about the following things in rtl file I dumped, ;; End of basic block 0, registers live: 1 [1] 3 [3] 31 [31] 33 [1] 34 [2] 35 [3] 36 [4] 37 [5] 38 [6] 39 [7] 40 [8] 67 [ap] 113 [sfp] I have searched it in Charpter 10 RTL representation in GCC internals for GCC 4.0, but I can not find anything to describe it. I guess it is a description of register usage. 1 means r1 ,31 means r31, 33 means f2, am I right? I often find it necessary to add debugging prints to these functions to show where parameters are found in registers and/or on the stack, and what kind of thing va_arg returns. These prints most conveniently take the form of if (dump_file) fprintf (dump_file, ...); to appear in the relevant file dumped by -da. I found not all the target in gcc/gcc/config directory use this functionality and is there any principle or guideline for location selection of dump_file in source code? I can add it in any locations I am interested in but how about it for the general purpose in gcc/gcc/config/rs6000/rs6000.c ? Thanks very much for your reply. Ian Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: var_args for rs6000 backend
I often find it necessary to add debugging prints to these functions
to show where parameters are found in registers and/or on the stack,
and what kind of thing va_arg returns. These prints most conveniently
take the form of
if (dump_file)
fprintf (dump_file, ...);
to appear in the relevant file dumped by -da.
Ian
Hi, Ian, I have tried this debugging prints and add it in
gcc/config/rs600/rs600.c. I post
part of the source code here for your reference,
5672 tree
5673 rs6000_gimplify_va_arg (tree valist, tree type, tree *pre_p, tree
*post_p)
5674 {
...
5733 if (dump_file)
5734 {
5735 fprintf (dump_file, "TARGET_HARD_FLOAT =
%d\n",TARGET_HARD_FLOAT);
5736 fprintf (dump_file, "TARGET_FPRS =%d\n", TARGET_FPRS);
5737 fprintf (dump_file, "TYPE_MODE (type) = %d\n", TYPE_MODE
(type));
5738 }
5739 if (TARGET_HARD_FLOAT && TARGET_FPRS
..
When I trace it here and find dump_file is NULL so I can not dump them out
with
-da option. I do not know how could you do it in this way, could you give
me
some advice?
BTW, I am concerned about the value of TARGET_HARD_FLOAT and TARGET_FPRS,
I think both of them is 1 here, because I built GCC natively on POWER, but
when I trace
it , I found it skips this condation statement as if ARGET_HARD_FLOAT is 0,
I do not know
why.
I have searched TARGET_HARD_FLOAT in GCC internals for GCC 3.3.5 and found
nothing about it. Could anyone tell me which file define these two macros?
I grep it in gcc/config/rs6000/ but it seems that there is no file define
it. Could
anybody here have a look at it and verify it for me, any comments are highly
appreicated.
Thanks in advance!
Best Regards
Yao Qi
Bejing Institute of Technology
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
Re: var_args for rs6000 backend
I don't know where the DFP arguments are passed. If they are passed in the floating point registers, then is the fix as simple as handling the new modes like SFmode and DFmode in rs6000_gimplify_va_arg? Yes, new modes has been added correspondingly. > > However, I am not sure about the following things in rtl file I dumped, > ;; End of basic block 0, registers live: > 1 [1] 3 [3] 31 [31] 33 [1] 34 [2] 35 [3] 36 [4] 37 [5] 38 [6] 39 [7] > 40 [8] 67 [ap] 113 [sfp] > > I have searched it in Charpter 10 RTL representation in GCC internals for > GCC 4.0, but I can not find anything to describe it. I guess it is a > description > of register usage. 1 means r1 ,31 means r31, 33 means f2, am I right? Yes. The strings in square brackets are the name of the registers. This is unfortunately unhelpful for the PowerPC, where the register names are just numbers. You can try using -mregnames to get better strings. Or just look at alt_reg_names in rs6000.c for a more useful mapping from register number to register name. Yes, alt_reg_names is much more clear than my imagination. dump_file is a global variable. It will be set if debugging is enabled for whatever pass is executing at the moment. Using -da turns on debugging for all RTL passes. Ian Best Regards Yao Qi Bejing Institute of Technology _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: var_args for rs6000 backend
From: Andrew Pinski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Yao qi) CC: ian@airs.com, gcc@gcc.gnu.org Subject: Re: var_args for rs6000 backend Date: Fri, 9 Sep 2005 01:51:58 -0400 (EDT) > BTW, I am concerned about the value of TARGET_HARD_FLOAT and TARGET_FPRS, > I think both of them is 1 here, because I built GCC natively on POWER, but > when I trace > it , I found it skips this condation statement as if ARGET_HARD_FLOAT is 0, > I do not know > why. > > I have searched TARGET_HARD_FLOAT in GCC internals for GCC 3.3.5 and found > nothing about it. Could anyone tell me which file define these two macros? > > I grep it in gcc/config/rs6000/ but it seems that there is no file define > it. Could > anybody here have a look at it and verify it for me, any comments are highly > appreicated. TARGET_HARD_FLOAT is defined by the options generating file. So it is defined in rs6000.opt: mhard-float Target Report RejectNegative InverseMask(SOFT_FLOAT, HARD_FLOAT) Use hardware floating point Do you mean the value of TARGET_HARD_FLOAT is *1* when option -mhard-float is specified according to rs6000.opt ? I tried to specify this option and it seems useless to set TARGET_HARD_FLOAT. If so, that is to say, in rs6000_gimplify_va_arg() , the condations statement in line 5734, 5733 5734 if (TARGET_HARD_FLOAT && TARGET_FPRS 5735 && (TYPE_MODE (type) == SFmode || TYPE_MODE (type) == DFmode is *always* FALSE and all the float parameters wiil be passed in GPRs instead of FPRs. Am I right? Everyone here could verify or deny it, thanks in advance! But that does not sense as the default value for powerpc-linux-gnu is hard floats. Thanks Andrew Pinski Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: var_args for rs6000 backend
From: "Meissner, Michael" <[EMAIL PROTECTED]> To: "Yao qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: RE: var_args for rs6000 backend Date: Thu, 8 Sep 2005 21:19:25 -0400 Yes, the eABI is a modification of the System V ABI. IIRC (but it has been several years since I worked on PowerPC), the differences between eABI and System V were: 1) eABI used r2 as a secondary small data pointer (System V used just r13), and r0 was used for data centered around location 0; 2) there were some relocations in eABI not in System V (support for 3 small data pointers, section relative relocations) and some relocations in System V not in eABI (shared library support); 3) System V had 16-byte stack alignment and eABI had 8-byte stack alignment. I suspect there may be more changes that I'm forgetting about, and also the 64-bit support probably changes things also. Thanks very much for your explanation, and I will take them in mind. Now, I can understand the ideas about ABI clearly and map these ideas to the source code partialy. However, I am cofused by the combination of TREE operations, RTX and GIMPLE in the functions about variable arguments. I have to conquer them before I hack code about variable arguments in GCC, don't you? However my focus now is routines about variable argument, and do you think it is necessary for me to understand TREE strucuture, RTX and GIMPLE before I pay attention on variable arguments ? Is there any workrounds to bypass them partially? If there is no such shortcut for them, could you tell me how to start the learning in these fields ? Thank you very much again. Best Regards Yao Qi Bejing Institute of Technology _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: var_args for rs6000 backend
Yes. TARGET_HARD_FLOAT is defined as #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) The -mhard-float option will clear the MASK_SOFT_FLOAT bit in target_flags. Yes, this option works when I use it in GDB like this, (gdb) run -mhard-float ../../gcc-dfp-cvs-Aung-10/gcc/testsuite/gcc.dg/dfp/qiyao/varargs-1.expand -o vararg-1.exe and TARGET_HARD_FLOAT becomes *TRUE*. Thanks. The default setting of the MASK_SOFT_FLOAT bit in target_flags depends upon the default processor. The condition is not always false. The value depends on exactly how you have configured the compiler and exactly what options you pass. Ian Best Regards ---- Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: var_args for rs6000 backend
Sorry for delayed reply.
As I said, I haven't looked at the code in awhile (before GIMPLE), but
the TREE code is the symbol table that allows you to look up the types
of arguments and the function return type.
Yes, I think you ar right. I found some other functionalities in
rs6000_gimplify_va_arg() of TREE, but I am not sure of it , could you have
a look at it and verify my thoughts to it. Some code listed here for
your reference.
5784 t = fold_convert (TREE_TYPE (reg), size_int (8 - n_reg + 1));
5785 t = build2 (GE_EXPR, boolean_type_node, u, t);
5786 u = build1 (GOTO_EXPR, void_type_node, lab_false);
5787 t = build3 (COND_EXPR, void_type_node, t, u, NULL_TREE);
5788 gimplify_and_add (t, pre_p);
I can not find any document to explain these routines and just infer the
meaning literally. When this slice of code executed, the structure of tree
is like this,
COND_EXPR
/\
/ \
GOTO_EXPR GE_EXPR
Am I missing some thing? Anyone could approve or deny this. On the
presumption I am on right track, I do not know why compute
(8 - n_reg + 1) in compile-time and convert to TREE_TYPE (reg)?
The RTX code are the
instructions you produce for va_arg, etc. For example, I believe the
eabi/System V had a structure that had a few elements, one of which was
the argument number, then there pointers to the save areas for gpr and
fpr registers and the stack frame. The va_arg code would have to
produce code that tested the argument number, and if it was the first 8
arguments it would use the pointer to the gpr/fpr save areas and if not
it would use the stack pointer, and finally bump up the argument number.
Yes, I have got something in my mind about you have pointed out, but
there is another concept confused me, align. For example,
5820 t = ovf;
5821 if (align != 1)
5822 {
5823 t = build2 (PLUS_EXPR, TREE_TYPE (t), t, size_int (align -
1));
5824 t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t,
5825 build_int_cst (NULL_TREE, -align));
5826 }
I do not know why align is relative to PLUS and BIT_AND, just for
alignment adjustment?
I may be somewhat wrong on the details. That is the trouble on working
on quite a few different ports -- after awhile all of the details blend
together.
Best Regards
----
Yao Qi
Bejing Institute of Technology
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: var_args for rs6000 backend
Hi, Ian, Sorry for this delayed reply, just because bug chasing is time-cosumping to a beginner. I think I found the root cause of the problem and post my ideas to it for your reference. As mentioned before in this thread, A new floating point type of 32 bit was introduced into GCC, and this floating point type will cause mistakes when it is variable argument list, just like single precision floating type. I add some checks in c_type_promotes_to() in gcc/c-typeck.c and now there would be a warning when this 32 bit floating type varialbes appeared in varialbe argument list and abort when executed. It seems that this problem itself has nothing to do with rs6000 backend and I was confused by the symptom at first. Thank you very much for all your previous reply. Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
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
Re: make distclean can not remove intl/config.cache
Ian Lance Taylor wrote:
Sounds like a bug.
May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
Thanks for your comments. Here is a patch for it.
2005-09-22 Yao Qi <[EMAIL PROTECTED]>
* gcc/intl/Makefile.in (distclean): Add config.cache.
* gcc/fixincludes/Makefile.in (distclean): Likewise.
Index: gcc/fixincludes/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/fixincludes/Makefile.in,v
retrieving revision 1.11
diff -c -r1.11 Makefile.in
*** gcc/fixincludes/Makefile.in 15 Aug 2005 00:50:43 - 1.11
--- gcc/fixincludes/Makefile.in 22 Sep 2005 05:18:28 -
***
*** 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
--- 134,140
rm -f mkheaders mkheaders.almost
distclean: clean
! rm -f Makefile config.h config.log config.status stamp-h config.cache
maintainer-clean: distclean
rm -f $(srcdir)/fixincl.x
Index: gcc/intl/Makefile.in
===
RCS file: /cvsroot/gcc/gcc/intl/Makefile.in,v
retrieving revision 1.5
diff -c -r1.5 Makefile.in
*** gcc/intl/Makefile.in13 May 2005 08:03:46 - 1.5
--- gcc/intl/Makefile.in22 Sep 2005 05:51:01 -
***
*** 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS
maintainer-clean: distclean
--- 182,188
clean: mostlyclean
distclean: clean
! rm -f Makefile ID TAGS config.status config.cache config.log
maintainer-clean: distclean
--
Regards, Yao
Yao Qi
Re: Tom de Vries appointed nvptx maintainer
On Fri, Sep 22, 2017 at 7:30 PM, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Tom de Vries as nvptx maintainer. > Congratulations, Tom! -- Yao (齐尧)
Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)
Hi,
I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some
-Werror=stringop-overflow= and -Werror=stringop-truncation warnings.
Some of them are not necessary to me,
1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char*
strncpy(char*, const char*, size_t)’ output truncated before terminating nul
copying as many bytes from a string as its length [-Werror=stringop-truncation]
strncpy (q, p, n);
^
../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length computed
here
n = strlen (p);
~~~^~~
the code is simple,
n = strlen (p);
/* Copy the line to Python and return. */
q = (char *) PyMem_RawMalloc (n + 2);
if (q != NULL)
{
strncpy (q, p, n);
q[n] = '\n';
q[n + 1] = '\0';
}
I don't see the point of warning here.
2. ../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char* strncpy(char*,
const char*, size_t)’ output truncated before terminating nul copying 2 bytes
from a string of the same length [-Werror=stringop-truncation]
strncpy (full_name + scope_length, "::", 2);
^~~
full_name = (char *) alloca (scope_length + 2 + strlen (name) + 1);
strncpy (full_name, scope, scope_length);
strncpy (full_name + scope_length, "::", 2);
strcpy (full_name + scope_length + 2, name);
the code looks right to me,
Likewise,
../../../binutils-gdb/gdb/gdbserver/remote-utils.c:1204:14: error: ‘char*
strncpy(char*, const char*, size_t)’ output truncated before terminating nul
copying 6 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (buf, "watch:", 6);
^~
strncpy (buf, "watch:", 6);
buf += 6;
*buf = '\0';
I can "fix" these warnings by changing GDB code, use strcpy in 1) and
use memcpy in 2). Do we expect all the users of GCC 8 changing their
correct code because GCC is not happy on the code? The warning is too
aggressive to me.
--
Yao (齐尧)
Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)
On 17-11-20 09:33:46, Martin Sebor wrote:
> On 11/20/2017 08:51 AM, Yao Qi wrote:
> >
> >Hi,
> >I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some
> >-Werror=stringop-overflow= and -Werror=stringop-truncation warnings.
> >Some of them are not necessary to me,
>
> I have the attached patch for two of these but I have been waiting
> to submit it until the latest GCC patch has been approved that
> adjusts the checker a bit.
Hi Martin,
can you post the patch to gdb-patc...@sourceware.org? The patch can
be reviewed there.
>
> >
> >1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char*
> >strncpy(char*, const char*, size_t)’ output truncated before terminating nul
> >copying as many bytes from a string as its length
> >[-Werror=stringop-truncation]
> > strncpy (q, p, n);
> > ^
> >../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length computed
> >here
> > n = strlen (p);
> > ~~~^~~
> >
> >the code is simple,
> >
> > n = strlen (p);
> >
> > /* Copy the line to Python and return. */
> > q = (char *) PyMem_RawMalloc (n + 2);
> > if (q != NULL)
> >{
> > strncpy (q, p, n);
> > q[n] = '\n';
> > q[n + 1] = '\0';
> >}
> >
> >I don't see the point of warning here.
>
> The overall purpose of the warning is to help find likely misuses
> of strncpy and strncat. As with any warning that's based on intent,
> it cannot avoid highlighting some safe uses, or missing some unsafe
> ones.
As a user, false negative is fine to me, but false positive is too noisy.
If I made stupid mistakes and compiler doesn't find them, that is fine.
The people who wrote such bad code should be blamed, rather than
compiler. However, if compiler emits many warnings to the correct code,
it is annoying. Usually, "too many false warnings" == "no warnings".
>
> The case above is based on a heuristic designed to find bugs where
> the bound depends on the length of the source rather the size of
> the destination, as in:
>
> strncpy (d, s, strlen (s));
>
> This is, unfortunately, a common misuse/mistake. It's often seen
> in legacy code that's being updated in response to a security
> mandate to replace strcpy with strncpy.
>
> The GDB use case, although safe, is also not how the function is
> intended to be used. The intended use is to specify the size of
> the destination, typically a statically allocated array, and have
> the function fill it with data (not necessarily a string, and
> not necessarily containing a terminating nul). When the array
> is allocated dynamically and sized to store the entire string
> it's preferable to use some other function (e.g., memcpy or
> strcpy).
The real issue here is GCC warning is too aggressive, and even emit
warnings to the correct code. We fixed glibc, gdb, what is the next?
GCC will be used to build thousands of packages, do you expect "fixing"
all of them? If I have to fix my correct code, just because gcc
complains about it, it is time I consider switching to other compilers
to compile my code.
>
> >
> >2. ../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char*
> >strncpy(char*, const char*, size_t)’ output truncated before terminating nul
> >copying 2 bytes from a string of the same length
> >[-Werror=stringop-truncation]
> > strncpy (full_name + scope_length, "::", 2);
> > ^~~
> >
> > full_name = (char *) alloca (scope_length + 2 + strlen (name) + 1);
> > strncpy (full_name, scope, scope_length);
> > strncpy (full_name + scope_length, "::", 2);
>
> This is safe, although also not the intended use of the function.
> The call above can be replaced either by memcpy or strcpy. There
> also is no good way to avoid warning on it without compromising
> the efficacy of the checker.
>
IMO, compiler != static analysis/checker, although they share many
technologies. They have different responsibilities, compiler is to
generate binary code from source code, while static analysis tool
is to find problems in the code as many as possible.
--
Yao (齐尧)
Different dynamical array debug info 7.2 vs. 8.0
Hi, I observed that gfortran 7.2 and 8.0 generate different debug info for dynamical array. Here is a case simplified from gdb test case gdb.fortran/vla-datatypes.f90 $ cat vla-datatypes.f90 program vla_primitives integer, allocatable:: intvla(:, :, :) logical :: l allocate (intvla (11,22,33)) l = allocated(intvla) ! vlas-allocated intvla(:,:,:) = 1 intvla(5,5,5) = 42 ! vlas-initialized end program vla_primitives In gcc 8.0, the intvla debug info is, <2>: Abbrev Number: 10 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0xcb): intvla DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type: <0x127> DW_AT_location: 3 byte block: 91 e0 7e (DW_OP_fbreg: -160) <1><127>: Abbrev Number: 14 (DW_TAG_array_type) <128> DW_AT_ordering: 1 (column major) <129> DW_AT_data_location: 4 byte block: 97 23 8 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref) <12e> DW_AT_allocated : 6 byte block: 97 23 8 6 30 2e (DW_OP_push_object_address; DW_OP_plus_uconst: 8; DW_OP_deref; DW_OP_lit0; DW_OP_ne) <135> DW_AT_type: <0x7b> <139> DW_AT_sibling : <0x174> <2><13d>: Abbrev Number: 15 (DW_TAG_subrange_type) <13e> DW_AT_lower_bound : 4 byte block: 97 23 28 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref) <143> DW_AT_upper_bound : 4 byte block: 97 23 30 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 48; DW_OP_deref) <148> DW_AT_byte_stride : 6 byte block: 97 23 20 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><14f>: Abbrev Number: 15 (DW_TAG_subrange_type) <150> DW_AT_lower_bound : 4 byte block: 97 23 40 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 64; DW_OP_deref) <155> DW_AT_upper_bound : 4 byte block: 97 23 48 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 72; DW_OP_deref) <15a> DW_AT_byte_stride : 6 byte block: 97 23 38 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 56; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><161>: Abbrev Number: 15 (DW_TAG_subrange_type) <162> DW_AT_lower_bound : 4 byte block: 97 23 58 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 88; DW_OP_deref) <167> DW_AT_upper_bound : 4 byte block: 97 23 60 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 96; DW_OP_deref) <16c> DW_AT_byte_stride : 6 byte block: 97 23 50 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 80; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><173>: Abbrev Number: 0 In gcc 7.2, it is, <2>: Abbrev Number: 10 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x12): intvla DW_AT_decl_file : 1 DW_AT_decl_line : 2 DW_AT_type: <0x127> DW_AT_location: 3 byte block: 91 e0 7e (DW_OP_fbreg: -160) <1><127>: Abbrev Number: 14 (DW_TAG_array_type) <128> DW_AT_ordering: 1 (column major) <129> DW_AT_data_location: 2 byte block: 97 6 (DW_OP_push_object_address; DW_OP_deref) <12c> DW_AT_allocated : 4 byte block: 97 6 30 2e (DW_OP_push_object_address; DW_OP_deref; DW_OP_lit0; DW_OP_ne) <131> DW_AT_type: <0x7b> <135> DW_AT_sibling : <0x170> <2><139>: Abbrev Number: 15 (DW_TAG_subrange_type) <13a> DW_AT_lower_bound : 4 byte block: 97 23 20 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref) <13f> DW_AT_upper_bound : 4 byte block: 97 23 28 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref) <144> DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><14b>: Abbrev Number: 15 (DW_TAG_subrange_type) <14c> DW_AT_lower_bound : 4 byte block: 97 23 38 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 56; DW_OP_deref) <151> DW_AT_upper_bound : 4 byte block: 97 23 40 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 64; DW_OP_deref) <156> DW_AT_byte_stride : 6 byte block: 97 23 30 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 48; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><15d>: Abbrev Number: 15 (DW_TAG_subrange_type) <15e> DW_AT_lower_bound : 4 byte block: 97 23 50 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 80; DW_OP_deref) <163> DW_AT_upper_bound : 4 byte block: 97 23 58 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 88; DW_OP_deref) <168> DW_AT_byte_stride : 6 byte block: 97 23 48 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 72; DW_OP_deref; DW_OP_lit4; DW_OP_mul) <2><16f>: Abbrev Number: Attributes DW_AT_data_location and DW_AT_allocated are different. There is an extra "DW_OP_plus_uconst: 8" generated by gcc 8.0. Is it intended or expected? gfortran 8.0 causes many gdb.
Re: Different dynamical array debug info 7.2 vs. 8.0
On Tue, Jan 23, 2018 at 4:02 PM, Yao Qi wrote: > > Hi, > I observed that gfortran 7.2 and 8.0 generate different debug info for > dynamical array. > Attributes DW_AT_data_location and DW_AT_allocated are different. There > is an extra "DW_OP_plus_uconst: 8" generated by gcc 8.0. Is it > intended or expected? gfortran 8.0 causes many gdb.fotran vla-related > tests fail, but gfortran 7.2 doesn't. That is why I took a look at the > debug information. > I did 'git bisect', and find the following commit causes the change in the debug information. Paul, do you have any clue on the different debug information caused by your commit? commit c0dbf68e8b1cf24bd54de0c3b6ec056436f174ac Author: pault Date: Sun Sep 10 17:02:53 2017 + 2017-09-10 Paul Thomas PR fortran/34640 PR fortran/40737 PR fortran/55763 PR fortran/57019 PR fortran/57116 * expr.c (is_subref_array): Add class pointer array dummies to the list of expressions that return true. * trans-array.c: Add SPAN_FIELD and update indices for subsequent fields. (gfc_conv_descriptor_span, gfc_conv_descriptor_span_get, gfc_conv_descriptor_span_set, is_pointer_array, get_array_span): New functions. (gfc_get_descriptor_offsets_for_info): New function to preserve API for access to descriptor fields for trans-types.c. (gfc_conv_scalarized_array_ref): If the expression is a subref array, make sure that info->descriptor is a descriptor type. Otherwise, if info->descriptor is a pointer array, set 'decl' and fix it if it is a component reference. (build_array_ref): Simplify handling of class array refs by passing the vptr to gfc_build_array_ref rather than generating the pointer arithmetic in this function. (gfc_conv_array_ref): As in gfc_conv_scalarized_array_ref, set 'decl'. (gfc_array_allocate): Set the span field if this is a pointer array. Use the expr3 element size if it is available, so that the dynamic type element size is used. (gfc_conv_expr_descriptor): Set the span field for pointer assignments. -- Yao (齐尧)
Both GCC and GDB buildbot use gcc114
Hi Paulo, I noticed that GDB buildbot pending build queue on aarch64-linux becomes longer and longer, https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-m64 as it takes longer to finish each build and test. Looks that you deployed aarch64-linux buildslave for GCC buildbot on gcc114 as well, that is reason that GDB build and test is slowed down (GCC build and test is slowed down too). We'd better avoid using the same machine for two buildbots. Are there any easy way to move one buildslave to a different machine like gcc115 or gcc116. As far as I know, they are identical. -- Yao (齐尧)
Re: Both GCC and GDB buildbot use gcc114
On Tue, Feb 27, 2018 at 9:46 PM, Paulo Matos wrote: > > Apologies for the clash on resources. Using gcc115 and gcc116 only now. > Thank you, Paulo. -- Yao (齐尧)
Re: -Os is weak...
On Fri, Sep 10, 2010 at 10:44:24AM +0200, Steven Bosscher wrote: > On Thu, Sep 9, 2010 at 6:43 PM, DJ Delorie wrote: > > > I guess the most important missing optimizations are various forms of > code unification, such as the sequence abstraction code that GCC used > to have (http://gcc.gnu.org/projects/cfo.html, but it never worked > properly and it was way too slow), or some suffix-tree based sequence > finding code. Various algorithms can be found in the academic > literature about code size optimizations via abstraction (see e.g. > "Procedural Abstraction with Reverse Prefix Trees", > http://portal.acm.org/citation.cfm?id=1545074). Was CFO finally merged to mainline? At least, I can't find it in current gcc. > Personally, I had hoped that the ARM folks (Linaro, or what's it > called?) would work on -Os. While I've never actually used it, a web > search suggests that the RealView compilers generate code that is as > much as 20% smaller than GCC at -Os (for unnamed benchmarks), so > apparently there is a lot of room for improvement in GCC and the ARM > people should know where. > We, Linaro Toolchain Working Group, are doing the investigation on code size improvements on thumb-2. As you said, there would be a lot of room for improvement, and here is the report we got, fyi. http://lists.linaro.org/pipermail/linaro-toolchain/2010-September/000202.html > Finally, of course there are just various issues with instruction > selection in GCC that result in larger-than-necessary code. It seems > that this doesn't hurt code speed so much, but for code size GCC > doesn't always select the shortes sequence possible. Some Google folks > (Carrot Wei in particular) have filed bugs and patches for a couple of > cases for ARM, but there is no target-independent frame work for > selecting the shortest insn or sequence. During the investigation, I feel that all the potential improvements are identified by ARM experts or by reading asm code manually. This mode doesn't scale very well. IMO, it is necessary to have a target-independent framework for code size optimization. I have no idea to do that framework though. -- Yao Qi CodeSourcery y...@codesourcery.com (650) 331-3385 x739
Alias-analysis in gccint
When I read the example of alias analysis from
http://gcc.gnu.org/onlinedocs/gccint/Alias-analysis.html, I could not
understand it. Here is this example and text,
"For instance, consider the following function:
foo (int i)
{
int *p, *q, a, b;
if (i > 10)
p = &a;
else
q = &b;
*p = 3;
*q = 5;
a = b + 2;
return *p;
}
After aliasing analysis has finished, the symbol memory tag for pointer
p will have two aliases, namely variables a and b. Every time pointer p
is dereferenced, we want to mark the operation as a potential reference
to a and b".
My questions is
How many aliases do p have? According to the doc here, it is
said that "p will have two aliases, namely variables a and b." What I
learned from compiler book is that p points-to &a, and q points-to &b.
Best Regards
--
Yao Qi GNU/Linux Developer
http://duewayqi.googlepages.com/
RE: var_args for rs6000 backend
From: "Meissner, Michael" <[EMAIL PROTECTED]>
To: "Yao qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: RE: var_args for rs6000 backend
Date: Tue, 6 Sep 2005 14:13:56 -0400
And note Yao qi, that there are different ABIs on the rs6000, each of
which has different conventions (ie, you will need to study the AIX ABI
as well as the System V/eabi ABIs, and possibly other ABIs that are now
used).
First, thanks for you suggestions.
Yes, I found there are at least *three* ABIs in gcc/config/rs6000/rs6000.c,
205 /* ABI enumeration available for subtarget to use. */
206 enum rs6000_abi rs6000_current_abi;
And in gcc/config/rs6000/rs6000.h, I found the defination,
1223 /* Enumeration to give which calling sequence to use. */
1224 enum rs6000_abi {
1225 ABI_NONE,
1226 ABI_AIX, /* IBM's AIX */
1227 ABI_V4, /* System V.4/eabi */
1228 ABI_DARWIN/* Apple's Darwin (OS X kernel) */
1229 };
I just have to concentrate on ABI_V4 if I work on gcc develoment on
powerpc-linux, am I right ?
I have traced cc1 and found DEFAULT_ABI in setup_incoming_varargs() is
ABI_V4.
Best Regards
Yao Qi
Bejing Institute of Technology
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: var_args for rs6000 backend
From: Ian Lance Taylor To: "Yao qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: Re: var_args for rs6000 backend Date: 06 Sep 2005 11:05:38 -0700 "Yao qi" <[EMAIL PROTECTED]> writes: These are partially documented in gcc/doc/tm.texi. Unfortunately the documentation is not particularly good. These functions are all oriented around C stdarg.h functions. In brief, setup_incoming_varargs is called for a function which takes a variable number of arguments, and does any required preparation statements. build_builtin_va_list builds the va_list data type. va_start is called to implement the va_start macro. gimplify_va_arg is called to implement the va_arg macro. Thanks for your detailed explanation, from which I got a general image of these routines. I think the setup_incoming_varargs is the starting point of these routines and I start my work from this function. I divided setup_incoming_varargs() to *three* parts logically on the condation that default ABI is ABI_V4, If I make some mistakes here, feel free to tell me. 1 Deal with all the named arguments. 2 Calculate the number of GPR needed and generate RTX for copying GPR to MEM. 3 Generate RTX for copying FPR to MEM. I met some problems when I go on further, so I want to display the symptoms here before I continue my question. New data types were added into GCC as well as new modes. Argument passing and return value works well, but when I pass arguments of these new types of variable length, and return a certain arguments in parameters list, the value is incorrect on PowerPC, but works well on x86. So I think it has something to do with PowerPC backend. Now, the most difficult thing for me is error location. I do not which part of PowerPC backend caused this problem. I dumped the test case in RTL form with option -dr and in assembly form, but both of them are not informative enough to expose the error. This "bug" may be relative to argument passing, stack alloction, new modes and register allocation, but I do not know how to get enought information about these fields. Could anybody give me some suggestions about information collection for them? I am lack of experience in gcc development, any comments about it are highly appreicate. > I do not know what is the precondation if I want to do it? May I need > to know the architecture of PowerPC and ABI for it? You do indeed need to know the PowerPC ABIs to understand what these routines are doing and why. Got it , thanks for your advice here. Ian Best Regards Yao Qi Bejing Institute of Technology _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
