Hello,
I experienced "asm operand requires impossible reload" error in our private
porting.
After digging into the reloading pass, I found something a bit fishy.
The error message is produced in reload_as_needed function (reload1.c)
...
/* If this was an ASM, make sure that all
On Thu, Apr 30, 2009 at 11:39, Janis Johnson wrote:
Thanks to Janis, Andrew, and David.
I see inside the script all you say, but it seems to be throwing up on
some ill-formed screen output from some of the tests, e.g.,
gawk: cmd. line:50: { next; }
gawk: cmd. line:50: ^ `next' used in E
Hello,
The GCC source tree is getting really big. We currently have in gcc/:
- 337 .c files
- 171 .h files
Personally, I think the source tree is quite a mess, the way it is
now. A long time ago (I can't find the threads involved) there was
some discussion about re-ordering the source tree a b
I'm in favor of such a reorganization, but would suggest:
(1) tree-* to go to gcc/tree-opt
(2) Not distinguish between the various rtl passes (why is sched "code
generation", for example?) and put all in gcc/rtl
(3) Not do this:
> - basic intermediate language support stays in gcc/ or goes to gc
2009/5/1 Steven Bosscher :
> Hello,
>
> Now that GCC uses subversion, we can move files around without
> destroying the file revision history, right? And we are in stage1, the
> perfect time for Big Changes like re-ordering the source tree.
If you going to tackle this, I would suggest to start wit
I am working on Cortex-A9 and M3 of ARM. I am using gcc 4.4.0, uClibc
0.9.30.1 and binutils 2.19.1 and building it for Cortex-m3. While
building for m3 if I specify arch as armv7-m alonmg with cpu
cortex-m3, the build fails.
Using the same set, if I build the toolchain for Cortex-A9
(cpu=cortex-a9
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nitin Garg
> Sent: 01 May 2009 14:11
> To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org
> Subject: Problem with gcc-4.4.0 with Cortex-m3 and cortex-a9 cpu
>
> I am working on Cortex-A9 and M3 of ARM
On Fri, 1 May 2009, Steven Bosscher wrote:
> - c-* go to gcc/c (including c-common.*, 29 files)
I still suggest using a separate c-family/ directory for those files also
shared with C++. There are some cleanups that need doing of files that
include C headers that shouldn't, and of c-family fil
On Fri, 1 May 2009, Joseph S. Myers wrote:
> On Fri, 1 May 2009, Steven Bosscher wrote:
>
> > - c-* go to gcc/c (including c-common.*, 29 files)
>
> I still suggest using a separate c-family/ directory for those files also
> shared with C++. There are some cleanups that need doing of files tha
On Fri, May 1, 2009 at 3:54 PM, Joseph S. Myers wrote:
> On Fri, 1 May 2009, Joseph S. Myers wrote:
>
>> On Fri, 1 May 2009, Steven Bosscher wrote:
>>
>> > - c-* go to gcc/c (including c-common.*, 29 files)
>>
>> I still suggest using a separate c-family/ directory for those files also
>> shared w
On Fri, 1 May 2009, Steven Bosscher wrote:
> Eh, ouch.
>
> I'll see if I can clean this up. I don't believe for 90% of these
> files that they should include c-common.h / c-tree.h. Looks like
> history and the usual carelessness when adding #include lines to new
> files/passes.
Thanks! I agre
"Bingfeng Mei" writes:
> I experienced "asm operand requires impossible reload" error in our private
> porting.
> After digging into the reloading pass, I found something a bit fishy.
>
> The error message is produced in reload_as_needed function (reload1.c)
>
> ...
> /* If this wa
> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com]
> Sent: 01 May 2009 15:32
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; bernd.schm...@analog.com; weig...@de.ibm.com
> Subject: Re: Reload problem: asm operand requires impossible reload
>
> "Bingfeng Mei" writes:
>
>
"Bingfeng Mei" writes:
> Actually, they do contain references to pseudo-registers. Only in following
> code (reload function in reload1.c, after the reload_as_needed function
> that emits error message), pseudo registers are replaced with requivalent
> memory operands.
Yes, but the insns generat
On Fri, May 1, 2009 at 4:13 PM, Joseph S. Myers wrote:
> On Fri, 1 May 2009, Steven Bosscher wrote:
>
>> Eh, ouch.
>>
>> I'll see if I can clean this up. I don't believe for 90% of these
>> files that they should include c-common.h / c-tree.h. Looks like
>> history and the usual carelessness whe
On Fri, 1 May 2009, Steven Bosscher wrote:
> Actually nothing uses it, except one case of %qE. And some passes
> forgot to include splay-tree.h but got it via c-*.h.
There should be no problem with %qE in non-front-end files, since:
2009-04-23 Rafael Avila de Espindola
* c-format.c
On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers wrote:
> On Fri, 1 May 2009, Steven Bosscher wrote:
>
>> Actually nothing uses it, except one case of %qE. And some passes
>> forgot to include splay-tree.h but got it via c-*.h.
>
> There should be no problem with %qE in non-front-end files, since:
On Fri, 1 May 2009, Steven Bosscher wrote:
> On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers
> wrote:
> > On Fri, 1 May 2009, Steven Bosscher wrote:
> >
> >> Actually nothing uses it, except one case of %qE. And some passes
> >> forgot to include splay-tree.h but got it via c-*.h.
> >
> > There
On Fri, May 1, 2009 at 7:01 PM, Joseph S. Myers wrote:
> On Fri, 1 May 2009, Steven Bosscher wrote:
>
>> On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers
>> wrote:
>> > On Fri, 1 May 2009, Steven Bosscher wrote:
>> >
>> >> Actually nothing uses it, except one case of %qE. And some passes
>> >> f
On Fri, May 1, 2009 at 2:05 PM, Steven Bosscher wrote:
> Hello,
>
> The GCC source tree is getting really big. We currently have in gcc/:
>
> - 337 .c files
> - 171 .h files
>
> Personally, I think the source tree is quite a mess, the way it is
> now. A long time ago (I can't find the threads in
Richard Guenther wrote:
> Branches will get confused. SVN does not really track file moves. So
> I think this is not a stage1 but more a stage3 thing.
>
> It also will make grepping even more painful than it is now (remember
> that ada change to introduce a 3rd directory level here ...).
>
> I
> On Fri, May 1, 2009 at 2:05 PM, Steven Bosscher wrote:
> > Hello,
> >
> > The GCC source tree is getting really big. We currently have in gcc/:
> >
> > - 337 .c files
> > - 171 .h files
> >
> > Personally, I think the source tree is quite a mess, the way it is
> > now. A long time ago (I can't
Yes, I have done that and now am looking to limit those numbers. For
example, I don't copy back the ones that are not live-out registers.
It works well but I am have an issue when recompiling the whole
compiler.
I've simplified this to this, if in my reorg function, I do only this :
FOR_EACH
Ok, I added a df_analyze at the beginning of my target reorg function
and now it works. Is there anything I should add to cleanup afterwards
?
Sorry about this, I'm slowly learning different parts of the GCC
compiler as I go,
Thanks again for all your help,
Jc
On Fri, May 1, 2009 at 4:33 PM, Jean
On Fri, May 1, 2009 at 3:54 PM, Joseph S. Myers wrote:
> attribs.c:#include "c-common.h"
> cgraphunit.c:#include "c-common.h"
> ipa-pure-const.c:#include "c-common.h"
> ipa-reference.c:#include "c-common.h"
> ipa-struct-reorg.c:#include "c-tree.h"
> ipa-struct-reorg.c:#include "c-common.h"
> ipa-t
> Ok, I added a df_analyze at the beginning of my target reorg function
> and now it works. Is there anything I should add to cleanup afterwards
> ?
As far as DF is concerned, no, probably nothing.
--
Eric Botcazou
On Fri, 1 May 2009, Steven Bosscher wrote:
> > And these are the problem inclusions of files specific to C and ObjC from
> > files also shared with C++:
> >
> > c-common.c:#include "c-tree.h"
> > c-dump.c:#include "c-tree.h"
> > c-gimplify.c:#include "c-tree.h"
> > c-lex.c:#include "c-tree.h"
> >
27 matches
Mail list logo
