Re: Are BOOT_CFLAGS, CFLAGS_FOR_TARGET, and CXXFLAGS_FOR_TARGET necessary and sufficient?
>> make "BOOT_CFLAGS=-O3" "CFLAGS_FOR_TARGET=-O3" "CXXFLAGS_FOR_TARGET=-O3" > Seems right to me. What happened when you tried it? I figured that "ask" instead of "try it and see what happens" was a better idea, especially because that wouldn't identify unnecessary variables. > Note that gcc@gcc.gnu.org is for the development of gcc. Questions > about using and building gcc should normally go to > gcc-h...@gcc.gnu.org. Aha, thanks!
Re: about emit_move_insn in define_expand
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "general_operand" "")
)]
""
{
if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
{
if(!no_new_pseudos)
{
operands[1]=force_reg(SImode,operands[1]);
}
}
printf("Here1\n");
emit_move_insn (operands[0], operands[1]);
printf("Here2\n");
DONE;
}
)
I have confirmed it will cause the recursion. The emit_move_insn will
call emit_move_insn again. So if the operands are valid in machine
assemble, I need to use gen*-move function, such as gen_load,
gen_store, or just let the define_expand to generate RTL. Like the
following, It won't cause recursion call:
(define_expand "movsi"
[(set (match_operand:SI 0 "nonimmediate_operand" "")
(match_operand:SI 1 "general_operand" "")
)]
""
{
if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG)
{
if(!no_new_pseudos)
{
operands[1]=force_reg(SImode,operands[1]);
}
printf("Here1\n");
emit_move_insn (operands[0], operands[1]);
printf("Here2\n");
DONE;
}
else
printf("Here3\n");
}
)
I should read more code in backend to avoid making such problems. ^_^
. Sorry for interruptting you.
Thank you very much.
Tian Xiaonan
2008/12/18 Uday P. Khedker :
> Yes, please keep me updated.
>
>> Hi Dr. Uday Khedker: I just found a something. I added 'emit_move_insn'
>> function into theoriginal file in spim5.md which was downloaded from your
>> website,everything seems fine. But I added into the file which I
>> havemodified, the cc1 will crash. I wll find the resean. Sorry, I
>> thinkit's my fault. and I will send the reason to you later.
>> Thank you.
>> Best wishes.
>>
>> Tian Xiaonan2008/12/18 Uday P.
>> Khedker >> Hi
>> Tian,>> I have an explanation for
>> it but let me first verify and
>> make sure> that the details are
>> correct. Will get back to you in a
>> day or two.>> Uday Khedker.>
>> -->
>> Dr. Uday Khedker> Associate
>> Professor> Department of Computer
>> Science & Engg.> IIT Bombay,
>> Powai, Mumbai 400 076, India.>
>> email : u...@cse.iitb.ac.in>
>> homepage:
>> http://www.cse.iitb.ac.in/~uday>
>> phone : Office - 91 (22) 2576
>> 7717> Res. - 91 (22)
>> 2576 8717, 91 (22) 2572 0288>
>> -->>>
>> > Hello, Dr. Uday Khedker:> >I
>> just found that emit_move_insn
>> function can't be used in> >
>> define_expand pattern in the spim
>> gcc4.0.2 platform. It will cause
>> the> > Segmentation Fault.
>> Something like recursion
>> happened.> >I changed the
>> define_expand "movsi" from:> >> >
>> (define_expand "movsi"> >
>> [(set (match_operand:SI 0
>> "nonimmediate_operand" "")> >
>>(match_operand:SI 1
>> "general_operand" "")> > )]>
>> > ""> > {> >
>> if(GET_CODE(operands[0])==MEM &&
>> GET_CODE(operands[1])!=REG)> >
>> {> >
>> if(!no_new_pseudos)> >
>> {> >
>> operands[1]=force_reg(SImode,operands[1]);>
>> >}> > }> >
>> }> > )> >> > to :> >> >
>> (define_expand "movsi"> >
>> [(set (match_operand:SI 0
>> "nonimmediate_operand" "")> >
>>(match_operand:SI 1
>> "general_operand" "")> > )]>
>> > ""> > {> >
>> if(GET_CODE(operands[0])==MEM &&
>> GET_CODE(operands[1])!=REG)> >
>> {> >
>> if(!no_new_pseudos)> >
>> {> >
>> operands[1]=force_reg(SImode,operands[1]);>
>> >}> > }> >
>> printf("Here1\n");> >
>> emit_move_insn (operands[0],
>> operands[1]);> >
>> printf("Here2\n");> >
>> DONE;> > }> > )> >> > The
>> string 'Here2' nerver come out.
>> Before Segmentation fault
>> occurred,> > cc1 prints lots of
>> the 'Here1'. So I guess the
>> function emit_move_insn> > caused
>> the recursion. But I checked the
>> mips md files. Mips also used the>
>> > emit_move_insn function in
>> define_expand "movsi" pattern. So
>> I guess> > whether I missed
>> something in md file. Can you give
>> me any advices?> >> > Thank you
>> very much.> >> > Best Wishes.> >
>>
>> Tian Xiaonan> >> >> >
>> --- On Tue, 12/9/08, Uday P.
>> Khedker
>> wrote:> >> >> From: Uday P.
>> Khedker > >>
>> Subject: Re: redundancy code> >>
>> To: tianxiaonan2...@yahoo.com.cn>
>> >> Date: Tuesday, December 9,
>> 2008, 12:25 PM> >> Hi Tian,> >>>
>> >> The goal of our machine
>> descriptions has been to identify>
>> >> the> >> minimal and hence
>> essential parts of machine
>> descriptions> >> in> >> order to
>> generate correct code. Improving
>> the code quality> >> has> >> not
>> been addressed in these
>> descriptions. In due course of> >>
>> time,> >> we should be able to
>> devise methodology for developin
Re: about emit_move_insn in define_expand
Yes, that is what was my first guess. That is the reason we avoid
using force_reg in reload pass (by using !no_new_pseudos).
Uday Khedker.
--
Dr. Uday Khedker
Associate Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
email : u...@cse.iitb.ac.in
homepage: http://www.cse.iitb.ac.in/~uday
phone : Office - 91 (22) 2576 7717
Res. - 91 (22) 2576 8717, 91 (22) 2572 0288
--
> (define_expand "movsi"[(set (match_operand:SI 0 "nonimmediate_operand"
> "") (match_operand:SI 1 "general_operand" ""))]""{
> if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG) {
>if(!no_new_pseudos) {
> operands[1]=force_reg(SImode,operands[1]); } }
> printf("Here1\n"); emit_move_insn (operands[0], operands[1]);
> printf("Here2\n"); DONE;})
> I have confirmed it will cause the recursion. The emit_move_insn willcall
> emit_move_insn again. So if the operands are valid in machineassemble, I
> need to use gen*-move function, such as gen_load,gen_store, or just let
> the define_expand to generate RTL. Like thefollowing, It won't cause
> recursion call:
> (define_expand "movsi"[(set (match_operand:SI 0 "nonimmediate_operand"
> "") (match_operand:SI 1 "general_operand" ""))]""{
> if(GET_CODE(operands[0])==MEM && GET_CODE(operands[1])!=REG) {
>if(!no_new_pseudos) {
> operands[1]=force_reg(SImode,operands[1]); }
> printf("Here1\n");emit_move_insn (operands[0], operands[1]);
> printf("Here2\n");DONE; } else
> printf("Here3\n"); })
> I should read more code in backend to avoid making such problems. ^_^.
> Sorry for interruptting you.Thank you very much.
> Tian Xiaonan
>
>
>
>
>
> 2008/12/18 Uday P. Khedker :> Yes, please keep me
> updated.>>> Hi Dr. Uday Khedker: I just found a something. I added
> 'emit_move_insn'>> function into theoriginal file in spim5.md which was
> downloaded from your>> website,everything seems fine. But I added into the
> file which I>> havemodified, the cc1 will crash. I wll find the resean.
> Sorry, I>> thinkit's my fault. and I will send the reason to you later.>>
> Thank you.>> Best wishes.
> Tian Xiaonan2008/12/18 Uday P.>> Khedker >> Hi>>
> Tian,>> I have an explanation for>> it but let me first verify and>> make
> sure> that the details are>> correct. Will get back to you in a>> day or
> two.>> Uday Khedker.>>>
> -->>>
> Dr. Uday Khedker> Associate>> Professor> Department of Computer>> Science
> & Engg.> IIT Bombay,>> Powai, Mumbai 400 076, India.>>> email :
> u...@cse.iitb.ac.in>>> homepage:>> http://www.cse.iitb.ac.in/~uday>>>
> phone : Office - 91 (22) 2576>> 7717> Res. - 91 (22)>> 2576
> 8717, 91 (22) 2572 0288>>>
> -->
> > Hello, Dr. Uday Khedker:> >I>> just found that emit_move_insn>>
> function can't be used in> >>> define_expand pattern in the spim>>
> gcc4.0.2 platform. It will cause>> the> > Segmentation Fault.>> Something
> like recursion>> happened.> >I changed the>> define_expand "movsi"
> from:> >> >>> (define_expand "movsi"> >>> [(set (match_operand:SI 0>>
> "nonimmediate_operand" "")> >>>(match_operand:SI 1>>
> "general_operand" "")> > )]>>> > ""> > {> >>>
> if(GET_CODE(operands[0])==MEM &&>> GET_CODE(operands[1])!=REG)> >>> {>
> >>> if(!no_new_pseudos)> >>> {> >>>
> operands[1]=force_reg(SImode,operands[1]);>>> >}> > }>
> >>> }> > )> >> > to :> >> >>> (define_expand "movsi"> >>> [(set
> (match_operand:SI 0>> "nonimmediate_operand" "")> >>>
> (match_operand:SI 1>> "general_operand" "")> > )]>>> > ""> >
> {> >>> if(GET_CODE(operands[0])==MEM &&>> GET_CODE(operands[1])!=REG)>
> >>> {> >>> if(!no_new_pseudos)> >>> {> >>>
> operands[1]=force_reg(SImode,operands[1]);>>> >}> > }>
> >>> printf("Here1\n");> >>> emit_move_insn (operands[0],>>
> operands[1]);> >>> printf("Here2\n");> >>> DONE;> > }> > )> >> >
> The>> string 'Here2' nerver come out.>> Before Segmentation fault>>
> occurred,> > cc1 prints lots of>> the 'Here1'. So I guess the>> function
> emit_move_insn> > caused>> the recursion. But I checked the>> mips md
> files. Mips also used the>>> > emit_move_insn function in>> define_expand
> "movsi" pattern. So>> I guess> > whether I missed>> something in md file.
> Can you give>> me any advices?> >> > Thank you>> very much.> >> > Best
> Wishes.> > Tian Xiaonan> >> >> >>> --- On Tue, 12/9/08,
> Uday P.>> Khedker >> wrote:> >> >> From: Uday P.>>
> Khedker > Subject: Re: redundancy code> To:
> tianxiaonan2..
GCC RES: Restrictive Exception Specification: 0.1 - Pre-Alpha.
Sorry I pressed enter accidentally on gmail and send with no title.
GCC RES: Restrictive Exception Specification: 0.1 - Pre-Alpha. (Third time lucky? Sorry about this)
Extract and rename as res.diff - It seems gmail wants to attach diff files as text instead of attachments. res.diff.tar.gz Description: GNU Zip compressed data
GCC RES: Restrictive Exception Specification: 0.1 - Pre-Alpha. (Ignore my previous 3 posts).
Hopefully this will all go right this time. If mods can delete the
other 3 posts I'd be much obliged. I just needed to put all these
files in the same post, and gmail is being a nuisance.
RES is my project to test (at compile time) whether C++ code can throw
unhandled exceptions.
I tidied up my source, made a patch, wrote and tested some testcases,
and wrote some documentation.
There should be three attachments here:
- res.diff
- res.txt
- test.tar.gz
I've never made patch files before, but hopefully this one is OK.
I used [diff -Naur original/gcc-3.4.2/gcc res/gcc-3.4.2/gcc > res.diff]
I tested it on a fresh gcc-3.4.2 extract and it worked with [patch -p1
< res.diff]
For a quick test, just call gcc with -Wres (or -Wres-debug to add the
debug info).
I haven't tested on much real-world code, there's a chance it may
still have bugs and segfault or something. It's still pre-alpha
though.
I tried to use GCC coding style but I didn't see an 80 character/line
limit anywhere in the document, so I didn't use any limit.
Perhaps someone will bite me for this or perhaps you'll all celebrate
the beginning of a new era of sensible unlimited lines :) anyway it's
pre-alpha so it hardly matters at present - it's just far easier for
me to read.
Testcases:
Unzip test.tar.gz and read test/tests.txt for instructions.
All the testcases except the last work as they should.
res.diff.tar.gz
Description: GNU Zip compressed data
RES: Restrictive Exception Specification.
An extension to G++, the C++ compiler from GCC.
By Simon Hill.
Under the same license as GCC.
CONTENTS
Overview
RES Principles
Usage Tips
Whitelisting
XES
TT
CNR
MES
Implementation
Comparison with EDoc++
C++ extensions to aid RES
Design Flaws
Todo
OVERVIEW
RES is a mechanism to provide a warning whenever code is compiled that may lead
to an unhandled exception.
RES is currently pre-alpha, ie under construction.
eg:
~
foo.cpp:
~
void foo() throw(int)
{
throw 1.5f;
}
~
> gcc -c foo.cpp -Wres
foo.cpp:1: warning: RES: âvoid foo() throw (int)â may terminate due to the
following uncaught and unspecified exceptions:
foo.cpp:3: note: RES: âfloatâ from here.
~
RES is invoked by -Wres,. See [Whitelisting] for info on .
RES considers exception propagation through try/catch blocks, and analyses the
exception specifications of called functions.
XES & TT:
RES comes with four complimentary but probably-less-useful mechanisms:
- XES (excessive exception specification), invoked by -Wres-xes. See [XES].
- TT (throw-terminate), invoked by -Wres-tt. See [TT].
- CNR (catch(...) no rethrow), invoked by -Wres-cnr. See [CNR]
- MES (missing exception specification), invoked by -Wres-cnr. See [MES]
Note: If any of RES, XES or TT are used, most exception checking routines are
enabled. (FIXME:Check) I doubt these affect compilation time significantly.
Note: RES by default ignores calls to functions declared in system includes
(eg: ). However, this can be changed by using -Wres.
==
RES PRINCIPLES
==
The RES project was designed to uphold design principles that I and others seem
to have developed independantly, which I shall here call RES Principles.
I believe it should be fully possible for a C++ compiler to check exception
propagation at compile time.
There has been much discussion on whether this should be so, including lots on
the gcc@gcc.gnu.org mailing list.
The main issue is template code. Unfortunately, with the current C++
specification, template code cannot work properly with RES. However I suggest
some minor changes to the spec in [C++ extensions to aid RES].
My RES Principles are:
1) Every thrown type that may propagate to the function boundary should be in
the function specification.
- IE, no unhandled thrown exceptions.
2) Every called function (whether explicit, implicit, function pointer or
otherwise) should be considered able to throw all types in it's exception
specification, regardless of the callee's implementation.
- IE, calls should be treated the same as a sequence of throws of the types
in the callee's specification.
3) Reachability of throws and calls is not considered. Non-reachable throws of
types that would otherwise lead to unhandled exceptions are not allowed.
4) There should be no throw-terminates. (Re-throws outside of catch blocks).
5) Every thrown type should be caught explicitly. All catch(...) blocks should
re-throw.
6) Every function should have an explicit exception specification (which may be
a no-throw specification).
7) main() and other entrypoints should be defined as throw();
The RES project currently warns on a subset of principle violations, as many
people may not agree with #5, #6 & #7. #5 & #6 can be enabled by -Wres-cnr and
-Wres-mes respectively.
RES deliberately misinterprets the intent exception specifications as
indications of what exception ty
Bug in optimize_bitfield_assignment_op()?
Hello,
My GCC porting for our own VLIW processor tracks mainline weekly. Test
991118-1.c has failed since two weeks ago. Following is a simplified version
of 99118-1.c. After some investigation, I found the following statement is
expanded to RTL wrongly.
;; tmp2.field = () () ((long long int)
tmp2.field ^ 0x8765412345678);
(insn 9 8 10
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-torture/execute/991118-1.c:23
(set (reg/f:SI 88)
(symbol_ref:SI ("tmp2") [flags 0x2] )) -1
(nil))
(insn 10 9 11
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-torture/execute/991118-1.c:23
(set (reg:DI 89)
(mem/s/j/c:DI (reg/f:SI 88) [0+0 S8 A64])) -1 (nil))
(insn 11 10 12
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-torture/execute/991118-1.c:23
(set:DI (reg:DI 90)
(const_int 284280 [0x45678])) -1 (nil)) < wrong constant
(insn 12 11 13
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-torture/execute/991118-1.c:23
(set (reg:DI 91)
(xor:DI (reg:DI 89)
(reg:DI 90))) -1 (nil))
(insn 13 12 0
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-torture/execute/991118-1.c:23
(set (mem/s/j/c:DI (reg/f:SI 88) [0+0 S8 A64])
(reg:DI 91)) -1 (nil))
Insn 11 only preserves the lower 20-bit of the 52-bit long constant. Further
investigation shows the problem arises in
optimize_bitfield_assignment_op function (expr.c).
...
case BIT_XOR_EXPR:
if (TREE_CODE (op1) != INTEGER_CST)
break;
value = expand_expr (op1, NULL_RTX, GET_MODE (str_rtx), EXPAND_NORMAL);
value = convert_modes (GET_MODE (str_rtx),
TYPE_MODE (TREE_TYPE (op1)), value,
TYPE_UNSIGNED (TREE_TYPE (op1)));
/* We may be accessing data outside the field, which means
we can alias adjacent data. */
if (MEM_P (str_rtx))
{
str_rtx = shallow_copy_rtx (str_rtx);
set_mem_alias_set (str_rtx, 0);
set_mem_expr (str_rtx, 0);
}
binop = TREE_CODE (src) == BIT_IOR_EXPR ? ior_optab : xor_optab;
if (bitpos + bitsize != GET_MODE_BITSIZE (GET_MODE (str_rtx)))
{
rtx mask = GEN_INT (((unsigned HOST_WIDE_INT) 1 << bitsize)
< Suspected bug
- 1);
value = expand_and (GET_MODE (str_rtx), value, mask,
NULL_RTX);
}
value = expand_shift (LSHIFT_EXPR, GET_MODE (str_rtx), value,
build_int_cst (NULL_TREE, bitpos),
NULL_RTX, 1);
result = expand_binop (GET_MODE (str_rtx), binop, str_rtx,
value, str_rtx, 1, OPTAB_WIDEN);
Here the bitpos = 0, bitsize = 52. HOST_WIDE_INT for our processor is 32,
though 64-bit long long type is supported. The marked statement produces a
mask of 0xf, thus causes the upper 32-bit removed later. Is this a
potential bug, or did I miss something?
I also tried the older version (> 2 weeks ago). This function is not called at
all, so can produce correct code.
Cheers,
Bingfeng
Broadcom UK
darwin g++ and libstdc++ regressions?
At revision r142799 on i686-apple-darwin9, I am seeing a few new regressions... FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_ ...at -m32 and -m64 as well as... FAIL: abi/demangle/regression/cw-16.cc execution test at -m32 in the libstdc++-v3 testsuite. Should we open PRs for these two? Jack
20 �ves l�ny keresi sexre v�gy� p�rj�t!
20 éves mult szöke leányzó keresi komoly párját! Bármilyen Sexuális formát felveszek! Telefonszámom: 06-30-769-75-92 hÃvjatok benne vagyok mindenben
Best Practice for using contrib/dg-cmp-results
Hi, I have made a lot of progress running the GCC Test Suite on RTEMS targets on the CFARM and reporting results. Now I would like to begin to run the tests on a regular basis and use dg-cmp-results to point out variances from one run to the next. I think this is critical because there are ~12 RTEMS target and when multiplied by the SVN trunk and branches, this is potential information overload. Do people save their gcc.log files in a directory structure arranged by branch, target, and date? And then compare gcc.log against a saved one? What is the accepted best practice in this situation? Thanks. --joel
gcc-4.3-20081218 is now available
Snapshot gcc-4.3-20081218 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081218/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 142822 You'll find: gcc-4.3-20081218.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20081218.tar.bz2 C front end and core compiler gcc-ada-4.3-20081218.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20081218.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20081218.tar.bz2 C++ front end and runtime gcc-java-4.3-20081218.tar.bz2 Java front end and runtime gcc-objc-4.3-20081218.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20081218.tar.bz2The GCC testsuite Diffs from 4.3-20081211 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
