[Bug ada/19959] [4.0 Regression] Can't compile gnattools for the AVR target
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
[Bug target/20016] Compiling libgcc2.c with -Os for avr-gcc?
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20016
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From ericw at evcohs dot com 2005-02-22 13:19 --- Subject: Re: unable to find a register to spill in class `POINTER_REGS' dieterbmeier at yahoo dot com wrote: >--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-22 >10:32 --- >Andy's patch works great for HEAD, but I get > >patching file avr.md >Hunk #1 FAILED at 344. >1 out of 1 hunk FAILED -- saving rejects to file avr.md.rej > >when patching 3_4 branch. > > > That's usually expected: a patch for HEAD does not guarantee that the patch will work for an earlier branch (3.4.x). Remember, this patch fixes a bug found on HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.
--- Additional Comments From ericw at evcohs dot com 2005-02-23 23:32 --- Please explain why you think it is a bug for the avr to support long long. Your description sounds like an opinion. The pointer size on the AVR is currently 16 bits. This will change in the near future to either 24 bits or 32 bits. -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.
--- Additional Comments From ericw at evcohs dot com 2005-02-24 14:04 --- Subject: Re: 4.0 bootstrap unreasonably requires 64-bit target type mode support. schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2005-02-24 02:49 >--- >Subject: Re: 4.0 bootstrap unreasonably requires > 64-bit target type mode support. > > > >>Please explain why you think it is a bug for the avr to support long long. >>Your description sounds like an opinion. >> >>The pointer size on the AVR is currently 16 bits. This will change in the >>near future to either 24 bits or 32 bits. >> >> > >Simply because no data type size support should be required beyond that >reasonably required by the source language itself. > > This is not an explanation; you are simply restating what you said earlier. >Please note that enabling the compiler to build with limited but perfectly >reasonable 32-bit maxim data types, does not prohibit the it's ability to >support significantly larger data types if desired for whatever reason; so >nor should the desire to restrict data type size support be inhibited.) > > If you experiment with the code, then you need to be prepared to unforseen limits. >As an aside, please don't confuse support of > 64KB FLASH program memory on >larger AVR's, with the architecture's inherent 16-bit data pointer / 64KB >data address space, as the two are orthogonal. Atmel has already clearly >positioned ARM to pick up where the AVR architecture leaves off; so although >we may likely see 256KB program + 8KB-32KB data memory versions forthcoming, >that's likely about it; as avr's target market has no corresponding need of >significantly more, not to mention it would bring the avr (an 8-bit machine) >needlessly to it's knees attempting to shuffle extended pointers around, >which wouldn't be too clever even if Atmel were to facilitate them; hence >Atmel's, and others, positioning of ARM and similar 16/32 based embedded >controllers. (Atmel understands what the avr is/isn't, to their credit.) > > > And a GCC bug report is not the place to get into a philosophical argument concerning Atmel's marketing practices. Please choose a more appropriate place to expound upon things unrelated to a GCC bug. You filed this "bug report" because you experimented and changed *working code* in CVS. The answer is "don't do that then". The change you made was not approved by either of the AVR maintainers and you ran into a limitation of the DWARF2 debugging format. I don't see how this is valid bug. The bug is in *your* changes, not in the FSF tree. GCC Bugzilla is a place for bugs in working FSF releases or for future extensions that are currently be worked on. AFAIK, there are no current plans to change long long to 32 bits. Feel free to contact either of the AVR maintainers, Denis Chertykov or Marek Michalkiewicz about this. But as this stands, this not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.
--- Additional Comments From ericw at evcohs dot com 2005-02-24 14:31 --- Subject: Re: 4.0 bootstrap unreasonably requires 64-bit target type mode support. schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2005-02-24 14:22 >--- >Subject: Re: 4.0 bootstrap unreasonably requires > 64-bit target type mode support. > > > >>>>Comments From ericw at evcohs dot com 2005-02-24 14:04 >>>>Please explain why you think it is a bug for the avr to support long long. >>>> >>>> > >- I'll try to type it slower, but don't think it would help; what's being > asserted is that the support of 64-bit long long should not be required to > build the compiler. (Any particular reason you believe it should be?) > > The code in CVS works. Your personal change did not. You need to explain why you think your personal change, to not support 64-bit long long, should be the new default for the avr port. And you need to explain it on the gcc mailing list, not in the context of a GCC bug report that describes a bug in your personal experimental changes. And as a courtesy you should CC the AVR maintainers. Again, you're just restating what you've said earlier without giving a reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
[Bug bootstrap/20143] 4.0 bootstrap unreasonably requires 64-bit target type mode support.
--- Additional Comments From ericw at evcohs dot com 2005-02-24 16:21 --- Subject: Re: 4.0 bootstrap unreasonably requires 64-bit target type mode support. schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2005-02-24 16:14 >--- >Subject: Re: 4.0 bootstrap unreasonably requires > 64-bit target type mode support. > > > >>Maybe I can be clearer, I am not stating that the avr port should not >>support 64-bit long long; just asserting that any port should not require >>64-bit integers to be able to build the compiler, if the language it's >>being built to support does not correspondingly require it. >> >>(the avr port was simply used as an example demonstration of the problem) >> >> > >The further good news is that upon reviewing the DWARF2 spec in detail, >and GCC's implementation, it's clear that a 32-bit DWARF data structure >is sufficient to support any target with 32-bit or less data type sizes. > >(which seems that it may be reasonably easy to support by declaring the >DWARF data structure size as a function of the size of target's the maxim >declared data type size; although possibly limited to a practical minimum >of 32-bits, which seems much more reasonable for smaller targets) > >[ I'll try a few experiments ] > > > > > Good. Can somebody with sufficient permissions please close this non-bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:01 --- Subject: Re: static initialization .data redundantly copied to ram prior to use. bjoern dot m dot haase at web dot de wrote: >--- Additional Comments From bjoern dot m dot haase at web dot de >2005-02-28 21:58 --- >I think the key problem is, that C language permits you to pass pointers to >your static const data structures to other functions. Possibly functions that >are not located within the same source file. While functions whithin the >source file that defines the const data structures could in principle know >that these data should be located in program memory and that they should be >accessed by using lpm instructions, I do not see how to pass this knowledge to >externally defined functions. Only solution in my opinion would be to define >different classes of pointers. > > > > Which is a *known issue* for the AVR port. At one point Svein Seldal was working on a patch to allow pointers to different memory spaces, but that was some time ago and I haven't heard from him about the status of his work. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug ada/19959] [4.0/4.1 Regression] Can't compile gnattools for the cross targets
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:03 --- Subject: Re: [4.0/4.1 Regression] Can't compile gnattools for the cross targets laurent at guerby dot net wrote: >--- Additional Comments From laurent at guerby dot net 2005-02-28 21:54 >--- >Please see http://www.rtems.com/phpwiki/index.php/RTEMSAda >for instructions on how to build a cross with Ada enabled >(this is for RTEMS but should be reusable). > > > If you look closely at the bug report, the target is for the AVR, which uses avr-libc and NOT newlib. The OP is working on the AVR-Ada project: <http://sourceforge.net/projects/avr-ada> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
[Bug middle-end/18887] [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:10 --- Subject: Re: [4.0/4.1 Regression] libgcc2.h Improperly determines required built-in function size requirements. schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2005-02-28 22:02 >--- >(In reply to comment #21) > > >>Hi, >> >>since this bug has been fixed by a patch of Roger Sayles a couple of weeks >>ago, I suggest to mark it as "fixed". >> >> > >It's true that the original failure mode, which nessesitated removing 64-bit >long longs >has been fixed, but observe that none the less; libgcc2.h still improperly >determines >built-in function types, if long-long types are not declared as being >supported by the >target. (the catch 22 is that one can't show a regression against an exiting >target, >because exiting targets would not build without 64-bit type support, therefore >the >only means to demonstraite it is to intentially remove such type support from >an exsiting >target, which should otherwise build fine, but wont')? > > > We've already gone over this. If you want to modify the sources to not declare the long long type for the AVR, fine, but that is on your experimental sources. See the previous discussion about this on bug # <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20143> Please stop rehashing the same stuff in bug reports. If the original failure is fixed, then close the bug report. If there are different failures, then open up new bug reports, one per failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug bootstrap/14316] collect2 doesnt build on windows hosts
--- Additional Comments From ericw at evcohs dot com 2005-02-28 23:42 --- What is the status of this bug wrt. to the 4.0 branch? Is it fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316
[Bug c/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-02 18:19 --- Please note that this was discussed heavily on avr-gcc-list recently, and it is a desired feature to have. This should be marked as an enhancement (since I don't have sufficient permissions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug c/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-02 18:20 --- And the Component should be marked "target". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-02 22:01 --- Link to discussion on avr-gcc-list: <http://lists.nongnu.org/archive/html/avr-gcc-list/2005-02/msg00220.html> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-03 19:49 --- Subject: Re: AVR assignment of a value through a 16 bit pointer generates out of order code schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2005-03-03 19:47 >--- >(In reply to comment #6) >Nope, these are peripheral i/o registers, and like any pheripheral interface >may have >access sequence requirements which need to be satsifyed within it's driver. >These >perpheral register's access sequence requirements have nothing to do with the >avr's >ISA or impled compiler requirments, just simply the conventions which need to >be >followed > > That's why this is an enhancement. This is a request to change those access conventions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug target/20227] [m68k] long double -> double cast fails with -0.0
--- Additional Comments From ericw at evcohs dot com 2005-03-04 00:38 --- Could you attach your proposed patch insted of putting it inline in the comment? Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20227
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From ericw at evcohs dot com 2005-03-04 14:19 --- (In reply to comment #11) Paul, Everybody who works on the AVR toolchain knows that it would be desirable to have attributes to allow objects to be put in and accessed in different address spaces. This has nothing to do with this bug report. Who are you trying to convince? Please refrain from muddying the waters with comments that have nothing to do with the issue at hand. You're just wasting bandwith. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug bootstrap/12026] m68k-coff build fails due to undefined references to _EH_FRAME_BEGIN
--- Additional Comments From ericw at evcohs dot com 2005-03-04 18:24 --- Could this problem be because it needs the --with-dwarf2 configure switch (for the __EH_FRAME_BEGIN__)? Reference: <http://gcc.gnu.org/ml/gcc/2002-07/msg00352.html> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12026
[Bug target/20296] Speeding up small interrupts on avr
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20296
[Bug middle-end/20355] MEM_READONLY_P & MEM_VOLATILE_P properties are lost on BLKmode rtl operands.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20355
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From ericw at evcohs dot com 2005-03-10 21:30 --- Marek, can you review this bug, the attached patches, and possibly approve committing the fix? Thanks Eric -- What|Removed |Added CC||marekm at amelek dot gda dot ||pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug target/19087] Overflowed address in dwarf debug line information
-- What|Removed |Added BugsThisDependsOn||19885 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- What|Removed |Added BugsThisDependsOn||19885 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added BugsThisDependsOn||19885 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug ada/20530] gnatlink does not respect -mno-cygwin
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
[Bug other/20594] New: Building AVR cross compiler: cannot build libgcc2
de -I../intl -DL_clear_bss -xassembler-with-cpp -c
../../gcc-3.4.3/gcc/config/avr/libgcc.S -o libgcc/./_clear_bss.o
/c/avrdev/gcc/build/gcc/xgcc -B/c/avrdev/gcc/build/gcc/ -B/WinAVR/avr/bin/
-B/WinAVR/avr/lib/ -isystem /WinAVR/avr/include -isystem /WinAVR/avr/sys-include
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF
-Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/
-I../../gcc-3.4.3/gcc/../include -I../intl -DL_ctors -xassembler-with-cpp -c
../../gcc-3.4.3/gcc/config/avr/libgcc.S -o libgcc/./_ctors.o
/c/avrdev/gcc/build/gcc/xgcc -B/c/avrdev/gcc/build/gcc/ -B/WinAVR/avr/bin/
-B/WinAVR/avr/lib/ -isystem /WinAVR/avr/include -isystem /WinAVR/avr/sys-include
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF
-Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/
-I../../gcc-3.4.3/gcc/../include -I../intl -DL_dtors -xassembler-with-cpp -c
../../gcc-3.4.3/gcc/config/avr/libgcc.S -o libgcc/./_dtors.o
/c/avrdev/gcc/build/gcc/xgcc -B/c/avrdev/gcc/build/gcc/ -B/WinAVR/avr/bin/
-B/WinAVR/avr/lib/ -isystem /WinAVR/avr/include -isystem /WinAVR/avr/sys-include
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF
-Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/
-I../../gcc-3.4.3/gcc/../include -I../intl -DL_muldi3 -c
../../gcc-3.4.3/gcc/libgcc2.c -o libgcc/./_muldi3.o
In file included from ../../gcc-3.4.3/gcc/libgcc2.c:43:
./tm.h:4:29: config/avr/avr.h: No such file or directory
./tm.h:5:28: config/dbxelf.h: No such file or directory
./tm.h:6:31: config/tm-dwarf2.h: No such file or directory
./tm.h:7:23: defaults.h: No such file or directory
../../gcc-3.4.3/gcc/libgcc2.c: In function `__mulhi3':
../../gcc-3.4.3/gcc/libgcc2.c:462: error: `BITS_PER_UNIT' undeclared (first use
in this function)
../../gcc-3.4.3/gcc/libgcc2.c:462: error: (Each undeclared identifier is
reported only once
../../gcc-3.4.3/gcc/libgcc2.c:462: error: for each function it appears in.)
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory `/c/avrdev/gcc/build/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/c/avrdev/gcc/build/gcc'
make: *** [all-gcc] Error 2
---
Building in Cygwin, but using --host=mingw32 --build=mingw32 configure switches
, -mno-cygwin compiler flag, GCC 3.3.3 does build an AVR cross compiler
correctly.
--
Summary: Building AVR cross compiler: cannot build libgcc2
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ericw at evcohs dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug other/20594] Building AVR cross compiler: cannot build libgcc2
--- Additional Comments From ericw at evcohs dot com 2005-04-07 16:47 --- According to this related thread: <http://gcc.gnu.org/ml/gcc/2005-03/msg01079.html> There is a patch on the MinGW project here: <http://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053052&group_id=2435> This patch works on Win2K according to the related thread, and it works for me for WinXP. -- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
[Bug other/20594] Building AVR cross compiler: cannot build libgcc2
--- Additional Comments From ericw at evcohs dot com 2005-04-07 16:50 --- Created an attachment (id=8556) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8556&action=view) Patch from MinGW project that fixes the problem on Win2k,XP This patch is from the MinGW project, at this bug report: <http://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053052&group_id=2435> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
[Bug other/20594] Building AVR cross compiler: cannot build libgcc2
-- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20594
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From ericw at evcohs dot com 2005-04-08 11:48 --- I got this same error as Rolf did, building an AVR cross GCC with Ada on MinGW. Could someone with more permissions be willing to set the Status as NEW? Eric Weddington -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug target/20808] Unrecognizable insn
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20808
[Bug middle-end/20937] BLK ptr's losing original ptr's static-constant readonly attribute.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From ericw at evcohs dot com 2005-04-13 15:43 --- FYI, I've tested the patch on my system here and it works for me. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug other/21052] New: Example does not compile in user docs, type attributes, packed
In the GCC 3.4.3 user manual, in the section on type attributes:
<http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html>
The example under the "packed" attribute does not compile.
See:
<http://gcc.gnu.org/ml/gcc/2005-04/msg00896.html>
--
Summary: Example does not compile in user docs, type attributes,
packed
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ericw at evcohs dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21052
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug target/21078] Testsuite reports excecution failure for gcc.c-torture/excecute/20010122.c for some optimization levels
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078
[Bug target/21079] avr-gcc lacks support for builtin ffs function
--- Additional Comments From ericw at evcohs dot com 2005-04-19 15:49 --- Björn, That sounds like a reasonable approach. Submit a bug report to the avr-libc project on Savannah: <http://savannah.nongnu.org/projects/avr-libc/> Eric -- What|Removed |Added CC| |ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21079
[Bug middle-end/21107] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21107
[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21284
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From ericw at evcohs dot com 2005-05-05 17:25 --- (In reply to comment #2) > Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug > (also a target which probably doesn't provide REAL 8). As a side note, it is known that Fortran does not build *at all* for the AVR target. AFAIK there has not been any work to provide Fortran for the AVR. This should be treated as a seperate issue. Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-05-05 18:09 --- Will someone with the requisite permissions please set this bug to NEW? This has been confirmed. Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/21479] optimizer removes incorrectly variable comparision in if clause
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.
--- Additional Comments From ericw at evcohs dot com 2004-12-14 05:03 --- Subject: Re: [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed. On 14 Dec 2004 at 2:13, schlie at comcast dot net wrote: > > --- Additional Comments From schlie at comcast dot net 2004-12-14 02:13 > --- > > Thank you all; and would like to try to verfiy on 4.0 as well > once we can figure out now to get the avr target to reliably build. > > AFAIK, the avr target is supposed to build now for HEAD. I haven't tried a snapshot recently, though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed.
--- Additional Comments From ericw at evcohs dot com 2004-12-14 14:18 --- Subject: Re: [3.4/4.0 Regression] ~6x+ performance regression, constant trees not being computed. On 14 Dec 2004 at 12:33, schlie at comcast dot net wrote: > > --- Additional Comments From schlie at comcast dot net 2004-12-14 12:33 > --- > Subject: Re: [3.4/4.0 Regression] ~6x+ performance > regression, constant trees not being computed. > > Nope, unfortunately not as of yesterday, since reload.c was tweaked last > week. Please file a separate bug report about this ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug target/19087] Overflowed address in dwarf debug line information
--- Additional Comments From ericw at evcohs dot com 2004-12-20 17:44 --- (In reply to comment #5) > Hmm, on the mainline I get an error about dwarf2 not being supported: > t.c:1: error: target system does not support the "dwarf-2" debug format > If you're talking about HEAD/4.0, then a seperate bug report needs to be filed. The avr port needs to be able to be configured for DWARF2 debug info. (Yes, I know that the avr port of GDB only uses stabs, but other tools use DWARF2.) The OP is using 3.4.1. -- What|Removed |Added CC| |ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/19293] avr-gcc crashes when using shifts with negative shift count
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
[Bug target/19684] avr-gcc 4.0 (and 3.3.4): wrong size in asm comment
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19684
[Bug other/19815] Documentation change - GCC Internals MODES_TIEABLE_P
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19815
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-02-10 18:59 --- The testcase compiles successfully with avr-gcc on 3.3.2, and 3.4.3, using -mmcu=atmega128. Could someone with sufficient permissions please set the "Known To Work" field. Dieter, could you confirm which device you're compiling for? -- What|Removed |Added CC| |ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-02-10 19:43 --- Dieter, could you please try this out with a more recent snapshot? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-02-10 21:48 --- Subject: Re: Can't compile ethernut OS (avr-gcc) dieterbmeier at yahoo dot com wrote: >--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-10 >21:44 --- >It still fails with 4.0.0 20050209. >BTW, it only fails with -Os. (-O0 to -O3 are OK) >3_4 branch is OK, too. > > > Which device are you compiling for? (-mmcu=?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug middle-end/19885] [4.0 Regression] avr dwarf-2 support is broken for head 4.0
--- Additional Comments From ericw at evcohs dot com 2005-02-10 23:36 --- As an aside, DWARF2 is about to become the default debugging information used in WinAVR, for both Atmel's AVR Studio and for use with avr-gdb/avr-insight. So this one is crucial for having a successful 4.0.0 release for the avr target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug target/19087] Overflowed address in dwarf debug line information
-- What|Removed |Added CC||bjoern dot m dot haase at ||web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Additional Comments From ericw at evcohs dot com 2005-02-11 19:38 --- Bernd, does this still fail on the most recent HEAD? Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug java/17939] New: Duplicate executable installed in building cross java compiler
Configured with: --build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++,java After build and install, in the installation directory are avr-gcjh.exe avr-avr-gcjh.exe and both executables have the same file size and they both report as the gcjh program with --version. -- Summary: Duplicate executable installed in building cross java compiler Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: minor Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ericw at evcohs dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17939
[Bug java/17939] Duplicate executable installed in building cross java compiler
--- Additional Comments From ericw at evcohs dot com 2004-10-11 18:33 --- Subject: Re: Duplicate executable installed in building cross java compiler pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 18:30 >--- >Do you use --program-prefix at all, if so this where the bug is. Otherwise this is a >target bug. > > > No --program-prefix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17939
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From ericw at evcohs dot com 2004-10-11 19:14 --- Subject: Re: Double target prefixed gcjh tromey at gcc dot gnu dot org wrote: >--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 19:08 >--- >Do you get a double prefix for gcj as well? > > For the avr target, no. >Can you tell me how the Makefile variable program_transform_name >is set in /gcc/Makefile? > > > For the avr target: # Sed command to transform gcc to installed name. program_transform_name := s,^,avr-,; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From ericw at evcohs dot com 2004-10-11 22:18 --- Subject: Re: Double target prefixed gcjh tromey at gcc dot gnu dot org wrote: >--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-11 21:20 >--- >I suppose you could try this. >I made it by looking at what other install rules are >doing in this area. I'm not at all sure it is correct. > >Index: Make-lang.in >=== >RCS file: /cvs/gcc/gcc/gcc/java/Make-lang.in,v >retrieving revision 1.145 >diff -u -r1.145 Make-lang.in >--- Make-lang.in 22 Sep 2004 11:21:21 - 1.145 >+++ Make-lang.in 11 Oct 2004 21:17:52 - >@@ -207,7 +207,9 @@ > rm -f $(DESTDIR)$(bindir)/$$tool_transformed_name$(exeext); \ > $(INSTALL_PROGRAM) $$tool$(exeext) >$(DESTDIR)$(bindir)/$$tool_transformed_name$(exeext); \ > chmod a+x $(DESTDIR)$(bindir)/$$tool_transformed_name$(exeext); \ >- if [ $$tool = gcjh ]; then \ >+ if [ -f $(GCJ)-cross$(exeext) ]; then \ >+true; \ >+ elif [ $$tool = gcjh ]; then \ > rm -f $(DESTDIR)$(bindir)/$(GCJH_TARGET_INSTALL_NAME)$(exeext); \ > ( cd $(DESTDIR)$(bindir) && \ > $(LN) $$tool_transformed_name$(exeext) >$(GCJH_TARGET_INSTALL_NAME)$(exeext) ); \ > > > > Patch works for the avr target. Thanks! Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From ericw at evcohs dot com 2004-10-13 13:45 --- Subject: Re: Double target prefixed gcjh On 13 Oct 2004 at 12:03, giovannibajo at libero dot it wrote: > > --- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:03 > --- > Confirmed. > > Eric, do you happen to know when this bug first appeared? Did you build other > older compilers which did not have this problem? > Unfortunately no, I do not know when this bug first appeared. Only in the last week did I first try to build java for the avr target, and to my knowledge it's the first time anybody has tried it. You can see some messages about this on the java list. And, no, I did not build it with older compilers. I can't speak for the original reporter of this bug though. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From ericw at evcohs dot com 2004-10-14 16:21 --- See related bug #17462. -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug target/17822] avr: Hard-coded XXX_FOR_TARGET
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822
[Bug debug/7241] DWARF encoding for "char" incorrect in gcc
--- Additional Comments From ericw at evcohs dot com 2004-10-14 18:37 --- Would someone comment if the fix in comment #6 is correct? And could it be applied to mainline to close out this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7241
[Bug target/18065] not using qi version of divmod
--- Additional Comments From ericw at evcohs dot com 2004-10-19 22:08 --- Bug #10733 is related. -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
[Bug target/18065] not using qi version of divmod
--- Additional Comments From ericw at evcohs dot com 2004-10-19 23:13 --- Subject: Re: not using qi version of divmod schlie at comcast dot net wrote: >--- Additional Comments From schlie at comcast dot net 2004-10-19 22:31 --- >Subject: Re: not using qi version of divmod > >Hi Eric, > >Out of curiosity, what exactly is the 10733 bug, is wrong result computed? > >If so, that implies that divmodhi is broken; otherwise it's not a bug, as >the intermediate (t1 + 40) expression yields an int result, as within the >context of the expression, although t1 is an unsigned char, there's no >guarantee that (t1 + 40) will not overflow an unsigned char size, therefore >properly assumed to be an int; unlike t1 = t1 % 3 or whatever, where all >operands are clearly type compatible with unsigned char, and a valid >optimization. > > Bug #10733 is a wrong-code bug involving the modulus operator on the AVR target. See the bug report itself for more information. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
[Bug target/18145] New: Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.
See FIXME in avr.c, function avr_file_start. -- Summary: Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty. Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ericw at evcohs dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
[Bug target/18151] New: Disable building of fixincludes for avr target.
Building and running fixincludes for the avr target is not necessary with the current canonical toolset of binutils, gcc and avr-libc: <http://savannah.nongnu.org/projects/avr-libc/> Building fixincludes currently fails for host=mingw32 host, which being corrected with bug #17832. But building fixincludes for the avr target is unnecessary to begin with. A potential patch would follow the form found here: <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00934.html> -- Summary: Disable building of fixincludes for avr target. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ericw at evcohs dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
-- What|Removed |Added CC||denisc at overta dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
-- What|Removed |Added CC||marekm at amelek dot gda dot ||pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
--- Additional Comments From ericw at evcohs dot com 2004-10-25 20:33 --- I've added the AVR mainters to the CC list of this bug. Would one of the AVR maintainers (Denis, Marek) be willing to approve such a change since this is a new feature? Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
--- Additional Comments From ericw at evcohs dot com 2004-10-28 18:02 --- Created an attachment (id=7425) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7425&action=view) Proposed patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug target/18151] Disable building of fixincludes for avr target.
--- Additional Comments From ericw at evcohs dot com 2004-10-28 19:54 --- Subject: Re: Disable building of fixincludes for avr target. pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 19:53 >--- >But you forgot to close it. > > > Thank you every one! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18151
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From ericw at evcohs dot com 2004-11-11 16:29 --- Subject: Re: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed. pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 >02:52 --- >or the default for -mint8 changed. > > > The size of long has always stayed at 32 bits. The default sizes for -mint8 *might* have changed. I know that Svein Seldal corrected a problem with the size of long with -mint8, but I thought that was on HEAD, i.e. for 4.0.0, not necessarily on 3.4.3. But I could be wrong. For reference: Normal: char = 8 bits int = 16 bits long = 32 bits With -mint8 (on 4.0.0 IIRC) char = 8 bits int = 8 bits long = 16 bits Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug target/18563] ICE: output_operand: invalid expression as operand
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug driver/18549] -save-temps option ends with corrupt object file
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
[Bug driver/18549] -save-temps option ends with corrupt object file
--- Additional Comments From ericw at evcohs dot com 2004-12-06 21:45 --- Subject: Re: -save-temps option ends with corrupt object file dannysmith at users dot sourceforge dot net wrote: >--- Additional Comments From dannysmith at users dot sourceforge dot net >2004-12-06 21:36 --- >It looks like you are mingw host. >If so, could you try trunk. This looks like dup of >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5620 > >Danny > > > This is correct. The avr toolset included in WinAVR is built as a MinGW host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18549
