Launchpad has imported 27 comments from the remote bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-10-30T19:09:23+00:00 Joel-l wrote: /home2/joel/build/b-avr-gcc/./gcc/xgcc -B/home2/joel/build/b-avr-gcc/./gcc/ -nostdinc -B/home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/ -isystem /home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/avr-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/avr-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/avr-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/avr-rtems4.11/sys-include -mmcu=avr25 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I/users/joel/test-gcc/gcc-svn/newlib/libc/search -Os -DPREFER_SIZE_OVER_SPEED -mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin -g -O2 -mmcu=avr25 -c -o lib_a-twalk.o `test -f 'twalk.c' || echo '/users/joel/test-gcc/gcc-svn/newlib/libc/search/'`twalk.c /users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c: In function '__expand_table': /users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: error: unable to find a register to spill in class 'POINTER_REGS' /users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: error: this is the insn: (insn 172 96 173 10 (set (reg:QI 18 r18) (mem/c:QI (plus:HI (reg/f:HI 28 r28) (const_int 5 [0x5])) [16 S1 A8])) /users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:886 1 {movqi_insn} (nil)) /users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: internal compiler error: in spill_failure, at reload1.c:2118 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/0 ------------------------------------------------------------------------ On 2011-10-30T19:42:50+00:00 Joel-l wrote: gcc (GCC) 4.7.0 20111029 (experimental) Newlib up to date at same time Cut and pasted from log with multiple jobs in parallel. The actual command line for hash.c was. /home2/joel/build/b-avr-gcc/./gcc/xgcc -B/home2/joel/build/b-avr- gcc/./gcc/ -nostdinc -B/home2/joel/build/b-avr-gcc/avr- rtems4.11/avr25/newlib/ -isystem /home2/joel/build/b-avr-gcc/avr- rtems4.11/avr25/newlib/targ-include -isystem /users/joel/test-gcc/gcc- svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/avr- rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/avr-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/avr-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/avr-rtems4.11/sys-include -mmcu=avr25 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I/users/joel/test-gcc /gcc-svn/newlib/libc/search -Os -DPREFER_SIZE_OVER_SPEED -mcall- prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin -g -O2 -c -o lib_a-hash.o `test -f 'hash.c' || echo '/users/joel/test-gcc/gcc- svn/newlib/libc/search/'`hash.c This shouldn't matter much except to have hash.c instead of twalk.c Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/1 ------------------------------------------------------------------------ On 2011-10-30T19:43:24+00:00 Joel-l wrote: Created attachment 25667 Preprocessed output Preprocessed code. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/2 ------------------------------------------------------------------------ On 2011-11-04T17:08:30+00:00 Gjl wrote: I can confirm this on current trunk r180962 with -Os/-O2/-O3. The bug disappears with -fno-caller-saves. I already observed trouble with -fcaller-saves together with -mstrict-X so that perhaps it is a good idea to disable that option for AVR? A size comparison if avr-libc generated with -f[no-]caller-saves looks as follows: Columns: 3nd = #bytes with -fcaller-saves 3rd = #bytes with -fno-caller-saves 4th = relative size gain 5th = absolute size gain vfscanf_flt.o : 21197 21347 0.7% 150 realloc.o : 4110 4164 1.3% 54 vfprintf_std.o : 8858 8840 -0.2% -18 vfprintf_flt.o : 16604 16508 -0.6% -96 calloc.o : 636 540 -15.1% -96 strdup.o : 654 516 -21.1% -138 vfscanf_min.o : 9613 9433 -1.9% -180 vfscanf_std.o : 12918 12736 -1.4% -182 :::::: Total ::::::: : 322839 322333 -0.2% -506 Other object do not change in size. Denis, what do you think: Should we kick off caller-saves alltogether? Appears that option increases register pressure/spill requests up to a level not appropriate for AVR. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/3 ------------------------------------------------------------------------ On 2011-11-04T17:12:21+00:00 Gjl wrote: Created attachment 25720 size-compared.txt This is a size comparison where objects of same name are not mangled. ...and let me add that the error also occurs for avr-unknown-none. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/4 ------------------------------------------------------------------------ On 2011-11-04T22:27:58+00:00 Gjl wrote: Asserting that the bug is not a flaw in avr backend, I set the component to "other". The bug is somewhere in the caller-saves/IRA/reload triangle like PR50775: http://gcc.gnu.org/ml/gcc/2011-10/msg00537.html Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/5 ------------------------------------------------------------------------ On 2011-11-14T01:26:40+00:00 Joel-l wrote: (In reply to comment #5) > Asserting that the bug is not a flaw in avr backend, I set the component to > "other". The bug is somewhere in the caller-saves/IRA/reload triangle like > PR50775: http://gcc.gnu.org/ml/gcc/2011-10/msg00537.html We need to get someone more general to look at this and get the right person investigating. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/6 ------------------------------------------------------------------------ On 2011-11-14T01:28:46+00:00 Joel-l wrote: Adding Jeff Law (to the right PR) in the hopes that he can determine who is the right person to investigate this. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/7 ------------------------------------------------------------------------ On 2011-11-14T17:09:04+00:00 Law-redhat wrote: I'm not going to be able to look at it anytime soon, but just some general thoughts: 1. Disabling caller-saves probably isn't appropriate. Just looking at codesize isn't the way to evaluate caller-saves either as caller-saves is tasked with improving performance, possibly at the expense of codesize. 2. The first thing someone needs to do is provide information as to why that insn needs reloads. I don't know enough about the AVR to hazard as guess why that insn needs reloads. 3. Find out where insn 172 comes from. There are restrictions on the insns created by caller-save. So if caller-save creates a bogus insn, then that needs to be investigated. Anyway, that's where I'd start. I can't say enough that disabling caller-saves merely to work around this problem is wrong wrong wrong. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/8 ------------------------------------------------------------------------ On 2011-12-05T18:31:53+00:00 Denisc-9 wrote: (In reply to comment #8) > I'm not going to be able to look at it anytime soon, but just some general > thoughts: I think that I'm ready to explain the bug. > 1. Disabling caller-saves probably isn't appropriate. Just looking at > codesize isn't the way to evaluate caller-saves either as caller-saves is > tasked with improving performance, possibly at the expense of codesize. I'm agree. I don't want to disable caller-saves. > > 2. The first thing someone needs to do is provide information as to why that > insn needs reloads. I don't know enough about the AVR to hazard as guess why > that insn needs reloads. > > 3. Find out where insn 172 comes from. There are restrictions on the insns > created by caller-save. So if caller-save creates a bogus insn, then that > needs to be investigated. Generally, caller-save generate right insn. 1. AVR port have a specific dependency between frame_pointer_neede and gat_frame_size() Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/9 ------------------------------------------------------------------------ On 2011-12-05T18:53:34+00:00 Law-redhat wrote: Other ports seem to work OK when the requirement for a frame pointer is conditional on the size of the stack. It's not the most common case, but it does come up in several ports. I still haven't seen a good description of why the particular insn needs reloads. Not everyone is familiar with the guts of the avr port. I'd then be looking at init_caller_save to determine why it thinks a particular address is OK for a caller-save, when in fact it isn't OK. jeff Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/10 ------------------------------------------------------------------------ On 2011-12-05T19:08:41+00:00 Denisc-9 wrote: Sorry, wrong button was pressed. (In reply to comment #8) > I'm not going to be able to look at it anytime soon, but just some general > thoughts: I think that I'm ready to explain the bug. > 1. Disabling caller-saves probably isn't appropriate. Just looking at > codesize isn't the way to evaluate caller-saves either as caller-saves is > tasked with improving performance, possibly at the expense of codesize. I'm agree. I don't want to disable caller-saves. > > 2. The first thing someone needs to do is provide information as to why that > insn needs reloads. I don't know enough about the AVR to hazard as guess why > that insn needs reloads. > > 3. Find out where insn 172 comes from. There are restrictions on the insns > created by caller-save. So if caller-save creates a bogus insn, then that > needs to be investigated. Generally, caller-save generate right insn. 1. AVR port have a specific dependency between frame_pointer_needed and get_frame_size(). avr_frame_pointer_required_p (void) { return (cfun->calls_alloca || cfun->calls_setjmp || cfun->has_nonlocal_label || crtl->args.info.nregs == 0 || get_frame_size () > 0); } 2. reload calls the `setup_save_areas ()' and after that get_frame_size () equal to 2, but frame_pointer_needed is 0. It's wrong for AVR port (If dependency between frame_pointer_needed and get_frame_size() is permitted by GCC core). 3. After that caller-save generate right save/restore insns for save to frame slot and restore from it. Like this (r28 is a frame pointer): (insn 162 77 163 10 (set (reg:QI 18 r18) (mem/c:QI (plus:HI (reg/f:HI 28 r28) (const_int 1 [0x1])) [8 S1 A8])) /mnt/d/avr-work/tst/nl.c:120 20 {movqi_insn} (nil)) 4. After that the following code was executed: /* If needed, eliminate any eliminable registers. */ if (num_eliminable || num_eliminable_invariants) did_elimination = eliminate_regs_in_insn (insn, 0); And right insns converted to wrong (__SP_L__ can not be used as a pointer): (insn 162 77 163 10 (set (reg:QI 18 r18) (mem/c:QI (plus:HI (reg/f:HI 32 __SP_L__) (const_int 1 [0x1])) [8 S1 A8])) /mnt/d/avr-work/tst/nl.c:120 20 {movqi_insn} (nil)) Here we have a wrong elimination FP->SP because frame_pointer_needed was not recalculated earlier. 5. relod have the following fragment: if (caller_save_needed) setup_save_areas (); /* If we allocated another stack slot, redo elimination bookkeeping. */ if (something_was_spilled || starting_frame_size != get_frame_size ()) continue; ------------------------------- But it's not resolve the problem. frame_pointer_needed isn't recalculated. Call to `update_eliminables ()' seems as a right solution. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/11 ------------------------------------------------------------------------ On 2011-12-05T19:15:11+00:00 Denisc-9 wrote: This is a very old bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42204 http://gcc.gnu.org/ml/gcc/2006-03/msg00783.html Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/12 ------------------------------------------------------------------------ On 2011-12-06T18:42:23+00:00 Denisc-9 wrote: Created attachment 26008 Simplified testcase Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/13 ------------------------------------------------------------------------ On 2012-01-12T18:30:00+00:00 Denisc-9 wrote: Author: denisc Date: Thu Jan 12 18:29:54 2012 New Revision: 183136 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183136 Log: PR target/50925 * config/avr/avr-protos.h (avr_hard_regno_nregs): Declare. * config/avr/avr.c (avr_can_eliminate): Simplify. (avr_initial_elimination_offset): Likewise. (avr_prologue_setup_frame): Use hard_frame_pointer_rtx. (expand_epilogue): Likewise. (avr_legitimize_address): Gut. (avr_legitimize_reload_address): Use hard_frame_pointer_rtx. (avr_hard_regno_nregs): New. (avr_hard_regno_ok): Allow only Pmode for arg and frame_pointers. (avr_regno_mode_code_ok_for_base_b): Handle arg and frame pointers. * config/avr/avr.h (FIXED_REGISTERS): Adjust arg pointer, add soft frame pointer. (CALL_USED_REGISTERS): Likewise. (REG_CLASS_CONTENTS): Likewise. (REGISTER_NAMES): Likewise. (HARD_REGNO_NREGS): Use avr_hard_regno_nregs. (HARD_FRAME_POINTER_REGNUM): New. (FRAME_POINTER_REGNUM): Use soft frame pointer. (ELIMINABLE_REGS): Eliminate from the soft frame pointer, remove the HARD_FRAME_POINTER self-elimination. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/14 ------------------------------------------------------------------------ On 2012-01-14T18:11:33+00:00 Denisc-9 wrote: Author: denisc Date: Sat Jan 14 18:11:29 2012 New Revision: 183183 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183183 Log: PR target/50925 * config/avr/avr-protos.h: Revert change of 2012-01-09. * config/avr/avr.c: Likewise. * config/avr/avr.h: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/15 ------------------------------------------------------------------------ On 2012-01-27T23:20:03+00:00 Gjl wrote: Created attachment 26486 main-loop.c (maybe related from PR52025) This is a small test case from PR52025 generates strange code: It sets up a frame to store a local variable. Notice that there is just one local variable in the whole little program, so there is really no frame needed. This issue can be resolved by -fno-caller-saves, so maybe it's related to the spill fails from here that can also be hacked around with -fno- caller-saves. Maybe this little programs helps to find what's going wrong with the register allocation and spill fails. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/16 ------------------------------------------------------------------------ On 2012-01-27T23:26:37+00:00 Gjl wrote: Assuming there is a connexion between these two issues. If that assumption turns out to be wrong, please cut the dependency. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/17 ------------------------------------------------------------------------ On 2012-01-28T10:05:50+00:00 Denisc-9 wrote: (In reply to comment #17) > Assuming there is a connexion between these two issues. > > If that assumption turns out to be wrong, please cut the dependency. Dependency cutted. 52025 isn't related to this bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/18 ------------------------------------------------------------------------ On 2012-02-27T20:42:39+00:00 Gjl wrote: Created attachment 26765 spill.c - another reduced test Here is yet another different and simplified test case. With that test case I can produce spill fails for 4.5.2, 4.6.2 and 4.7 trunk (build from around 2012-02-17). >> avr-gcc spill.c -Os -S spill.c: In function 'menu_cycle': spill.c:31:1: error: unable to find a register to spill in class 'POINTER_REGS' spill.c:31:1: error: this is the insn: (insn 36 20 21 2 (set (reg:QI 18 r18) (mem/c:QI (plus:HI (reg/f:HI 28 r28) (const_int 1 [0x1])) [3 S1 A8])) spill.c:29 18 {movqi_insn} (nil)) spill.c:31:1: internal compiler error: in spill_failure, at reload1.c:2120 Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/19 ------------------------------------------------------------------------ On 2012-02-27T21:04:29+00:00 Gjl wrote: Adjusted "known to fail" as with the new test case. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/20 ------------------------------------------------------------------------ On 2012-03-13T09:44:04+00:00 Gjl wrote: *** Bug 52575 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/21 ------------------------------------------------------------------------ On 2012-03-22T08:26:54+00:00 Rguenth wrote: GCC 4.7.0 is being released, adjusting target milestone. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/22 ------------------------------------------------------------------------ On 2012-06-14T08:31:44+00:00 Rguenth wrote: GCC 4.7.1 is being released, adjusting target milestone. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/23 ------------------------------------------------------------------------ On 2012-08-02T17:24:25+00:00 Gjl wrote: FYI, I just tried the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P hook but without avail: Even with the most restrict setup (always return true) attachment 26765 triggers the bug. The kook isn't even called once... Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/24 ------------------------------------------------------------------------ On 2012-08-02T17:34:40+00:00 Gjl wrote: (In reply to comment #24) > The kook isn't even called once... My bad... The hook IS called, but it does not help with this bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/25 ------------------------------------------------------------------------ On 2012-09-20T10:19:12+00:00 Jakub-gcc wrote: GCC 4.7.2 has been released. Reply at: https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/1112499/comments/26 ** Changed in: gcc Status: Unknown => Confirmed ** Changed in: gcc Importance: Unknown => Medium ** Bug watch added: GCC Bugzilla #42204 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42204 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1112499 Title: WiFi.cpp doesn't compile with default flags To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/1112499/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
