[Bug target/71678] New: [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 Bug ID: 71678 Summary: [avr] ICE from switch / case on long long (casesi + DImode) Product: gcc Version: 5.2.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr Created attachment 38778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38778&action=edit ice-casesi.c: C test case $ avr-gcc -mmcu=atmega128 ice-casesi.c -Os -S -fno-tree-switch-conversion unsigned char foo (long long x) { unsigned char y = 0; switch (x) { case 0: y = 67; break; case 1: y = 20; break; case 2: y = 109; break; case 3: y = 33; break; case 4: y = 44; break; case 5: y = 37; break; case 6: y = 10; break; case 7: y = 11; break; } return y; } will throw an ICE: ice-casesi.c: In function 'foo': ice-casesi.c:16:1: error: unrecognizable insn: } ^ (insn 55 54 56 4 (parallel [ (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) (clobber (scratch:QI)) ]) ice-casesi.c:4 -1 (nil)) ice-casesi.c:16:1: internal compiler error: in extract_insn, at recog.c:2287 ice-casesi.c:16:1: internal compiler error: Segmentation fault Problem is the casesi expander and its explicit SUBREG. Here casesi from current trunk, but the define_expand looks the same sice r31935: (define_expand "casesi" [(parallel [(set (match_dup 6) (minus:HI (subreg:HI (match_operand:SI 0 "register_operand" "") 0) (match_operand:HI 1 "register_operand" ""))) (clobber (scratch:QI))]) ... I used avr-gcc 5.2.1 but affected are all versions of avr-gcc (maybe with a slightly different test case with more cases or so).
[Bug target/71676] New: [avr] casesi won't handle switch values larger than 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71676 Bug ID: 71676 Summary: [avr] casesi won't handle switch values larger than 16 bits Product: gcc Version: 5.2.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr Created attachment 38776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38776&action=edit bug-casesi.c: C test case This is a funny wrong code bug that is present since the avr backend has been added to GCC in r31935. casesi reads https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/avr/avr.md?view=markup&pathrev=31935#l1760 (define_expand "casesi" [(parallel [(set (match_dup 6) (minus:HI (subreg:HI (match_operand:SI 0 "register_operand" "") 0) (match_operand:HI 1 "register_operand" ""))) (clobber (scratch:QI))]) (parallel [(set (cc0) (compare (match_dup 6) (match_operand:HI 2 "register_operand" ""))) (clobber (match_scratch:QI 9 ""))]) ... which means that switch / case won't handle large values correctly provided casesi is used. The following code shows the problem. Compile with $ avr-gcc -mmcu=atmega128 bug-casesi.c -save-temps -dp -Os volatile unsigned char y; __attribute__((noinline,noclone)) unsigned char foo (unsigned long x) { switch (x) { case 0: y = 67; break; case 1: y = 20; break; case 2: y = 109; break; case 3: y = 33; break; case 4: y = 44; break; case 5: y = 37; break; case 6: y = 10; break; case 7: y = 98; break; } return y; } int main (void) { if (0 != foo (7L + 0x1L)) __builtin_abort(); return 0; } As casesi takes HImode SUBREG of x, only the lower 16 bits of x (R22 and R23) are used to determine whether the switch has to be entered or not. avr-gcc-5.2 generates: foo: cpi r22,8; 9 *cmphi/6 cpc r23,__zero_reg__ brsh .L2 ; 10 branch movw r30,r22 ; 91 *movhi/1 subi r30,lo8(-(gs(.L4))) ; 11 *addhi3/2 sbci r31,hi8(-(gs(.L4))) jmp __tablejump2__ ; 12 *tablejump/3 Hence 0x10007 will be treated the same way as 0x7.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #13 from Georg-Johann Lay --- (In reply to Senthil Kumar Selvaraj from comment #12) > This works if the start of data is specified as -Tdata 0xaddress. Other ways > of specifying the same thing don't work; -Tdata=0xaddress, > -Wl,-Tdata=0xaddress or -Wl,-Tdata,0xaddress all fail. Hard to fix all these in the compiler like -Wl,--section-start We could document the current behavior and that -Tdata or -Ttext should be used. Or we could introduce a new option to use in the specs only and that also wraps around like %{!mnew-option:%{!Tdata:Tdata ...}} In any case the user must read the documentation and be aware of the new option or the recommended practice. A new option does not make much sense because instead of -mnew-option she could just as well use -Tdata as needed... > Do you know why the linker picks the option first appearing on the > commandline, rather than the usual last? No, and dunno how the linker handles several maybe conflicting multiple specifications.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.2 --- Comment #15 from Georg-Johann Lay --- Fixed in 4.9.4, 5.5 and 6.2+.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED Host|x86_64-linux-gnu| Resolution|--- |FIXED Target Milestone|--- |6.2 Build|x86_64-linux-gnu| Severity|minor |enhancement --- Comment #11 from Georg-Johann Lay --- Fixed in 4.9.4, 5.5 and 6.2+.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #10 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 11:00:54 2016 New Revision: 237643 URL: https://gcc.gnu.org/viewcvs?rev=237643&root=gcc&view=rev Log: Backport from 2016-06-21 trunk r237639. PR target/30417 * config/avr/driver-avr.c (avr_device_to_data_start): Wrap -Tdata into %{!Tdata:...}. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/driver-avr.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:43:12 2016 New Revision: 237641 URL: https://gcc.gnu.org/viewcvs?rev=237641&root=gcc&view=rev Log: Backport from 2016-06-21 trunk r237639. PR target/30417 * config/avr/gen-avr-mmcu-specs.c (print_mcu): [*link_data_start]: Wrap -Tdata into %{!Tdata:...}. [*link_text_start]: Wrap -Ttext into %{!Ttext:...}. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:39:59 2016 New Revision: 237640 URL: https://gcc.gnu.org/viewcvs?rev=237640&root=gcc&view=rev Log: Backport from 2016-06-21 trunk r237639. PR target/30417 * config/avr/gen-avr-mmcu-specs.c (print_mcu): [*link_data_start]: Wrap -Tdata into %{!Tdata:...}. [*link_text_start]: Wrap -Ttext into %{!Ttext:...}. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:36:13 2016 New Revision: 237639 URL: https://gcc.gnu.org/viewcvs?rev=237639&root=gcc&view=rev Log: PR target/30417 * config/avr/gen-avr-mmcu-specs.c (print_mcu): [*link_data_start]: Wrap -Tdata into %{!Tdata:...}. [*link_text_start]: Wrap -Ttext into %{!Ttext:...}. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #14 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:23:08 2016 New Revision: 237638 URL: https://gcc.gnu.org/viewcvs?rev=237638&root=gcc&view=rev Log: PR target/71103 * config/avr/avr.md (movqi): Only handle loading subreg:qi of constant addresses if can_create_pseudo_p. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.md
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #13 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:18:26 2016 New Revision: 237637 URL: https://gcc.gnu.org/viewcvs?rev=237637&root=gcc&view=rev Log: PR target/71103 * config/avr/avr.md (movqi): Only handle loading subreg:qi of constant addresses if can_create_pseudo_p. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr.md
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #12 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:15:25 2016 New Revision: 237636 URL: https://gcc.gnu.org/viewcvs?rev=237636&root=gcc&view=rev Log: PR target/71103 * config/avr/avr.md (movqi): Only handle loading subreg:qi of constant addresses if can_create_pseudo_p. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.md
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #11 from Georg-Johann Lay --- Author: gjl Date: Tue Jun 21 10:10:46 2016 New Revision: 237635 URL: https://gcc.gnu.org/viewcvs?rev=237635&root=gcc&view=rev Log: PR target/71103 * config/avr/avr.md (movqi): Only handle loading subreg:qi of constant addresses if can_create_pseudo_p. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Georg-Johann Lay --- Unfortunately there are now cases where the subregs pop up during reload and hence copy_to_mode_reg is prohibited like with strftime from avr-libc :-( There are already insns that assume that subregs of constants work to some degree like xload8_A and xload_A. Maybe we'll have to support subregs of constants in their own right...
[Bug target/52305] [avr] ICE in avr_print_operand: unknown mode (const_double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52305 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Georg-Johann Lay --- (In reply to Pitchumani from comment #3) > Not re-producible in gcc-7 trunk. Is it valid anymore? Did you try on a 32-bit host? ähhh.. the last remains of need_64bit_hwi have been removed with r210632 and today we assume that HWI is 64 bits at least, i.e. need_64bit_hwint=yes is assumed. Hence the test case should work also on 32-bit hosts without any itches because target long long is always represented as CONST_INT, not as CONST_DOUBLE. Issue closed.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail|4.9.2, 5.2.1|4.9.3, 5.4.1, 6.1.1 --- Comment #9 from Georg-Johann Lay --- Fixed in 4.9.4, 5.5, 6.2.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 12:02:36 2016 New Revision: 237594 URL: https://gcc.gnu.org/viewcvs?rev=237594&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:55:11 2016 New Revision: 237593 URL: https://gcc.gnu.org/viewcvs?rev=237593&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #6 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:20:27 2016 New Revision: 237591 URL: https://gcc.gnu.org/viewcvs?rev=237591&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:01:13 2016 New Revision: 237589 URL: https://gcc.gnu.org/viewcvs?rev=237589&root=gcc&view=rev Log: gcc/ PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const). gcc/testsuite/ PR target/71103 * gcc.target/avr/torture/pr71103-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|5.2.0 |7.0 Resolution|--- |FIXED Assignee|gjl at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Georg-Johann Lay --- Implemented for v7.
[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053 --- Comment #6 from Georg-Johann Lay --- (In reply to Michael Weiser from comment #5) > I think it's well estabilished and verified by now that this is an > avr-target-specific regression (which I think is what Richard meant). Well, "avr-specific" would mean that the bug is in the avr backend (component=target) part of the compiler. I don't see how the avr backend could produce different code for C++ vs. C and make a v-qualifier disappear for C++ only and in such an early stage of compilation... The fact that up to now it has been reproduced for target=avr only does not necessarily mean it's an avr thing. > Can I do anything to help debug this further (i.e. try to figure out > the commit that caused the regression)? Would be great to see the commit that made the "{v}" disappear from the .ssa dump. Same for the commit that introduced the problem; presumably it's the same commit. If you use that dump as an indicator you can -fdump-tree-ssa which should contain a "{v}" -- at least v5.1 dumps and the dumps for C do contain the "{v}".
[Bug c++/71053] [6/7 Regression] Volatile read optimized into endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053 Georg-Johann Lay changed: What|Removed |Added Priority|P4 |P3 Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-08 Component|target |c++ CC||gjl at gcc dot gnu.org Host|x86_64-apple-darwin15 |x86_64 Ever confirmed|0 |1 Known to fail||7.0 Build|x86_64-apple-darwin15 | --- Comment #4 from Georg-Johann Lay --- (In reply to Richard Biener from comment #1) > On x86_64 I get > > main: > .LFB0: > .cfi_startproc > .L2: > movb1, %al > testb $1, %al > je .L2 > xorl%eax, %eax > ret > > and thus it works fine there. Target issue. Sorry, I cannot follow your argument. Test case: #define REG (*(unsigned char volatile*)0x31) void foo () { while ((REG & 1) == 1); } worsks fine then compiled as C, but for C++ $ avr-gcc -x c++ foo.c -S -Os -fdump-tree-all I see the following .ssa dump: ;; Function void foo() (_Z3foov, funcdef_no=0, decl_uid=1976, cgraph_uid=0, symbol_order=0) void foo() () { volatile unsigned char * _1; unsigned char _2; int _3; int _4; bool retval.0_6; : _1 = 49B; _2 = *_1; _3 = (int) _2; _4 = _3 & 1; retval.0_6 = _4 != 0; if (retval.0_6 != 0) goto ; else goto ; : return; } The dump is missing a {v} qualifier which is present in the dump generated for C code: ... _2 ={v} *_1; ... The missing qualifier results in the mentioned wrong optimization in load invariant motion, see .lim2 dump. I used avr-gcc built from trunk SVN 236978 from 2016-06-11: $ ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-7 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld target_alias=avr --enable-languages=c,c++,lto
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #13 from Georg-Johann Lay --- Disadvantage of havong tables in same text section a code is that code side might increase for the following reason: branches that cross a switch statement will also have to cross the jump table, hence branch offsets and thus code size might increase.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #11 from Georg-Johann Lay --- well, IIRC for Tiny .rodata is still a part of .data and not part of .text? If this is still the case, then on Tiny the best place for jump tables is also .text.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #10 from Georg-Johann Lay --- Well, then we should remove TARGET_ASM_FUNCTION_RODATA_SECTION implementation altogether (it's weird, not only because it patches flag_data_sections), same for ASM_OUTPUT_ADDR_VEC_ELT. Instead implement ASM_OUTPUT_ADDR_VEC and do the whole addr_vec stuff by hand: 1) switch to correct section: if -ffunction-sections is on, cook up a section like .progmem.gcc_sw_table., otherwise just .progmem.gcc_sw_table 1) Alternatively, just emit .pushsection and .popsection around the jump table. 2) Output alignment .p2align. The original alignment from ASM_OUTPUT_BEFORE_CASE_LABEL might be too early (wrong section), so that the alignment must be output again. ASM_OUTPUT_BEFORE_CASE_LABEL is no more needed. 3) Output the jump table, see final.c for how to iterate. Anyway, we might consider putting the jump table into .text section. Since PR63223 we can handle jump-tables at any location, there is no need for having it in .progmem (which is supposed to reside in the lowest 64k). And for Tiny targets, where .rodata is the best place, JUMP_TABLES_IN_TEXT_SECTION can just return 0.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #8 from Georg-Johann Lay --- What about avr_asm_function_rodata_section? Isn't it possible to filter DECL and only transform for addr_vect?
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #6 from Georg-Johann Lay --- (In reply to Anatol from comment #5) > It is a severe compiler issue that stop avr-gcc 6 from using. > Consider changing "Importance" status to blocker. It's definite not a "blocker". "blocker" would mean the issue is so severe that no toolchain could be released, e.g. because the compiler for a primary or secondary platform cannot be built. Moreover, as Senthil pointed out above, the problem can be worked around by adding -fno-merge-constants to the command options. Anyway, twiddling the "importance" won't have any effect w.r.t. bug fixing quality or swiftness... In the case of avr, that speed is solely determindey by the number of people that are willing to contribute to avr-gcc... If all goes well I might have a day or two to work on avr-gcc in June.
[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677 --- Comment #5 from Georg-Johann Lay --- Maybe -fno-caller-saves is what you are looking for? Here is a C test case guessed from your first code snipped: typedef struct { unsigned char x, y; } point; extern void printSpeed (long, unsigned char); extern long cnvGroundSpeed (void); void panVel (point p) { printSpeed (cnvGroundSpeed(), p.y & 0x40); } compiled with avr-gcc 5.x $ avr-gcc -S -Os we'll get panVel: push r28 push r29 push __zero_reg__ in r28,__SP_L__ in r29,__SP_H__ mov r20,r25 andi r20,lo8(64) std Y+1,r20 rcall cnvGroundSpeed ldd r20,Y+1 pop __tmp_reg__ pop r29 pop r28 rjmp printSpeed Adding -fno-caller-saves: panVel: push r28 mov r28,r25 andi r28,lo8(64) rcall cnvGroundSpeed mov r20,r28 pop r28 rjmp printSpeed I actually don't know whether this is a flaw in the avr backend (like a cost issue) or wrong assumptions in the middle-end. Saving / Restoring in the frame is actually not more costly than saving in a call-saved register; what makes it expensive is the frame setup in prologue and epilogue...
[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677 --- Comment #3 from Georg-Johann Lay --- You can follow the bug reporting instructions an provide the preprocessed code and the compiler output as described in https://gcc.gnu.org/bugs/#need Just add -v -save-temps to the compiler's command line options, re-build the project, and supply the output of the compiler and the generated *.i file (in case of C) resp. *.ii file (in case of C++). This is needed because you have to resolve the non-standard stuff like "INPUT" or "Ardiuno.h". There's no need that you change the suorces to accomplish this (if you can manage to find a smalle test case, this is nice but not mandatory).
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 --- Comment #3 from Georg-Johann Lay --- You can follow the bug reporting instructions an provide the preprocessed code and the compiler output as described in https://gcc.gnu.org/bugs/#need Just add -v -save-temps to the compiler's command line options, re-build the project, and supply the output of the compiler and the generated *.i file (in case of C) resp. *.ii file (in case of C++).
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #3 from Georg-Johann Lay --- This change is at least incomplete: it does not handle CONST. To see this change the test case to returnValue.response = response + 1; Who is generating these SUBREGs? If it's in a push insn, we should handle that case in the push insn/expander so that these SUBREGs won't be generated in the first place.
[Bug target/69647] gcc build for avr-unknown-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69647 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Georg-Johann Lay --- Invalid bug: Read v5 Release Caveats > On AVR, support has been added for the devices ATtiny4/5/9/10/20/40. > This requires Binutils 2.25 or newer. http://gcc.gnu.org/gcc-5/changes.html
[Bug target/70676] suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- You missed to add a test case, cf. https://gcc.gnu.org/bugs/#need > Can GCC in -Os really optimize only size and rollback optimizations No, GCC usually won't "rollback" optimizations, and it won't perform speculative optimizations. There are cases where avr-gcc does not optimize sibling calls. Provided you use -mrelax (or link with -Wl,--relax), the linker tries to replace [R]CALL+RET by [R]JMP instruction. If there is a label at the }, i.e. between the CALL and the RET, no optimization is possible.
[Bug target/70677] Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- Would you provide a test case, please? Cf. https://gcc.gnu.org/bugs/#need For example there is nothing like "panVel" in your code.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 Georg-Johann Lay changed: What|Removed |Added CC||gigo121 at gmail dot com --- Comment #4 from Georg-Johann Lay --- *** Bug 70999 has been marked as a duplicate of this bug. ***
[Bug target/70999] AVR: String incorrectly placed in flash instead of RAM when building with -ffunction-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70999 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE Severity|major |normal --- Comment #1 from Georg-Johann Lay --- Same as PR71151, more info there. *** This bug has been marked as a duplicate of bug 71151 ***
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|UNCONFIRMED |NEW Known to work||4.6.2 Keywords||ice-on-valid-code Last reconfirmed||2016-05-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.7.2, 4.8.0, 4.9.2, 5.2.1 Severity|major |normal --- Comment #1 from Georg-Johann Lay --- Confirmed for 5.2.1. At .expand we have ;; MEM[(struct ResponseStruct *)&D.1574 + 1B] = &response; (insn 6 5 7 (set (subreg:QI (reg:PSI 42 [ D.1574 ]) 1) (subreg:QI (symbol_ref:HI ("response") [flags 0x2] ) 0)) foo.c:11 -1 (nil)) (insn 7 6 0 (set (subreg:QI (reg:PSI 42 [ D.1574 ]) 2) (subreg:QI (symbol_ref:HI ("response") [flags 0x2] ) 1)) foo.c:11 -1 (nil)) hence the load of HImode &response is broken into 2 QImode leaving us with subregs of the symbol_ref. 4.6.2 does work (presumably because there was no PSImode in <= 4.6)
[Bug target/71000] Wrong defines for ATMEGA328p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71000 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay --- Target support macros and headers are realm of AVR-Libc, it is not a compiler issue. Please report at AVR-Libc's bug tracker http://savannah.nongnu.org/bugs/?group=avr-libc
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code CC||gjl at gcc dot gnu.org --- Comment #2 from Georg-Johann Lay --- Cannot reproduce this on 5.x. The avr BE tries to apply -fdata-sections to data in progmem in a similar way like -fdata-sections acts on data in RAM. A dedicated option like -mprogmem-sections was not possible because of the terrible section implementation in varasm.c. Presumably, the problem is TARGET_ASM_FUNCTION_RODATA_SECTION in avr.c. Maybe we'll have to give up the feature alltogether and drop the .progmem.var subsections and return to one bulk .progmem.data again.
[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30417 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #6 from Georg-Johann Lay --- As of GCC 5 this should be no issue any more: The new device specs might specify -Tdata e.g. specs-atmega88 reads *link_data_start: -Tdata 0x800100 The file is located in $prefix/lib/gcc/avr/$version/device-specs/ provided default paths are used with configure. Cf. also the relevant release notes. Hence you could -- Drop that -Tdata from the device specs and specify appropriate -Tdata on the command line. -- Provide custom specs file derived from the one above. Sounds strange that bootloader and application are managed that way. Ususally, after the bootloader has finished, its memory is no more needed and will be cleaned up by the application's start-up code and used by the application without any conflicts.
[Bug target/69685] GCC cross compiler build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685 --- Comment #4 from Georg-Johann Lay --- FYI, as you are using Newlib (and not avr-libc as all the folks does) you want to configure with --with-avrlibc=no.
[Bug target/69685] GCC cross compiler build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #3 from Georg-Johann Lay --- (In reply to Pieter Cardoen from comment #2) > How do you mean: appending -v? The only command I execute is: Above, you pasted a call of xgcc. Add -v -save-temps to that command and execute it from the right directory. Usually make prints the directory where it stops execution due to some tool error; this will be some libgcc multilib directory. The -save-temps gives you a preprocessed input file fixed-bit.i (provided it's not the preprocessor that hangs).
[Bug target/69049] [avr] strange/unnecessary commands in compiled code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69049 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID
[Bug other/67031] avr-gcc internal compiler error: segmentation fault in push_reload, at reload.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2016-01-29 Component|target |other CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 Summary|avr-gcc internal compiler |avr-gcc internal compiler |error |error: segmentation fault ||in push_reload, at reload.c Known to fail||5.2.1 --- Comment #2 from Georg-Johann Lay --- Confirmed with 5.2.1 on mingw32 and $ avr-gcc source.c -S -O3 -mmcu=atmega8 Also tried to reduce even more and to get it closer to sensible C but the ICE remains: avr-gcc foo.c -S -Wall -O3 -mmcu=atmega8 -save-temps foo.c: In function 'func': foo.c:23:1: internal compiler error: in push_reload, at reload.c:1380 } ^ foo.c:23:1: internal compiler error: Segmentation fault extern int sscanf (const char*, const char*, ...); typedef struct { int iii; char ppp[50]; } S; extern S a; extern int b, c, e, g, h, i; void func2(char *p1) { sscanf(p1, "%d %d %d %d", &e, &i, &h, &g); char j[30]; func2(j); } void func(void) { int d = (int)func; while (c < d) { b = 23; func2(a.ppp); } }
[Bug target/69049] [avr] strange/unnecessary commands in compiled code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69049 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-29 Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- 1) Even after including stdint.h your code won't compile 2) No command options are given For guidelines on how to report problems and make them reproducible for others cf. http://gcc.gnu.org/bugs/#need
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-25 CC||gjl at gcc dot gnu.org Known to work||4.9.2 Ever confirmed|0 |1 Known to fail||5.2.1 --- Comment #4 from Georg-Johann Lay --- Senthil, isn't this supposed to be fixed in 5.3? Compiling the PR67839 code from the test suite with -Os -c -mmcu=attiny44 generates the following assembler code: main: sbi 0x1f,0 cbi 0x1f,0 sbi 0x20,0 cbi 0x20,0 in r24,__SREG__ out __SREG__,r24 ldi r30,lo8(96) ldi r31,0 ld r24,Z st Z,r24 ldi r24,0 ldi r25,0 ret .size main, .-main .ident "GCC: (GNU) 5.3.1 20160106" BTW, why isn't 4.9 and older affected? The *cbi and *sbi insn are usualy forged by combine. Where 4.9 rejects Failed to match this instruction: (set (mem/v:QI (const_int 64 [0x40]) [0 MEM[(volatile char *)64B]+0 S1 A8]) (ior:QI (mem/v:QI (const_int 64 [0x40]) [0 MEM[(volatile char *)64B]+0 S1 A8]) (const_int 1 [0x1]))) 5.3 accepts the exact same insn: Successfully matched this instruction: (set (mem/v:QI (const_int 64 [0x40]) [0 MEM[(volatile char *)64B]+0 S1 A8]) (ior:QI (mem/v:QI (const_int 64 [0x40]) [0 MEM[(volatile char *)64B]+0 S1 A8]) (const_int 1 [0x1]))) Only difference is that the constraint has been changed from "n" to "i" which looks very odd to me.
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Georg-Johann Lay changed: What|Removed |Added CC||karaliusliudas+bugzilla@gma ||il.com --- Comment #3 from Georg-Johann Lay --- *** Bug 69330 has been marked as a duplicate of this bug. ***
[Bug target/69330] avr-gcc Error: operand out of range: 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69330 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Known to work||4.9.2 Resolution|--- |DUPLICATE Known to fail||5.2.1 --- Comment #1 from Georg-Johann Lay --- Appears to be already fixed. Assembler generated CBI / SBI with address of 0x20. cbi 0x20,0 ; 9 *cbi[length = 1] ret ; 15 return [length = 1] which violates CBI. *** This bug has been marked as a duplicate of bug 67839 ***
[Bug target/68199] avr-gcc rise a warning when defining a custom interruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68199 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Georg-Johann Lay --- Cf. PR67353 *** This bug has been marked as a duplicate of bug 67353 ***
[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Georg-Johann Lay changed: What|Removed |Added Keywords||easyhack Target Milestone|6.0 |---
[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Georg-Johann Lay changed: What|Removed |Added CC||astralien3000 at yahoo dot fr --- Comment #1 from Georg-Johann Lay --- *** Bug 68199 has been marked as a duplicate of this bug. ***
[Bug other/67373] Can't compile gcc snapshot for avr target with mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |WAITING Keywords||build Last reconfirmed||2016-01-25 Component|bootstrap |other CC||gjl at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #5 from Georg-Johann Lay --- Created attachment 36282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36282&action=edit output of avr-gcc-6 (SVN trunk 227033)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #4 from Georg-Johann Lay --- Created attachment 36281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36281&action=edit output of gcc-5.2
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #3 from Georg-Johann Lay --- Created attachment 36280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36280&action=edit i.c (C-source 3/3)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #2 from Georg-Johann Lay --- Created attachment 36279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36279&action=edit e.c (C-source 2/3)
[Bug ipa/67428] lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 --- Comment #1 from Georg-Johann Lay --- Created attachment 36278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36278&action=edit Bug.c (C-source 1/3)
[Bug ipa/67428] New: lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67428 Bug ID: 67428 Summary: lto1: fatal error: test.elf.ltrans0.o: section is missing with -flto -fipa-pta Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Host: x86-linux-gnu Target: i386 Build: x86-linux-gnu Following error (sources will follow) occurs when compiling == Command Line == $ gcc Bug.c e.c i.c -flto -Os -fipa-pta -o test.elf -save-temps -v $ avr-gcc -mmcu=atmega328p Bug.c e.c i.c -flto -Os -fipa-pta -o test.elf -save-temps -v == Error Message == lto1: fatal error: test.elf.ltrans0.o: section Foo is missing compilation terminated. lto-wrapper: fatal error: /local/gnu/install/gcc-6/bin/avr-gcc returned 1 exit status Foo is declared in module e.c == GCC configures as == Target: i686-pc-linux-gnu Configured with: ../../gcc.gnu.org/gcc-5-branch/configure --prefix=/mnt/nfs/home/georg/gnu/install/gcc-native-5 --disable-nls --enable-checking=release --enable-languages=c,c++,lto Thread model: posix gcc version 5.2.1 20150721 (GCC) Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-6 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld target_alias=avr --enable-languages=c,c++,lto --no-create --no-recursion Thread model: single gcc version 6.0.0 20150720 (experimental) (GCC) Target: avr Configured with: ../../gcc.gnu.org/gcc-5-branch/configure --target=avr --prefix=/local/gnu/install/gcc-5 --disable-nls --disable-shared --with-dwarf2 --with-gnu-ld --with-gnu-as target_alias=avr --enable-languages=c,c++,lto Thread model: single gcc version 5.2.1 20150816 (GCC)
[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 Target Milestone|--- |6.0 Ever confirmed|0 |1 Severity|normal |enhancement
[Bug target/67353] New: [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Bug ID: 67353 Summary: [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler" Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: gjl at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr Add -W flag to control the mentioned warning or turn it into an error.
[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 Ever confirmed|0 |1
[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.0
[Bug target/67352] New: [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352 Bug ID: 67352 Summary: [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: addr-space, diagnostic Severity: normal Priority: P3 Component: target Assignee: gjl at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr == C source == typedef struct { char a, b[3]; } S; const __flash char* get_b1 (const __flash S *s) { return s->b; } extern const __flash S ab; const __flash char* get_b2 (void) { return ab.b; } == Command line == $ avr-gcc -mmcu=atmega8 main.c -Werror=addr-space-convert -fsyntax-only == avr-gcc Output == main.c: In function 'get_b1': main.c:8:4: error: conversion from address space 'generic' to address space '__flash' [-Werror=addr-space-convert] main.c: In function 'get_b2': main.c:15:4: error: conversion from address space 'generic' to address space '__flash' [-Werror=addr-space-convert]
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 --- Comment #3 from Georg-Johann Lay --- (In reply to Matthijs Kooijman from comment #2) > So, IIUC, this is quite hard to fix? Either you use lib functions, which > prevents the optimizer from just relabeling or coyping registers to apply > shifting, or you don't and then more complex operations will become very > verbose and messy? avr-gcc is using lib functions, but not as libcall but as transparent call instead. You'll find the implementation in avr-dimode.md. avr-gcc has no proper DImode support. For reasoning cf. the comments in the head of that file.
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.9.4 Resolution|--- |FIXED Target Milestone|--- |5.3 Known to fail||4.9.3, 5.2.1 --- Comment #5 from Georg-Johann Lay --- Fixed in 5.3, 4.9.4.
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Tue Jul 21 17:31:22 2015 New Revision: 226048 URL: https://gcc.gnu.org/viewcvs?rev=226048&root=gcc&view=rev Log: Backport from 2015-07-21 trunk r226046. PR target/66956 * config/avr/avr-dimode.md (mulsidi3_insn) (mulsidi3): Don't use if !AVR_HAVE_MUL. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr-dimode.md
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Tue Jul 21 17:29:47 2015 New Revision: 226047 URL: https://gcc.gnu.org/viewcvs?rev=226047&root=gcc&view=rev Log: Backport from 2015-07-21 trunk r226046. PR target/66956 * config/avr/avr-dimode.md (mulsidi3_insn) (mulsidi3): Don't use if !AVR_HAVE_MUL. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr-dimode.md
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Tue Jul 21 17:25:48 2015 New Revision: 226046 URL: https://gcc.gnu.org/viewcvs?rev=226046&root=gcc&view=rev Log: PR target/66956 * config/avr/avr-dimode.md (mulsidi3_insn) (mulsidi3): Don't use if !AVR_HAVE_MUL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-dimode.md
[Bug libgcc/64401] avr-elf crtbegin.o fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64401 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay --- I cannot find objects built from crtstuff in any of my avr-builds, so the question is why it tries to generate this modules in the first place. ./libgcc/config.host reads: case ${host} in [...] *-*-elf) extra_parts="crtbegin.o crtend.o" ;; esac so presumably the build system is confused by your *-elf configuration. Is there a specific reason for why you are not configuring --target=avr ?
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 Georg-Johann Lay changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Georg-Johann Lay --- Compile that test case with $ avr-gcc -Os mul32.c -S Result is something like: mul_u32: rcall __umulsidi3 mov r22,r18 mov r23,r19 mov r24,r20 mov r25,r21 ret mul_s32: rcall __mulsidi3 mov r22,r18 mov r23,r19 mov r24,r20 mov r25,r21 ret
[Bug target/66956] [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-21 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/66956] New: [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66956 Bug ID: 66956 Summary: [avr] Using 32*32=64 multiplicatiion (umulsidi3) for 32=32*32 without MUL. Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr Created attachment 36020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36020&action=edit mul32.c
[Bug target/66933] [AVR] Shifted multiplication produces suboptimal asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66933 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P5
[Bug target/66933] [AVR] Shifted multiplication produces suboptimal asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66933 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay --- Created attachment 36019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36019&action=edit Possible solution as combine patterns. Well, this optimization is very special. You could, of course: Index: avr.md === --- avr.md (revision 226011) +++ avr.md (working copy) @@ -1695,6 +1695,39 @@ (define_insn "*oumulqihi3" [(set_attr "length" "4") (set_attr "cc" "clobber")]) +;; Proposed in PR target/66933 +;; "*mulqihi3.lsr7" +;; "*umulqihi3.lsr7" +(define_insn "*mulqihi3.lsr7" + [(set (match_operand:HI 0 "register_operand" "=r") +(lshiftrt:HI (mult:HI (any_extend:HI (match_operand:QI 1 "register_operand" "a")) + (any_extend:HI (match_operand:QI 2 "register_operand" "a"))) + (const_int 7)))] + "AVR_HAVE_MUL" + "fmul %2,%1 + mov %A0,r1 + clr %B0 + rol %B0 + clr __zero_reg__" + [(set_attr "length" "5") + (set_attr "cc" "clobber")]) + +;; Proposed in PR target/66933 +;; "*mulqihi3.asr7" +;; "*umulqihi3.asr7" +(define_insn "*mulqihi3.asr7" + [(set (match_operand:HI 0 "register_operand" "=r") +(ashiftrt:HI (mult:HI (any_extend:HI (match_operand:QI 1 "register_operand" "a")) + (any_extend:HI (match_operand:QI 2 "register_operand" "a"))) + (const_int 7)))] + "AVR_HAVE_MUL" + "fmul %2,%1 + mov %A0,r1 + sbc %B0,%B0 + clr __zero_reg__" + [(set_attr "length" "4") + (set_attr "cc" "clobber")]) + ;** ; multiply-add/sub QI: $0 = $3 +/- $1*$2 ;** As you can see, this needs 1 more instruction (signed shift) resp. 2 more instructions (unsigned shift) because it is not known at the time that only the low part of the expression will be used. Hence the high part must also be computed. One more instruction might be needed due to the register class restriction "a" for FMUL instead of "r" for MUL.
[Bug preprocessor/64220] gcc preprocessor defines outside of the reserved namespace: unix linux AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64220 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Georg-Johann Lay --- Confusion has been resolved with help of the documentation.
[Bug tree-optimization/66768] address space gets lost on literal pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768 Georg-Johann Lay changed: What|Removed |Added Keywords||addr-space CC||gjl at gcc dot gnu.org --- Comment #10 from Georg-Johann Lay --- Guess the target should be x86?
[Bug rtl-optimization/49857] Put constant switch-tables into flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857 Georg-Johann Lay changed: What|Removed |Added Target Milestone|5.3 |6.0
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 --- Comment #1 from Georg-Johann Lay --- (In reply to Matthijs Kooijman from comment #0) > I haven't found a readily available 5.x package yet to test. It's the same. > As you can see, the versions operating on 64 bit values preserve the > 8-bit shift (which is very inefficient on AVR), while the versions > running on 32 bit values simply copy the right registers. Lib functions are used because users complained about bloated 64-bit arithmetic. Notice that indide these 64-bit shift functions byte-shifts are used. > The foo32_16 function still has some useless instructions (r27 and r26 > are not part of the return value, not sure why these are set) but that > is probably an unrelated problem. Yes. > I've marked this with component "target", since I think these > optimizations are avr-specific (or at least not applicable to bigger > architectures).
[Bug target/66201] [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201 Georg-Johann Lay changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Georg-Johann Lay --- WOn't fix this invalid corner case.
[Bug target/66511] [avr] whole-byte shifts not optimized away for uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 CC||gjl at gcc dot gnu.org Severity|normal |enhancement
[Bug target/66201] [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201 --- Comment #2 from Georg-Johann Lay --- In short: If avr we should skip that test, or at least remove code which is using that function, e.g. #ifdef __AVR__.
[Bug target/66201] [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201 --- Comment #1 from Georg-Johann Lay --- IMO using operands attached to "m" constraint in the asm template is no valid avr code. You can never know the matching instructions because "m" is too generic: Use LD, LD+ or LDS? The only valid use of that constraint on avr is to indicate that respective memory is clobbererd by means of "+m". To perform the respective change, however, you'll need the address in a register, i.e. "b" or similar, or you know in advance that the address is known at link time an may use "s" etc. Moreover the insn itself is invalid because we don't have DImode support in the avr backend.
[Bug tree-optimization/65964] [meta] Operand Shortening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay --- Created attachment 35437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35437&action=edit combo.c: C test case The problem in PR41076 is mostly about composing bytes to wider integer values as indicated in the test case. It can be handled in the backend (in the case of avr) by adding some more complex combiner patterns, at least for the 16-bit cases like for (from .combine dump): (set (regi:HI 24) (ior:HI (ashift:HI (reg:HI 51) (const_int 8)) (zero_extend:HI (reg:QI 24 or (set (reg:HI 24) (ior:HI (ashift:HI (zero_extend:HI (reg:QI 49)) (const_int 8)) (zero_extend:HI (reg:QI 24 The 32-bit cases are beyond anything a sane avr backend could do. Maybe such patterns could be detected similar to the bswap detection? (which does not work very well from my experience).
[Bug target/65185] avr-gcc mcus.def missing rfr2 devices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65185 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 Severity|normal |enhancement --- Comment #1 from Georg-Johann Lay --- The devices have been added as SVN trunk r212692 (5.0 experimental at that time). http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=212692
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Bug 65296 depends on bug 65895, which changed state. Bug 65895 Summary: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49)) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Keywords||build CC||gjl at gcc dot gnu.org Blocks||65296 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.2 Known to fail||5.1.0 Severity|minor |normal --- Comment #3 from Georg-Johann Lay --- Fixed in 5.2. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 [Bug 65296] [avr] fix various issues with specs file generation
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Mon Apr 27 11:49:42 2015 New Revision: 222460 URL: https://gcc.gnu.org/viewcvs?rev=222460&root=gcc&view=rev Log: Backport from 2015-04-27 trunk r222459. PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #13 from Georg-Johann Lay --- Author: gjl Date: Mon Apr 27 11:49:42 2015 New Revision: 222460 URL: https://gcc.gnu.org/viewcvs?rev=222460&root=gcc&view=rev Log: Backport from 2015-04-27 trunk r222459. PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65895] Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Mon Apr 27 11:43:20 2015 New Revision: 222459 URL: https://gcc.gnu.org/viewcvs?rev=222459&root=gcc&view=rev Log: PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #12 from Georg-Johann Lay --- Author: gjl Date: Mon Apr 27 11:43:20 2015 New Revision: 222459 URL: https://gcc.gnu.org/viewcvs?rev=222459&root=gcc&view=rev Log: PR target/65296 PR target/65895 * config/avr/gen-avr-mmcu-specs.c (print_mcu): Close file. Add hint how to use own spec file. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Georg-Johann Lay changed: What|Removed |Added Keywords||link-failure Status|ASSIGNED|RESOLVED URL||https://savannah.nongnu.org ||/bugs/?44574 Resolution|--- |FIXED --- Comment #11 from Georg-Johann Lay --- Fixed in 5.2. Please keep in mind hat this issue is related to https://savannah.nongnu.org/bugs/?44574
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #10 from Georg-Johann Lay --- Author: gjl Date: Wed Apr 22 16:14:50 2015 New Revision: 222333 URL: https://gcc.gnu.org/viewcvs?rev=222333&root=gcc&view=rev Log: Backport from trunk r222179. 2015-04-17 Sivanupandi Pitchumani PR target/65296 * config/avr/gen-avr-mmcu-specs.c (*avrlibc_startfile): Adjust to new AVR-LibC file layout (bug #44574). (*avrlibc_devicelib): Same. * config/avr/avr-mcus.def: Adjust comments. * config/avr/avr.opt (nodevicelib): Adjust help. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr-mcus.def branches/gcc-5-branch/gcc/config/avr/avr.opt branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |5.2
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Fri Apr 17 13:54:16 2015 New Revision: 222179 URL: https://gcc.gnu.org/viewcvs?rev=222179&root=gcc&view=rev Log: PR target/65296 * config/avr/gen-avr-mmcu-specs.c (*avrlibc_startfile): Adjust to new AVR-LibC file layout (bug #44574). (*avrlibc_devicelib): Same. * config/avr/avr-mcus.def: Adjust comments. * config/avr/avr.opt (nodevicelib): Adjust help. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug other/65794] New: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794 Bug ID: 65794 Summary: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o' Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Host: i386-mingw32 Target: x86_64-linux-gnu Build: x86_64-linux-gnu GCC configured as: ../../gcc.gnu.org/trunk/configure --build=x86_64-linux-gnu --host=i386-mingw32 --enable-languages=c,c++ --target=x86_64-linux-gnu --prefix=/home/georg/gnu/install/gcc-64-32-cross with empty build and empty install directory. Building the compiler aborts: ... /usr/bin/msgfmt --statistics -o po/zh_TW.gmo ../../../gcc.gnu.org/trunk/gcc/po/zh_TW.po 3519 translated messages, 6759 fuzzy translations, 904 untranslated messages. TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h config/linux-android.h config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh tm.h TARGET_CPU_DEFAULT="" \ HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh tm_p.h TARGET_CPU_DEFAULT="" \ HEADERS="auto-build.h ansidecl.h" DEFINES="" \ /bin/bash ../../../gcc.gnu.org/trunk/gcc/mkconfig.sh bconfig.h make[2]: *** No rule to make target `auto-build.h', needed by `build/genmddeps.o'. Stop. make[2]: Leaving directory `/data/home/georg/gnu/build/gcc-64-32-cross/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/data/home/georg/gnu/build/gcc-64-32-cross' make: *** [all] Error 2 The system has a i386-mingw32 toolchain installed, but presumably the above problem occurs also with other crossback configuration with build = target != host
[Bug target/63633] [avr] internal compiler error: unrecognizable insn with mult insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Georg-Johann Lay --- Reopened on behalf of PR65657.
[Bug target/63633] [avr] internal compiler error: unrecognizable insn with mult insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633 Georg-Johann Lay changed: What|Removed |Added CC||jonathan.creekmore@synapse- ||wireless.com --- Comment #4 from Georg-Johann Lay --- *** Bug 65657 has been marked as a duplicate of this bug. ***
[Bug target/65657] [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code Target||avr Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Georg-Johann Lay --- (In reply to Senthil Kumar Selvaraj from comment #5) > This tentative patch (pending regression tests) makes the problem go away > [...] > @@ -9959,7 +9959,11 @@ avr_rtx_costs_1 (rtx x, int codearg, int outer_code > ATTRIBUTE_UNUSED, >return true; > > case MEM: > - *total = COSTS_N_INSNS (GET_MODE_SIZE (mode)); > + /* MEM rtx with non-default address space is more > + expensive. Not expressing that results in reg > + clobber during expand (PR 65657). */ > + *total = COSTS_N_INSNS (GET_MODE_SIZE (mode) > + + (MEM_ADDR_SPACE(x) == ADDR_SPACE_RAM ? 0 : 5)); This might lead to better code, but costs should never be a proper fix for wrong code or ICE. *** This bug has been marked as a duplicate of bug 63633 ***
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Thu Apr 9 11:37:11 2015 New Revision: 221947 URL: https://gcc.gnu.org/viewcvs?rev=221947&root=gcc&view=rev Log: PR target/65296 * config/avr/driver-avr.c (avr_devicespecs_file): Don't specify a device specs file if "device-specs%s" didn't resolve to a path. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/driver-avr.c