As I can see in my first post I would like to modify gcc AVR backend to
support new feature – putting vtables into FLASH not SRAM. That’s why I
sent my message here.
Ok, I’ve studied a little bit gcc sources, I’ve found sections
responsible for generating different register loading instruction
It seems the bot or whatever that generates the weekly snapshots
has stopped working for the 4.3 branch. I would have expected a
new snapshot 2-3 days ago but found nothing on the mirrors.
(And there has been commits since the last snapshot.)
/Mikael
2009/6/16 Jeff Law :
> Ian Lance Taylor wrote:
>>
>> daniel tian writes:
>>
>>
>>>
>>> There is a problem I encountered. I port gcc to 32bit RISC. The
>>> LOAD/STORE only has 8bit displacement. If the immediate displacement
>>> larger than 256, the displacement must be force into register. In
>>>
On Wed, 17 Jun 2009, Mikael Pettersson wrote:
> It seems the bot or whatever that generates the weekly snapshots
> has stopped working for the 4.3 branch. I would have expected a
> new snapshot 2-3 days ago but found nothing on the mirrors.
> (And there has been commits since the last snapshot.)
Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
before I add the second_reload macro. There are two problems happened.
1. there is a RTL code which move the memory data to another memory
location. RTL extracted from file *.23.greg :
(insn 128 127 130 7 (set (mem/i:SI (plus:
On Tue, Jun 16, 2009 at 7:30 PM, Basile
STARYNKEVITCH wrote:
> Diego Novillo wrote:
>>
>> On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
>>
>>
>>>
>>> Basile, people are saying that MELT no longer belongs in a branch of
>>> the GCC repository because now that plug-ins are supported, MELT no
>>
Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of
individual snapshots or other individual jobs run from cron, you should
follow the gccadmin and overseers lists, where you would have seen the
message showing the breakage and the subsequent discussion of
Richard Guenther wrote:
On Tue, Jun 16, 2009 at 7:30 PM, Basile
STARYNKEVITCH wrote:
Diego Novillo wrote:
On Tue, Jun 16, 2009 at 13:10, Janis Johnson wrote:
Basile, people are saying that MELT no longer belongs in a branch of
the GCC repository because now that plug-ins are s
daniel tian writes:
> Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
> before I add the second_reload macro. There are two problems happened.
> 1. there is a RTL code which move the memory data to another memory
> location. RTL extracted from file *.23.greg :
>
> (insn 12
On Wed, 17 Jun 2009, Kai Henningsen wrote:
> Joseph S. Myers schrieb:
> > If you are interested in following the fine points of breakage of individual
> > snapshots or other individual jobs run from cron, you should follow the
> > gccadmin and overseers lists, where you would have seen the message
Joseph S. Myers wrote:
> On Wed, 17 Jun 2009, Kai Henningsen wrote:
>
>> Joseph S. Myers schrieb:
>>> If you are interested in following the fine points of breakage of individual
>>> snapshots or other individual jobs run from cron, you should follow the
>>> gccadmin and overseers lists, where you
DJ Delorie writes:
> genrecog uses strings to keep track of where it is, specifically,
> digits and letters. I've got an insn that writes to more than 26
> registers. Would switching to something bigger than [A-Z] be
> difficult? Perhaps using Japanese letters instead of English? ;-)
That so
Adam Nemet writes:
> Ian Lance Taylor writes:
>> truncate has a machine independent meaning.
>
> Yes, I guess with your definition below it does. It's interesting though that
> Jim had said the opposite in the excerpts posted by Jeff:
>
> And a later message from Jim:
>
> Truncate convert
Tomasz Francuz writes:
> Ok, I’ve studied a little bit gcc sources, I’ve found sections
> responsible for generating different register loading instructions,
> and indeed there is no information telling to the compiler how to load
> data
>> From FLASH. This is easy to correct, I suppose. But I h
Dave Korn writes:
> Joseph S. Myers wrote:
>> On Wed, 17 Jun 2009, Kai Henningsen wrote:
>>
>>> Joseph S. Myers schrieb:
If you are interested in following the fine points of breakage of
individual
snapshots or other individual jobs run from cron, you should follow the
gccad
I have created a wiki page to act as a repository of GCC plugins:
http://gcc.gnu.org/wiki/plugins
The page is linked from the main wiki page as well. Feel free to add
new entries and other information that I was too lame to add.
Diego.
Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> Joseph S. Myers wrote:
>>> On Wed, 17 Jun 2009, Kai Henningsen wrote:
>>>
Joseph S. Myers schrieb:
> If you are interested in following the fine points of breakage of
> individual
> snapshots or other individual jobs run from cron
On Wed, 17 Jun 2009, Ian Lance Taylor wrote:
> While "overseers" sounds like it might be a cool list, in actual
> practice most of the traffic consists of "please change my e-mail
> address."
And most of the gccadmin traffic is completely routine messages from cron
- things don't break that ofte
Adam Nemet wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
Adam Nemet writes:
I am trying to understand the checkin by Jeff Law from about 11 years ago:
r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lines
* combine.c (simplify_rtx, c
Hello All
(In case you don't read gcc-patches@)
I just posted in http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01363.html
some thoughts & experiments about gengtype in plugins.
I came to the following tentative conclusions.
All this makes me think that
A. we should generate appropriately a
On Wed, Jun 17, 2009 at 11:15, Basile
STARYNKEVITCH wrote:
>> All this makes me think that
>>
>> A. we should generate appropriately a $gccplugins/gtyp-input-plugins.list
>> B. we should install gengtype as gcc-gengtype at some appropriate place
>> C. we should document that, and update the docume
Ian Lance Taylor writes:
> I'm not entirely sure, but I don't think Jim said the opposite. He said
> that the way truncate works is machine dependent. I said that the
> output of truncate is machine independent. Since truncate is only
> defined for fixed-point modes, I think both statements are
Adam Nemet writes:
> Ian Lance Taylor writes:
>> I'm not entirely sure, but I don't think Jim said the opposite. He said
>> that the way truncate works is machine dependent. I said that the
>> output of truncate is machine independent. Since truncate is only
>> defined for fixed-point modes, I
ASSEZ D'INJUSTICES
Défendez-vous. Cessez d'être les coupables. Avec la Coordination Nationale Des
Indépendants - CNDI - sauvez les "petites" entreprises.
Elles sont le tissu économique de la France, de notre pays, de notre patrie.
Mobilisez-vous. Allez sur le site Internet :
http://www.cndi.fr/
I'd like to be able to specify registers that are safe across function calls
(without the need to save/restore) and I cannot figure out how to do this.
I know that I can set these particular registers to '0' in
CALL_USED_REGISTERS and then remove the call/restore in the
prologue/epilogue, but the
Please ignore this previous message... I found the error in my machine
dependent code.
Dobes wrote:
>
> I'd like to be able to specify registers that are safe across function
> calls (without the need to save/restore) and I cannot figure out how to do
> this. I know that I can set these particu
On Sun, Jun 14, 2009 at 11:17:32AM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 13, 2009 at 10:08:39PM +0200, Jakub Jelinek wrote:
> > I really think we need to do (limited) -fvar-tracking even for -O0, it is
> > really bad that most arguments have wrong locations through the prologue,
> > while a
> That sounds like an awkward insn.
The opcode swaps two register banks. 32 SETs total.
> It would be nice if genrecog at least checked for an out of range
> letter.
Or used "ch-'a' < 32" tests, but would that work with EBCDIC build
machines?
DJ Delorie writes:
>> That sounds like an awkward insn.
>
> The opcode swaps two register banks. 32 SETs total.
Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit
machine, using DImode will cut the number of operands in half.
Ian
> > The opcode swaps two register banks. 32 SETs total.
>
> Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit
> machine, using DImode will cut the number of operands in half.
They're DImode already, but I did figure out a workaround that reduces
it to 16 SETs, so I'm all set.
30 matches
Mail list logo
