MELT plugin 0.9.2 for GCC 4.6 (& future 4.7) available

2011-12-08 Thread Basile Starynkevitch
Hello All, It is my pleasure to announce the MELT plugin 0.9.2 release candidate 2 December 08th, 2011: Release of MELT plugin 0.9.2 for gcc-4.6 (& future gcc-4.7) dedicated to the memory of John McCarthy http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist) MELT is a

How could I cast the return type of a function created by gimple_build_call?

2011-12-08 Thread Feng LI
Hi, I'm building a function with fread = build_decl (LOCATION, FUNCTION_DECL, get_identifier (name), type); and then use it in gimple with gimple gfread = gimple_build_call (fread, 1, offset); gimple_call_set_lhs (fread, lhs); But I need a cast here, since the lhs has a different type than the r

Bug in Tree to RTL expansion?

2011-12-08 Thread Bingfeng Mei
Hi, I experienced a code generation bug with 4.5 (yes, our port is still stuck at 4.5.4). Since the concerned code is full of our target-specific code, it is not easy to demonstrate the error with x86 or ARM. Here is what happens in expanding process. The following is a piece of optimized tree c

Re: Bug in Tree to RTL expansion?

2011-12-08 Thread Richard Guenther
On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei wrote: > Hi, > I experienced a code generation bug with 4.5 (yes, our > port is still stuck at 4.5.4). Since the concerned code > is full of our target-specific code, it is not easy > to demonstrate the error with x86 or ARM. > > Here is what happens i

Re: How could I cast the return type of a function created by gimple_build_call?

2011-12-08 Thread Martin Jambor
Hi, On Thu, Dec 08, 2011 at 10:38:24AM +0100, Feng LI wrote: > Hi, > > I'm building a function with > fread = build_decl (LOCATION, FUNCTION_DECL, get_identifier (name), type); > > and then use it in gimple with > gimple gfread = gimple_build_call (fread, 1, offset); > gimple_call_set_lhs (fread

Re: How could I cast the return type of a function created by gimple_build_call?

2011-12-08 Thread Richard Guenther
On Thu, Dec 8, 2011 at 1:26 PM, Martin Jambor wrote: > Hi, > > On Thu, Dec 08, 2011 at 10:38:24AM +0100, Feng LI wrote: >> Hi, >> >> I'm building a function with >> fread = build_decl (LOCATION, FUNCTION_DECL, get_identifier (name), type); >> >> and then use it in gimple with >> gimple gfread = gi

RE: Bug in Tree to RTL expansion?

2011-12-08 Thread Bingfeng Mei
Richard, Thanks. -fno-tree-ter does work around the problem. I did look at the info about coalescing, which doesn't give much info. I think I have to take a closer look at TER and coalescing algorithm. Regards, Bingfeng > -Original Message- > From: Richard Guenther [mailto:richard.guent..

Re: RFC - GCC Architectural Goals

2011-12-08 Thread Diego Novillo
On 12/07/11 22:20, 陳韋任 wrote: However, it is true that some patches are not in that category. In general, we prefer to keep patch traffic in a single place (gcc-patches@), but we use message tagging extensively. How about '[trivial]'? If reviwer can pick up trivial patches easily by this w

Re: Bug in Tree to RTL expansion?

2011-12-08 Thread Michael Matz
Hi, On Thu, 8 Dec 2011, Richard Guenther wrote: > > What I am not sure is whether the coalescing algorithm or the > > expanding procedure is wrong here. The forwarding of _218 is wrong. TER shouldn't have marked it as being able to forward (check the expand-detailed dump for the "Replacing E

Re: Bug in Tree to RTL expansion?

2011-12-08 Thread Richard Guenther
On Thu, Dec 8, 2011 at 2:49 PM, Michael Matz wrote: > Hi, > > On Thu, 8 Dec 2011, Richard Guenther wrote: > >> > What I am not sure is whether the coalescing algorithm or the >> > expanding procedure is wrong here. > > The forwarding of _218 is wrong.  TER shouldn't have marked it as being > able

Re: volatile correctness: combine vs. target.md

2011-12-08 Thread Georg-Johann Lay
Ian Lance Taylor wrote: > Georg-Johann Lay: >> >> What about that predicate? >> >> (define_predicate "low_io_mem" >>(and (match_code "mem") >> (match_test "low_io_address_operand (XEXP (op, 0))"))) >> >> Guess it operates the same because the drag-volatile-over-volatile >> happens not i

Re: MELT plugin 0.9.2.b for GCC 4.6 (& future 4.7) available

2011-12-08 Thread Basile Starynkevitch
Hello All, Sorry for the quasi-repeated message (I've send a wrong one just at the start of a fire alarm exercise...) (I had to correct a last-minute bug in the MELT 0.9.2 plugin, so I am releasing the MELT plugin 0.9.2.b for GCC 4.6 & future 4.7) It is my pleasure to announce the MELT plugi

middle end generated builtin functions passing to backend problem

2011-12-08 Thread Feng LI
Hi, I'm extending the i386 instructions by using the builtins in the backend. And generate the builtin functions in the middle end. And would like the generated builtin functions will be transformed to ASM code. I tested the backend with a hand writing builtin functions, it *works* well, but *not

gcc-4.5-20111208 is now available

2011-12-08 Thread gccadmin
Snapshot gcc-4.5-20111208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: middle end generated builtin functions passing to backend problem

2011-12-08 Thread Andrew Pinski
On Thu, Dec 8, 2011 at 1:47 PM, Feng LI wrote: > Hi, > > I'm extending the i386 instructions by using the builtins in the backend. > And generate the builtin functions in the middle end. And would like > the generated builtin functions will be transformed to ASM code. > > I tested the backend with