Menu
▾
▴
winavr-users — For users of the WinAVR distribution of the AVR toolset.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
(11) |
Oct
(15) |
Nov
(10) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(11) |
Feb
(32) |
Mar
(8) |
Apr
(12) |
May
(6) |
Jun
(22) |
Jul
(4) |
Aug
(13) |
Sep
(5) |
Oct
(14) |
Nov
(15) |
Dec
(33) |
| 2006 |
Jan
(25) |
Feb
(6) |
Mar
(10) |
Apr
(9) |
May
(9) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(13) |
Oct
(3) |
Nov
(7) |
Dec
(9) |
| 2007 |
Jan
(22) |
Feb
(15) |
Mar
(46) |
Apr
(29) |
May
(7) |
Jun
(6) |
Jul
(8) |
Aug
(9) |
Sep
(12) |
Oct
(10) |
Nov
(20) |
Dec
(12) |
| 2008 |
Jan
(30) |
Feb
(13) |
Mar
(41) |
Apr
(36) |
May
(17) |
Jun
(5) |
Jul
(50) |
Aug
(9) |
Sep
(9) |
Oct
(8) |
Nov
(21) |
Dec
(37) |
| 2009 |
Jan
(16) |
Feb
(13) |
Mar
(18) |
Apr
(21) |
May
|
Jun
(6) |
Jul
(8) |
Aug
(13) |
Sep
(10) |
Oct
(21) |
Nov
(14) |
Dec
(8) |
| 2010 |
Jan
(104) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:13:28
|
Bugs item #2028719, was opened at 2008-07-26 07:57 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2028719&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: DelikanliMuhendis (ee_ilyas) Assigned to: Nobody/Anonymous (nobody) Summary: Winavr EICALL BUG Initial Comment: I use Atmega2561 and build my project in WinAvr vers WinAVR-20080610 in GCC language. I write this line code: ((void (*)())0x1F000)(); it is for accessing bootloader at the adress 0x1F000. but code does not work. when i look at the assembly codes, i saw the bug. the two LSB bytes (0xF000) are loaded into ZH and ZL registers and eicall function is called. but eicall function cannot access to 0x1F000 adress because the MSB byte (0x01) is not loaded to EIND register. i did it manually and the code worked. this function has to be improved to be able to access further adress locations in the program memory. Best Regards.. ilyas Electronics Engineer ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:45 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2028719&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:12:17
|
Bugs item #2774485, was opened at 2009-04-19 09:49 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2774485&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jim Remington (jremington) Assigned to: Nobody/Anonymous (nobody) Summary: internal compiler error: illegal instruction Initial Comment: Attempt to compile "blink.c" for ATtiny26 via AVR Studio IV (4.16 Build 628) leads to the titled error message. See attached files AVR-GCC version from install WinAVR_20090313 Pentium processor running Windows 98 on Toshiba 550CDT laptop Command leading to error message: avr-gcc -mmcu=attiny26 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT Blink.o -MF dep/Blink.o.d -c ../Blink.c ../Blink.c: In function '_delay_ms' ../Blink.c:30 internal compiler error: illegal instruction ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:36 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2774485&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:11:36
|
Bugs item #2009732, was opened at 2008-07-03 07:30 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2009732&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: AVR-LibC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Willi (wiste) Assigned to: Nobody/Anonymous (nobody) Summary: Accessing EEPROM shows some anomalies Initial Comment: Using the latest WinAVR toolchain 20080610, the genereated binaries show anomalies when accessing odd addresses. E.g.: . . uint8_t byte1 EEMEM; /* even address */ uint8_t byte2 EEMEM; /* odd address */ uint8_t foo_var; . . foo_var = eeprom_read_byte(&byte1); /* works fine */ . . foo_var = eeprom_read_byte(&byte2); /* fails by reseting the µC */ . . Similar functions that access the EEPROM show the same behavior. The same code just works fine and doesn't show this behavior using WinAVR version 20060421. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:43 Message: This needs to be reported to the avr-libc project at: http://savannah.nongnu.org/bugs/?group=avr-libc This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in avr-libc (the standard C library for the AVR) must be reported to the avr-libc project and not here. Closed as "Won't Fix". ---------------------------------------------------------------------- Comment By: Nick Kolesnikov (nk2064) Date: 2008-10-07 13:14 Message: I'm have a similar problem : #define EEPROM_SECTION __attribute__ ((section (".eeprom"))) u16 eeprom_magic EEPROM_SECTION = 0x55AA; var uint16_t magic; ... magic=eeprom_read_word(&eeprom_magic); //freeze on first access :( ---------------------------------------------------------------------- Comment By: Willi (wiste) Date: 2008-07-07 13:41 Message: Logged In: YES user_id=2134926 Originator: YES File Added: For Joerg.zip ---------------------------------------------------------------------- Comment By: Willi (wiste) Date: 2008-07-03 09:30 Message: Logged In: YES user_id=2134926 Originator: YES I'm compiling for the mega 128. -mmcu=atmega128 Further I attached the whole make file output. -------- begin -------- avr-gcc (WinAVR 20080610) 4.3.0 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Size before: AVR Memory Usage ---------------- Device: atmega128 Program: 10258 bytes (7.8% Full) (.text + .data + .bootloader) Data: 706 bytes (17.2% Full) (.data + .bss + .noinit) EEPROM: 71 bytes (1.7% Full) (.eeprom) Compiling C: RS1Tuele.c avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=7372800UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./RS1Tuele.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/RS1Tuele.o.d RS1Tuele.c -o RS1Tuele.o Linking: RS1Tuele.elf avr-gcc -mmcu=atmega128 -I. -gdwarf-2 -DF_CPU=7372800UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=RS1Tuele.o -std=gnu99 -Wundef -MMD -MP -MF .dep/RS1Tuele.elf.d RS1Tuele.o --output RS1Tuele.elf -Wl,-Map=RS1Tuele.map,--cref -Wl,-u,vfprintf -lprintf_flt -lm Creating load file for Flash: RS1Tuele.hex avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock RS1Tuele.elf RS1Tuele.hex Creating load file for EEPROM: RS1Tuele.eep avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \ --change-section-lma .eeprom=0 --no-change-warnings -O ihex RS1Tuele.elf RS1Tuele.eep || exit 0 Creating Extended Listing: RS1Tuele.lss avr-objdump -h -S -z RS1Tuele.elf > RS1Tuele.lss Creating Symbol Table: RS1Tuele.sym avr-nm -n RS1Tuele.elf > RS1Tuele.sym Size after: AVR Memory Usage ---------------- Device: atmega128 Program: 10258 bytes (7.8% Full) (.text + .data + .bootloader) Data: 706 bytes (17.2% Full) (.data + .bss + .noinit) EEPROM: 71 bytes (1.7% Full) (.eeprom) srec_cat RS1Tuele.hex -Intel -Output RS1Tuele.srec -Motorola -Line_Length 142 -------- end -------- ---------------------------------------------------------------------- Comment By: Joerg Wunsch (joerg_wunsch) Date: 2008-07-03 08:00 Message: Logged In: YES user_id=1097648 Originator: NO Please indicate which controller (-mmcu option) you are compiling for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2009732&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:04:37
|
Bugs item #2324021, was opened at 2008-11-21 18:29 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2324021&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Andre Payant (darkdragon2000) Assigned to: Nobody/Anonymous (nobody) Summary: RAMPZ forced to 0 in 20081205 Initial Comment: When compiling SW located in upper memory (RAMPZ=1), WinAVR20081118rc2 forces RAMPZ=0 in the do_copy_data section. This prevents code from running correctly. Attached are test_OK.lss where application is located at 0x0000 and test_NOK.lss where application is located at 0xF000 on a AT90CAN128. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:43 Message: This needs to be reported to the avr-libc project at: http://savannah.nongnu.org/bugs/?group=avr-libc This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in avr-libc (the standard C library for the AVR) must be reported to the avr-libc project and not here. Closed as "Won't Fix". ---------------------------------------------------------------------- Comment By: Andre Payant (darkdragon2000) Date: 2008-12-01 11:54 Message: Hi, Basically any code which uses the Z pointer will fail. If you look at the example below (Test_NOK.lss) you can see that RAMPZ is set correctly to 1, and then reset to 0 at the end of do_copy_data. Otherwise the rest of the compiled code is fine. In fact, other than this addition of setting RAMPZ to 0, the rest of the compiled code essentially matches what the 20080610 version outputs. If you set a breakpoint at the beginning of main and forcefully set RAMPZ to 1, the application will work fine, proving that the issue is only this extra RAMPZ initialization. I think the main issue is only this initialization of RAMPZ, the handling of RAMPZ by the compiler for the rest of the code should be otherwise unaffected and should work correctly. I guess a temporary workaround would be to add an assembler command right at the beginning of main to force RAMPZ to 1 if it's compiled for a MEGA128 (of course only for bootloader applications). ---------------------------------------------------------------------- Comment By: Anatoly Sokolov (aesok) Date: 2008-12-01 10:19 Message: Hi Eric, Andre. Give an example what code fail, GCC generated code, avr-libc code or aplication code. The avr-libc have functions which can change contest of RAMPZ, pgm_read_*_far and __boot_page_*_extended for example. It is impossible to assume that if RAMPZ it is initialized in setup code it never to change in application code. Initializing of RAMPZ in setup code it is wrong. Anatoliy. ---------------------------------------------------------------------- Comment By: Anatoly Sokolov (aesok) Date: 2008-12-01 10:19 Message: Hi Eric, Andre. Give an example what code fail, GCC generated code, avr-libc code or aplication code. The avr-libc have functions which can change contest of RAMPZ, pgm_read_*_far and __boot_page_*_extended for example. It is impossible to assume that if RAMPZ it is initialized in setup code it never to change in application code. Initializing of RAMPZ in setup code it is wrong. Anatoliy. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2008-11-30 21:03 Message: Hi Anatoliy, I made these changes based on reports from internal groups were they had a problem: If an application had > 64K data, then __do_copy_data will increment RAMPZ to be 1. This caused application code in main() to immediately fail, as it was expecting RAMPZ to default to 0. Of course, the ideal solution is for the compiler and C library to properly handle RAMPZ in all situations. ---------------------------------------------------------------------- Comment By: Anatoly Sokolov (aesok) Date: 2008-11-29 12:05 Message: avr-libc ChangeLog: 2008-10-07 Eric B. Weddington <.....> * crt1/gcrt1.S: Clear the RAMPZ register after __do_copy_data for devices > 64K flash. Eric, why you have made these changes? Staring with GCC 4.4 code of "__do_copy_data" for avr51 and avr6 architecture device will take up from gcc/config/avr/libgcc.S, not from avr-libc/crt1/gcrt1.S If You consider that these changes are necessary, they should be added in libgcc.S also. Anatoliy. ---------------------------------------------------------------------- Comment By: Andre Payant (darkdragon2000) Date: 2008-11-27 20:40 Message: I have added a version located in upper memory compiled with 20080610 which compiles correctly ---------------------------------------------------------------------- Comment By: Andre Payant (darkdragon2000) Date: 2008-11-27 20:34 Message: This effectively prevents compiling bootloaders on the larger AVRs. ---------------------------------------------------------------------- Comment By: Andre Payant (darkdragon2000) Date: 2008-11-21 18:29 Message: File Added: test_NOK.lss ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2324021&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:03:54
|
Bugs item #2264356, was opened at 2008-11-11 13:03 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2264356&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: SprinterSB (sprintersb) Assigned to: Nobody/Anonymous (nobody) Summary: avr-gcc accesses EECR with wrong instruction Initial Comment: For several µC of AVR family, the is a known and well described silicon bug: Reading EEPROM by using ST or STS to set EERE bit triggers unexpected interrupt request. Reading EEPROM by using the ST or STS command to set the EERE bit in the EECR register triggers an unexpected EEPROM interrupt request. Problem Fix / Workaround Always use OUT or SBI to set EERE in EECR. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:39 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: SprinterSB (sprintersb) Date: 2008-12-01 16:27 Message: Added preprocessed C source runtime error would occur for ATmega64 with -O1 File Added: eetest.i ---------------------------------------------------------------------- Comment By: SprinterSB (sprintersb) Date: 2008-11-11 13:10 Message: Sorry, I just intended to upload the C-source, bit this sent the report... However, avr-gcc generates the forbidden instruction. Using the command line avr-gcc -S eetest.c -mmcu=atmega64 -O1 -fverbose-asm produced the output eetest.s which contains the ST/LD to access bit 0 of address 60, i.e. EERE in EECR. For details see for example datasheet of AVR ATmega64 summary, chapter Errata http://atmel.com/dyn/resources/prod_documents/2490S.pdf Regards, Georg-Johann File Added: eetest.s ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2264356&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:03:21
|
Bugs item #2528856, was opened at 2009-01-22 09:16 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2528856&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Michael Kochnev (st1ng) Assigned to: Nobody/Anonymous (nobody) Summary: pointers in constant-expressions and as template parameters Initial Comment: avr-c++ compiler v4.3.0 const int i1 = 0; int* const pi = ( int* )i1; // cast int to pointer const int i2 = ( int )( int* )i1; // only cast to pointer and back to int template< int i > class SomeTemplate { }; template< int* p > class AnotherTemplate { }; enum SomeEnum { entry_1 = i1, // ok entry_2 = ( int )pi, // error: 'pi' cannot appear in a constant-expression entry_3 = i2 // error: 'i2' cannot appear in a constant-expression }; SomeTemplate< 0 > st; // ok SomeTemplate< i1 > st1;// ok SomeTemplate< ( int )pi > st2;// error: 'pi' cannot appear in a constant-expression SomeTemplate< i2 > st3;// error: 'i2' cannot appear in a constant-expression AnotherTemplate< ( int* )0 > at; // error: a cast to a type other than an integral or enumeration type cannot appear in a constant-expression AnotherTemplate< ( int* )i1 > at1;// error: a cast to a type other than an integral or enumeration type cannot appear in a constant-expression AnotherTemplate< pi > at2;// error: 'pi' cannot appear in a constant-expression AnotherTemplate< ( int* )i2 > at3;// error: 'i2' cannot appear in a constant-expression ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:37 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2528856&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:02:52
|
Bugs item #2664491, was opened at 2009-03-05 02:09 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2664491&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Harald Hellmann (uc-harry) Assigned to: Nobody/Anonymous (nobody) Summary: if behaviour for U8 different to U16 Initial Comment: The behaviour of an if (a - b > c) is different when using U8 instead of U16. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:33 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: Harald Hellmann (uc-harry) Date: 2009-03-05 11:46 Message: I am sorry about the missing bug report within the description. But I thought discribing the behaviour beside the program which gets the bug could be very helpful to get ride of it. If a compiler handles an if (a - b > c) for unsigned chars (U8) different than unsigned shorts (U16) then it should be a bug. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-03-05 10:02 Message: Generally the description of the problem is listed in the bug report itself, not in the source code of the test case. ---------------------------------------------------------------------- Comment By: Harald Hellmann (uc-harry) Date: 2009-03-05 09:54 Message: Of course I think it is a bug. The types U8 and U16 are typedefs at the top of the source files for unsigned char and unsigned short. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-03-05 06:33 Message: Is this a bug report? Because I cannot tell if there is any mention of a bug here. Nowhere is it defined what U8 and U16 means here, as they are user-defined and not standard types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2664491&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:01:16
|
Bugs item #2536024, was opened at 2009-01-25 13:26 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2536024&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: SprinterSB (sprintersb) Assigned to: Nobody/Anonymous (nobody) Summary: internal compiler error: in propagate_rtx, at fwprop.c:469 Initial Comment: Whec compiled with -Os the attached source causes avr-gcc 4.3.2 to throw in ICE. The trigger is -fforward-propagate, the crash happens in pass .142r.fwprop1 e:/WinAVR-20081205/bin/avr-gcc -mmcu=atmega8 -S uput.i.c -v -Os Using built-in specs. Target: avr Configured with: ../gcc-4.3.2/configure --enable-win32-registry=WinAVR-20081205 --with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr --enable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-pkgversion='WinAVR 20081205' --with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse' Thread model: single gcc version 4.3.2 (WinAVR 20081205) COLLECT_GCC_OPTIONS='-mmcu=atmega8' '-S' '-v' '-Os' e:/winavr-20081205/bin/../libexec/gcc/avr/4.3.2/cc1.exe -quiet -v -imultilib avr4 -iprefix e:\winavr-20081205\bin\../lib/gcc/avr/4.3.2/ uput.i.c -quiet -dumpbase uput.i.c -mmcu=atmega8 -auxbase uput.i -Os -version -o uput.i.s ignoring nonexistent directory "e:/winavr-20081205/lib/gcc/../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: e:\winavr-20081205\bin\../lib/gcc/avr/4.3.2/include e:\winavr-20081205\bin\../lib/gcc/avr/4.3.2/include-fixed e:/winavr-20081205/lib/gcc/../../lib/gcc/avr/4.3.2/include e:/winavr-20081205/lib/gcc/../../lib/gcc/avr/4.3.2/include-fixed e:/winavr-20081205/lib/gcc/../../avr/include End of search list. GNU C (WinAVR 20081205) version 4.3.2 (avr) compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version 4.2.3, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32702 Compiler executable checksum: 67867e0bb6a39ca5af7615e31f09b8c9 uput.i.c: In function 'put_sfrac16': uput.i.c:21: internal compiler error: in propagate_rtx, at fwprop.c:469 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse> for instructions. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:33 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2536024&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:00:50
|
Bugs item #2896957, was opened at 2009-11-12 17:56 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2896957&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Don Kinzer (dkinzer) Assigned to: Nobody/Anonymous (nobody) Summary: Relocatable Expression Error Initial Comment: In avr-as, the modifiers like lo8(), hi8(), etc. provide an 8-bit value representing a portion of a relocatable expression. While these work correctly when used as an operand for an immediate mode instruction like ldi r24, lo8(foo), using them in a .byte directive results in an error indicating "Error: illegal relocation size: 1". .section .text .byte pm_lo8(bar), 0 ldi r24, pm_lo8(bar) bar: ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:34 Message: This needs to be reported to the GNU Binutils project at: http://sourceware.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in GNU Binutils must be reported to the GNU Binutils project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2896957&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:00:32
|
Bugs item #2525738, was opened at 2009-01-20 23:22 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2525738&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Young-seop Seo (syseop) Assigned to: Nobody/Anonymous (nobody) Summary: eeprom.h is not compatible with Winavr gcc .cpp mode Initial Comment: eeprom.h is not compatible with Winavr gcc .cpp mode when eeprom.h is included, Cpp Project is not compiled, I have tested in Atmega2560 MCU, but it doesn't matter in C Mode, ./eeprom.h:292: error: ISO C++ forbids incrementing a pointer of type 'void*' ./eeprom.h:292: error: ISO C++ forbids incrementing a pointer of type 'const void*' ./eeprom.h:292: error: invalid conversion from 'const void*' to 'const uint8_t*' How do I solve this problem? ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:41 Message: This needs to be reported to the avr-libc project at: http://savannah.nongnu.org/bugs/?group=avr-libc This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in avr-libc (the standard C library for the AVR) must be reported to the avr-libc project and not here. Closed as "Won't Fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2525738&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 01:00:08
|
Bugs item #2734371, was opened at 2009-04-05 07:52 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2734371&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Arnaud (trollace) Assigned to: Nobody/Anonymous (nobody) Summary: bug with switch() Initial Comment: IF i use the optimization -Os -mcall-prologues with a code relocated in the memory (ex in boot loader space) the compilation of a switch() generate wrong code and the code jump to invalid location ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:37 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: Anatoly Sokolov (aesok) Date: 2009-04-05 11:48 Message: > switch() generate wrong code and the code jump to invalid location For what device reported this bug? If for device with more than 64 KB of code memory then use "-fno-jump-tables" for compiling the bootloader code. This is documented in avr-libc user manual in "Selected general compiler options/-fno-jump-tables" section. Anatoly. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-04-05 08:12 Message: We need these items for a proper bug report: - A small test case that can be compiled that shows the problem - The command line being used that generates the problem - Version number of WinAVR and/or GCC that is being used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2734371&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:58:59
|
Bugs item #1854716, was opened at 2007-12-20 02:05 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1854716&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Binutils Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Colin Wall (colin_uu) Assigned to: Nobody/Anonymous (nobody) Summary: avr-objdump.exe -S switch not working Initial Comment: WinAVR release 20071221rc1. avr-objdump appears to not honour the -S switch for interleaving source code with the machine code in the list file. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:41 Message: This needs to be reported to the GNU Binutils project at: http://sourceware.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in GNU Binutils must be reported to the GNU Binutils project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: Martin Thomas (eversmith) Date: 2008-02-07 09:59 Message: Logged In: YES user_id=1598357 Originator: NO This patch should fix the issue: diff -Nbaur binutils-2.18.50/binutils/objdump.c binutils-2.18.50-mod/binutils/objdump.c --- binutils-2.18.50/binutils/objdump.c Thu Feb 7 16:04:47 2008 +++ binutils-2.18.50-mod/binutils/objdump.c Thu Feb 7 16:02:11 2008 @@ -964,7 +964,12 @@ #endif const char *map; struct stat st; + +#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN32__ + int fd = open (fn, O_RDONLY | O_BINARY); +#else int fd = open (fn, O_RDONLY); +#endif if (fd < 0) return NULL; ---------------------------------------------------------------------- Comment By: Marshall Jose (josemj1) Date: 2008-01-18 13:59 Message: Logged In: YES user_id=931728 Originator: NO WORKAROUND: Problem occurs for source text with DOS (CRLF) line endings, but goes away if files are converted to Unix (LF) line endings! It seems that AVR Studio honors each opened file's EOL convention, so it should be sufficient to run dos2unix once on the source files. ---------------------------------------------------------------------- Comment By: Marshall Jose (josemj1) Date: 2008-01-18 13:32 Message: Logged In: YES user_id=931728 Originator: NO Interestingly, avr-objdump will show you the correct filename and line number if you give it the -l option. So it seems to know where the correct source file is and the correct line number, but just won't get it and include it in the output. ---------------------------------------------------------------------- Comment By: Frank Haselmaier (fhbp) Date: 2007-12-29 10:14 Message: Logged In: YES user_id=1929722 Originator: NO Have the same Problem witch this new release. Old Version of avr-objdump (GNU objdump 2.16.1 + coff-avr-patch (20050630)) is working fine. Is this a special problem if the WINAVR build ? ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2007-12-20 09:01 Message: Logged In: YES user_id=543419 Originator: NO Note: this is for binutils 2.18. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1854716&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:48:32
|
Bugs item #2229892, was opened at 2008-11-06 08:02 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2229892&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 9 Private: No Submitted By: optech (optech_tr) Assigned to: Nobody/Anonymous (nobody) Summary: BUG: WINAVR ATMega2561 wrong addressing (probably eicall). Initial Comment: I wrote a code for atmega2561. The code's memory usage in prog memory is almost 153000 bytes. The problem is, code doesn't work properly. the mcu getting reset or something like this... I think compiled code calls wrong addresses in somewhere of the memory. When I comment some of part of text messages in the memory, the total memory usage become 126000 bytes and the code works good.... I had also had a problem with eicall in winavr. I had fixed it like this: EIND = 1; asm("ldi r30,0x00"); asm("ldi r31,0xf0"); asm("eicall"); I guess winavr doesn't set "EIND = 1;" for atmega2561 while compiling. So i cannot using the other part of mega2561 (nearly 128K) because of this BUG. Please somebody fix it, it is very urgent... Thanks.... ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:44 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: optech (optech_tr) Date: 2008-11-07 04:51 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. ---------------------------------------------------------------------- Comment By: optech (optech_tr) Date: 2008-11-07 04:51 Message: It was just a guess that it is releted with eicall. May be it has a different reason. Now I cannot use the other part of atmega2561, so it is a big problem... ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2008-11-06 08:48 Message: Duplicate of bug #2028719. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2229892&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:23
|
Bugs item #1996284, was opened at 2008-06-17 10:49 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1996284&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Binutils Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Danjel McGougan (danjelm) Assigned to: Nobody/Anonymous (nobody) Summary: objdump disassembles "lpm reg, Z" wrongly Initial Comment: avr-objdump found in release WinAVR-20080610 disassembles the "lpm reg, Z" instruction wrongly. Output from "avr-objdump -d <elf-file>": ... 2de: 81 e8 ldi r24, 0x81 2e0: 9f e0 ldi r25, 0x0F 2e2: 24 91 lpm r18, Z+ 2e4: 31 96 adiw r30, 0x01 2e6: e1 99 sbic 0x1c, 1 ... The instruction at 2e2 should disassemble to "lpm r18, Z". (Tested on elf binary compiled for ATmega128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1996284&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:23
|
Bugs item #2562424, was opened at 2009-02-03 16:10 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2562424&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: AVR-LibC Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Larry Barello (lbarello) Assigned to: Nobody/Anonymous (nobody) Summary: xmega header files missing #defines Initial Comment: These appears to be missing from all the xmega header files in WinAvr 20081205. #define PROGMEM_PAGE_SIZE 256 (128 for the 64k parts) and #define EEPROM_PAGE_SIZE 32 ---------------------------------------------------------------------- Comment By: Larry Barello (lbarello) Date: 2009-02-04 09:51 Message: I misread the xmega doco: the flash page sizes are specified in WORDS, so the sizes in the GCC header need to be 256 & 512 BYTES respectively. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-02-03 16:21 Message: Thanks for catching that! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2562424&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:21
|
Bugs item #2424083, was opened at 2008-12-13 08:43 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2424083&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Andre Payant (darkdragon2000) Assigned to: Nobody/Anonymous (nobody) Summary: Add word definitions to iocanxx.h Initial Comment: Please add word definitions for CANEN and CANIE to iocanxx.h: #define CANIE _SFR_MEM16(0xDE) #define CANEN _SFR_MEM16(0xDC) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2424083&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:20
|
Bugs item #2805617, was opened at 2009-06-12 12:17 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2805617&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Binutils Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Cliff Lawson (wrightflyer) Assigned to: Nobody/Anonymous (nobody) Summary: Memory sizes wrong for Tiny88 device Initial Comment: Both the datasheet and Atmel XML file for ATtiny88 - that is: <INT_SRAM> <SIZE>512</SIZE> <START_ADDR>$100</START_ADDR> </INT_SRAM> show that the Tiny88 device has 512 bytes of SRAM. As the base of SRAM in the device is at 0x100 this means that RAMEND is at 0x2FF and that the ram size is 512. iotn88.h wrongly contains: /* Constants */ #define RAMEND 0x1FF the value here should be 0x2FF. In the source for avr-size (that is binutils-2.18/binutils/size.c) it contains: {"attiny88", AVR8K, AVR256, AVR64}, the AVR256 in this should be AVR512 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2805617&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:18
|
Bugs item #2832677, was opened at 2009-08-05 08:38 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2832677&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: AVR-LibC Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: MartinEJ (mejohansen) Assigned to: Nobody/Anonymous (nobody) Summary: XMEGA A3B, RTC32 not properly supported Initial Comment: The RTC32_struct declared in iox256a3b.h is missing the double-word registers COMP, PER and CNT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2832677&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:46:18
|
Bugs item #2886068, was opened at 2009-10-25 13:12 Message generated for change (Settings changed) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2886068&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: DosMan (dosdaddy) Assigned to: Nobody/Anonymous (nobody) Summary: EEPROM location wrong for XMEGA Initial Comment: To use EEPROM memory mapping on XMEGA, the address of EEPROM variables must start at offset 0x1000 instead of 0. This should be done by changing all the XMEGA linker scripts so the .eeprom section starts at 0x811000 instead of 0x810000. There appear to be 35 linker script files that are affected. AVR Studio debugger will currently not recognize EEPROM data at this alternate starting address. I am submitting a request to Atmel to change that. In the meantime, there is an easy work-around using avr-objcopy to reset the EEPROM address so the debugger will recognize it: avr-objcopy --change-section-vma .eeprom=0x810000 <target>.elf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2886068&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:39:47
|
Bugs item #1884949, was opened at 2008-02-01 16:40 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1884949&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installer Group: v1.0 (example) >Status: Closed >Resolution: Wont Fix Priority: 7 Private: No Submitted By: Craig Greenlaw (craiggreenlaw) Assigned to: Nobody/Anonymous (nobody) Summary: System Path Blown Away After Install of WinAVR-20071221 Initial Comment: After installing WinAVR-20071221 my system wide path was reduced to only: C:\WinAVR-20071221\bin;C:\WinAVR-20071221\utils\bin Luckily I am able to recover most of my path from other machines with similar software installations, but I am sure others are completely out of luck. Basic entries like: %SystemRoot%\system32;%SystemRoot%; Are gone. Please look into this problem. Craig ---------------------------------------------------------------------- >Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:39 Message: Closing as "Won't Fix". ---------------------------------------------------------------------- Comment By: eightyfiv (eightyfiv) Date: 2008-12-12 22:24 Message: Oh. And path1.log is empty (0b), and path2.log is "C:\devtools\WinAVR\20081205\utils\bin". Which isn't all that surprising... ---------------------------------------------------------------------- Comment By: eightyfiv (eightyfiv) Date: 2008-12-12 22:22 Message: 'nother victim here. Path before: PATH=C:\DevTools\Perl\site\bin;C:\DevTools\Perl\bin;c:\devtools\watcom-1.3\binnt;c:\devtools\watcom-1.3\binw;c:\program files\windows resource kits\tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\program files\ati technologies\ati control panel;c:\program files\openafs\client\program;c:\program files\openafs\common;c:\program files\kerberos\;c:\program files\symantec\norton ghost 2003\;c:\sfu\common\;c:\program files\microsoft sql server\90\tools\binn\;c:\devtools\jdk1.5.0_06\bin;c:\devtools\apache-ant-1.6.5\bin;c:\devtools\bc7\bin;c:\devtools\bc7\binb;C:\DevTools\Usrp\bin;c:\program files\subversion\bin;C:\Program Files\MATLAB\R2007a\bin;C:\Program Files\MATLAB\R2007a\bin\win32;C:\Program Files\Microsoft Driver Test Manager\Controller\;C:\DevTools\IronPython-1.1.2\;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\Microsoft SQL Server\90\DTS\Binn\;C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ After: C:\devtools\WinAVR\20081205\bin;C:\devtools\WinAVR\20081205\utils\bin XP SP2, AVR Studio just installed, no other WinAVR or AVR anything previously installed. As you can see, a disturbing amount of other crap present. (Could long paths be an issue? Insufficient buffer space when querying? Or what about case sensitivity in querying prior value?) At any rate, you could just punt and issue an error if the path string has only two entries when you're about to write it and tell the user to manually punch 'em in. I'm lucky I had a dos box open (with the prior path intact), or I'd have to do a system restore. --eightyfiv ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2008-03-19 10:40 Message: Logged In: YES user_id=543419 Originator: NO Again, I cannot reproduce this on my system. However, I am adding some logging capabilities to the installer. The installer will write the contents of the PATH environment variable to a log file before it changes it. The installer changes the PATH environment variable twice, once to add the Utilities directory, and another time to add the Binaries directory. So there will actually be two log files written with the contents of the PATH variable before it gets changed. Hopefully this can be used to track down which step is failing, but at the very least it will make recovery of the PATH environment variable easier. This is all I can do right now until this can be reliably reproduced. But I will keep this bug report open until this gets figured out. ---------------------------------------------------------------------- Comment By: Manny (corio) Date: 2008-03-07 09:21 Message: Logged In: YES user_id=2029467 Originator: NO FYI, my system is: Windows XP SP2 Dell 370 Precision Workstation. ---------------------------------------------------------------------- Comment By: Manny (corio) Date: 2008-03-06 12:52 Message: Logged In: YES user_id=2029467 Originator: NO I am having the exact same problem with this version 'WinAVR-20071221'. I am not sure what is causing this to occur but it didn't happen on one system but did on another so giving instruction on how to replicate this issue is not possible for me at this point. I never had a previous version of WinAVR installed on the system in question so that is definitely not the issue. Any help would be great.. ---------------------------------------------------------------------- Comment By: Craig Greenlaw (craiggreenlaw) Date: 2008-02-23 12:06 Message: Logged In: YES user_id=1998263 Originator: YES I believe the previously installed version was 20070122. If I remember correctly I uninstalled 20070122 after installing 20071221. Does this help any? Craig ---------------------------------------------------------------------- Comment By: Craig Greenlaw (craiggreenlaw) Date: 2008-02-23 01:06 Message: Logged In: YES user_id=1998263 Originator: YES On a machine that has never had winavr installed I didn't have a problem with PATH corruption. The machine on which I had the reported problem had a previous installation of winavr. Unfortunately I don't recall which version was installed. Do you know if the previous version my be stored in the registry? I haven't searched it yet, but I can if needed. Craig ---------------------------------------------------------------------- Comment By: Craig Greenlaw (craiggreenlaw) Date: 2008-02-23 00:40 Message: Logged In: YES user_id=1998263 Originator: YES This was also noted in bug# 1800537. I don't have the machine in front of me right now, but I will on Monday. I am trying it on another machine right now. I'll let you know if it occurs again. Craig ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2008-02-02 08:32 Message: Logged In: YES user_id=543419 Originator: NO I have had one other report about this issue (on AVR Freaks IIRC), but I am unable to reproduce the problem on my machine. Can you give me some more details about your machine and OS version? Thanks, Eric Weddington ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=1884949&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:38:40
|
Bugs item #2811273, was opened at 2009-06-23 22:13 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2811273&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: nix (nixhanno) Assigned to: Nobody/Anonymous (nobody) Summary: STATUS_ACCESS_VIOLATION Initial Comment: Using WinAVR-20090313: When compiling with AVR-GCC using command line macro definition (-D) if the parameter value is encolsed in quotes (e.g. -DPARAM="VALUE") there must be TWO spaces between one definition and the next (or previous, or both) otherwise it fails with the following: 0 [main] sh 2908 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 68455 [main] sh 2908 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump This is not an issue when compiling on Mac OS X using CrossPack-AVR-20090415 with only ONE space character being necessary. I have provided the stackdump mentioned above. If anything else is needed, just let me know. ---------------------------------------------------------------------- >Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:38 Message: Closing as "Won't Fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2811273&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:36:48
|
Bugs item #2755364, was opened at 2009-04-12 03:58 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2755364&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: SprinterSB (sprintersb) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong shift/bitfield extract in WinAVR-20090313/-20081205 Initial Comment: The following testcase will generate wrong code compilerd as avr-gcc -O -S foo.c char bug (unsigned x) { return x >> 12; } bug: swap r24 andi r24,lo8(15) ret both in WinAVR-20090313 and WinAVR-20081205 The same is true for >> 13, >> 14 and respective bitfield extractions. The bug is introduced by 41-gcc-4.3.2-bug-11259_v3.patch which defines erroneous define_insn_and_split "*lshrqi3_const4", "*lshrqi3_const5", "*lshrqi3_const6". The bug can be suppressed by -fno-split-wide-types or by disabling optimization. For a discussion see http://lists.gnu.org/archive/html/avr-gcc-list/2009-04/msg00005.html Georg-Johann ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:36 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: Anatoly Sokolov (aesok) Date: 2009-04-18 06:35 Message: Hi Georg-Johann. Please, more clearly describe why you are seeing this bug. The GCC HEAD generate this code for 'bug' function: avr-gcc -std=gnu99 -gdwarf-2 -Wall -Os -mmcu=atmega128 -D F_CPU=4000000UL -save- temps -c -o main.o main.c .global bug .type bug, @function bug: .LFB0: .LM1: .LVL0: /* prologue: function */ /* frame size = 0 */ .LM2: mov r24,r25 .LVL1: swap r24 andi r24,lo8(15) /* epilogue start */ ret .LFE0: .size bug, .-bug Anatoly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2755364&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:34:29
|
Bugs item #2905895, was opened at 2009-11-30 03:23 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2905895&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Ilya Potrepalov (i501-q) Assigned to: Nobody/Anonymous (nobody) Summary: use -ffixed-reg registers Initial Comment: In GCC manual "3.18 Options for Code Generation Conventions": -ffixed-reg Treat the register named reg as a fixed register; generated code should never refer to it (except perhaps as a stack pointer, frame pointer or in some other fixed role). reg must be the name of a register. The register names accepted are machine-specific and are defined in the REGISTER_NAMES macro in the machine description macro file. Code: main.c ----------------- long bug( long a, long b, long c ); register unsigned char reg16 asm( "r16" ); register unsigned char reg17 asm( "r17" ); int main( void ) { long t = bug( 1, 2, 3 ); } ----------------- bug.c: ----------------- long bug( long a, long b, long c ) { return a + b + c; } ----------------- make.bat: ----------------- avr-gcc -ffixed-r16 -ffixed-r17 -mmcu=atmega64 main.c bug.c avr-objdump -S a.out > dis.lst ----------------- dis.lst (only intresting part): ----------------- 000000a4 <main>: a4: ef 92 push r14 a6: ff 92 push r15 a8: df 93 push r29 aa: cf 93 push r28 .... c6: 0f 2e mov r0, r31 c8: f3 e0 ldi r31, 0x03 ; 3 ca: ef 2e mov r14, r31 cc: f0 e0 ldi r31, 0x00 ; 0 ce: ff 2e mov r15, r31 d0: f0 e0 ldi r31, 0x00 ; 0 d2: 0f 2f mov r16, r31 d4: f0 e0 ldi r31, 0x00 ; 0 d6: 1f 2f mov r17, r31 d8: f0 2d mov r31, r0 da: 0e 94 80 00 call 0x100 ; 0x100 <bug> ... fe: 08 95 ret ----------------- GCC use registers r16, r17 (and it did not save them). GCC must not use registers that list in -ffixed-reg options. GCC use registers r18, r19 in bultin functions when r18, r19 list in -ffixed-reg option. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:34 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2905895&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:33:54
|
Bugs item #2726449, was opened at 2009-04-02 03:30 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2726449&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: Yes Submitted By: Rainer Lauer (lauerr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong shift left operation Initial Comment: When shifting a variable declared as uint16_t left by 6 only the lower 8 bits are shifted, upper 8 bits are fixed to 0. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:33 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: Rainer Lauer (lauerr) Date: 2009-04-03 08:06 Message: Sorry, I got you wrong. Here you are. Find the assembler, compiler and linker flags in makefile attached. ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-04-03 07:04 Message: I didn't ask what the error is; I found that in your file. I need to know what avr-gcc command line you used. What compiler flags did you use? ---------------------------------------------------------------------- Comment By: Rainer Lauer (lauerr) Date: 2009-04-03 06:24 Message: You'll find in the attached file following block: realAddress = (((DCC_Data0 >> 4) & 0b00000111) ^ 0b00000111) << 6; source code line causing problem 18e: 80 91 75 00 lds r24, 0x0075 192: 82 95 swap r24 194: 8f 70 andi r24, 0x0F ; 15 196: 80 95 com r24 198: 82 95 swap r24 19a: 88 0f add r24, r24 ; Rainer Lauer: No overrun from lower 8 bits (r24) into upper 8 bits (r25) 19c: 88 0f add r24, r24 ; Rainer Lauer: No overrun from lower 8 bits (r24) into upper 8 bits (r25) 19e: 80 7c andi r24, 0xC0 ; 192 1a0: 90 e0 ldi r25, 0x00 ; 0 ; Rainer Lauer: ERROR shift operation NOT OK, only 8 bit operation, NO 16 bit !!!! 1a2: 90 93 77 00 sts 0x0077, r25 1a6: 80 93 76 00 sts 0x0076, r24 ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2009-04-02 09:02 Message: What is the command line that you used that shows the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2726449&group_id=68108 |
|
From: SourceForge.net <no...@so...> - 2010-01-13 00:32:44
|
Bugs item #2150149, was opened at 2008-10-06 13:26 Message generated for change (Comment added) made by arcanum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2150149&group_id=68108 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GCC Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Rene Bourgouin (rbourgouin) Assigned to: Nobody/Anonymous (nobody) Summary: Internal compiler error : bad address + print operand Initial Comment: This following function, extracted from the July 2008 AVR technical library ("using the XMEGA DAC")doesn't work using WinAVR-20080610 and AVR Studio version 4.14 for the Atmel XMega 128 A1: #include <avr\io.h> uint8_t SP_ReadCalibrationByte( uint8_t index ) { uint8_t result; __asm__ __volatile__ ( "ldi r20, %3" "\n\t" "mov r30, %2" "\n\t" "clr r31" "\n\t" "sts %1, r20" "\n\t" "lpm %0, Z" "\n\t" "ldi r20, %4" "\n\t" "sts %1, r20" : "=r" (result) : "m" (NVM_CMD), "r" (index), "M" (NVM_CMD_READ_CALIB_ROW_gc), "M" (NVM_CMD_NO_OPERATION_gc) : "r20", "r30", "r31" ); return result; } The compilation errors generated are: ../src/dummy.c: In function 'SP_ReadCalibrationByte': ../src/dummy.c:32: error: internal compiler error. Bad address: (plus:HI (reg/f:HI 26 r26 [44]) (const_int 10 [0xa])) ../src/dummy.c:32: internal compiler error: in print_operand, at config/avr/avr.c:1270 Please submit a full bug report... ---------------------------------------------------------------------- Comment By: Eric Weddington (arcanum) Date: 2010-01-12 17:32 Message: This needs to be reported to the GCC project at: http://gcc.gnu.org/bugzilla/ This is not a WinAVR bug. The WinAVR User Manual states that any potential bugs in the GCC compiler must be reported to the GCC project and not here. Closed as "Won't Fix." ---------------------------------------------------------------------- Comment By: SprinterSB (sprintersb) Date: 2009-01-30 01:22 Message: Please correct you inline asm statement. A proposal could lokk like this: uint8_t SP_ReadCalibrationByte (uint8_t index) { uint8_t result; __asm__ __volatile__ ( "sts %1, %3" "\n\t" "lpm %0, %a2" "\n\t" "sts %1, %4" : "=&r" (result) : "i" (&NVM_CMD), "z" ((uint16_t) index), "r" ((uint8_t) NVM_CMD_READ_CALIB_ROW_gc), "r" ((uint8_t) NVM_CMD_NO_OPERATION_gc) ); return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2150149&group_id=68108 |
2 messages has been excluded from this view by a project administrator.
