SH2A: "RTV/N Rn" implementation
Hi, RTV/N instruction is one of the new instructions added in the SH2A target. Description : RTV/N instruction performs a return from a subroutine procedure after a transfer from specified general register Rn to R0. That is, after the Rn value is stored in R0, the PC is restored from PR, and processing is resumed from the address indicated by the PC. RTV/N Rn = Rn--->R0 + RTS/N So RTV/N instruction can be used as an optimized return instruction in case of the functions having the return type as INTEGER_TYPE. This instruction moves the return argument of the function from register Rn--->R0 along with RETURN. So there is no need to exclusively transfer the RETURN value of the function to RETURN_REG (R0) before RETURN. We implemented the direct RTL for RTV/N instruction and found that the RTL is not recognized by the GNUSH compiler. It was because the return value is moved from the register Rn--->R0 before the epilogue sequence and RETURN is performed after the epilogue sequence. As the observation goes, all the architectures as incorporated in GCC transfers the RETURN value of a function to RETURN_REG (Rn--->R0) before the epilogue sequence followed by RETURN. We investigated and found that the register transfer Rn--->R0 is done in the top level file "gcc/stmt.c". The function where this transfer is done is expand_value_return (rtx val). RTV/N instruction requires this transfer to be suppressed and using the register Rn in RETURN pattern as "RTV/N Rn". Implementation : We tried to get the register (Rn) transferred to RETURN_REG(R0) from the function expand_value_return (rtx val). This register Rn needs to be used as the operand in "RTV/N Rn" instruction. However register (Rn) in the function expand_value_return (rtx val) is a PSEUDO REGISTER instead of a HARD REGISTER. "RTV/N Rn" expects the register Rn to be a hard register. Any help in implementing this instruction would be highly appreciated. Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune (INDIA) ~~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on June 1, 2007. ~~
Re: kind of regression -fprofile-* between r126538 and r126587
Hi Andrew, after applying the patch the problem was fixed! crafty 'works' after -fprofile-generate/-use like a charm (again)! Thank you :-) Best regards, Thomas On Mon, 16 Jul 2007, Andrew Pinski wrote: On 7/16/07, Janis Johnson <[EMAIL PROTECTED]> wrote: I don't have time right now to look into it, either. I think we have a handle on this regression. See http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01462.html for an approved patch. Thanks, Andrew Pinski
Re: SH2A: "RTV/N Rn" implementation
On Tue, Jul 17, 2007 at 01:12:19PM +0530, Naveen H.S. wrote: > Hi, > > RTV/N instruction is one of the new instructions added in the SH2A > target. > > Description : RTV/N instruction performs a return from a subroutine > procedure after a transfer from specified general register Rn to R0. > That is, after the Rn value is stored in R0, the PC is restored from > PR, and processing is resumed from the address indicated by the PC. > > RTV/N Rn = Rn--->R0 + RTS/N > So RTV/N instruction can be used as an optimized return instruction > in case of the functions having the return type as INTEGER_TYPE. This > instruction moves the return argument of the function from register > Rn--->R0 along with RETURN. So there is no need to exclusively > transfer the RETURN value of the function to RETURN_REG (R0) before > RETURN. [snip] > Any help in implementing this instruction would be highly appreciated. Presumably the main problem here is that combine runs before the epilogue is emitted, leaving no chance for combine to generate RTV/N? My first shot at this would be to emit RTV/N in a dummy form as part of the epilogue and leave the usual Rn--->R0 setup as it is, producing (set (reg R0) (reg Rn)) ... (parallel [ (set (reg R0) (reg R0)) (return) ]) and hope that the rnreg pass changes this to (set (reg R0) (reg Rn)) ... (parallel [ (set (reg R0) (reg Rn)) (return) ]) at which point the first instruction becomes dead and we should get just (parallel [ (set (reg R0) (reg Rn)) (return) ]) which is the RTV/N instruction. Actually, this is something the register allocator should get right, but that doesn't seem to happen any time soon. -- Rask Ingemann Lambertsen
Re: Can realloc be marked as a mallloc-like function?
> On Mon, Jul 16, 2007 at 02:39:39PM -, Wolfram Gloger wrote: > > > int *p; > > > p = malloc (4); > > > *p = 0; > > > p = realloc (p, 4); > > > *p = 1; > > > > By that reasoning, consider: > > > > int *p; > > p = malloc (4); > > *p = 0; > > free(p); > > p = malloc (4); > > *p = 1; > > Except that in the first sequence, the value of *p is retained across > the reallocation, so "*p = 0" is not dead. The two examples aren't > really the same at all. I'm not saying they are the same. But, how does gcc determine that it can move "*p = 0" after realloc()? Does it treat realloc() specially and insert a run-time check to look at its result to compare it with the old pointer? That would seem like a dubious feature totally independent of __attribute_malloc__. Surely you agree that in my second example, "*p = 0" _cannot_ be moved after the call to destroy_something_and_allocate_anotherthing(p)? Regards, Wolfram.
Re: RFH: GPLv3
> > For that matter, I doubt the FSF would answer either. > > But this is simpler; the FSF publishes the releases, so anyone can > compare what they got with what the FSF published, and then ask the > distributor "do you hold the copyright for these differences?" But many companies won't even let their technical people LOOK at software until the licensing is clear, so that's often not practical. > Why would you trust Microsoft, that won't even let you > see the code, and won't idemnify you, but you wouldn't trust a Free > Software vendor, who will let you see the code, and might even be > willing to idemnify you? Seeing the code doesn't make you sure that you know what it's IP status is, unfortunately. I thought Microsoft did indemnify, but I just looked at current EULA's and they don't anymore. So that's a good quesion!
Re: RFH: GPLv3
> > If A obtains software from the FSF and distributes it to B, who > > distributes it to C who, in turn, distributes it to D, there is a > > license between A and the FSF, B and C, C and B, and D and C. > > If it were so and any of them infringes on the license, then all > downstream users would have their licenses at risk. This situation > would be akin to sub-licensing. But this is not how the GPL works. As I said, the purpose (and need!) for those licenses is so that you can know that what you are getting IS GPl'ed software: each is certifying to the person they gave it to that there is no other IP involved.
Re: RFH: GPLv3
[EMAIL PROTECTED] (Richard Kenner) writes: >> Seems simple: the COPYING file contains the conditions, and all files >> have the same as well. And it's all directly from the copyright holder. > > Except quite often it ISN'T direct from the copyright holder. E.g., a > RedHat or Debian distribution. Different story, I'm interested in the direct case. > Some statement that can be viewed in the context of a contractual > relationship between the parties. It seems it doesn't apply in my country in this case, a contract requires conditions of contract known to both parties at the time of making the agreement. -- Krzysztof Halasa
Re: Efficiently encoding a hierarchy
On 7/14/07 7:14 PM, Kannan Goundan wrote: > - A (0,5) > - B (1,1) > - C (2,4) > - D (3,3) > - E (4,4) > - F (5,5) > - G (6,7) > - H (7,7) > > A given instance is of type "C" if its "code" field is between 2 and 4, > inclusive. Interesting, thanks. In this case, we probably should rename subcode as it really is a set of flags, which in some cases happen to be code from the 'tree' data structures. The hierarchy is actually flat. We use code ranges in a way similar to your proposal to group related codes. For instance, all the codes that take operands have consecutive numbers. Admittedly, this is fairly primitive but so is the language we have to deal with.
plugin branch initial commit
Hi All, On behalf of Sean I've made the initial commit to the gcc plugin branch. This work directly applies to the paper that he'll be giving at the summit this week. If people want to try out the code and or just look and see what direction he's going. If you have any questions or comments on the code please let him know - if you're at the summit and want to know how to use it just ask him! Otherwise I'm sure he'd like mail. The branch is at: svn://gcc.gnu.org/svn/gcc/branches/plugin -eric
GPL exception for fptr.c and milli64.s
John -- RMS has OK'd adding the license exception to fptr.c and milli64.s. Please apply your patch. It is OK to do this on the 4.2 branch, too, even though that's otherwise locked down for release. However, I will not be doing an RC3, so please make sure that the files still compile with the change. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
4.2 branch frozen for release
I plan to spin the GCC 4.2.1 release tomorrow. Please do not make any further changes to the branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Execute test fails in gcc testsuite
I am working on the testsuite for a new crosscompiler hosted on x86 Platform, While performing execute test using gcc testsuite, I am getting the error message in execute test /tmp/2112-1.x0: /tmp/2112-1.x0: cannot execute binary file I know, have to use cross compiler simulator, for executing $Arch-sim /tmp/2112-1.x0 But I don't know where to mention this configuration. how can I pass the execute test because the target application only can run under simulator, I'd also looked into the c-torture.exp under the lib dir of the testsuite source, suppose it depend on the call to gcc-load(.). But still no hint to understand the syntax staff of expect. maybe I'm wrong totally, thanks in advance for any suggestion. Please help me. --Venkat DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission. E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Consulting Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside.
RE: SH2A: "RTV/N Rn" implementation
Hi, >> My first shot at this would be to emit RTV/N in a dummy form as >> part of the epilogue and leave the usual Rn--->R0 setup as it is, >> producing >> (set (reg R0) (reg Rn)) ... >> (parallel [ >> (set (reg R0) (reg R0)) >> (return) >> ]) >> and hope that the rnreg pass changes this to >> (set (reg R0) (reg Rn)) ... >> (parallel [ >> (set (reg R0) (reg Rn)) >> (return) >> ]) Thanks for your valuable suggestion. We had implemented an insn as:- (define_insn "return_rtv" [(parallel [ (set (reg:SI R0_REG) (match_operand:SI "register_operand" "r")) (return)])] We modified the implementation after the suggestion as:- (define_insn "return_rtv" [(parallel [ (set (reg:SI R0_REG) (reg:SI R0_REG)) (return)])] The complier still did not recognize the RTL pattern and the RTV/N Rn instruction was not generated. Can you please comment on the above modifications? Regards, Naveen.H.S. KPIT Cummins Infosystems Ltd, Pune (INDIA) ~~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on June 1, 2007. ~~
