[Bug 1001528] New: compat/posix: porting to GCC 4.6

[Bug 1001528] New: compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

           Summary: compat/posix: porting to GCC 4.6
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: minor
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: sergei.gavrikov@gmail.com
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1635)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1635)
Fix new warnings for unused variables

Porting to GCC 4.6 http://gcc.gnu.org/gcc-4.6/porting_to.html
Fixed new warnings in `posix' package.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001528] compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |jifl@ecoscentric.com
         AssignedTo|unassigned@bugs.ecos.source |jifl@ecoscentric.com
                   |ware.org                    |

--- Comment #1 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-11 23:19:11 GMT ---
I'm happy with the mqueue part. I'm less certain about the signal2 change -
this might mean that with GCC 4.6, the assignment of 'x' might be optimised
away. We have to make sure it isn't because of what we're trying to achieve in
that function. Do you have a disassembly of that function when compiled with
GCC 4.6 and -O2 ?

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001528] compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

--- Comment #2 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-12 17:35:57 GMT ---
> I'm happy with the mqueue part. I'm less certain about the signal2
> change - this might mean that with GCC 4.6, the assignment of 'x'
> might be optimised away. We have to make sure it isn't because of what
> we're trying to achieve in that function. Do you have a disassembly of
> that function when compiled with GCC 4.6 and -O2 ?

Thank you for your point. I will investigate next days as I am little
unwell.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001528] compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-13 12:34:09 GMT ---
Sorry, for delayed answer. Snippets are below:

 tests/signal2.c:128
    volatile int x;
    volatile CYG_ADDRESS p=(CYG_ADDRESS) &jbuf;

    do
    {
        x = *(volatile int *)(p);
        p += (CYG_ADDRESS)0x100000;
    } while( p != (CYG_ADDRESS)&jbuf );

 GCC 4.3 (-O2)
 16c:   e58d400c        str     r4, [sp, #12]
 170:   e1a00004        mov     r0, r4
 174:   e59d300c        ldr     r3, [sp, #12]
 178:   e5932000        ldr     r2, [r3]
 17c:   e58d2010        str     r2, [sp, #16]
 180:   e59d300c        ldr     r3, [sp, #12]
 184:   e2833601        add     r3, r3, #1048576        ; 0x100000
 188:   e58d300c        str     r3, [sp, #12]
 18c:   e59d200c        ldr     r2, [sp, #12]
 190:   e1500002        cmp     r0, r2
 194:   1afffff6        bne     174 <main+0x174>

 GCC 4.6 (-O2)
 158:   e58d4014        str     r4, [sp, #20]
 15c:   e59d3014        ldr     r3, [sp, #20]
 160:   e5933000        ldr     r3, [r3]
 164:   e58d3010        str     r3, [sp, #16]
 168:   e59d3014        ldr     r3, [sp, #20]
 16c:   e2833601        add     r3, r3, #1048576        ; 0x100000
 170:   e58d3014        str     r3, [sp, #20]
 174:   e59d3014        ldr     r3, [sp, #20]
 178:   e1540003        cmp     r4, r3
 17c:   1afffff6        bne     15c <main+0x15c>

Thus, new compiler uses less registers, but, GCC 4.6 provides the same
functionality (I tested the loop in GDB, and I got `sigbus' call at the
end with new code). Though, you are right, a using CYGBLD_ATTRIB_UNUSED
for the forced volatile variables would break smart things.

Then, maybe leave signal2 test without the changes as I tested the code
for one CPU only? What is your verdict?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001528] compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-13 14:26:50 GMT ---
Thanks for the disassembly.

(In reply to comment #3)
> 
> Thus, new compiler uses less registers, but, GCC 4.6 provides the same
> functionality (I tested the loop in GDB, and I got `sigbus' call at the
> end with new code). Though, you are right, a using CYGBLD_ATTRIB_UNUSED
> for the forced volatile variables would break smart things.

Well, it _could_ break things if the gcc policy was that even volatile accesses
could be eliminated for things which are both unused and explicitly marked
unused. That appears not to be the case, which is good.

> Then, maybe leave signal2 test without the changes as I tested the code
> for one CPU only? What is your verdict?

No it can go. If GCC thought it was unused and could be discarded it would
definitely get rid of it during optimisation, and that would be true on all
architectures.

So your full patch including signal2 change can go in now, thanks!

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001528] compat/posix: porting to GCC 4.6

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001528

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #5 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-13 14:53:59 GMT ---
Checked-in.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.