AVR Freaks

Answer from atmel:
For the time being from our initial analysis it shows that changing the optimization levels (e.g. -O2/-O3) avoids this issue.

I found the bug listing for this bug and see that it was first reported in 9/2013, and isn't assigned to anyone yet. I guess I'm toast unless I can go back a version.

Hi,

I just hit this issue when recompiling some my old source files for Atmega32. It's a shame that the bug is still not fixed after years, even if it's claimed as "RESOLVED FIXED" on bugzilla

I tried many versions of avr-gcc toolchain (win32) and it seems that all new versions are affected:

4.8.0 from 2013

4.9.2 from official Atmel Studio 7 package

5.2.1 from here

6.1.1 from here

older version 4.7.1 works fine

The problematic code is a switch block with multiple cases. If I comment most of cases out, leave 1 or 2 it passed. Otherwise I got familar error message:

gpsnmea.c:310:1: internal compiler error: in push_reload, at reload.c:1380

Problem code:

  if (strncasecmp_P(str,PSTR("$GPGGA"),6)==0) // Time, position and fix releated data
    {
    if (gps_utc2ltc_shift<0)           // je-li posun LTC zaporny,
      gps_utc2ltc_shift=24+gps_utc2ltc_shift; // preved ho na kladny
    while ((str=strchr(str,','))!=NULL)// opakuj dokud retezec obsahuje carky
      {
      if (*(++str)!=',')               // pokud za carkou hned neni dalsi carka
        {
        switch (param)                 // dekoduj parametr
          {                            // pro dany parametr pouzij specificky format
          case 0 : sscanf_P(str,PSTR("%02u%02u%02u.%u"),&gps_data.utc_time.h,&gps_data.utc_time.m,&gps_data.utc_time.s,&gps_data.utc_time.d); break; // UTC time hhmmss.ddd
          case 1 : sscanf_P(str,PSTR("%02u%02u.%lu"),&gps_data.latitude.d,&gps_data.latitude.m,&gps_data.latitude.dd);
//          if (str[9]==',')
//            gps_data.latitude.dd*=10;
//            break; // latitude llmm.dddd(d)
/*          case 2 : gps_data.latitude.u=*str; break; // latitude type <N|S>
          case 3 : sscanf_P(str,PSTR("%03u%02u.%lu"),&gps_data.longitude.d,&gps_data.longitude.m,&gps_data.longitude.dd); if (str[10]==',') gps_data.longitude.dd*=10; break; // longitude lllmm.dddd(d)
          case 4 : gps_data.longitude.u=*str; break; // longitude type <E|W>
          case 5 : gps_data.fix=atoi(str); break; // 0=not valid, 1=valid SPS, 2=valid DGPS, 3=valid PPS, 6=extrapolovane z predchozi pozice
          case 6 : gps_data.satellites=atoi(str); break; // number of used satellites
          case 7 : sscanf_P(str,PSTR("%u.%u"),&gps_data.hdop[0],&gps_data.hdop[1]); break; // HDOP (Horizontal Dilution Of Precision)
          case 8 : sscanf_P(str,PSTR("%d.%u"),&gps_data.altitude.a,&gps_data.altitude.d); break; // altitude above sea level
          case 9 : gps_data.altitude.u=*str; break; // altitude unit <M>
          case 10 : sscanf_P(str,PSTR("%d.%u"),&gps_data.altitudediff.a,&gps_data.altitudediff.d); break; // difference between WGS-84 elipsoid surface and mean-sea-level altitude*/
          case 11 : gps_data.altitudediff.u=*str; break; // altitudediff unit <M>
          }                            // dalsi parametry ignoruj
        }                              // jinak se parametr nenacte a v promenne zustane puvodni hodnota
      param++;                         // inkrementuj pocitadlo parametru
      }
    return(0);                         // konec
    }

The workaroud with -fno-move-loop-invariants parameter works but how can I be sure it generate proper code and not fail on a bit more comlex code? It seem's to me that avr-gcc is quite buggy :( not my first experience with avr toolchain bug )

OK, sure I know opensource but I think that also Atmel should commit some fixes when they gains from gcc project. If there were no gcc then they have to invest money for developing a commercial compiler or leave this bought on theirs customers (disadvantage compared to other MCU manuf. who provide some free compilers). So presence of gcc is surely positive for Atmel and they should care a bit. I know that e.g. AMD supports other opensource project they benefit from...

Well, so currently there's no other fix than -fno-move-loop-invariants ? Did someone found a case when this parameter doesn't fixed the problem ? I will keep backup of older compiler for such case...

OK, I tried to cut my code to bare bone, try to compile it with params: avr-gcc -g -Wall -Os -mmcu=atmega32 -c -o gpsnmea.o gpsnmea.c

Then try to comment out one of case branches and try again.

</p>
<p>C:\WINAVR\GPS_OLED>avr-gcc -g -Wall -Os -mmcu=atmega32 -c -o gpsnmea.o gpsnmea.c</p>
<p>gpsnmea.c: In function 'gps_parse_string':<br />
gpsnmea.c:51:1: internal compiler error: in push_reload, at reload.c:1380<br />
 }<br />
 ^</p>
<p>gpsnmea.c:51:1: internal compiler error: Segmentation fault</p>
<p>

</p>
<p>//gpsnmea.c</p>
<p> </p>
<p>#include <stdio.h>                     // sprintf,...<br />
#include <stdlib.h>                    // definice standardnich funkci<br />
#include <string.h>                    // fce na praci s daty v pameti<br />
#include <avr/pgmspace.h>              // fce na praci s daty v prog. pameti</p>
<p>//***************** struktura UTC casu **************************************<br />
typedef struct {<br />
  uint8_t h;                              // hodiny [0-23]<br />
  uint8_t m;                              // minuty [0-59]<br />
  uint8_t s;                              // vteriny [0-59]<br />
  uint16_t d;                              // decimalni zlomky vteriny [0-999]<br />
} __attribute__((packed)) GPS_UTC_TIME;</p>
<p>//***************** struktura souradnice ************************************<br />
typedef struct {<br />
  uint8_t d;                              // stupne [0-90/180]<br />
  uint8_t m;                              // minuty [0-59]<br />
  uint32_t dd;                            // decimalni zlomky minut [0-99999]<br />
  char u;                              // typ <N|S|E|W><br />
} __attribute__((packed)) GPS_COORDINATE;</p>
<p>//***************** struktura GPS dat ***************************************<br />
typedef struct {<br />
  GPS_UTC_TIME utc_time;               // UTC cas<br />
  GPS_COORDINATE latitude;             // zemepisna sirka severni/jizni<br />
} __attribute__((packed)) GPS_DATA;</p>
<p>GPS_DATA gps_data;                     // struktura pro ukladani prijatych GPS dat</p>
<p>//***************** zpracuje retezec GPS NMEA a pripadne nastavi prislusne polozky globalni struktury<br />
void gps_parse_string(char *str)       // vraci 0 pokud byl retezec zpracovan a byla nalezena platna data<br />
{<br />
  uint8_t param=0;</p>
<p>  if (strncasecmp_P(str,PSTR("$GPGGA"),6)==0) // Time, position and fix releated data<br />
    {<br />
    while ((str=strchr(str,','))!=NULL)// opakuj dokud retezec obsahuje carky<br />
      {<br />
      if (*(++str)!=',')               // pokud za carkou hned neni dalsi carka<br />
        {<br />
        switch (param)                 // dekoduj parametr<br />
          {                            // pro dany parametr pouzij specificky format<br />
          case 0 : sscanf_P(str,PSTR("%02u%02u%02u.%u"),&gps_data.utc_time.h,&gps_data.utc_time.m,&gps_data.utc_time.s,&gps_data.utc_time.d); break; // UTC time hhmmss.ddd<br />
          case 1 : sscanf_P(str,PSTR("%02u%02u.%lu"),&gps_data.latitude.d,&gps_data.latitude.m,&gps_data.latitude.dd); break; // latitude llmm.dddd(d)<br />
// More case branches removed. If you leave only one, it will compile without push_reload error<br />
          }                            // dalsi parametry ignoruj<br />
        }                              // jinak se parametr nenacte a v promenne zustane puvodni hodnota<br />
      param++;                         // inkrementuj pocitadlo parametru<br />
      }<br />
    }<br />
}</p>
<p> </p>
<p>

I've opened up a new case 71932 on GCC Bugzilla:

https://gcc.gnu.org/bugzilla/sho...

This is the compiler error in push_reload() as opposed to the segmentation fault you are seeing but they may be related since sometimes I've seen bad compiler output (strange results as if registers didn't contain the right contents).  So there's probably an internal compiler bug that may be corrupting memory or executing bad code that is sometimes getting caught and reported as an error in push_reload, sometimes causing a segmentation fault, and sometimes creating bad compiler output with no warning/error.

By the way, I've sometimes (rarely) seen that even setting -fno-move-loop-invariants would not workaround the problem.  In some cases, setting the "__attribute__ ((noinline))" for a called function worked.  Other times combining code (mostly to simplify it) worked around the problem.

I've linked to this AVRFREAKS thread in the above bug report.

I don't know, but I think that in most cases if you make a change in the code or in compiler options that has the compiler error or crash go away then usually the code output will be correct.  The situation I saw where that might not have been the case was where I made changes in the code that made it more, not less, complex.  It may have pushed beyond the type of failure that is caught as an error, but that could have just been coincidental.  When the compiler output was bad, the problems were pretty severe and not subtle, but they will drive you nuts if you think it's a bug in your code since just adding more code to debug it makes it worse, though at that point it's pretty obvious it's not your code at fault.