Quoting Ian Lance Taylor :
DJ Delorie writes:
Except that in this case we want to reverse *only* structures that
represent peripherals, *not* other structures.
I'm sorry, that just seems frigging ridiculous.
I can see arguments to have it either way.
At any rate, once you have an attribut
> I'm tempted to agree. I thought people had stopped numbering bits
> in the wrong order
This has nothing to do with numbering bits, it's about how gcc
allocates bitfields within structures. Consider:
struct {
char a:4;
char b:4;
} Foo;
Nothing says that 'a' is in the LSBs of the byte, or
> > Except that in this case we want to reverse *only* structures that
> > represent peripherals, *not* other structures.
>
> I'm sorry, that just seems frigging ridiculous.
Ridiculous? Why? I see no reason why we should dictate how other
people write their software, or design their chips. Ca
On Mar 9, 2011, at 8:52 PM, Ian Lance Taylor wrote:
> DJ Delorie writes:
>
>> Except that in this case we want to reverse *only* structures that
>> represent peripherals, *not* other structures.
>
> I'm sorry, that just seems frigging ridiculous.
I'm tempted to agree. I thought people had st
DJ Delorie writes:
> Except that in this case we want to reverse *only* structures that
> represent peripherals, *not* other structures.
I'm sorry, that just seems frigging ridiculous.
>> If you need type attributes for this beyond a simple macro, then I agree
>> that they should be target ind
> First I have to say that people should not use bitfields to access
> memory mapped peripherals. However, at least this case is not as
> bad as the volatile bitfields issue.
Agreed, but that doesn't stop people from doing it, and it does lead
to more readable code.
> It seems to me that the an
DJ Delorie writes:
> In the RX chip (and others, of course), the memory-mapped peripherals
> have a fixed bit-ordering independent of the endianness of data.
> However, GCC defines bitfields in structures differently for different
> endians - effectively always beginning allocations with the lowe
Christian Grössler writes:
It seems that gcc wants to create an instruction like "p2=add(p1,p3)".
How can I tell him not to do that?
I tried to fiddle with the "p_d_general_operand" predication and use a
modified one for operand 2, but
at the time the constraint is called
In the RX chip (and others, of course), the memory-mapped peripherals
have a fixed bit-ordering independent of the endianness of data.
However, GCC defines bitfields in structures differently for different
endians - effectively always beginning allocations with the lowest
addressed byte.
To avoid
On 24.02.11 19:27, Christian Grössler wrote:
On 24.02.11 15:38, Jean-Marc Saffroy wrote:
On 02/23/2011 09:52 PM, Christian Grössler wrote:
Hello,
I have a problem with register allocation. Our architecture has some
pointer registers "pX" (24bit)
and some data registers "dX" (32bit). Since poin
On Mar 9, 2011, at 3:35 PM, Georg-Johann Lay wrote:
> Paulo J. Matos schrieb:
>> Hi,
>> I am having some trouble really understanding the working of cc_status.
>> In order to understand it better I was looking at the code for avr under gcc
>> 4.3.
>> My assumption is that set_zn, set_* means tha
Paulo J. Matos schrieb:
Hi,
I am having some trouble really understanding the working of cc_status.
In order to understand it better I was looking at the code for avr under
gcc 4.3.
My assumption is that set_zn, set_* means that an instructions _changes_
these flags. So an instruction that s
On 03/09/2011 10:09 AM, Georg-Johann Lay wrote:
Vladimir Makarov schrieb:
On 03/08/2011 06:36 AM, Georg-Johann Lay wrote:
Returning memory move costs 4 times higher (8 instead of 2) for QI
memory moves, IRA/reload generates code as expected.
Is there any other way than lying about the costs?
Hi,
I am having some trouble really understanding the working of cc_status.
In order to understand it better I was looking at the code for avr under
gcc 4.3.
My assumption is that set_zn, set_* means that an instructions _changes_
these flags. So an instruction that set_zn means that Z and N
Dear Friends,
Andi's document is quite helpful and I may use some information from it in my
tutorial being conducted along with CGO conference at Chamonix, France on 2nd
April. Novices may find it useful to attend it. The relevant details can be
found at:
- http://www.cgo.org/cgo2011/tut
Vladimir Makarov schrieb:
On 03/08/2011 06:36 AM, Georg-Johann Lay wrote:
Georg-Johann Lay schrieb:
In current trunk (r170704), 4.4-branch and 4.5-branch I observe the
following optimization issue in IRA: It saves regs in the frame
instead of in callee-saved registers which would be much smar
On Wed, Mar 9, 2011 at 3:18 PM, Basile Starynkevitch
wrote:
> Hello,
>
> I have a few users reporting bugs (so far on
> gcc-melt-fre...@googlegroups.com in French) for the MELT plugin and branch.
>
> Can these users use GCC bugzilla? If yes, how can they mark the bug as MELT
> specific?
>
> The ty
Hello,
I have a few users reporting bugs (so far on
gcc-melt-fre...@googlegroups.com in French) for the MELT plugin and branch.
Can these users use GCC bugzilla? If yes, how can they mark the bug as MELT
specific?
The typical MELT bug is very often (& sadly) related to the MELT language
itself.
18 matches
Mail list logo
