Extremely simple code leads to GCC error: "unrecognizable insn"

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I hit a compiler bug while coding for an AVR32 GCC project with Atmel Studio 7.0.634; after a bit of tinkering I could reproduce it with a minimal test:

int result;

void test(float f)
{
    if (f < 0.0f) f = 0.0f;
    result = f;
}

int main (void)
{
    test(0.0f);
}

 

This is the error text:

error: unrecognizable insn:
    (insn 10 8 11 3 ../src/main.c:13 (set (reg:SF 24)
            (if_then_else:SF (ge (reg/v:SF 22 [ f ])
                    (reg:SF 25))
                (reg/v:SF 22 [ f ])
                (const_double:SF 0 [0x0] 0.0 [0x0.0p+0]))) -1 (nil))
error: in extract_insn, at recog.c:2048

 

This error happens when the option -ffast-math is added to the compilation options, while all the other options are left as defaults set by Atmel Studio 7.0.634 on a newly created C project.

This is the compiler line, broken down into lines for easier reading:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr32\avr32-gnu-toolchain\bin\avr32-gcc.exe"
-x c -DBOARD=USER_BOARD -DDEBUG
-I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\UC3C_DFP\1.0.42\include"
-I"../common/applications/user_application/user_board/config"
-I"../src/ASF/avr32/utils" -I"../src/config" -I"../src/ASF/common/boards"
-I"../src/ASF/avr32/utils/preprocessor" -I"../src/ASF/avr32/drivers/intc"
-I"../src/ASF/common/utils" -I"../src" -I"../src/ASF/common/boards/user_board"
-O1 -fdata-sections -ffunction-sections -fdata-sections -ffast-math -masm-addr-pseudos
-g3 -Wall -mpart=uc3c1512c -c -std=gnu99 -fno-strict-aliasing -Wstrict-prototypes
-Wmissing-prototypes -Werror-implicit-function-declaration -Wpointer-arith
-mrelax -mno-cond-exec-before-reload -MD -MP -MF
"src/main.d" -MT"src/main.d" -MT"src/main.o" -o "src/main.o" "../src/main.c"

 

Compiler version:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr32\avr32-gnu-toolchain\bin\avr32-gcc.exe" --version
avr32-gcc.exe (AVR_32_bit_GNU_Toolchain_3.4.3_820) 4.4.7

 

I have found several old bug reports with similar error messages, and after all I guess this is probably a bug which may have been solved on more recent GCC versions, but 4.4.7 is the one which comes integrated with current Atmel Studio.

Instead of filling a bug report on that old version of GCC, I think that it may be more sensible to ask Atmel to update their version of GCC. This has also been mentioned before in this forum...

 

Do you think (because of previous attempts) that it is a lost cause to ask Atmel about upgrading their bundled version of GCC?

Meanwhile, is it possible to download an up-to-date version of GCC for AVR32? I only found very old downloads of WinAVR from 2010... that's an eternity in the software world.

 

See you!

 

 


EDIT

 

I found this useful blog post: http://andybrown.me.uk/2015/03/0...

where the author provides a compiled build of avr-gcc 4.9.2 for Windows.

 

That's great, however it's not useful with Atmel Studio because there are some options which are not recognized by the new GCC:

error: unrecognized command line option '-mpart=uc3c1512c'
error: unrecognized command line option '-masm-addr-pseudos'
error: unrecognized command line option '-mno-cond-exec-before-reload'

I will try to "mask" these options and substitute them with the equivalent ones in the new GCC version, if at all possible. However I haven't found yet a way to tell GCC to ignore any unrecognized option...

Last Edited: Sun. Dec 13, 2015 - 12:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can't use avr-gcc (for the AVR line of 8-bit MCU's) , as a replacement for avr32-gcc (for the UC3's and other avr32 MCU's)

 

/Bingo

 

Last Edited: Sun. Dec 13, 2015 - 05:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:

You can't use avr-gcc (for the AVR line of 8-bit MCU's) , as a replacement for avr32-gcc (for the UC3's and other avr32 MCU's)

 

It seems now so obvious after you pointed it out... I got it wrong while reading in the website that "The binaries are 32-bit"... Now it's clear to me that it means the actual executable files, not the platform they are cross-compiling for.

 

After reading on the Wikipedia about AVR32 and how it seems to be an architecture exclusively used by Atmel, and not finding any kind of independent product website for the AVR32 toolchain, I have filed a support request on the Atmel AVR 32-bit GNU Toolchain support pagehttp://www.atmel.com/design-supp...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does seem odd that Atmel don't seem to be issuing 4.9.2 for AVR32 as they have for AVR8 but have stuck with some very old and out of date compiler for UC3.

 

Presumably they only re-engineer the compiler when new models of UC3 are added and that hasn't happened so they just rest on their laurels?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
[...] when new models of UC3 are added and that hasn't happened[...]

I realise this might be seen as FUDding, but isn't this fact a hint about the possible future of the UC3 family?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I realise this might be seen as FUDding, but isn't this fact a hint about the possible future of the UC3 family?

AFAIK the AVR32 effectively died when they pulled the AP7000 before it even got started. The UC3s were just something that "came out in the wash".

 

It's got to be very hard to make an "ARM beater" these days I think. (perhaps witnessed by the fact that in recent years most Atmel release have either been towards the lowest end of the AVR8 range or SAM devices (which low end AVRs don't really compete with)). I think Atmel know which side their bread is buttered!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The higher-end touch controllers use AVR32; eg, 

 

http://www.atmel.com/devices/mXT...

 

When they start switching them to ARM, I guess the writing will be on the wall for AVR32 ... ?

 

(I wonder if the new owners might hasten that demise?)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...