avr-gcc 4.7.0 for the brave

Go To Last Post
205 posts / 0 new

Pages

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

demiurg_spb wrote:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
void func(void)
{
	static const int PROGMEM x = 0;
	(void)x; // dummy
}

warning: uninitialized variable 'x' put into program memory area [-Wuninitialized]

You must do someting wrong. With the compiler version you mentioned if compile
#define PROGMEM __attribute__((progmem))
void func(void) 
{ 
   static const int PROGMEM x = 0; 
   (void)x;
}

with

    avr-gcc foo.c -Os -S -Wextra -Wall -W -std=gnu99 -pedantic
there is no warning.

avrfreaks does not support Opera. Profile inactive.

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

sry doublepost-delete this

Last Edited: Wed. Aug 29, 2012 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I was tracking one bug in gcc 4.7.0 (20.4.2012), maybe it helps somebody else to save his time.
I was working on bootloader with Xmodem download feature for ATmega88pa. Because of limited boot section space to 2kB I had to optimize a lot. This was reason why I switched from gcc 4.3.3 to 4.7.0 because it shorted code size ~150B - nice. But it introduced a bug that cause strange hang in Xmodem receiver function. I had allocaded one static Byte buffer for data and when ~30 bytes received it crashed. After hours of messing around I found it happen due to wrong .bss section position. When the buffer was not static it worked because it was placed ijn stack. Or if I made some global variables that filled section. data.
In the map file I saw, that when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 - the beginning of SRAM. To prevent it I have to made just one byte global variable (that was used to prevent gcc optimizer to remove it), then .bss was correctly from 0x102 (after that glob. var.). Now you can imagine what happened when Xmodem receiver was writting to buffer at 0x60 - it completly rewite system registers - I also saw that LED flashed shortly when written to PORTB before it crashed [note: as I was debugging UART transaction I couldn't use the same UART for debug prints so I could just debug via LED]....
Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section that caused .bss shift.

Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it. For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?

I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR. I found that boot.h check it's presence via #ifdef that is enough to not compile my source. I also found that this bug was reported and is still opened. My hotfix was simply to comment the poison line in
IOM128.H:
// #pragma GCC poison SPMCR // cause error in boot.h header that test this macro
I don't know better solution but as both SPMCR and SPMSCR regs are defined same way I don't care...

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

glaux wrote:
what do you reccomend? Should I completly update to 4.7.1 ...?
I think that avr-gcc-4.7.1 should be better choice.
SprinterSB wrote:
You must do someting wrong...
Maybe yes, maybe no...
I forgot to say that I use -flto as -combine like manner.
I can't produce minimal test case to show this situation.
Warning is gone if I make simple project with 2 src files main.c and module.c (this module.c is cause warning in real project). Also real project compiles without warnings if I remove -Wextra flag.

IMHO, this is not normal situation
Because next case

static const int PROGMEM x;

produces correct warning in any cases with and without -Wextra flag.

Attachment(s): 

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

glaux wrote:
when .data section was empty the linker placed .bss section (the buffer) at address 0x60! Instead of 0x100 [...] Also I have to note that I use -fdata-sections -ffunction-sections --gc-sections options to remove unused sections. But gcc was probably too agressive and removed whole empty data section
GCC does not remove empty section.

You hit binutils PR13697. To work around you can use up to date binutils, patch your default ld script as indicated by the patch along with PR13697, or put some data into .data that cannot be removed.

glaux wrote:
Anyway when I just a hour ago started to read this thread I found there's gcc 4.7.1 RC package that has updated linker scripts and it solved this problem. It's enough to copy LDSCRIPTS dir to my 4.7.0 compiler package to fix it, so thanks for it.
Yes, that will suffice to fix PR13697 but notice that 4.7.1 has more bugs fixed than yust that one. Have a look at the source directory of the 4.7.1rc1 and at GCC bugzilla.

glaux wrote:
For users experienced with this new gcc 4.7.x what do you reccomend? Should I completly update to 4.7.1 or just the linker scripts to 4.7.0?
I'd recommend to update to 4.7.1.

glaux wrote:
I also had one issue caused by avr-libC 1.8.0 at ATmega128:
when I included I got an error due to poisoned SPMCR.
This is AVR-Libc issue #36410.

avrfreaks does not support Opera. Profile inactive.

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

>SprinterSB
Thanks for info. I started to use GCC 4.7.1 and currently didn't find any problem.

>This is AVR-Libc issue #36410.
AFAIK still not solved for ~3 months...

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

demiurg_spb wrote:
compile.zip
That's just babbling from make, it's not possible to reproduce the issue from that.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
That's just babbling from make, it's not possible to reproduce the issue from that.
I understand. What should I do to make useful "bug report" in my case? Thx!

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

  1. [Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
  2. The compiler option you use
  3. The compiler version you use
  4. The compiler output/messages/diagnostics
You can get 2. 3. and 4. by adding -v to the compiler command options.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
  1. [Try to] work out a small test case. Most code in your C files won't be needed to reproduce the warning. Remind that others don't have files that you #include.
I can't do minimal case. When I exclude any module from my project I get no error :-(

May I send You my project directly?

Attachment(s): 

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

Can't you compiler with -Wno-error=uninitialized for a start?

And -fwhole-program does not look like a good idea of you use LTO.

Can't you reduce it to two or three files?

Are you sure you have extern in prototypes in the headers?

If I don't miss something that the warning is only during the LTO link, not when compiling to .o. Is that right?

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Can't you compiler with -Wno-error=uninitialized for a start?

with -Wno-error=uninitialized project compiles without any errors but with warnings.

In file included from :117:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
In file included from :92:0:
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]
./../../../arclib/common/metrology/dac.c:83:31: warning: uninitialized variable 'dac_out_range' put into program memory area [-Wuninitialized]

SprinterSB wrote:
And -fwhole-program does not look like a good idea of you use LTO.
There is no difference (I've tried to compile without whole-program).

SprinterSB wrote:
Are you sure you have extern in prototypes in the headers?
No this is local constant data:

//=============================================================================
void dac_update(uint8_t ch, float x)
{
	#define DAC_FS   (DAC_20MA - DAC_0MA) // full scale

	#define DAC_4MA  (DAC_0MA + FROUND(DAC_FS/5.0f))
	#define DAC_5MA  (DAC_0MA + FROUND(DAC_FS/4.0f))
	#define DAC_10V  (DAC_0MA + FROUND(DAC_FS))
	#define DAC_1V   (DAC_0MA + FROUND(DAC_FS/10.0f))
	#define DAC_0V   (DAC_0MA)

	typedef struct
	{
	 	uint16_t lo;
	 	uint16_t hi;
	} range_t;


	static const range_t PROGMEM dac_out_range[] =
	{
			{DAC_0MA, DAC_0MA },     // off
			{DAC_4MA, DAC_20MA}      // 4-20 mA
	
		#ifdef DAC_WITH_ALL_CURRENTS
			,
			{DAC_0MA, DAC_5MA },     // 0-5  mA
			{DAC_0MA, DAC_20MA}      // 0-20 mA
		# ifdef DAC_WITH_VOLTAGE
			,
			{DAC_0V,  DAC_10V },     // 0-10 V
			{DAC_0V,  DAC_1V  }      // 0-1  V
		#  ifdef DAC_WITH_MAN_CTL
			,
			{DAC_0V,  DAC_10V },     // 0-10 V  RS485
			{DAC_0MA, DAC_20MA}      // 0-20 mA RS485
		#  endif
		# endif
		#endif
	};
....
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would you attach a zip containing

  • all needed sources
  • a plain text file that lists the commands and options that trigger the warning
Please make sure that there are no external dependencies like missing headers that avoid that someone alse can reproduce it.

For example you can inflate zu zip into an empty directory and run the collected compile/assemble/link commands there in order to make sure it actually reproduces the issue.

avrfreaks does not support Opera. Profile inactive.

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

Hi,
I just downloaded AVR-GCC-4.7.2. Tried to compile an existing project where I have used PROGMEM. I am getting errors!!! The earlier version compiled OK. Thanks for any suggestions.

Parthasaradhi Nayani

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

in 4.7.2 you need to use __flash. I changed all reference to progmem in my code. To define string I am using:

#define _FLASH 	const __flash
#define FLASH_STR(s) ({static char _FLASH __c[] = (s); &__c[0];})

Also SprinterSB, FIY, my project with:

4.7.1 : 15700 bytes
4.7.2 : 15674 bytes
4.8.0 : 15788 bytes

PS: big thanks to you for making avr-gcc build! 8) :D

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

Hi,
const char PROGMEM ch; works. No errors are reported.

Used makefile and PN for compiling an existing project. Avr-size has thrown out error. It does not understand --mcu option. Avr-size seems to be original GCC size without the extra mcu option.

One question- what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers. Thank you.

Parthasaradhi Nayani

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

Magister wrote:
in 4.7.2 you need to use __flash.
Not quite. you may use __flash but there is no need to use __flash. You can just as well use attribute progmem aka. PROGMEM macro together with the pgm_read_* accessors from AVR-Libc.

Nayani P wrote:
I tried to compile an existing project where I have used PROGMEM. I am getting errors!!!
Very descriptive, really...

Presumably you are tring to put non-const data into flash. We don't know.

Nayani P wrote:
avr-size has thrown out error. It does not understand --mcu option.
avr-size is from binutils. It comes without -C kludge or similar. Read the binutils documentation or avr-size --help to learn about supported command options.

Nayani P wrote:
what is the maximum size of a pointer that is allowed in this release? My primary interest is in having 32 bit pointers.
Pointers in the impementation are 16 bits wide. There are no 32-bit pointers.

There is a 24-bit address space __memx which is a C extension. __memx linearizes flash and internal RAM. Read the compiler documentation and the GCC release notes.

avrfreaks does not support Opera. Profile inactive.

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

GCC 4.7.2 is released now and I decided to provide a build of avr-gcc 4.7.2 for MS Windows.

If you are interested, see avr-gcc 4.7 for Windows in the avr-gcc-list mailing list archive.

For questions and feedback, please follow up to that mailing list. For details like subscribing to that list, see the avr-gcc-list@nongnu.org main page.

Thanks.

avrfreaks does not support Opera. Profile inactive.

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

I am using it for a few days now, no difference with the release candidate I think.

Thanks a lot for your work, it's highly appreciated!

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

I copied avr-size.exe from AVR tool chain that comes with AVR Studio 5.1.208 to be able to use AVR GCC 4.7.2 with AVR Studio 5. I have not checked to see if the result is correct.

C option is not supported. So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

metal wrote:
So, how can I modify AVR Studio 5 to use original avr-size.exe that comes with avr-gcc-4.7.2-mingw32
avr-size that comes with avr-gcc-4.7.2-mingw32 is unpatched and don't knows avr-format (C option is not supported). Just use old (patched) avr-size.exe from WinAvr or AvrStudio.
You can check path and version of avr-size by next two commands:
"which avr-size.exe"
"avr-size.exe --v"
Magister wrote:
I am using it for a few days now, no difference with the release candidate I think.
I see different to previous version (-18 bytes on 70 KB project) :-).

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

what is the reason for not patching avr-size.exe to have the required options.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

Quote:

what is the reason for not patching avr-size.exe to have the required options.

It was a patch developed by Eric Weddington. While the source may be open (I think it has to be as avr-size is likely GPL) the fact is that it would require maintenance as modern tool chains cover a whole load of new AVRs. So only if someone's willing to invest the time/effort (which I guess wouldn't be THAT complex) can a version that matches the device support in a typical 4.6/4.7/4.8 build be produced.

I think I looked at this before and as you may guess it's just a table of device names together with their flash, RAM and EEPROM sizes so -C can show percentages.

As Atmel have taken on the gauntlet of new device additions (in their private branch) you might hope that they would have thought of doing this work. However their choice was to run the vanilla avr-size then run their own post-processor that digests the output then fails to show percentages correctly. Ho hum.

(I think Atmel may have done it that way as they wanted a common mechanism that could work with AVR32 and SAM3/4 too).

EDIT:

E:\WinAVR-20100110\source\avr\binutils\2.19>dir 30*
 Volume in drive E is VBOX_windows
 Volume Serial Number is 0000-0801

 Directory of E:\WinAVR-20100110\source\avr\binutils\2.19

19/01/2010  19:08            16,260 30-binutils-2.19-avr-size.patch

Clearly that needs to be brought up from 2.19 to 2.22 or whatever.

EDIT2: hey I'm famous. I was searching for "{"atmega164p", AVR16K, AVR1K, AVR512}" online to see if I could find a maintained copy of the patch and it hit this site:

https://build.opensuse.org/packa...

So they named the package after my internet persona!

Oh and I did find a 2.20 version:

http://fbsdmon.org/ports/devel/a...

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

I asked on the 1st pg. if this toolchain could be used with Studio 4.18, and from Clawson's reply I tried adding its path, for avr-gcc-4.7.2.exe, in Custom Options. I'm confused about MAKE.exe, since it's not in the chain. I assume then that I can use the same one from Winavr, so that path's unchanged.

I tested it on my MP3 pjt, using FATFS and this is the output:
1st warning in ff.c:347:3( the return line )

	case FS_FAT16 :
		if (move_window(fs, fsect + (clst / (SS(fs) / 2)))) break;
		return LD_WORD(&fs->win[((WORD)clst * 2) & (SS(fs) - 1)]);
Build started 18.10.2012 at 12:29:06
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ff.o -MF dep/ff.o.d  -c  ../ff.c

../ff.c: In function 'get_fat':
../ff.c:347:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:351:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'check_fs':
../ff.c:1445:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1448:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1450:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c: In function 'chk_mounted':
../ff.c:1531:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1535:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1536:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1540:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1542:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1543:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1544:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1546:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
../ff.c:1554:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LCD.o -MF dep/LCD.o.d  -c  ../LCD.c

avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT vs1011.o -MF dep/vs1011.o.d  -c  ../vs1011.c

../vs1011.c: In function 'sd_cmd':
../vs1011.c:39:2: warning: right shift count >= width of type [enabled by default]
../vs1011.c: In function 'VS_sci_rd':
../vs1011.c:247:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT diskio.o -MF dep/diskio.o.d  -c  ../diskio.c

../diskio.c:187:6: warning: 'select' defined but not used [-Wunused-function]
avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sections  -mcall-prologu
es                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT mp3.o -MF dep/mp3.o.d  -c  ../mp3.c

avr-gcc-4.7.2 -I"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\Xmegas\xmega16A4\My_MP3\..\..\..\MY_Includes"  -mmcu=atxmega16a4 -mmcu=atxmega16a4 -Wall -gdwarf-2 -std=gnu99     -fno-inline-small-functions  -ffunction-sections  -fdata-sectio
ns  -mcall-prologues                                  -DF_CPU=2000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT ccp.o -MF dep/ccp.o.d  -x assembler-with-cpp -Wa,-gdwarf2 -c  ../ccp.S

avr-gcc-4.7.2 -mmcu=atxmega16a4 -Wl,--relax -Wl,--gc-sections -Wl,-Map=My_MP3.map ff.o LCD.o vs1011.o diskio.o mp3.o ccp.o   -L"C:\Documents and Settings\Jeromeo\My Documents\Avr Projects 2\MY_LIBS"  -lm  -o My_MP3.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  My_MP3.elf My_MP3.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex My_MP3.elf My_MP3.eep || exit 0
avr-objdump -h -S My_MP3.elf > My_MP3.lss

avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=        Set the binary file format
            @                   Read options from 
  -h        --help                    Display this information
  -v        --version                 Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make: *** [size] Error 1
Build failed with 1 errors and 17 warnings...

It's fine with the latest Winavr and I'm missing something(s)...

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Sprinter is building a plain-vanilla avr-gcc.

avr-size (Binutils) hasn't been patched with the "Atmel patches"

Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch

/Bingo

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

Bingo600 wrote:
Sprinter is building a plain-vanilla avr-gcc.

avr-size (Binutils) hasn't been patched with the "Atmel patches"

Just skip the "Atmel specific option -C" avr-size step , or apply the Atmel patch called something like 30-binutils-avr-size.patch

/Bingo

1) Skipping -C option...how, that's in Atmel's MAKEFILE isn't it ?

OR

2) Patch option... I don't have a clue how to apply it. I can find it. I'm running 'Doze XP.

Thanks for the help.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

If you have no clue on using patch ...

I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C

/Bingo

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

Bingo600 wrote:
If you have no clue on using patch ...

/Bingo

Yeah, I found the patch on their site, but nothing on how to install it in 'Doze XP. Much easier in Linux, I bet. It looks like just a C file, I was thinking it would be a *.exe file to integrate into the toolchain.

Quote:
I'd select option 1 , and find the place in the makefile where avr-size gets called.
Then either comment it out , or at least remove the -C
When I comment out the line or even take out just the option, MAKEFILE doesn't keep the saved changed . I edit Atmel's MAKEFILE, save it and rebuild...original line's back ( what voodoo is this ??! ). All the warnings go away, though.

Jerome

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Wed. Oct 24, 2012 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read freaky member demiurg_spb's reply above on this pg. , thanks man, and so I just copied Winavr's avr-size.exe in place of 4.7.2's and it complies now, but the same 17 warnings are back.

Xmega16A4, -Os

Winavr compile: 7218 bytes

AVR-GCC 4.7.2 compile: 6914

Thanks Sprinter for all your work.

Edit: This switch used to turn those warnings off, produced from FATFS code ( must be a harmless warning in this case ):

-fno-strict-aliasing

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Johann,

Now that https://www.avrfreaks.net/index.p... has been solved through http://sourceware.org/bugzilla/s... , could you please provide a binary build which removes the initializer problem described under "Limitations and caveats" in http://gcc.gnu.org/onlinedocs/gc... ?

Thanks,

Jan

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

There is avr-gcc-4.7.1-rc1-mingw32.zip that comes with a backport of PR53344 to 4.7, see the source directory for respective patchset.

avrfreaks does not support Opera. Profile inactive.

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

Yes, but that in turn has not included the binutils PR13503 fix.

an1.s: Assembler messages:
an1.s:23: Error: junk at end of line, first unrecognized character is `('
an1.s:24: Error: junk at end of line, first unrecognized character is `('
an1.s:25: Error: junk at end of line, first unrecognized character is `('
.global	pfoo
	.section	.progmem.data,"a",@progbits
	.type	pfoo, @object
	.size	pfoo, 3
pfoo:
	.byte	lo8(foo) ; need binutils PR13503
	.byte	hi8(foo) ; need binutils PR13503
	.byte	hh8(foo) ; need binutils PR13503

I know it is possible to compile using the 4.7.1 and assemble and link using the tools from the 4.7.2 build, but if it is not a big hassle for you, it would be nice to have it as a single bundle working "out-of-the-box".

The 4.7.2 bundle has seen already a couple of dozens of downloads. There *is* a need for this stuff, in lack of a WinAVR-style package.

Thanks,

Jan

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

Does 4.7.2 work for you and instead of compiling / assembling in "one" step

avr-gcc -c file.c $(options)

you do two steps like so?

avr-gcc -S file.c $(options)
sed file.s -e 's:\.byte.*hh8:.byte hlo8:g' > file-2.s
avr-gcc -c file-2.s -Wa,--no-warn $(options)

Notice PR53344 won't be backported to 4.7 because the avr port maintainers did not approve a backport which is in accordance with GCC policies:

    Bug fixes and documentation changes only.

avrfreaks does not support Opera. Profile inactive.

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

Apart from the aesthetical drawback that the warning remains, it also simply fails, because:

#include 

const __memx char dummy1[32767];
const __memx char dummy2[32767];
const __memx char dummy3[32767];
const __memx char dummy4[32767];
const __memx char foo;
const __memx char * const __flash pfoo = &dummy1[0];

int main(void) {
}

results in

an12.s: Assembler messages:
an12.s:24: Warning: assembling 24-bit address needs binutils extension for hh8(d
ummy1)
an12.s:23: Error: value of 98305 too large for field of 2 bytes at 0

(line 23 is .word dummy1 )

I (and presumably others too) would be obliged if you could find time to produce a working set of binaries.

(Just wondering, how does "does not produce assemblable code" fail short of the official definition of "bug").

Thanks,

Jan

PS. Johann, could you please also comment on https://www.avrfreaks.net/index.p... ? Thanks.

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

How does the assembler code look like?
And how did you assemble that?

At the moment all the time I can spend on avr-gcc is consumed by other stuff.

I will come back toi this as soon I have some time left.

Thanks for your patience.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
How does the assembler code look like?
And how did you assemble that?
In attachment; see an1.bat (there's a bit more in that than absolutely needed, but the point should be clear).

SprinterSB wrote:
At the moment all the time I can spend on avr-gcc is consumed by other stuff.

I will come back toi this as soon I have some time left.

That's OK of course.

Thanks,

Jan

Attachment(s): 

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

What about the 4.8.0 snapshot?

avrfreaks does not support Opera. Profile inactive.

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

Why not?

You tell what could be a gotcha.

JW

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

Fixed-Point support is broken by design.

Slighly inefficient reloading because of outdated constraint cost (PR54815).

@@@ A CAPTCHA for this post???

avrfreaks does not support Opera. Profile inactive.

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

Okay, but aren't both already present in 4.7.x? If so, that's no real gotcha in using a 4.8 snapshot rather than a 4.7.whatever release.

I mean, users presumably would try 4.7+ mainly to test the new features, of which IMO __flash and kin are the most interesting and worth more thorough testing and further discussion.

I did not mention it, but I now started asking for these things just because somebody else asked for string literals in high FLASH (pointers to) arrays also in high FLASH (*), in a local mailing list. I in answer recommended the newest development in 4.7+ just to be told that it does not work...

JW

(*) I tried to keep the C type declaration style :-)

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

It work for me with __flash1 etc.

Notice one segment cannot hold more than 64KiB and you need a liker script as explaned in the GCC docs. Ther is no one-fits-all-memory-arrangements script, at least I failed in finding one. Maybe just because my very limited knowledge on binutils and a wizard finds an nea solution...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#pragma pack(push, 4)
typedef struct
{
	uint8_t a;
	uint8_t b;
	uint8_t c;
} abc_t;
#pragma pack(pop)

abc_t x, y, z;

STATIC_ASSERT(sizeof(abc_t)==3); // true (should be false IMHO)

something is broken in avr-gcc 4.7.2
and in 4.3.3
and in 4.4.3 too :-(

Structures x,y,z and their fields are placed in memory without any gaps.

It seems to be very old bug:https://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=65874&start=0

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

please solution
After update gcc from 4.3 to 4.7.2 I cant compile my code some unseen error appeared

Build started 22.1.2013 at 10:44:14
avr-gcc -I"C:\Mariaus\myproject\EEPROM_flasher\."  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                                                      -DF_CPU=14740000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT EEPROM_fl
asher.o -MF dep/EEPROM_flasher.o.d  -c  ../EEPROM_flasher.c

In file included from ../EEPROM_flasher.c:6:0:
../spi.c: In function 'read_sector_prtct_stat':
../spi.c:206:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
avr-gcc -mmcu=atmega644 -Wl,--defsym=__stack=0x1000 -Wl,-Map=EEPROM_flasher.map EEPROM_flasher.o     -o EEPROM_flasher.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  EEPROM_flasher.elf EEPROM_flasher.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex EEPROM_flasher.elf EEPROM_flasher.eep || exit 0
avr-objdump -h -S EEPROM_flasher.elf > EEPROM_flasher.lss

avr-size: invalid option -- C
Usage: avr-size [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
  -t        --totals                  Display the total sizes (Berkeley only)
            --common                  Display total size for *COM* syms
            --target=        Set the binary file format
            @                   Read options from 
  -h        --help                    Display this information
  -v        --version                 Display the program's version

avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
make: *** [size] Error 1
Build failed with 1 errors and 1 warnings...

may somebody knows the solution or need some more information...

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

Quote:

may somebody knows the solution

The only error there is the attempt to use -C on avr-size. The fact is that in WinAVR Eric Weddington developed/applied a patch to avr-size utility so that as well as the normal -A and -B that the generic "size" program accepts it would now accept -C along with an additional --mcu= so it could produce a much more readable output display that even included % of flash and data figures. It does this as it has a large table of all the known AVR models along with their flash, RAM and EEPROM sizes. The version of avr-size you are using does not have this patch. So edit the Makefile you are using and stop it attempting to use -C and --mcu=.

Alternatively find out what version of avr-size is now being used and temporarily replace it with the avr-size.exe copied from WinAVR as the old version should still work on "modern" .elf files.

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

Thanks clawson for the answer seems the reason is quiet clear and known by avr freaks.

the problem is What I'm not sure I know how to do everything you wrote above. Can you write some short description how to update avr-size content and how to edit MakeFile? It will be very helpfully for me and I think for others too.

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

Well the simplest would just be to replace the avr-size.exe now being found/used with one that does accept -C. At a Command Prompt type:

E:\>which avr-size.exe
E:\WinAVR-20100110\bin\avr-size.exe

As you can see, on my machine the one being used is the one in WinAVR2010. I guess (assuming which.exe can also be found!) your machine is going to give the path to the "new" version. Once you locate it rename it out of the way:

ren avr-size.exe avr-size.new

Then copy the old one from WinAVR in to that same place so it will now be found.

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

Done.
Working thanks dude, one problem is solved ;]

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

Quote:
Using built-in specs.
COLLECT_GCC=z:\gcc\avr-gcc\bin\avr-gcc.EXE
COLLECT_LTO_WRAPPER=z:/gcc/avr-gcc/bin/../libexec/gcc/avr/4.7.2/lto-wrapper.exe
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 --with-avrlibc=yes
Thread model: single
gcc version 4.7.2 (GCC)

Quote:
module.c: In function 'foo':
module.c:52:1: error: unable to find a register to spill in class 'BASE_POINTER_REGS'
module.c:52:1: error: this is the insn:
(insn 73 72 74 5 (set (reg:SF 66 [ D.1445 ])
(unspec:SF [
(reg:HI 30 r30)
(const_int 0 [0])
] UNSPEC_LPM)) module.c:28 9 {load_sf}
(expr_list:REG_DEAD (reg:HI 30 r30)
(nil)))
module.c:52: confused by earlier errors, bailing out
make.EXE: *** [../bin/test/test.elf] Error 1

This bug is present with __flash keyword, with PROGMEM everything is ok. Testcase is in attached archive.

Attachment(s): 

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

Would you file a GCC bug report?

http://gcc.gnu.org/bugzilla/

For more information, see http://gcc.gnu.org/bugs/#report

Thanks.

avrfreaks does not support Opera. Profile inactive.

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

I think I know where the problem is. But it will be hard to fix. I cannot say if there will be a working solution for 4.7

avrfreaks does not support Opera. Profile inactive.

Pages