[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 Eric Weddington changed: What|Removed |Added Priority|P3 |P4 Severity|major |normal --- Comment #1 from Eric Weddington 2012-09-05 20:39:08 UTC --- Reducing importance. I don't know of anyone building toolchains with the avr target and using newlib as the C library. The avr-rtems target should be tried, though.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #8 from Eric Weddington 2012-03-13 05:37:45 UTC --- (In reply to comment #7) > ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error: > allocating 2050 bytes of stack is more than 'at90s2313' can provide > make[8]: *** [lib_a-glob.o] Error 1 > > => Progress, at least no ICE. > > However, this warning still leaves users in unclearity as GCC doesn't tell the > maximum of stack it can provide. You can look up in the device datasheet to see how much RAM it has. Or do you want GCC to print out how much RAM each device has? > > > or whatever and > > tries to build insane code with 2050 bytes of stack for device(s) with only > > 128 > > bytes of RAM. > Well, my view is different: The avr's default set of multilib variants is > non-suitable as general default set of multlib variants. It probably is > suiteable as set of multilibs for bare-metal targets, but does not meet the > demands of OSes. Do you have recommendations? Or better still, a patch?
[Bug rtl-optimization/48715] CASE_VALUES_THRESHOLD should be settable with --param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48715 Eric Weddington changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Eric Weddington 2011-12-01 12:53:46 UTC --- Hi Mike, Were you planning on getting this patch in for 4.7?
[Bug target/49857] Put constant switch-tables into flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2011-07-27 00:00:00 |2011-12-01 Ever Confirmed|0 |1
[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50733 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||eric.weddington at atmel ||dot com Resolution||WONTFIX --- Comment #3 from Eric Weddington 2011-12-01 12:43:35 UTC --- This issue should go away when address spaces are done for the avr target (in future 4.7). The PROGMEM macro equates to a GCC attribute for that variable to place that into the Flash (Program Memory). It is up to the user to know this and to use the related macros in avr-libc to correctly retrieve the data from Flash. The AVR is a Harvard architecture chip and until Address Spaces were added to GCC it didn't have a good way of knowing these address spaces and able to generate a warning. I'm marking this bug as WONTFIX, but I suggest that the bug reporter add their email address to the CC field of bug #49868 (address spaces on the avr).
[Bug target/51050] [AVR, attiny26] ICE: invalid rtl sharing found in the insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51050 --- Comment #2 from Eric Weddington 2011-12-01 12:36:23 UTC --- Johann, Is this a duplicate of your bug #51345?
[Bug middle-end/37165] [4.4/4.5/4.6/4.7 Regression] FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37165 Eric Weddington changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Target Milestone|4.4.7 |4.7.0 --- Comment #10 from Eric Weddington 2011-12-01 12:30:17 UTC --- Failure is no longer showing up in 4.7 trunk. http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00955.html Closing bug.
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868
--- Comment #5 from Eric Weddington
2011-10-20 14:36:01 UTC ---
Hi Johann,
I would prefer if the name of the address space for program memory be named
"__flash" so that way it is the same name as what the IAR compiler uses. Using
the same name as the IAR compiler assists users who wish to migrate from the
IAR to the GCC toolchains. Like so:
+ c_register_addr_space ("__flash", ADDR_SPACE_PGM);
[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49903 Eric Weddington changed: What|Removed |Added Summary|AVR: Redundant comparisons |[avr] Redundant comparisons |in binary-seach switch/case |in binary-search |expansion |switch/case expansion Severity|normal |enhancement --- Comment #1 from Eric Weddington 2011-07-29 15:07:52 UTC --- Johann, Would some type of peephole optimization help out on this?
[Bug target/49881] [AVR] Inefficient stack manipulation around calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49881 --- Comment #1 from Eric Weddington 2011-07-27 23:13:31 UTC --- (In reply to comment #0) > Created attachment 24848 [details] > Hack to set ACCUMULATE_OUTGOING_ARGS > > While looking at PR49864 I noticed some awful code. > > First, the argument setup code doesn't use push: > > rcall . > rcall . > rcall . Please note that the rcall instruction has a side effect of subtracting 2 bytes from the SP (or 3 bytes if the avr device has a 22-bit PC). This side effect is used in doing the "rcall ." instructions as an optimization to avoid doing 2 pushes (the rcall and push instructions are the same size). But I agree that the code looks bad, and you show an improvement. Where is this test case that you're referring to? I can only find your patch at this PR, and only a patch at PR49864. Thanks, Eric Weddington
[Bug target/49857] Put constant switch-tables into flash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Eric Weddington changed: What|Removed |Added Severity|normal |enhancement
[Bug target/46898] libgcc build failure on lm32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898 Eric Weddington changed: What|Removed |Added CC||eric.weddington at atmel ||dot com --- Comment #16 from Eric Weddington 2011-07-24 22:32:03 UTC --- (In reply to comment #15) > Same problem with the AVR arch, using the same testcase: > avr-gcc-4.5.2: OK > avr-gcc-4.6.0: avr-gcc -gdwarf-2 foo.c > foo.c:1:0: internal compiler error: in dwarf2out_frame_init, at > dwarf2out.c:4260 > Please submit a full bug report, > with preprocessed source if appropriate. > > $ avr-gcc -v > Using built-in specs. > COLLECT_GCC=/usr/bin/avr-gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.6.0/lto-wrapper > Target: avr > Configured with: ../gcc-4.6.0/configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls > --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs > --with-pkgversion='Fedora 4.6.0-1.fc14' > --with-bugurl=https://bugzilla.redhat.com/ > Thread model: single > gcc version 4.6.0 (Fedora 4.6.0-1.fc14) Thibault, Please retest with trunk and/or 4.6.1, and if problem still exists on avr target then please submit a separate bug report. Eric Weddington
[Bug target/47509] avr-gcc error: could not split insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47509 Eric Weddington changed: What|Removed |Added CC||eric.weddington at atmel ||dot com, gjl at gcc dot ||gnu.org --- Comment #2 from Eric Weddington 2011-07-24 21:43:26 UTC --- Johann, you might want to take a look at this one too.
[Bug target/49313] Inefficient libgcc implementations for avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49313 Eric Weddington changed: What|Removed |Added CC||eric.weddington at atmel ||dot com --- Comment #3 from Eric Weddington 2011-07-23 21:24:46 UTC --- Johann, You've committed a patch for this PR. Can this be closed now? Eric
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807
--- Comment #2 from Eric Weddington
2011-07-21 20:12:58 UTC ---
(In reply to comment #0)
> This C source:
>
> #define SPDR (*((char volatile*) 0x2c))
Hi Johann,
That's not quite correct. In avr-libc the header file sfr_defs.h will define a
register as this:
#define SPDR (*((volatile char *) 0x2c))
It's a pointer to a volatile char, not a volatile pointer to a char.
> Changing the source like
>
> #define SPDR0 (*((char*) 0x2c))
> #define SPDR1 (*((char*) 0x2d))
> #define SPDR2 (*((char*) 0x2e))
> #define SPDR3 (*((char*) 0x2f))
>
> void read_adc (long big)
> {
>SPDR0 = big >> 24;
>SPDR1 = big >> 16;
>SPDR2 = big >> 8;
>SPDR3 = big;
> }
>
>
> and it compiles fine:
Is your intent to change the address AND remove the volatile keyword? If you
want to test if it's the volatile keyword that is the cause then you should
only change that part:
#define SPDR (*((char *) 0x2c))
void read_adc (long big)
{
SPDR = big >> 24;
SPDR = big >> 16;
SPDR = big >> 8;
SPDR = big;
}
Overall, though, I think you're on the right track. Most users would like to be
able to do the shift-and-assign pattern in C and have it compile to storing the
individual byte without a shift in the assembly. Right now, the only way to do
a workaround to achieve that result is through the use of a union with a struct
and an integer type (like a long). If this issue can be fixed then I think that
this has a chance to reduce a lot of code size problems.
[Bug target/46278] avr-gcc 4.5.1 doing suboptimal reloads using X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46278 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2011-07-07 00:00:00 |2011.07.19 13:55:18 Ever Confirmed|0 |1 --- Comment #5 from Eric Weddington 2011-07-19 13:55:18 UTC --- There's enough evidence to confirm this missed optimization.
[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.14 20:22:06 Ever Confirmed|0 |1 --- Comment #1 from Eric Weddington 2011-07-14 20:22:06 UTC --- Recent AVR test results confirm these two tests failing. http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01530.html FAIL: gcc.c-torture/compile/pr34448.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr34448.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr34448.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr34448.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr34448.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr34448.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr34448.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/pr34448.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr34448.c -O2 -flto (internal compiler error) FAIL: gcc.c-torture/compile/pr34448.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39928-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39928-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 -flto (internal compiler error) FAIL: gcc.c-torture/compile/pr39928-1.c -O2 -flto (test for excess errors)
[Bug target/49687] [4.6 Regression][avr] Missed optimization for widening MUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49687 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.14 18:45:17 Summary|AVR: Missed optimization|[4.6 Regression][avr] |for widening MUL|Missed optimization for ||widening MUL Ever Confirmed|0 |1 --- Comment #3 from Eric Weddington 2011-07-14 18:45:17 UTC --- The test case results using GCC 4.3.3 (WinAVR 20100110) shows that the mul8_126 case is smaller: .globalmul8_126 .typemul8_126, @function mul8_126: /* prologue: function */ /* frame size = 0 */ mov r18,r24 ; 2*movqi/1[length = 1] ldi r24,lo8(126) ; 6*movqi/2[length = 1] muls r18,r24 ; 7mulqihi3[length = 3] movw r18,r0 clr r1 movw r24,r18 ; 32*movhi/1[length = 1] /* epilogue start */ ret ; 30return[length = 1] .sizemul8_126, .-mul8_126 So this is a regression wrt to gcc 4.6.1. The case of mul8_155 shows the identical problem as for gcc 4.6.1.
[Bug target/49687] AVR: Missed optimization for widening MUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49687 --- Comment #2 from Eric Weddington 2011-07-14 18:41:56 UTC --- Created attachment 24758 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24758 Test case results using GCC 4.3.3 (WinAVR 20100110)
[Bug middle-end/49491] Superfluous move because of unnecessary spill for 2-operand insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49491 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.14 18:29:55 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1 Known to fail||4.3.3, 4.6.1, 4.7.0 --- Comment #1 from Eric Weddington 2011-07-14 18:29:55 UTC --- Confirmed. Identical failure with gcc 4.3.3 (WinAVR 20100110).
[Bug target/38159] [avr] ICE: gcc.c-torture/execute/pr38051.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38159 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.14 17:15:35 CC||gjl at gcc dot gnu.org Known to work||4.6.2 Ever Confirmed|0 |1 Known to fail||4.4.0, 4.7.0 --- Comment #3 from Eric Weddington 2011-07-14 17:15:35 UTC --- Odd, this does not show up as a failure in latest 4.6.2 test results: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01528.html But, it does show up as a failure in the latest 4.7.0 test results: http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01530.html There it fails for -O[23s] (plus various flags). The error is triggered even if -finline-functions is not specified.
[Bug target/44506] -mtiny-stack causes internal compiler error on gcc for avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44506 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.6.1 --- Comment #2 from Eric Weddington 2011-07-14 16:45:15 UTC --- (In reply to comment #1) > I cannot reproduce it with 4.6+. > > Maybe it's already fixed by r175048. > http://gcc.gnu.org/viewcvs?view=revision&revision=175048 Closing as WORKSFORME. Set milestone to 4.6.1 since revision 175048 is included in that release.
[Bug middle-end/43690] [4.4 Regression] Internal compiler error detected by avr-gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43690 --- Comment #9 from Eric Weddington 2011-07-12 02:58:20 UTC --- Patches were committed some time ago. Does this bug need to be marked as RESOLVED FIXED?
[Bug libmudflap/14118] h8300-elf, avr-elf, m68k-elf ports cannot build libmudflap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14118 Eric Weddington changed: What|Removed |Added CC||eric.weddington at atmel ||dot com --- Comment #13 from Eric Weddington 2011-07-12 02:23:51 UTC --- Is this really a bug anymore? How long has this been suspended?
[Bug c/49017] [avr] -ffunction-sections causes linker to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49017 Eric Weddington changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #4 from Eric Weddington 2011-07-11 20:47:20 UTC --- (In reply to comment #3) > Yes. I guess this feature will become obsolete when -flto gets stable, but I > don't how far that is. Actually it won't become obsolete. They do different things.
[Bug c/49017] [avr] -ffunction-sections causes linker to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49017 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.07.11 18:53:40 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1 --- Comment #2 from Eric Weddington 2011-07-11 18:53:40 UTC --- Stefan, does your application link correctly if you remove -ffunction-sections?
[Bug target/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212 Eric Weddington changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.6.1 --- Comment #6 from Eric Weddington 2011-07-11 17:57:58 UTC --- Since this works on 4.6.1, setting target milestone and closing.
[Bug target/18145] Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145 Eric Weddington changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #14 from Eric Weddington 2011-06-27 21:49:18 UTC --- > > Two things to consider: > > . Regardless of whether someone votes to remove an option, a segfault > should always be analyzed. It's easy enough to otherwise just hide > an error that will only reappear later on. Except that this is a segfault on a compiler switch that is unmaintained, and there are little to no user complaints about it. I would say remove the offending item and then fix anything if needed. > . As long as the AVR backend has a substantial number of PRs open about > "missed optimization", related to [u]int8_t -> int promotions, the > -mint8 option should stay, There are PRs open regarding missed optimization in this category. I'm not sure what is required to meet "substantial". > as it appears to be useful in particular > to people using very small controllers (ATtiny13, also think about > the new ATtiny4/5/6/9 series). Non-applicability of this option to > avr-libc is not a serious issue for those targets anyway, so this > (counter-)argument doesn't count here. Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I would call "experimental", in that they are only in distros and not upstream, and you know as well as I do that there is a serious wrong-code bug with them anyway. So those users don't even count. As to the other small device users, those devices still use avr-libc and there has been opportunity for users to complain through various channels (gcc, avr-gcc-list, avr-libc-dev) that -mint8 doesn't work. While we have had some complaints in the past, there haven't been much recently. You and I have also been telling users that -mint8 doesn't work with avr-libc and that it is unmaintained. We all know that the ideal solution is to fix the avr backend regarding optimizing (removing) unnecessary promotion. We can start by biting the bullet and removing -mint8. Eric
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #10 from Eric Weddington
2011-06-27 05:43:20 UTC ---
Hi All,
Johann is correct in his comment to bug #46261 (below).
The -mint8 compiler switch is now causing the compiler to give an ICE.
We need to finally make a decision from one of these options:
1. Fix ICE, leave -mint8 in the compiler, don't do anything with avr-libc, even
though avr-libc doesn't build with it.
2. Fix ICE, leave -mint8 in the compiler, work on avr-libc to also build with
-mint8 (eventually).
3. Remove -mint8, because avr-libc will never be changed to work with it.
Or suggest an alternative option.
Personally, I vote for #3. What's your option?
Thanks,
Eric Weddington
> -Original Message-
> From: gjl at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: Sunday, June 26, 2011 1:42 PM
> To: Weddington, Eric
> Subject: [Bug target/46261] avr-gcc: Segfaults when compiled with the -
> mint8 option
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
>
> Georg-Johann Lay changed:
>
>What|Removed |Added
> --
> --
>Keywords||ice-on-valid-code
> Status|RESOLVED|NEW
>Last reconfirmed||2011.06.26 19:41:11
> Resolution|WONTFIX |
> Ever Confirmed|0 |1
> Known to fail||4.5.2, 4.6.1
>
> --- Comment #9 from Georg-Johann Lay 2011-06-26
> 19:41:11 UTC ---
> (In reply to comment #1)
> > The -mint8 option also does not work with building avr-libc. There has
> been
> > discussion (on the avr-gcc-list mailing list) about eventually removing
> this.
> > There has been no interest by the AVR port maintainers (that I'm aware
> of) in
> > continuing to maintain this switch.
> >
> > Closed as WONTFIX.
>
> I strongly oppose the WON'T FIX.
>
> Either we keep that option and is is functional.
> Or we keep it and say sorry("-mint8 is discontinued") when it is used.
> Or we remove it.
>
> By no means the compiler is supposet to run into ICE/segfault, so allow me
> to
> reopen this issue.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.21 16:15:37 Ever Confirmed|0 |1
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Eric Weddington changed: What|Removed |Added Component|c |target --- Comment #1 from Eric Weddington 2011-06-21 15:27:41 UTC --- (In reply to comment #0) > Compiling the following function triggers an internal compiler error in (at > least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620: Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5? I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled successfully for -O[0123s]. > This was compiled using a cross-compiler on an x86_64 system as outlined > below: Could you try using a 32-bit host?
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2011-04-20 00:00:00 |2011.06.13 07:30:05 Ever Confirmed|0 |1 Severity|normal |major --- Comment #14 from Eric Weddington 2011-06-13 07:30:05 UTC --- (In reply to comment #13) > Can you change the state to NEW and raise the severity to blocker? I don't > have > required privileges. I've set state to NEW, but raised the severity to MAJOR. You need to understand that the severity is for the entire GCC project and the AVR target is not even a "secondary" target, even though it might be critical for Atmel.
[Bug target/48896] avr.o warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48896 Eric Weddington changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/44643] ice in c-typeck.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643 Eric Weddington changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug inline-asm/37895] AVR inline assembly clobbers input value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37895 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Eric Weddington 2011-03-14 14:13:35 UTC --- (In reply to comment #3) > So, please go ahead and close it. Ok. Closing as WORKSFORME.
[Bug target/42976] Illegal translation for IF operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42976 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Eric Weddington 2011-03-10 20:21:23 UTC --- Resolving as invalid.
[Bug target/37942] [4.4/4.5/4.6 Regression] FAIL: gcc.c-torture/compile/930618-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37942 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.4.6 |4.6.0 --- Comment #2 from Eric Weddington 2011-03-05 01:10:07 UTC --- I'll go ahead and mark this as fixed for 4.6.0.
[Bug target/45263] registers used in __do_global_ctors can get clobbered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263 --- Comment #10 from Eric Weddington 2010-12-05 19:52:33 UTC --- (In reply to comment #9) > Is R15 used anywhere else in startup code that might not obey the register > save > conventions (ie does do_global_ctors need to preserve R15) I strongly suggest not using R15. The ATtiny10 Family of devices (ATtiny10/4/5/9/20/40) only has R16-R31. So using R15 won't work for this class of devices. It would be best if we can find a register that will for all AVR devices.
[Bug target/44501] Wrong register stored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501 Eric Weddington changed: What|Removed |Added AssignedTo|unassigned at gcc dot |eweddington at gcc dot |gnu.org |gnu.org --- Comment #5 from Eric Weddington 2010-11-06 12:56:40 UTC --- (In reply to comment #4) > I think this bug should be closed. > > It's about a private port from Atmel for AVR32 which is not in GCC main line. I'm leaving it open for the moment. Assigning to self.
[Bug target/46278] avr-gcc 4.5.1 doing suboptimal reloads using X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46278 Eric Weddington changed: What|Removed |Added Keywords||missed-optimization CC||eric.weddington at atmel ||dot com Severity|enhancement |normal
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 Eric Weddington changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||eric.weddington at atmel ||dot com Resolution||WONTFIX --- Comment #1 from Eric Weddington 2010-11-02 18:39:59 UTC --- The -mint8 option also does not work with building avr-libc. There has been discussion (on the avr-gcc-list mailing list) about eventually removing this. There has been no interest by the AVR port maintainers (that I'm aware of) in continuing to maintain this switch. Closed as WONTFIX.
