Bug 28568 - compiler generates incorrect ARM instructions when using long bitfields
compiler generates incorrect ARM instructions when using long bitfields
Status: RESOLVED DUPLICATE of bug 23623
Product: gcc
Classification: Unclassified
Component: target
4.1.1
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-02 10:16 UTC by Jason Morgan
Modified: 2006-10-03 16:25 UTC (History)
3 users (show)

See Also:
Host:
Target: arm-elf
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Morgan 2006-08-02 10:16:57 UTC
#define __REG32 volatile unsigend long

typedef struct
{
  __REG32 Bit0 :1;
  __REG32 Bit1 :1;
  ...etc...
  __REG32 Bit31 :1;
}__Bitfield;

#define ADDRESS <address of my register>

#define REG (*( __REG32 *)(ADDRESS))
#define REG_bit (*(__Bitfield *)&REG)

When I access the register using the bitfield I get the code like the following

LCD_bit.Backlight=1;		//??
     358:	e3a0320e 	mov	r3, #-536870912	; 0xe0000000
     35c:	e283390a 	add	r3, r3, #163840	; 0x28000
     360:	e5d32001 	ldrb	r2, [r3, #1]
     364:	e3822004 	orr	r2, r2, #4	; 0x4
     368:	e5c32001 	strb	r2, [r3, #1]
Comment 1 Richard Earnshaw 2006-08-02 10:38:15 UTC
Please provide a fully compilable testcase that demonstrates the bug.
Comment 2 Pawel Sikora 2006-08-02 10:58:50 UTC
(In reply to comment #0)
> #define __REG32 volatile unsigend long
> 
> typedef struct
> {
>   __REG32 Bit0 :1;
>   __REG32 Bit1 :1;
>   ...etc...
>   __REG32 Bit31 :1;
> }__Bitfield;
> 
> #define ADDRESS <address of my register>
> 
> #define REG (*( __REG32 *)(ADDRESS))
> #define REG_bit (*(__Bitfield *)&REG)
> 
> When I access the register using the bitfield I get the code like the following
> 
> LCD_bit.Backlight=1;            //??
>      358:       e3a0320e        mov     r3, #-536870912 ; 0xe0000000
>      35c:       e283390a        add     r3, r3, #163840 ; 0x28000
>      360:       e5d32001        ldrb    r2, [r3, #1]
>      364:       e3822004        orr     r2, r2, #4      ; 0x4
>      368:       e5c32001        strb    r2, [r3, #1]
> 

this code isn't wrong. gcc doesn't know that is a register
mapped into arm address space which requires full-word access.
imo this is a dup of PR23623.
Comment 3 Jason Morgan 2006-08-02 11:30:13 UTC
Indeed it is.

I didn't mean to post this and was still researching the problem when I accidently posted it.  I found PR23623 shortly afterwards.

What is the status of PR23624.   I see there was a checkin, what do I have to do to make use of the change?

*** This bug has been marked as a duplicate of 23623 ***
Comment 4 Richard Earnshaw 2006-08-02 12:35:11 UTC
> What is the status of PR23624.   I see there was a checkin, what do I have to
> do to make use of the change?


You have to convert your code/system to use the EABI version of GCC; or you have to modify your source so that it doesn't use volatile bitfields.  The EABI for ARM mandates the behaviour of volatile bitfields, but the arm-elf configuration does not use that ABI and has different semantics in this area.
Comment 5 Jason Morgan 2006-08-02 12:56:48 UTC
The problem is that I am porting code from the IAR systems compiler that makes large use of bitfields to access registers.  Obviously it handles bitfields correctly. And I don't particularly want to re-write every access.

Where do I obtain EABI and what effect will it have on my toolchain?

Is there any plan or project to merge the resolution to PR23623 back into gcc 4.1.1
Comment 6 Richard Earnshaw 2006-09-11 12:14:33 UTC
Subject: Re:  compiler generates incorrect ARM instructions
	when using long bitfields

On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot
com wrote:

> Where do I obtain EABI and what effect will it have on my toolchain?

http://www.arm.com/products/DevTools/ABI.html

> Is there any plan or project to merge the resolution to PR23623 back into gcc
> 4.1.1

No, this doesn't fit the critera for a regression, so it won't be fixed
in FSF releases.

However, I think the CodeSourcery distributions have this feature in a
4.1 build.



Comment 7 Jason Morgan 2006-09-17 08:47:06 UTC
Subject: RE:  compiler generates incorrect ARM instructions when using long bitfields

Why not? What are the criteria?  It is obviously wrong and would be so
simple to fix, even optionally with a
runtime option.

-----Original Message-----
From: rearnsha at arm dot com [mailto:gcc-bugzilla@gcc.gnu.org]
Sent: 11 September 2006 13:15
To: jason.morgan@vpnsolutions.uk.com
Subject: [Bug c/28568] compiler generates incorrect ARM instructions
when using long bitfields




------- Comment #6 from rearnsha at arm dot com  2006-09-11 12:14 -------
Subject: Re:  compiler generates incorrect ARM instructions
        when using long bitfields

On Wed, 2006-08-02 at 13:56, jason dot morgan at vpnsolutions dot uk dot
com wrote:

> Where do I obtain EABI and what effect will it have on my toolchain?

http://www.arm.com/products/DevTools/ABI.html

> Is there any plan or project to merge the resolution to PR23623 back into
gcc
> 4.1.1

No, this doesn't fit the critera for a regression, so it won't be fixed
in FSF releases.

However, I think the CodeSourcery distributions have this feature in a
4.1 build.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.

Comment 8 Andrew Pinski 2006-09-17 08:51:45 UTC
(In reply to comment #7)
> Subject: RE:  compiler generates incorrect ARM instructions when using long
> bitfields
> 
> Why not? What are the criteria?  It is obviously wrong and would be so
> simple to fix, even optionally with a
> runtime option.

It just is not a regression since it has been wrong since the begining of time for GCC.
Comment 9 Jason Morgan 2006-09-17 15:14:54 UTC
Subject: RE:  compiler generates incorrect ARM instructions when using long bitfields

Surely that's the definition of a bug?

I've heard of "If it ain't broke, don't fix it.."  but never "If it's always
been broke, its probably supposed to be like that.."  Its a bit like the guy
with a knackered car that never fixes it because "It's always made that
noise"

:)


j.


-----Original Message-----
From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org]
Sent: 17 September 2006 09:52
To: jason.morgan@vpnsolutions.uk.com
Subject: [Bug target/28568] compiler generates incorrect ARM
instructions when using long bitfields




------- Comment #8 from pinskia at gcc dot gnu dot org  2006-09-17
08:51 -------
(In reply to comment #7)
> Subject: RE:  compiler generates incorrect ARM instructions when using
long
> bitfields
>
> Why not? What are the criteria?  It is obviously wrong and would be so
> simple to fix, even optionally with a
> runtime option.

It just is not a regression since it has been wrong since the begining of
time
for GCC.


--

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
          Component|c                           |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
You reported the bug, or are watching the reporter.

Comment 10 Andrew Pinski 2006-09-17 15:21:00 UTC
(In reply to comment #9)
> Subject: RE:  compiler generates incorrect ARM instructions when using long
> bitfields
> 
> Surely that's the definition of a bug?
> I've heard of "If it ain't broke, don't fix it.."  but never "If it's always
> been broke, its probably supposed to be like that.."  Its a bit like the guy
> with a knackered car that never fixes it because "It's always made that
> noise"

Except it is fixed and really it is not a bug for most ABIs, only the ARM EABI which is new for GCC to support recently.
Comment 11 Richard Earnshaw 2006-10-03 16:25:27 UTC
(In reply to comment #7)
> Subject: RE:  compiler generates incorrect ARM instructions when using long
> bitfields
> 
> Why not? What are the criteria?  

Because it isn't a regression.

A regression is when all of the following are satisfied:

a) It's a bug
b) A previous release of the compiler supported the compiler configuration
c) That previous release produced correct code
d) This release produces the wrong code

In this case b) does not hold and hence c) can't either.