Atmel Studio 6.2 issue "push_reload, at reload.c:1360&q

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

Hi,
I have a project that did compile with Atmel Studio 6.1 without any problem. I upgraded to Atmel Studio 6.2 and I am getting the following error:

Error: in push_reload, at reload.c:1360"

has any body encountered this error?

I am using xmega256d3

I unloaded 6.2 and then 6.1 is giving me the same error. I unloaded 6.1 and reloaded it running the setup and I am still having this issue. I cannot see the file "reload.c" anywhere and I am stuck now.

Any help would be greatly appreciated.

Thank You.

Charles

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

Quote:

I unloaded 6.2 and then 6.1 is giving me the same error.

You may have noticed when you installed AS6.2 it popped up and said "I'm going to upgrade the tools under Atmel Toolchain" - they were originally installed by 6.1 so I don't think there's a way back to the 6.1 compiler without removing "Atmel Toolchain" then running the 6.1 installer again.

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

Guess it's this one. Seems that Georg-Johann has some ideas :)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

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.

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

ggerold wrote:
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.
Using AS6.2.993. When I first got the error "in push_reload", changing optimization helped, however now I get the error with the optimization set at levels 1,2, or 3. Any new info on this bug? I have tried re-arranging some of the code since this has apparently helped some folks, but to no avail. Using AVR/GNU C Compiler : 4.8.1. and ATXMEGA16E5. Suggestions anyone?

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

Quote:

AS6.2.993

Try the full release of 6.2, it should have a new toolchain with it.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

meolsen wrote:
Quote:

AS6.2.993

Try the full release of 6.2, it should have a new toolchain with it.
Morten - Thanks for your suggestion. For awhile I had been locked in to the AS6.2.993 release as for some reason the update would fail on my computer. Your suggestion prompted me to give it another try. It still failed so I went into the registry and removed the references to "6.2.1153" installation that had been attempted. It installed then and brought me up to date. The toolchain that it installed however is still at version 4.8.1. After trying a few things, I discovered that if I compile for "Release" instead of debug, the error goes away (at least for now ?) so at least my project isn't "dead in the water". I see notes on the web that the GNU compiler is at 4.8.3 but I don't know enough about the Atmel IDE internals to know if I can update that outside of their system, or how to even go about it. Thanks for your reply.

Marty

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

You can add toolchains into studio as described here: http://www.atmel.com/webdoc/atmelstudio/ch10s03s11s01.html

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

meolsen wrote:
You can add toolchains into studio as described here: http://www.atmel.com/webdoc/atme...
Thanks again Morten for your comments. I hadn't realized you were with Atmel until I read through these postings again. I'm not a newbie at embedded development, but I am a newbie to the Atmel world of micro controllers. I have been using mostly NXP 8051 type devices and some TI MSP430. I liked the low power features of the XMEGA series and am developing a system that uses remote radio devices running on batteries, so that's how I got here. I am however "stuck" again as now I am getting the "Error: in push_reload, at reload.c:1360" all the time no matter what optimization level I am using or if in debug or release mode. I appreciate your comments to help point AStudio to another toolchain location. The problem I have at the moment is trying to find GCC4.8.3 that is built for the AVR environment. Is that something that is readily available or is it something that still needs to come from Atmel? I guess I don't know enough about how the GNU/GCC toolchains for various environments come about. Is there a good reference you can direct me too for getting my hands on the right version of the GCC tools that will run under windows and develop object code for the AVR 8bit micros? Otherwise has there been any new feedback on work-arounds for this push_reload bug? I'm getting pretty desperate here. :shock: Thanks.

Marty

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

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.

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

I don't know why, but using the compiler option

-fno-move-loop-invariants

made the bug disappear for me! I hope this also helps someone else.

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

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 )

Last Edited: Fri. Jul 1, 2016 - 01:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xrayer wrote:
It seem's to me that avr-gcc is quite buggy

So you are saying it's worth every penny you paid?

 

If you think there is a problem, fix it and donate your work back to the GNU GCC project. THAT is how open source software improves over time.

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

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...

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

xrayer wrote:

OK, sure I know opensource but I think that also Atmel should commit some fixes when they gains from gcc project.

 

$ pwd

/home/saaadhu/code/work/gcc-writable/gcc

$ find . -name 'ChangeLog' | xargs grep "atmel" | grep 2016 | wc -l
16

 

 

 

That's the number of ChangeLog entries for atmel stuff in upstream gcc - surely that counts as "some" fixes? Add 19 or so commits in upstream binutils, and a few in avr-libc, and you can see that we do care.

 

For your bug, can you post a complete testcase that I can compile? internal compiler error in push_reload is a fairly generic error and can be triggered in multiple ways - yours is probably different from the one in the bugzilla entry.

 

 

 

 

Regards

Senthil

 

blog | website

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

saaadhu wrote:

For your bug, can you post a complete testcase that I can compile? internal compiler error in push_reload is a fairly generic error and can be triggered in multiple ways - yours is probably different from the one in the bugzilla entry.

 

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>

 

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

Damn formating, try this http://pastebin.com/BQYG1txc

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

https://gcc.gnu.org/bugzilla/sho... appears to match this. I'll take a look.

Regards

Senthil

 

blog | website

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

OK, I hope this helps to track the bugs. Could it help to compile avr-gcc with stack protector enabled? Or add some bounary checks if some arrays are accessed in the push_reload func?

Does it caused because of loop optimization remove something outside of loop but needs allocate some temp register that is not available or bug in its allocation?

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

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.

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

And can I rely, that the target code produced with -fno-move-loop-invariants without a crash is valid like with older gcc? I mean if there couldn't be some hidden bad behavior that don't crash gcc yet but emmits buggy code. Of course I could compare produced asm listings but... I'm not sure if it's rather better to stay with gcc 4.7 until it will be fixed...

 

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

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.

Last Edited: Tue. Jul 19, 2016 - 06:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Future Notes...

 

I replicated this on the latest version of 6.2. Then I compiled the same code with AS 7.0.1188 and it compiled fine. Looks like its fixed in the newest Toolchain.

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

That would be 

Issue #AVRTC-825: Fix internal compiler error in push_reload with varargs functions (PR target/71873).

from the release notes for Atmel AVR 8-bit GNU Toolchain (3.5.4.1709). Like I mentioned here the maintainers did not approve backporting, so FSF gcc 5.x and 6.x still have the bug.

Regards

Senthil

 

blog | website

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

I guess their argument was that it's been like that for so long and not really affecting that many people that it's quite low priority?

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

Yeah. The fix was in a target independent pass (reload) and avr is not a primary target, so no. This was the actual response.

Regards

Senthil

 

blog | website

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

OK, so if I understand well, this means the bug will not be fixed in gcc 6.x or older versions and we have to wait for gcc 7.x - if Atmel will plan to include theirs win32 build into new version of AVR Studio...

There would be a possibility to apply the patch to 6.x or 5.x gcc but probably nobody will care, I personally don't have enough skills with gcc rebuild, I never tried it. Probably as many other users I'm busy with programming my own code relying on existing compiler and no time to fiddle with compiler myself.

I know that I should migrate to some newer better supported platform e.g. C-M0 years ago but I stilll have a bunch of spare AVRs and they are simple to use so I don't want to trash them...