Re: MinGW, GCC Vista,
Although the file io.h from MinGW/include has a patch, I still have not be able to use effectively the new build of gcc. I build it from a latop with a semprom and execute it in a desktop pc with a core 2 duo. The result is the same every time, there is a problem installation and it tells that cc1 is not found. Have you already built gcc 3.4.5 and tested it in Vista64? Thanks. -- View this message in context: http://www.nabble.com/MinGW%2C-GCC-Vista%2C-tf3707859.html#a10427219 Sent from the gcc - Dev mailing list archive at Nabble.com.
RE: gcc 4.3 on Interix
Hi Flavell I am sorry for replying so late. If you can detail me the exact scenario where program compiled using gcc3.3 crashes, then we can try to help you. Tell us about the following:- 1: machine spec 2: OS with SP if any 3: program u are trying to compile 4: what options u are passing to compiler. Regarding compiling on 4.1.2, I guess no active support is present for the same, but I could see some bugs filed in bugzilla for people being able to compile gcc on interix. I will try to dig that bug out. I am working on compiling 4.1.2 on SUA (Subsystem for Unix -based Applications) available with Win2k3 R2 and Windows Vista Ultimate/Enterprise SKU. Will let you know when this is done. HTH Thanks Mayank From: Flavell, Conwyn [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 1:21 AM To: Mayank Kumar; [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Subject: gcc 4.3 on Interix Hi Everybody Interix downloads with gcc 3.3 and normally works on all my PC W2000 and XP but I have a XP Dell Processor x86 Family 6 Model 14 Stepping 8 GenuineIntel ~1830 Mhz And gcc 3.3 has a segmentation fault in cc1 in the most basic of programs. So I thought I would try to build GCC 412 on my working XP machine. I downloaded I ran make configure which generated the makefile And then the instructions says make bootstrap but when I try it says do not nkow to make boot strap stop. I tried make and make all but they do nothing but make -dA does produce lots of output so it is running through the make file. Can you briefly tell me what I need to do to generate 412 under interix from a interix environment (running under XP) I use Internix to run a program that collects data from Cisco routers and generates web pages. Regards Conwyn * This email is intended solely for the use of the individual to whom it is addressed and may contain confidential and/or privileged material. Any views or opinions presented are solely those of the author and do not necessarily represent those of AGCO. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Neither AGCO nor the sender accepts any responsibility for viruses and it is your responsibility to scan and virus check the e-mail and its attachment(s) (if any). * AGCO Limited, a limited company, registered in England (registered no.509133) with its registered office at Abbey Park Stoneleigh, Kenilworth CV8 2TQ, England.
Re: Updating an operand in RTL for a builtin function
On 5/4/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Mohamed Shafi writes:
> I am trying to implement a builtin function __macf for a private target.
> I have added the required target hooks for this.
> Say for the following code
>
> int main()
> {
> int operand1 = 2;
> int operand2 = 3;
> int operand3 = 4;
> int result;
>
>/* operand3 = operand3 + (operand1 * operand2)*/
>
> result = __macf(operand1, operand2, operand3);
>
> }
>
> Requirement : I need the value of operand3 and result to be same
> after calling the builtin.
> But this is not happening.
What do you mean, exactly? C only has call by value, and gcc's
builtins can only return one value. Builtins don't change their
arguments. If you want to update one of the arguments you'll have to
pass a pointer to the builtin.
After the builtin i want to have the following operations also to carried out
operand3 = result ;
Since builtins don't change their arguments and since i don't want to
pass the pointers, i will have to write some kind of wrapper function
to do that. Where should i be doing this? in target_expand_builtin
function ? or should it be done in the backend patten of macf builtin
?
Thanks in advance.
Regards,
Shafi
Re: [dataflow] partial register handling
Hi,
On Thu, 10 May 2007, I wrote:
> I have a few problems with the m68k mulsidi3 pattern on the dataflow
> branch.
To illustrate the problem here is what happens during combine:
-(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
(parallel [
-(set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
-(mult:SI (reg/v:SI 33 [ x ])
-(subreg:SI (reg/v:DI 32 [ sum ]) 4)))
-(set (subreg:SI (reg:DI 30 [ D.1547 ]) 0)
-(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg/v:SI
33 [ x ]))
-(sign_extend:DI (subreg:SI (reg/v:DI 32 [ sum ])
4)))
-(const_int 32 [0x20]
-]) 182 {*m68k.md:2733} (expr_list:REG_DEAD (reg/v:SI 33 [ x ])
-(expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
-(nil
+(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4 (set
(subreg:SI (reg:DI 30 [ D.1547 ]) 4)
+(mult:SI (mem/c/i:SI (plus:SI (reg/f:SI 24 %argptr)
+(const_int 16 [0x10])) [3 x+0 S4 A32])
+(subreg:SI (reg/v:DI 32 [ sum ]) 4))) 176 {*m68k.md:2643}
(expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
+(nil)))
The REG_UNUSED note is wrong and thus combine is confused.
Using strict_low_part doesn't make a difference, as DF_REF_PARTIAL isn't
set in this case either, so df thinks the first set is overwritten by
second one and generates this note.
> Currently incorrect code is generated as the DF_REF_PARTIAL bit isn't
> set for its destinations and dataflow thinks both set the register
> completely, thus one destination is set to unused. I could change the
> pattern to include a strict_low_part, but that still wouldn't help due
> to a bug in df_def_record_1().
It may help my understanding of df_def_record_1() to have a few examples
of how the flags should be correctly set (for a 32 bit port):
(set (subreg:SI (reg:DI) 4) ...
DF_REF_READ_WRITE|DF_REF_PARTIAL?
(set (subreg:HI (reg:DI) 6) ...
DF_REF_READ_WRITE?
(set (subreg:HI (reg:SI) 2) ...
DF_REF_READ_WRITE?
(set (strict_low_part (subreg:HI (reg:DI) 6)) ...
DF_REF_READ_WRITE|DF_REF_PARTIAL?
(set (strict_low_part (subreg:HI (reg:SI) 2)) ...
DF_REF_READ_WRITE|DF_REF_PARTIAL?
(set (zero_extract:SI (reg:SI) (const_int 16) (const_int 16)) ...)
DF_REF_READ_WRITE|DF_REF_PARTIAL?
The basic question is maybe how a partial write should exactly be handled.
bye, Roman
Re: [dataflow] partial register handling
On Fri, May 11, 2007 at 01:54:24PM +0200, Roman Zippel wrote:
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (parallel [
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> -(mult:SI (reg/v:SI 33 [ x ])
> -(subreg:SI (reg/v:DI 32 [ sum ]) 4)))
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 0)
> -(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg/v:SI
> 33 [ x ]))
> -(sign_extend:DI (subreg:SI (reg/v:DI 32 [ sum ])
> 4)))
> -(const_int 32 [0x20]
> -]) 182 {*m68k.md:2733} (expr_list:REG_DEAD (reg/v:SI 33 [ x ])
> -(expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
> -(nil
> +(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> +(mult:SI (mem/c/i:SI (plus:SI (reg/f:SI 24 %argptr)
> +(const_int 16 [0x10])) [3 x+0 S4 A32])
> +(subreg:SI (reg/v:DI 32 [ sum ]) 4))) 176 {*m68k.md:2643}
> (expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
> +(nil)))
The first one is the insn pattern right below the mulsidi3 expander,
right? Please give all insn patterns a name to make searches easier.
May I ask why the original insn 7 isn't coded something like
(set (reg:DI 30) (mult:DI (sign_extend:DI (reg:SI 33))
(sign_extend:DI (reg:SI 32
instead?
--
Rask Ingemann Lambertsen
Re: [dataflow] partial register handling
Roman Zippel wrote:
> Hi,
>
> On Thu, 10 May 2007, I wrote:
>
>
>> I have a few problems with the m68k mulsidi3 pattern on the dataflow
>> branch.
>>
>
> To illustrate the problem here is what happens during combine:
>
> -(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (parallel [
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> -(mult:SI (reg/v:SI 33 [ x ])
> -(subreg:SI (reg/v:DI 32 [ sum ]) 4)))
> -(set (subreg:SI (reg:DI 30 [ D.1547 ]) 0)
> -(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg/v:SI
> 33 [ x ]))
> -(sign_extend:DI (subreg:SI (reg/v:DI 32 [ sum ])
> 4)))
> -(const_int 32 [0x20]
> -]) 182 {*m68k.md:2733} (expr_list:REG_DEAD (reg/v:SI 33 [ x ])
> -(expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
> -(nil
> +(insn 7 28 8 2 ../gcc/gcc/testsuite/gcc.c-torture/execute/20001108-1.c:4
> (set (subreg:SI (reg:DI 30 [ D.1547 ]) 4)
> +(mult:SI (mem/c/i:SI (plus:SI (reg/f:SI 24 %argptr)
> +(const_int 16 [0x10])) [3 x+0 S4 A32])
> +(subreg:SI (reg/v:DI 32 [ sum ]) 4))) 176 {*m68k.md:2643}
> (expr_list:REG_UNUSED (reg:DI 30 [ D.1547 ])
> +(nil)))
>
> The REG_UNUSED note is wrong and thus combine is confused.
> Using strict_low_part doesn't make a difference, as DF_REF_PARTIAL isn't
> set in this case either, so df thinks the first set is overwritten by
> second one and generates this note.
>
>
Roman,
There was a debate several months ago on this issue: how much should the
df scanner be a theorem prover with respect to how many bits survive an
operation.
For instance, I could easily add to your list, anding and oring
operations which also preserve bits.
The decision was made that what is done in the dataflow scanner was
sufficient and that the machine descriptions should conform to this.
If you have a pattern that cannot be made to conform to what the df
scanner currently does, then we will certainly reopen this issue. But
the consensus was at the time that this was sufficient and that we did
not want to further burden the scanner.
While I could be argued that this is an arbitrary decision, it is
important to keep the scanning fast and there is a lot of downstream
benefit to imposing some consistency on the md's coding style.
Kenny
>> Currently incorrect code is generated as the DF_REF_PARTIAL bit isn't
>> set for its destinations and dataflow thinks both set the register
>> completely, thus one destination is set to unused. I could change the
>> pattern to include a strict_low_part, but that still wouldn't help due
>> to a bug in df_def_record_1().
>>
>
> It may help my understanding of df_def_record_1() to have a few examples
> of how the flags should be correctly set (for a 32 bit port):
>
> (set (subreg:SI (reg:DI) 4) ...
> DF_REF_READ_WRITE|DF_REF_PARTIAL?
>
> (set (subreg:HI (reg:DI) 6) ...
> DF_REF_READ_WRITE?
>
> (set (subreg:HI (reg:SI) 2) ...
> DF_REF_READ_WRITE?
>
> (set (strict_low_part (subreg:HI (reg:DI) 6)) ...
> DF_REF_READ_WRITE|DF_REF_PARTIAL?
>
> (set (strict_low_part (subreg:HI (reg:SI) 2)) ...
> DF_REF_READ_WRITE|DF_REF_PARTIAL?
>
> (set (zero_extract:SI (reg:SI) (const_int 16) (const_int 16)) ...)
> DF_REF_READ_WRITE|DF_REF_PARTIAL?
>
> The basic question is maybe how a partial write should exactly be handled.
>
> bye, Roman
>
Supporting 'MAC' instruction on gcc v4.1.1
Hello all, I am working on gcc v4.1.1 for a non-gcc target. I want to support 'MAC' instruction (mac OP1, OP2, OP3 => OP3 += OP1 * OP2). I have PLUS, MULT and following MAC pattern, in my target.md file. (define_insn "" [(set (match_operand:SI 0 "data_reg" "=f") (plus:SI (mult:SI (match_operand:SI 1 "data_reg" "f") (match_operand:SI 2 "data_reg" "f")) (match_operand:SI 3 "data_reg" "0")))] "" "mac\\t%1, %2, %3" [(set_attr "type" "arith") (set_attr "length" "2")] ) But for the following example int a = 1; int b = 2; int c = 3; c = c + a * b; the MAC pattern is not getting recognized, instead it is still using PLUS and MULT patterns. I noticed the following point in gcc-internals doc: "Instruction combination pass attempts to combine groups of two or three instructions that are related by data flow into single instructions". Please tell me whether this is feasible in gcc v4.1.1 or not? Am i missing any other changes or additions? Regards, Rahul
Re: [dataflow] partial register handling
On Thu, May 10, 2007 at 07:43:19PM +0200, Roman Zippel wrote: > Looking closer at this I don't think strict_low_part should be required > as splitting DI registers produces a lot of (subreg:SI (reg:DI)) even as > destination, but they only set strictly part of the register. If I look > through i386/m68k I don't see a single (strict_low_part (subreg:SI)). That's because with UNITS_PER_WORD == 4, (subreg:SI (reg:DI) n) is implicitly a strict low part for n == 0 or n == 4. When used as destination, such a subreg is defined as not clobbering anything outside the subreg. -- Rask Ingemann Lambertsen
Re: [dataflow] partial register handling
Hi, On Fri, 11 May 2007, Rask Ingemann Lambertsen wrote: >The first one is the insn pattern right below the mulsidi3 expander, >right? Please give all insn patterns a name to make searches easier. It's on the TODO list. :) >May I ask why the original insn 7 isn't coded something like > > (set (reg:DI 30) (mult:DI (sign_extend:DI (reg:SI 33)) > (sign_extend:DI (reg:SI 32 > > instead? In the long term we want to expose the subreg for better register allocation. It would be possible to initially generate this and split it later (this would also avoid this problem), but this makes only more complicated. So I'm a little hesitant to do this, if we can just generate the final form immediately. bye, Roman
Re: [dataflow] partial register handling
My opinion: (set (subreg:SI (reg:DI) 4) ... DF_REF_READ_WRITE|DF_REF_PARTIAL? yep (set (subreg:HI (reg:DI) 6) ... DF_REF_READ_WRITE? Also PARTIAL. you can rely on the content of the 0-3 word. Likewise for: (set (subreg:HI (reg:DI) 2) ... here you can rely on the content of the 4-7 word. (set (subreg:HI (reg:SI) 2) ... DF_REF_READ_WRITE? yep, only case without PARTIAL (set (strict_low_part (subreg:HI (reg:DI) 6)) ... DF_REF_READ_WRITE|DF_REF_PARTIAL? yep (set (strict_low_part (subreg:HI (reg:SI) 2)) ... DF_REF_READ_WRITE|DF_REF_PARTIAL? yep (set (zero_extract:SI (reg:SI) (const_int 16) (const_int 16)) ...) DF_REF_READ_WRITE|DF_REF_PARTIAL? yep
Re: [dataflow] partial register handling
Hi, On Fri, 11 May 2007, Kenneth Zadeck wrote: > There was a debate several months ago on this issue: how much should the > df scanner be a theorem prover with respect to how many bits survive an > operation. > For instance, I could easily add to your list, anding and oring > operations which also preserve bits. I think that's a different problem, as I don't want to know which bits exactly survive. It's about the information that something survived. If we can't or don't want to prove what survives we can't eliminate previous operations. The problem here is that scanner IMO incorrectly thinks that nothing survives (by not setting the partial bit). bye, Roman
Re: Supporting 'MAC' instruction on gcc v4.1.1
[EMAIL PROTECTED] wrote on 11/05/2007 15:26:16: > Hello all, > > I am working on gcc v4.1.1 for a non-gcc target. I want to support > 'MAC' instruction > (mac OP1, OP2, OP3 => OP3 += OP1 * OP2). > http://gcc.gnu.org/ml/gcc/2007-05/msg00114.html seems relevant to your problem. Revital > > > Regards, > Rahul
Re: Supporting 'MAC' instruction on gcc v4.1.1
On Fri, May 11, 2007 at 05:56:16PM +0530, Rahul wrote: > I have PLUS, MULT and following MAC pattern, in my target.md file. > (define_insn "" > [(set (match_operand:SI 0 "data_reg" "=f") > (plus:SI (mult:SI (match_operand:SI 1 "data_reg" "f") > (match_operand:SI 2 "data_reg" "f")) > (match_operand:SI 3 "data_reg" "0")))] > "" > "mac\\t%1, %2, %3" > [(set_attr "type" "arith") > (set_attr "length" "2")] > ) > > But for the following example > int a = 1; > int b = 2; > int c = 3; > c = c + a * b; > the MAC pattern is not getting recognized, instead it is still using > PLUS and MULT patterns. See what is in the progname.c.*.combine file produced by -fdump-rtl-combine. Double check that your "data_reg" predicate is working. You will make your life easier by giving the insn pattern a name. The RTL dumps and in particular the -S -dp output will be easier to read. -- Rask Ingemann Lambertsen
Re: [dataflow] partial register handling
First of all, scrap my other message... There was a debate several months ago on this issue: how much should the df scanner be a theorem prover with respect to how many bits survive an operation. For instance, I could easily add to your list, anding and oring operations which also preserve bits. The rules should be simple. Bits of the dest reg survive only if one of the following is true. - there is a STRICT_LOW_PART (of a SUBREG) - there is a ZERO_EXTRACT (not necessarily of a SUBREG!) - the subreg is part of a multiword subreg The last point is decided in other parts of the code than the one Roman is touching. So, Roman's change to df_read_modify_subreg_p is wrong; other subregs, in particular (subreg:HI (reg:SI 123) 2), should not be affected. At most, we might want there the more pedantic return (isize > osize && isize > REGMODE_NATURAL_SIZE (GET_MODE (isize)); It seems to me that all is missing is setting DF_REF_PARTIAL for ZERO_EXTRACT. That is - if (GET_CODE (dst) == STRICT_LOW_PART) -dst_in_strict_lowpart = true; + if (GET_CODE (dst) == STRICT_LOW_PART + || GET_CODE (dst) == ZERO_EXTRACT) +flags |= DF_REF_PARTIAL; Paolo
Re: Supporting 'MAC' instruction on gcc v4.1.1
On May 11, 2007, at 08:26, Rahul wrote: But for the following example int a = 1; int b = 2; int c = 3; c = c + a * b; the MAC pattern is not getting recognized, instead it is still using PLUS and MULT patterns. In general, this transformation is not valid, as it has different rounding behavior from the expression with the + and * operations. While fused multiply-add is a very powerful instruction that can be helpful for both speed and accuracy (especially accuracy exceeding native precision), good algorithms may become unstable if fused multiply-add is used when a*b+c is expected or vice versa. So, implementing a builtin (conforming to C99's fma) would seem the best approach. The -ffast-math option, or preferably #pragma STDC CONTRACT ON, could be used to enable the transformation. -Geert
Re: [dataflow] partial register handling
Hi,
On Fri, 11 May 2007, Paolo Bonzini wrote:
> First of all, scrap my other message...
>
> > There was a debate several months ago on this issue: how much should the
> > df scanner be a theorem prover with respect to how many bits survive an
> > operation.
> > For instance, I could easily add to your list, anding and oring
> > operations which also preserve bits.
>
> The rules should be simple. Bits of the dest reg survive only if one of the
> following is true.
>
> - there is a STRICT_LOW_PART (of a SUBREG)
>
> - there is a ZERO_EXTRACT (not necessarily of a SUBREG!)
>
> - the subreg is part of a multiword subreg
>
> The last point is decided in other parts of the code than the one Roman is
> touching. So, Roman's change to df_read_modify_subreg_p is wrong; other
> subregs, in particular (subreg:HI (reg:SI 123) 2), should not be affected. At
> most, we might want there the more pedantic
>
> return (isize > osize
> && isize > REGMODE_NATURAL_SIZE (GET_MODE (isize));
>
>
> It seems to me that all is missing is setting DF_REF_PARTIAL for ZERO_EXTRACT.
> That is
>
> - if (GET_CODE (dst) == STRICT_LOW_PART)
> -dst_in_strict_lowpart = true;
> + if (GET_CODE (dst) == STRICT_LOW_PART
> + || GET_CODE (dst) == ZERO_EXTRACT)
> +flags |= DF_REF_PARTIAL;
That clears up about df_read_modify_subreg_p, thanks.
But I don't think that's enough, with the current loop it would strip the
subreg of a multiword subreg and there is some logic in df_ref_record,
which wouldn't see it. An alternative might be:
while (GET_CODE (dst) == STRICT_LOW_PART
|| GET_CODE (dst) == ZERO_EXTRACT)
{
flags |= DF_REF_READ_WRITE | DF_REF_PARTIAL;
loc = &XEXP (dst, 0);
dst = *loc;
}
if (df_read_modify_subreg_p (dst))
flags |= DF_REF_READ_WRITE | DF_REF_PARTIAL;
That would only leave singleword subreg and paradoxical subreg, if they
should require anything.
One could also restrict STRICT_LOW_PART to subregs, as after reload the
subreg part is usually gone.
bye, Roman
Re: Supporting 'MAC' instruction on gcc v4.1.1
Geert Bosch writes: > > On May 11, 2007, at 08:26, Rahul wrote: > > But for the following example > > int a = 1; > > int b = 2; > > int c = 3; > > c = c + a * b; > > the MAC pattern is not getting recognized, instead it is still using > > PLUS and MULT patterns. > > In general, this transformation is not valid, as it has > different rounding behavior from the expression with the > + and * operations. It shouldn't have. All args are ints, and if we are assuming (as the C standard says) that int overflow is undefined, the transformation is valid. Andrew.
Re: Supporting 'MAC' instruction on gcc v4.1.1
On May 11, 2007, at 11:31, Andrew Haley wrote: It shouldn't have. All args are ints, and if we are assuming (as the C standard says) that int overflow is undefined, the transformation is valid. Aarghh..! I even quoted the part that mentioned ints, but still thought it was about float. Sure, for int this should be fine. Undefinedness in C also isn't really relevant here. Sorry for the noise. -Geert
Re: [dataflow] partial register handling
The rules should be simple. Bits of the dest reg survive only if one of
the following is true.
- there is a STRICT_LOW_PART (of a SUBREG)
- there is a ZERO_EXTRACT (not necessarily of a SUBREG!)
- the subreg is part of a multiword subreg
So, this is a prototype patch that I would like to go in.
Paolo
* df-scan.c (df_read_modify_subreg_p): Use REGMODE_NATURAL_SIZE.
(df_def_record_1): Sets to ZERO_EXTRACT get DF_REF_PARTIAL.
Index: gcc-test-df/base-gcc-src/gcc/df-scan.c
===
--- gcc-test-df/base-gcc-src/gcc/df-scan.c (revision 124539)
+++ gcc-test-df/base-gcc-src/gcc/df-scan.c (working copy)
@@ -2697,12 +2697,15 @@ df_ref_record (struct df_collection_rec
bool
df_read_modify_subreg_p (rtx x)
{
+ enum machine_mode imode, omode;
unsigned int isize, osize;
if (GET_CODE (x) != SUBREG)
return false;
- isize = GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)));
- osize = GET_MODE_SIZE (GET_MODE (x));
- return (isize > osize && isize > UNITS_PER_WORD);
+ imode = GET_MODE (SUBREG_REG (x));
+ omode = GET_MODE (x);
+ isize = GET_MODE_SIZE (imode);
+ osize = GET_MODE_SIZE (omode);
+ return (isize > osize && isize > REGMODE_NATURAL_SIZE (imode));
}
@@ -2751,30 +2754,18 @@ df_def_record_1 (struct df_collection_re
|| GET_CODE (dst) == ZERO_EXTRACT
|| df_read_modify_subreg_p (dst))
{
-#if 0
- /* Strict low part always contains SUBREG, but we do not want to make
-it appear outside, as whole register is always considered. */
- if (GET_CODE (dst) == STRICT_LOW_PART)
- {
- loc = &XEXP (dst, 0);
- dst = *loc;
- }
-#endif
- loc = &XEXP (dst, 0);
- if (GET_CODE (dst) == STRICT_LOW_PART)
- dst_in_strict_lowpart = true;
- dst = *loc;
flags |= DF_REF_READ_WRITE;
+ /* Apart from sets to a subreg of a multi-word register, all
+ partial sets are recognized here. */
+ if (GET_CODE (dst) == STRICT_LOW_PART
+ || GET_CODE (dst) == ZERO_EXTRACT)
+ flags |= DF_REF_PARTIAL;
+
+ loc = &XEXP (dst, 0);
+ dst = *loc;
}
- /* Sets to a subreg of a single word register are partial sets if
- they are wrapped in a strict lowpart, and not partial otherwise.
- */
- if (GET_CODE (dst) == SUBREG && REG_P (SUBREG_REG (dst))
- && dst_in_strict_lowpart)
-flags |= DF_REF_PARTIAL;
-
if (REG_P (dst)
|| (GET_CODE (dst) == SUBREG && REG_P (SUBREG_REG (dst
df_ref_record (collection_rec,
The Linux binutils 2.17.50.0.16 is released
This is the beta release of binutils 2.17.50.0.16 for Linux, which is
based on binutils 2007 0511 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.16 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.17.50.0.15:
1. Update from binutils 2007 0511.
2. Fix objcopy --only-keep-debug and linker multiple BSS sections handling.
PR 4479.
3. Fix "readelf -s -D" for gnu hash. PR 4476.
4. Fix ia64 linker crash with --unresolved-symbols=ignore-all. PR 4409.
5. Improve crc32 support in x86 assembler/dissassembler.
6. Improve displacement handling in x86 dissassembler. PR 4430.
7. Correct PC relative displacement handling in x86-64 dissassembler for
Intel mode. PR 4429.
8. Fix various PPC bugs.
9. Fix various SPU bugs.
10. Fix various ARM bugs.
11. Fix various m68k bugs.
12. Fix various xtensa bugs.
Changes from binutils 2.17.50.0.14:
1. Update from binutils 2007 0418.
2. Support Intel SSE4 instructions.
3. Fix linker --fatal-warnings for --warn-shared-textrel. PR 4304.
4. Improve linker error message to identify linker script error
location. PR 4090.
5. Fix objcopy to allow removing all sections. PR 4348.
6. Don't print addresses of 32-bit targets as 64-bit values on 64bit
host. PR 4292.
7. Improve checking for corrupted input files. PR 4110.
8. Improve alpha linker performance.
9. Add a new linker option, -l:foo.
10. Fix a PPC linker bug. PR 4267.
11. Misc vxworks bug fixes.
12. Misc SH bug fixes.
13. Misc SPU bug fixes.
14. Misc ARM bug fixes.
15. Misc MIPS bug fixes.
16. Misc xtensa bug fixes.
Changes from binutils 2.17.50.0.13:
1. Update from binutils 2007 0322.
2. Fix >16byte nop padding regression in x86 assembler.
3. Fix x86-64 disassembler for xchg. PR 4218.
4. Optimize opcode for x86-64 xchg.
5. Allow register operand with x86 nop.
6. Properly handle holes between sections for PE-COFF. PR 4210.
7. Print more PE-COFF info for objdump -p.
8. Report missing matching LO16 relocation for HI16 relocation in mips
linker.
9. Use PC-relative relocation for Win64.
10. Fix strip for Solaris. PR 3535.
11. Fix a C++ demangler crash.
12. Some m32c update.
13. Fix misc ARM bugs.
Changes from binutils 2.17.50.0.12:
1. Update from binutils 2007 0315.
2. Add EFI/x86-64 support.
3. Fix ELF linker for relocation against STN_UNDEF. PR 3958.
4. Fix ELF linker for SHT_NOBITS section whose VMA > page size. PR 4144.
5. Make assembler and disassembler consistent for "test %eax,%ebx". PR
4027.
6. Fix i386 32bit address wraparound. PR 3966.
7. Allow Linux/i386 linker to read FreeBSD/i386
Re: Updating an operand in RTL for a builtin function
> > > result = __macf(operand1, operand2, operand3); > > > > > > } > > > > > > Requirement : I need the value of operand3 and result to be same > > > after calling the builtin. > > > But this is not happening. > > > > What do you mean, exactly? C only has call by value, and gcc's > > builtins can only return one value. Builtins don't change their > > arguments. If you want to update one of the arguments you'll have to > > pass a pointer to the builtin. > > After the builtin i want to have the following operations also to carried > out operand3 = result ; Why do you want this to happen? It seems very surprising semantics. If at all possible my advice is to not do that. None of the other sets of compiler builtins I know of do this. One of the advantages of using builtins rather than assembly directly is the user can ignore all the weird register constraints of instructions (eg. read-write operands) and the compiler sorts all that out. If you absolutely need these semantics to conform to some third party specification, then I suggest you use a macro wrapper something along the lines of: #define __macf(a, b, c) (a = __builtin_macf(a, b, c)) Paul
RE: Updating an operand in RTL for a builtin function
On 11 May 2007 19:27, Paul Brook wrote: >>> > result = __macf(operand1, operand2, operand3); > >>> > } >>> > >>> > Requirement : I need the value of operand3 and result to be same > >>> after calling the builtin. > But this is not happening. >>> >>> What do you mean, exactly? C only has call by value, and gcc's >>> builtins can only return one value. Builtins don't change their >>> arguments. If you want to update one of the arguments you'll have to >>> pass a pointer to the builtin. >> >> After the builtin i want to have the following operations also to carried >> out operand3 = result ; > > Why do you want this to happen? I think what he means is he wants operand 3 and operand zero to be placed in the same register, hence the "0" constraint. As to quite why it's not working, I don't know. A very similar pattern, only with "=&" modifiers on operand zero, works fine for me under 3.4.4. cheers, DaveK -- Can't think of a witty .sigline today
RE: Updating an operand in RTL for a builtin function
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Dave Korn > Sent: Friday, May 11, 2007 11:32 AM > To: 'Paul Brook'; gcc@gcc.gnu.org > Cc: 'Mohamed Shafi'; 'Andrew Haley' > Subject: RE: Updating an operand in RTL for a builtin function > > > On 11 May 2007 19:27, Paul Brook wrote: > > >>> > result = __macf(operand1, operand2, operand3); > > >>> > } > >>> > > >>> > Requirement : I need the value of operand3 and result > to be same > > >>> after calling the builtin. > But this is not happening. > >>> > >>> What do you mean, exactly? C only has call by value, and gcc's > >>> builtins can only return one value. Builtins don't change their > >>> arguments. If you want to update one of the arguments > you'll have to > >>> pass a pointer to the builtin. > >> > >> After the builtin i want to have the following operations > also to carried > >> out operand3 = result ; > > > > Why do you want this to happen? > > I think what he means is he wants operand 3 and operand > zero to be placed in > the same register, hence the "0" constraint. As to quite why it's not > working, I don't know. A very similar pattern, only with > "=&" modifiers on > operand zero, works fine for me under 3.4.4. > > > cheers, > DaveK > -- > Can't think of a witty .sigline today > > > >>> > result = __macf(operand1, operand2, operand3); > Since operand3 is passed by value, operand3 should not be changed for the above code. Could you re-write your code as this: "operand3 = __macf(operand1, operand2, operand3);" ? Then, operand3 will be updated. Regards, Chaoy-ing
Re: Improper Frame Description Entry - DWARF2 debug info
Rohit Arul Raj wrote: When looking at the dwarf dump, the starting frame address for function "fun" is given as < 0><0:0xc> Assuming you made a beginner mistake, I'd say the problem here is that you ran dwarfdump on a .o file, and you failed to notice that dwarfdump doesn't handle the relocations in a .o file. If you link first, then run dwarfdump on an executable, you should get the right info. Use "objdump -r" to see the relocations. These kinds of problems are easier to diagnose if you give the actual commands you typed. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Updating an operand in RTL for a builtin function
On Friday 11 May 2007, Dave Korn wrote: > On 11 May 2007 19:27, Paul Brook wrote: > >>> > result = __macf(operand1, operand2, operand3); > >> After the builtin i want to have the following operations also to > >> carried out operand3 = result ; > > > > Why do you want this to happen? > > I think what he means is he wants operand 3 and operand zero to be placed > in the same register, hence the "0" constraint. As to quite why it's not > working, I don't know. A very similar pattern, only with "=&" modifiers on > operand zero, works fine for me under 3.4.4. That's an implementation detail of the RTL patterns. It should not effect the semantics of the C builtin function. For example the x86 MME/SSE instructions are two-operand instructions (ie the first instruction operand is overwritten with the result). However the builtins are still expressed as a function that reads two values and returns a third independent value. Paul
GCC 4.2.0 Status Report (2007-05-11)
Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Please let me know the status of these soon. If we can't fix 'em, I'll just proceed with what we've got. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Why are you waiting for this one? RTEMS is not a primary or secondary platform. So there is no reason to wait with the release because of this PR, according to the release criteria (xf. http://gcc.gnu.org/gcc-4.2/criteria.html). Gr. Steven
Re: GCC 4.2.0 Status Report (2007-05-11)
On Sat, May 12, 2007 at 12:05:49AM +0200, Steven Bosscher wrote: > On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >PR 31797: An infinite loop in the compiler while building RTEMS. > >Daniel, I see you've been commenting on this; are you working on the > >fix? If so, do you have an ETA? > > Why are you waiting for this one? RTEMS is not a primary or secondary > platform. So there is no reason to wait with the release because of > this PR, according to the release criteria (xf. > http://gcc.gnu.org/gcc-4.2/criteria.html). As long as there are other blockers (e.g. 30252), I see no reason why RTEMS shouldn't have a chance to fix bootstrap. If there were no other blockers, then there would be an issue.
Re: GCC 4.2.0 Status Report (2007-05-11)
Steven Bosscher wrote: > On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> PR 31797: An infinite loop in the compiler while building RTEMS. >> Daniel, I see you've been commenting on this; are you working on the >> fix? If so, do you have an ETA? > > Why are you waiting for this one? RTEMS is not a primary or secondary > platform. So there is no reason to wait with the release because of > this PR, according to the release criteria (xf. > http://gcc.gnu.org/gcc-4.2/criteria.html). I'm not particularly interested in it because of its RTEMS-ness. Rather, I'm interested in it because it's a new case of the compiler failing to correctly process valid code, not present in previous versions of GCC. The test case is not RTEMS-specific; it's a problem that looks like it could equally well apply to lots of other code out there making use of volatile storage. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: PR 31797: An infinite loop in the compiler while building RTEMS. 1. Can you localize its last output that stops in its internal infinite loop? 2. Or, is there an infinite outputting in the console?
gcc-4.3-20070511 is now available
Snapshot gcc-4.3-20070511 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070511/ 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/trunk revision 124627 You'll find: gcc-4.3-20070511.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070511.tar.bz2 C front end and core compiler gcc-ada-4.3-20070511.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070511.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070511.tar.bz2 C++ front end and runtime gcc-java-4.3-20070511.tar.bz2 Java front end and runtime gcc-objc-4.3-20070511.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070511.tar.bz2The GCC testsuite Diffs from 4.3-20070504 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.
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 11, 2007, at 3:02 PM, Mark Mitchell wrote: Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Please let me know the status of these soon. If we can't fix 'em, I'll just proceed with what we've got. Hi Mark, This one was just filed against 4.2.0: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 It is causing LLVM (at least) to fail to build. Do you think it's worth adding to the list? -bw
Re: Supporting 'MAC' instruction on gcc v4.1.1
> But for the following example > int a = 1; > int b = 2; > int c = 3; > c = c + a * b; > the MAC pattern is not getting recognized, instead it is still using > PLUS and MULT patterns. Your example is bogus. This is optimized to "c = 5" well before we get to RTL. Paul
Re: GCC 4.2.0 Status Report (2007-05-11)
Bill Wendling wrote: > This one was just filed against 4.2.0: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 > > It is causing LLVM (at least) to fail to build. Do you think it's worth > adding to the list? Does it show up anywhere other than Darwin? On the basis of Darwin alone, I would not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 11, 2007, at 5:15 PM, Mark Mitchell wrote: Bill Wendling wrote: This one was just filed against 4.2.0: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903 It is causing LLVM (at least) to fail to build. Do you think it's worth adding to the list? Does it show up anywhere other than Darwin? On the basis of Darwin alone, I would not further hold up the release. That is not to say that I would not consider a patch to fix it, of course. Andrew Pinski wasn't able to reproduce the link error on Linux, and I've only seen it on Darwin. However, as Chris Lattner pointed out, this indicates a fairly serious problem (which shows up even on the Linux build) in that the symbols aren't getting internal linkage (they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. -bw
Re: GCC 4.2.0 Status Report (2007-05-11)
Bill Wendling wrote: > Andrew Pinski wasn't able to reproduce the link error on Linux, and I've > only seen it on Darwin. However, as Chris Lattner pointed out, this > indicates a fairly serious problem (which shows up even on the Linux > build) in that the symbols aren't getting internal linkage (they're in > an anonymous namespace, so should). It could impact performance on large > systems quite a bit. Certainly during linking. Names in anonymous namespaces had external linkage for a long time in G++. Did they have internal linkage in 4.1, or was that introduced (in theory) for 4.2? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
On Fri, May 11, 2007 at 05:21:01PM -0700, Bill Wendling wrote:
> On May 11, 2007, at 5:15 PM, Mark Mitchell wrote:
> >Bill Wendling wrote:
> >>This one was just filed against 4.2.0:
> >>
> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
> >>
> >>It is causing LLVM (at least) to fail to build. Do you think it's
> >>worth
> >>adding to the list?
> >
> >Does it show up anywhere other than Darwin? On the basis of Darwin
> >alone, I would not further hold up the release. That is not to say
> >that
> >I would not consider a patch to fix it, of course.
> >
> Andrew Pinski wasn't able to reproduce the link error on Linux, and
> I've only seen it on Darwin. However, as Chris Lattner pointed out,
> this indicates a fairly serious problem (which shows up even on the
> Linux build) in that the symbols aren't getting internal linkage
> (they're in an anonymous namespace, so should). It could impact
> performance on large systems quite a bit. Certainly during linking.
Shipping FSF releases already have that problem. Just try
---
namespace {
int foo = 0;
}
int bar = foo;
---
and look at the output with 4.1.2.
Re: GCC 4.2.0 Status Report (2007-05-11)
On May 11, 2007, at 5:28 PM, Mark Mitchell wrote: Bill Wendling wrote: Andrew Pinski wasn't able to reproduce the link error on Linux, and I've only seen it on Darwin. However, as Chris Lattner pointed out, this indicates a fairly serious problem (which shows up even on the Linux build) in that the symbols aren't getting internal linkage (they're in an anonymous namespace, so should). It could impact performance on large systems quite a bit. Certainly during linking. Names in anonymous namespaces had external linkage for a long time in G++. Did they have internal linkage in 4.1, or was that introduced (in theory) for 4.2? It was introduced in 4.2. Also, this bug may be specific to typeinfo objects - other symbols seem to be ok. -Chris
Re: GCC 4.2.0 Status Report (2007-05-11)
On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? It's not actually a PRE bug, andrew is right. None of the statements accessing volatile variables end up with has_volatile_ops set on them, which is what is really causing the problem.
Re: GCC 4.2.0 Status Report (2007-05-11)
Daniel Berlin wrote: > On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Every time I think we're almost there with this release, I seem to >> manage to get stuck. :-( However, we're very close: the only PRs that >> I'm waiting for are: >> >> PR 31797: An infinite loop in the compiler while building RTEMS. >> Daniel, I see you've been commenting on this; are you working on the >> fix? If so, do you have an ETA? > > It's not actually a PRE bug, andrew is right. > None of the statements accessing volatile variables end up with > has_volatile_ops set on them, which is what is really causing the > problem. Thanks -- but that doesn't answer my questions. :-) Seriously, what I'm trying to figure out is whether you (or someone) is working on fixing this, so I can get a sense of the tradeoffs between releasing and waiting for a fix. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
Sorry to bring this up so late, but I just tried building the last 4.2.0 prerelease and hit what seems to be a build bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906 paul
Re: GCC 4.2.0 Status Report (2007-05-11)
On Sat, May 12, 2007 at 12:32:25AM -0400, Paul Jarc wrote: > Sorry to bring this up so late, but I just tried building the last > 4.2.0 prerelease and hit what seems to be a build bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906 I don't even think this qualifies as a bug. It's basically an enhancement request, to have a clean way of supporting glibc in an unusual place. You tried a hand-edit, and it didn't work as expected, and you filed a bug. Now you're bringing it up in a thread about release-blocking bugs?
Re: GCC 4.2.0 Status Report (2007-05-11)
Joe Buck <[EMAIL PROTECTED]> wrote: > I don't even think this qualifies as a bug. It's basically an > enhancement request, to have a clean way of supporting glibc in > an unusual place. It works in previous versions going back to 2.95.3, so I'd think it would be a bug, and a regression. But since this is such a rare circumstance, I wouldn't expect it to be a release-blocker. I brought it up only in the hope that it might be transparent to someone and fixed before the release, but I certainly understand if it isn't. paul
