[Bug c/45207] New: The -Os flag generates wrong code for ARM966e-s

[Bug c/45207] New: The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

We have problems with GCC-4.5.0 and GCC-4.5.1 for ARM when using the "-Os"
optimizer flag. The code crashes due to what seems to be undefined instruction
exception.

If we instead use "-O1" or "-O2" it works fine. Also GCC-4.3.x and GCC-4.4.x
works well.

I also tried to add all excluded -O2 flags when compiling with -Os but this
gave still wrong code.

Our CFLAGS:
-g3 -ggdb3 -gdwarf-2 -mthumb -c -Wall -W -Wextra -Wno-unused-parameter
-mcpu=arm966e-s -Os -mhard-float -mfpu=fpa -ffunction-sections -fdata-sections

I attach build-script for our arm-elf-toolchain built on an intel machine.

Also arm-elf-gdb 7.1 complaints about the elf file when trying to debug:

warning: (Internal error: pc 0x4a42c in read in psymtab, but not in symtab.)

Thanks and Best Regards,
Fredrik Hederstierna


-- 
           Summary: The -Os flag generates wrong code for ARM966e-s
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fredrik dot hederstierna at securitas-direct dot com
GCC target triplet: arm-elf-gcc


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #1 from fredrik dot hederstierna at securitas-direct dot com  2010-08-06 07:20 -------
Created an attachment (id=21421)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21421&action=view)
Script to build arm-elf toolchain


-- 


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

[Bug target/45207] The -Os flag generates wrong code for ARM966e-s

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-06 07:52 -------
Have you tried compiling with -fno-strict-aliasing ?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |wrong-code


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #3 from fredrik dot hederstierna at securitas-direct dot com  2010-08-06 08:36 -------
(In reply to comment #2)
> Have you tried compiling with -fno-strict-aliasing ?

I've tried it now, and it made no difference I'm afraid.
The code got slightly bigger, but behavior is the same as previously.
/Fredrik


-- 

fredrik dot hederstierna at securitas-direct dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fredrik dot hederstierna at
                   |                            |securitas-direct dot com
          Component|target                      |c


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #4 from fredrik dot hederstierna at securitas-direct dot com  2010-08-06 09:09 -------
Hm, I now tried to disable all possible optimization flags, but still "-Os"
does not work, but "-O2" still works!

Does the "-Os" option do anything more that is not controllable from command
line options/flags?

# Disable O1 flags
CFLAGS          +=           -fno-auto-inc-dec 
CFLAGS          +=           -fno-cprop-registers 
CFLAGS          +=           -fno-dce 
CFLAGS          +=           -fno-defer-pop 
CFLAGS          +=           -fno-delayed-branch 
CFLAGS          +=           -fno-dse 
CFLAGS          +=           -fno-guess-branch-probability 
CFLAGS          +=           -fno-if-conversion2 
CFLAGS          +=           -fno-if-conversion 
CFLAGS          +=           -fno-ipa-pure-const 
CFLAGS          +=           -fno-ipa-reference 
CFLAGS          +=           -fno-merge-constants
CFLAGS          +=           -fno-split-wide-types 
CFLAGS          +=           -fno-tree-builtin-call-dce 
CFLAGS          +=           -fno-tree-ccp 
CFLAGS          +=           -fno-tree-ch 
CFLAGS          +=           -fno-tree-copyrename 
CFLAGS          +=           -fno-tree-dce 
CFLAGS          +=           -fno-tree-dominator-opts 
CFLAGS          +=           -fno-tree-dse 
CFLAGS          +=           -fno-tree-forwprop 
CFLAGS          +=           -fno-tree-fre 
CFLAGS          +=           -fno-tree-phiprop 
CFLAGS          +=           -fno-tree-sra 
CFLAGS          +=           -fno-tree-pta 
CFLAGS          +=           -fno-tree-ter 
CFLAGS          +=           -fno-unit-at-a-time

# Disable O2 flags
CFLAGS          +=           -fno-thread-jumps 
CFLAGS          +=           -fno-align-functions  -fno-align-jumps 
CFLAGS          +=           -fno-align-loops  -fno-align-labels 
CFLAGS          +=           -fno-caller-saves 
CFLAGS          +=           -fno-crossjumping 
CFLAGS          +=           -fno-cse-follow-jumps  -fno-cse-skip-blocks 
CFLAGS          +=           -fno-delete-null-pointer-checks 
CFLAGS          +=           -fno-expensive-optimizations 
CFLAGS          +=           -fno-gcse  -fno-gcse-lm  
CFLAGS          +=           -fno-inline-small-functions 
CFLAGS          +=           -fno-indirect-inlining 
CFLAGS          +=           -fno-ipa-sra 
CFLAGS          +=           -fno-optimize-sibling-calls 
CFLAGS          +=           -fno-peephole2 
CFLAGS          +=           -fno-regmove 
CFLAGS          +=           -fno-reorder-blocks  -fno-reorder-functions 
CFLAGS          +=           -fno-rerun-cse-after-loop  
CFLAGS          +=           -fno-sched-interblock  -fno-sched-spec 
CFLAGS          +=           -fno-schedule-insns  -fno-schedule-insns2 
CFLAGS          +=           -fno-strict-aliasing -fno-strict-overflow 
CFLAGS          +=           -fno-tree-switch-conversion 
CFLAGS          +=           -fno-tree-pre 
CFLAGS          +=           -fno-tree-vrp

# Disable flags for debugging purposes
CFLAGS          +=       -fno-omit-frame-pointer -fno-web

The code size increased alot when disabling all this options.

/Fredrik


-- 


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[ramana at gcc dot gnu dot org]

------- Comment #5 from ramana at gcc dot gnu dot org  2010-08-06 09:13 -------
If you don't give us a testcase we can't verify / see what's going wrong here.
Please report bugs as described here. http://gcc.gnu.org/bugs/ .

Thanks,
Ramana


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #6 from fredrik dot hederstierna at securitas-direct dot com  2010-08-06 12:06 -------
Yes you are right, unfortunately I just had problems to break out any small
test case from our sources.

I think I found out what is the source of the problems.
The "-Os" disable alignment of functions. In some case I try to force alignment

void __attribute__((aligned(4))) _irq_off(void);

since we have some thumb->arm trampoline functions to modify cpu-flags.
I guess somehow some functions got thumb-aligned, but I try to investigate this
further.

/Fredrik


-- 


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[siarhei dot siamashka at gmail dot com]

------- Comment #7 from siarhei dot siamashka at gmail dot com  2010-08-06 19:36 -------
Do you have any packed structs? I wonder if the problem could be somehow
related to PR45070. But it's hard to say anything until you narrow down the
problem to a smaller testcase.


-- 

siarhei dot siamashka at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siarhei dot siamashka at
                   |                            |gmail dot com


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

[Bug c/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #8 from fredrik dot hederstierna at securitas-direct dot com  2010-08-09 07:55 -------
I think I found what was the problem, the flags

-mthumb -mcpu=arm966e-s -Os -falign-functions=4

Did not 32-bit-align my thumb->arm trampoline function.
I dont know if -Os win over -falign-functions flag in this case.
Anyway, my function ended up on a 16-bit aligned address and that caused an
abort.

/Fredrik


-- 


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

[Bug target/45207] The -Os flag generates wrong code for ARM966e-s

[fredrik.hederstierna@securitas-direct.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207

Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #9 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
It seems like functions are not always 4-aligned, even if -falign-functions=4
is passed, but I see no problem with this currently. I was running thumb
not-interworking code, and wrote custom ISR handler using ARM-code trampoline
function, but I found a work-around.