[Bug other/94165] New: Wrong "warning: this statement may fall through" after __builtin_unreachable().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94165
Bug ID: 94165
Summary: Wrong "warning: this statement may fall through" after
__builtin_unreachable().
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 48026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48026&action=edit
C/C++ test case.
The compiler gcc, g++ incorrectly complain about fall-through case after
__builtin_unreachable().
Compiler test case with
$ g++ -c -W -Wall
w.c: In function ‘int func(int, int)’:
w.c:7:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
(__extension__({\
~
int _r = error_at (msg);\
~
__builtin_unreachable();\
~
_r; \
~~^~~
}))
~~~
w.c:15:9: note: in expansion of macro ‘error’
error ("bug");
^
w.c:16:5: note: here
case 1: case 2:
^~~~
The only route to the fall-through is via __builtin_unreachable(), thus this
warning is wrong.
[Bug target/89148] [AVR] Merge plugin to place C++ vtables in flash memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89148 --- Comment #2 from Georg-Johann Lay --- Some remarks: 1. There are AVR devices that don't support named address spaces. You will run into ICEs with this approach. You'll have to disable it for respective avr families. 2. The patch sets non-generic address-spaces for objects / types used in the C++ front-end, and that front-end does not support named address-spaces. How is it ensured that all transformations that take place in the C++ front-end handle ASes correctly / consistently? 3. In the case there are problems, the user should be able to switch the feature off by a command-line option. This option requires documentation, in particular it's not an optimization option because it changes the ABI. 4. The plugin must be built / installed. So I'd expect some extensions to the build system like t-avr?
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #9 from Georg-Johann Lay --- (In reply to Berni from comment #8) > I just compiled AVR gcc 9.3.0 and tested the code again. Still no > improvement! Don't expect anything from v9 (or from v10 for that matter). The problem is in the middle-end, and problems there that affect targets like avr will not be fixed -- except in the rare case you manage to show that the issue affects a target that is important enough and report it for that target. And don't expect anything from v11+ either. The avr backend will likely be removed from the compiler, see PR92729. The depreciation is for v11 and wasn't even worth a mention in the v10 release notes caveats https://gcc.gnu.org/gcc-10/changes.html The general recommendation is to switch to clang / llvm where the respective backend is improving and has left experimental status;and is not suffering from self-destruction...
[Bug target/95478] CPP stack pointer SP is 0x5d but assembly shows __SP_L_ at 0x3d (target AVR MEGA2560)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95478 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay --- Closed as invalid: avr-gcc is using the I/O address here, not the SRAM address. Mind SFR-I/O address offset as documented with the built-in macros.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #17 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 06:46:03 2019 New Revision: 277142 URL: https://gcc.gnu.org/viewcvs?rev=277142&root=gcc&view=rev Log: gcc/testsuite/ Fix some fallout for small targets. PR testsuite/52641 * gcc.c-torture/execute/20190820-1.c: Add dg-require-effective-target int32plus. * gcc.c-torture/execute/pr85331.c Add dg-require-effective-target double64plus. * gcc.dg/pow-sqrt-1.c: Same. * gcc.dg/pow-sqrt-2.c: Same. * gcc.dg/pow-sqrt-3.c: Same. * gcc.c-torture/execute/20190901-1.c: Same. * gcc.c-torture/execute/user-printf.c [avr]: Skip. * gcc.c-torture/execute/fprintf-2.c [avr]: Skip. * gcc.c-torture/execute/printf-2.c [avr]: Skip. * gcc.dg/Wlarger-than3.c [avr]: Skip. * gcc.c-torture/execute/ieee/20041213-1.c (sqrt) [avr,double=float]: Provide custom prototype. * gcc.dg/pr36017.c: Same. * gcc.c-torture/execute/pr90025.c: Use 32-bit int. * gcc.dg/complex-7.c: Add dg-require-effective-target double64. * gcc.dg/loop-versioning-1.c: Add dg-require-effective-target size32plus. * gcc.dg/loop-versioning-2.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/20190820-1.c trunk/gcc/testsuite/gcc.c-torture/execute/20190901-1.c trunk/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c trunk/gcc/testsuite/gcc.c-torture/execute/ieee/20041213-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr85331.c trunk/gcc/testsuite/gcc.c-torture/execute/pr90025.c trunk/gcc/testsuite/gcc.c-torture/execute/printf-2.c trunk/gcc/testsuite/gcc.c-torture/execute/user-printf.c trunk/gcc/testsuite/gcc.dg/Wlarger-than3.c trunk/gcc/testsuite/gcc.dg/complex-7.c trunk/gcc/testsuite/gcc.dg/loop-versioning-1.c trunk/gcc/testsuite/gcc.dg/loop-versioning-2.c trunk/gcc/testsuite/gcc.dg/pow-sqrt-1.c trunk/gcc/testsuite/gcc.dg/pow-sqrt-2.c trunk/gcc/testsuite/gcc.dg/pow-sqrt-3.c trunk/gcc/testsuite/gcc.dg/pr36017.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 06:53:34 2019 New Revision: 277143 URL: https://gcc.gnu.org/viewcvs?rev=277143&root=gcc&view=rev Log: PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:10:20 2019 New Revision: 277147 URL: https://gcc.gnu.org/viewcvs?rev=277147&root=gcc&view=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:12:34 2019 New Revision: 277148 URL: https://gcc.gnu.org/viewcvs?rev=277148&root=gcc&view=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 --- Comment #10 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 18 09:16:16 2019 New Revision: 277149 URL: https://gcc.gnu.org/viewcvs?rev=277149&root=gcc&view=rev Log: Backport from 2019-10-18 trunk r277143. PR target/86040 * config/avr/avr.c (avr_out_lpm): Do not shortcut-return. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/avr/avr.c
[Bug target/86040] [avr]: RAMPZ is not always cleared after loading __flashN data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86040 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Georg-Johann Lay --- Fixed in v7.5, v8.4 and v9.3+
[Bug other/92152] New: [10 Regression] Wring code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 Bug ID: 92152 Summary: [10 Regression] Wring code (Resurrection of PR53663) Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr The following test case from GCC testsuite runs into abort. https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/torture/pr53663-2.c?view=markup == compile == $ avr-gcc pr53663-2.c -Os -dp -S the generated asm code for main is: main: sts v+1,__zero_reg__ ; 5 [c=4 l=4] *movhi/3 sts v,__zero_reg__ rcall abort ; 6 [c=0 l=1] call_insn/1 i.e. it always calls abort.
[Bug other/92152] [10 Regression] Wring code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 --- Comment #1 from Georg-Johann Lay --- configure: Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-10 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld --enable-checking=release --enable-languages=c,c++ --with-long-double64 --with-fixed-point=no --disable-gcov Thread model: single Supported LTO compression algorithms: zlib gcc version 10.0.0 20191017 (experimental) (GCC)
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #18 from Georg-Johann Lay --- Author: gjl Date: Mon Oct 21 06:54:42 2019 New Revision: 277236 URL: https://gcc.gnu.org/viewcvs?rev=277236&root=gcc&view=rev Log: Fix some fallout for small targets. PR testsuite/52641 * gcc.dg/torture/pr86034.c: Use 32-bit base type for a bitfield of width > 16 bits. * gcc.dg/torture/pr90972.c [avr]: Add option "-w". * gcc.dg/torture/pr87693.c: Same. * gcc.dg/torture/pr91178.c: Add dg-require-effective-target size32plus. * gcc.dg/torture/pr91178-2.c: Same. * gcc.dg/torture/20181024-1.c * gcc.dg/torture/pr86554-1.c: Use 32-bit integers. * gcc.dg/tree-ssa/pr91091-1.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/20181024-1.c trunk/gcc/testsuite/gcc.dg/torture/pr86034.c trunk/gcc/testsuite/gcc.dg/torture/pr86554-1.c trunk/gcc/testsuite/gcc.dg/torture/pr87693.c trunk/gcc/testsuite/gcc.dg/torture/pr90972.c trunk/gcc/testsuite/gcc.dg/torture/pr91178-2.c trunk/gcc/testsuite/gcc.dg/torture/pr91178.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr91091-1.c
[Bug tree-optimization/92152] [10 Regression] Wrong code (Resurrection of PR53663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152 --- Comment #3 from Georg-Johann Lay --- (In reply to Richard Biener from comment #2) > Hmm, on avr int == short == int16_t, right? Correct.
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-24 Summary|[9 Regression] Useless code |[9/10 Regression] Useless |generated for stack / |code generated for stack / |register operations on AVR |register operations on AVR Ever confirmed|0 |1 --- Comment #4 from Georg-Johann Lay --- Still an issue with v10.
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #4 from Georg-Johann Lay ---
Created attachment 47114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47114&action=edit
double64-5.diff: Support --with-double={32|64} --with-long-double={32|64}
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Fri Oct 25 15:13:23 2019 New Revision: 277455 URL: https://gcc.gnu.org/viewcvs?rev=277455&root=gcc&view=rev Log: PR target/85969 * config/avr/gen-avr-mmcu-specs.c (str_prefix_p): Remove unused static function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/85969] avr/gen-avr-mmcu-specs.c:56: unused function ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85969 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Georg-Johann Lay --- Fixed in v10.
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #5 from Georg-Johann Lay ---
Created attachment 47149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47149&action=edit
double64-6.diff: Support --with-double={|32|64|32,64|64,32}
--with-long-double={|32|64|32,64|64,32,double}
gcc/
Support 64-bit double and 64-bit long double configurations.
PR target/92055
* config.gcc (tm_defines) [avr]: Set from --with-double=,
--with-long-double=.
* config/avr/t-multilib: Remove.
* config/avr/t-avr: Output of genmultilib.awk is now fully
dynamically generated and no more part of the repo.
(HAVE_DOUBLE_MULTILIB, HAVE_LONG_DOUBLE_MULTILIB): New variables.
Pass them down to...
* config/avr/genmultilib.awk: ...here and handle them.
* gcc/config/avr/avr.opt (-mdouble=, avr_double). New option and var.
(-mlong-double=, avr_long_double). New option and var.
* common/config/avr/avr-common.c (opts.h): Include.
(diagnostic.h): Include.
(TARGET_OPTION_OPTIMIZATION_TABLE) <-mdouble=>: Set default as
requested by --with-double=.
<-mlong-double=>: Set default as requested by --with-long-double=.
(TARGET_OPTION_OPTIMIZATION_TABLE) <-mdouble=, -mlong-double=>:
Set default as requested by --with-double=
(TARGET_HANDLE_OPTION): Define to this...
(avr_handle_option): ...new hook worker.
* config/avr/avr.h (DOUBLE_TYPE_SIZE): Define to avr_double.
(LONG_DOUBLE_TYPE_SIZE): Define to avr_long_double.
(avr_double_lib): New proto for spec function.
(EXTRA_SPEC_FUNCTIONS) : Add.
(DRIVER_SELF_SPECS): Call %:double-lib.
* config/avr/avr.c (avr_option_override): Assert
sizeof(long double) >= sizeof(double) for the target.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)
[__HAVE_DOUBLE_MULTILIB__, __HAVE_LONG_DOUBLE_MULTILIB__]
[__HAVE_DOUBLE64__, __HAVE_DOUBLE32__, __DEFAULT_DOUBLE__=]
[__HAVE_LONG_DOUBLE64__, __HAVE_LONG_DOUBLE32__]
[__HAVE_LONG_DOUBLE_IS_DOUBLE__, __DEFAULT_LONG_DOUBLE__=]:
New built-in defined depending on --with-double=, --with-long-double=.
* config/avr/driver-avr.c (avr_double_lib): New spec function.
* doc/invoke.tex (AVR Options) <-mdouble=,-mlong-double=>: Doc.
libgcc/
Support 64-bit double and 64-bit long double configurations.
PR target/92055
* config/avr/t-avr (HOST_LIBGCC2_CFLAGS): Only add -DF=SF if
long double is a 32-bit type.
* config/avr/t-avrlibc: Copy double64 and long-double64
multilib(s) from the vanilla one.
* config/avr/t-copy-libgcc: New Makefile snip.
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #5 from Georg-Johann Lay --- Created attachment 47173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47173&action=edit bloat.c: A trivial test case demonstrating the problem. A (small) part of the overhead can be worked around with -fsplit-wide-types-early, but the major problem is from the register allocator, ira specifically. compile $ avr-gcc -S bloat.c -Os -mmcu=atmega128 -dp -da -fsplit-wide-types-early Generated code: call: push r28 ; 17 [c=4 l=1] pushqi1/0 push r29 ; 18 [c=4 l=1] pushqi1/0 ; SP -= 4 ; 22 [c=4 l=2] *addhi3_sp rcall . rcall . in r28,__SP_L__ ; 23 [c=4 l=2] *movhi/7 in r29,__SP_H__ /* prologue: function */ /* frame size = 4 */ /* stack size = 6 */ .L__stack_usage = 6 std Y+1,r22 ; 14 [c=4 l=4] *movsf/3 std Y+2,r23 std Y+3,r24 std Y+4,r25 /* epilogue start */ ; SP += 4 ; 34 [c=4 l=4] *addhi3_sp pop __tmp_reg__ pop __tmp_reg__ pop __tmp_reg__ pop __tmp_reg__ pop r29 ; 35 [c=4 l=1] popqi pop r28 ; 36 [c=4 l=1] popqi jmp func ; 7 [c=24 l=2] call_value_insn/3 Optimal code: call: jmp func The problem is that IRA concludes that register moves are always more expensive than memory moves, i.e. whatever costs you assign to TARGET_REGISTER_MOVE_COST and TARGET_MEMORY_MOVE_COST, memory will *always* win. From bloat.c.278r.ira: Pass 0 for finding pseudo/allocno costs a1 (r44,l0) best NO_REGS, allocno NO_REGS a0 (r43,l0) best NO_REGS, allocno NO_REGS a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000 a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000 NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000 == configure == --target=avr --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld --enable-checking=release --enable-languages=c,c++
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #6 from Georg-Johann Lay --- Author: gjl Date: Thu Nov 7 09:19:31 2019 New Revision: 277908 URL: https://gcc.gnu.org/viewcvs?rev=277908&root=gcc&view=rev Log: gcc/ Support 64-bit double and 64-bit long double configurations. PR target/92055 * config.gcc (tm_defines) [avr]: Set from --with-double=, --with-long-double=. * config/avr/t-multilib: Remove. * config/avr/t-avr: Output of genmultilib.awk is now fully dynamically generated and no more part of the repo. (HAVE_DOUBLE_MULTILIB, HAVE_LONG_DOUBLE_MULTILIB): New variables. Pass them down to... * config/avr/genmultilib.awk: ...here and handle them. * gcc/config/avr/avr.opt (-mdouble=, avr_double). New option and var. (-mlong-double=, avr_long_double). New option and var. * common/config/avr/avr-common.c (opts.h, diagnostic.h): Include. (TARGET_OPTION_OPTIMIZATION_TABLE) <-mdouble=, -mlong-double=>: Set default as requested by --with-double= (TARGET_HANDLE_OPTION): Define to this... (avr_handle_option): ...new hook worker. * config/avr/avr.h (DOUBLE_TYPE_SIZE): Define to avr_double. (LONG_DOUBLE_TYPE_SIZE): Define to avr_long_double. (avr_double_lib): New proto for spec function. (EXTRA_SPEC_FUNCTIONS) : Add. (DRIVER_SELF_SPECS): Call %:double-lib. * config/avr/avr.c (avr_option_override): Assert sizeof(long double) >= sizeof(double) for the target. * config/avr/avr-c.c (avr_cpu_cpp_builtins) [__HAVE_DOUBLE_MULTILIB__, __HAVE_LONG_DOUBLE_MULTILIB__] [__HAVE_DOUBLE64__, __HAVE_DOUBLE32__, __DEFAULT_DOUBLE__=] [__HAVE_LONG_DOUBLE64__, __HAVE_LONG_DOUBLE32__] [__HAVE_LONG_DOUBLE_IS_DOUBLE__, __DEFAULT_LONG_DOUBLE__=]: New built-in define depending on --with-double=, --with-long-double=. * config/avr/driver-avr.c (avr_double_lib): New spec function. * doc/invoke.tex (AVR Options) <-mdouble=,-mlong-double=>: Doc. * doc/install.texi (Cross-Compiler-Specific Options) <--with-double=, --with-long-double=>: Doc. libgcc/ Support 64-bit double and 64-bit long double configurations. PR target/92055 * config/avr/t-avr (HOST_LIBGCC2_CFLAGS): Only add -DF=SF if long double is a 32-bit type. * config/avr/t-avrlibc: Copy double64 and long-double64 multilib(s) from the vanilla one. * config/avr/t-copy-libgcc: New Makefile snip. Added: trunk/libgcc/config/avr/t-copy-libgcc Removed: trunk/gcc/config/avr/t-multilib Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/avr/avr-common.c trunk/gcc/config.gcc trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/driver-avr.c trunk/gcc/config/avr/genmultilib.awk trunk/gcc/config/avr/t-avr trunk/gcc/doc/install.texi trunk/gcc/doc/invoke.texi trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/config/avr/t-avr trunk/libgcc/config/avr/t-avrlibc
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/install ||/configure.html#avr Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #7 from Georg-Johann Lay --- Added for v10.
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Fri Nov 8 08:49:07 2019 New Revision: 277954 URL: https://gcc.gnu.org/viewcvs?rev=277954&root=gcc&view=rev Log: PR target/92055 * config/avr/avr.opt (-mdouble=, -mlong-double=): Fix a missing '-' when displaying these options in the help screen. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.opt
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #9 from Georg-Johann Lay --- Author: gjl Date: Wed Nov 13 08:18:35 2019 New Revision: 278115 URL: https://gcc.gnu.org/viewcvs?rev=278115&root=gcc&view=rev Log: PR target/92055 * config/avr/t-avr (avr-mcus): Do not depend on $(srcdir)/config/avr/t-multilib. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/t-avr
[Bug target/92545] New: avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 Bug ID: 92545 Summary: avr: support ATmega devices from the 0-series Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- ...like ATmega4808.
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Target Milestone|--- |10.0
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 18 07:52:55 2019 New Revision: 278387 URL: https://gcc.gnu.org/viewcvs?rev=278387&root=gcc&view=rev Log: Add support for AVR devices from the 0-series. PR target/92545 * config/avr/avr-arch.h (avr_mcu_t) : New field. * config/avr/avr-devices.c (avr_mcu_types): Adjust initializers. * config/avr/avr-mcus.def (AVR_MCU): Add respective field. * config/avr/specs.h (LINK_SPEC) <%(link_pm_base_address)>: Add. * config/avr/gen-avr-mmcu-specs.c (print_mcu) <*cpp, *cpp_mcu, *cpp_avrlibc, *link_pm_base_address>: Emit code for spec definitions. * doc/avr-mmcu.texi: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-arch.h trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/config/avr/gen-avr-mmcu-texi.c trunk/gcc/config/avr/specs.h
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 18 07:54:30 2019 New Revision: 278388 URL: https://gcc.gnu.org/viewcvs?rev=278388&root=gcc&view=rev Log: PR target/92545 * doc/avr-mmcu.texi: Regenerate. Modified: trunk/gcc/doc/avr-mmcu.texi
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Georg-Johann Lay --- Added.
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #4 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 18 08:19:08 2019 New Revision: 278389 URL: https://gcc.gnu.org/viewcvs?rev=278389&root=gcc&view=rev Log: PR target/92545 * config/avr/gen-avr-mmcu-specs.c (print_mcu) [link_pm_base_address]: Symbol name is __RODATA_PM_OFFSET__. Modified: trunk/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Wed Nov 20 08:19:44 2019 New Revision: 278478 URL: https://gcc.gnu.org/viewcvs?rev=278478&root=gcc&view=rev Log: Make 0-series device specs work with older versions of avr-gcc. PR target/92545 * config/avr/specs.h (LINK_SPEC) <%(link_pm_base_address)>: Remove. * config/avr/gen-avr-mmcu-specs.c (print_mcu) <*link_pm_base_address>: Don't write spec. <*link_arch>: Add --defsym=__RODATA_PM_OFFSET__= as needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/config/avr/specs.h
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #10 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 25 08:59:06 2019 New Revision: 278668 URL: https://gcc.gnu.org/viewcvs?rev=278668&root=gcc&view=rev Log: gcc/ Build double32 / long-double32 multilibs if needed. PR target/92055 * config/avr/t-avr: (HAVE_DOUBLE_MULTILIB, HAVE_LONG_DOUBLE_MULTILIB): Remove vars. (HAVE_DOUBLE32, HAVE_LONG_DOUBLE32, WITH_LONG_DOUBLE) (HAVE_DOUBLE64, HAVE_LONG_DOUBLE64, WITH_DOUBLE): Set from tm_defines and pass to genmultilib.awk. * config/avr/genmultilib.awk: Use these variables to add double32 and / or long-double32 multilib(s) as needed. * config/avr/driver-avr.c (avr_double_lib): Adjust comment. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/driver-avr.c trunk/gcc/config/avr/genmultilib.awk trunk/gcc/config/avr/t-avr
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #11 from Georg-Johann Lay --- Author: gjl Date: Thu Nov 28 10:29:30 2019 New Revision: 278805 URL: https://gcc.gnu.org/viewcvs?rev=278805&root=gcc&view=rev Log: Must use push insn to pass varargs arguments of DFmode because otherwise the middle-end generates wrong code. PR target/92055 * config/avr/avr.md (MPUSH) [DF, DC]: Add modes to mode iterator. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055 --- Comment #12 from Georg-Johann Lay --- Author: gjl Date: Thu Dec 5 09:47:35 2019 New Revision: 278992 URL: https://gcc.gnu.org/viewcvs?rev=278992&root=gcc&view=rev Log: PR target/92055 * config/avr/t-avrlibc (MULTISUBDIR): Search for double, not double64. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/avr/t-avrlibc
[Bug target/92606] [avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #1 from Georg-Johann Lay --- Created attachment 47484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47484&action=edit 123.c: C test case. Confirmed with the attached test case compiler with $ avr-gcc -mmcu=atmega128 123.c -flto -Os -save-temps -o 123.elf Then 123.elf.ltrans0.s reads: xyz_prog: .byte 123 ... .setxyz,xyz_prog Which is obviously wrong. With -ffat-lto-objects (so that 123.s has asm code) it is correct: xyz and xyz_prog are distinct objects, the first in .data and the latter in .progmem.data.
[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-13 Component|target |other Summary|[avr] invalid merge of |[8/9/10 Regression][avr] |symbols in progmem and data |invalid merge of symbols in |sections|progmem and data sections Ever confirmed|0 |1 --- Comment #2 from Georg-Johann Lay --- Confirmed with v8, v9 and v10. Set component to "other" for now, dunno if it's a missing target hook or a tree flaw.
[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #3 from Georg-Johann Lay --- Created attachment 47485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47485&action=edit 123f.c: C test case with address space __flash. ...and the code is also wrong with address spaces like __flash (and the same options like in comment #1): $ avr-gcc -mmcu=atmega128 123f.c -flto -Os -save-temps -o 123f.elf
[Bug tree-optimization/92932] New: Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932 Bug ID: 92932 Summary: Optimizers generate wrong code due to aggressive data optimization. Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- GCC sometimes aliases symbols if they refer to identical data. However, in order for this to be legitimate optimization, it must be ensured that the code will be accessed in the same way. This is not always the case, an example where this generates wrong code is PR92606. Such a new hook needs at least the following information to disallow aliasing by means of .set or similar means: * The attributes specified for either objects. * The address spaces specified for either objects.
[Bug tree-optimization/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Blocks||92606 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 [Bug 92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #4 from Georg-Johann Lay --- The problem is that there isn't even a target hook to disallow such optimizations, files as as PR92932. In a respective hook, at least the attributes and address spaces of either object must be available.
[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Georg-Johann Lay changed: What|Removed |Added CC||larsch at belunktum dot dk --- Comment #6 from Georg-Johann Lay --- *** Bug 91189 has been marked as a duplicate of this bug. ***
[Bug other/91189] 20% binary size regression in avr-gcc 9.1.0 from 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Georg-Johann Lay --- *** This bug has been marked as a duplicate of bug 90706 ***
[Bug tree-optimization/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> Dup of at least PR92294 and PR54666;
These PRs are different because no target hook is needed to see that the code
is wrong. This is different with PR92606 because a target attribute is
involved.
Hence this PR for a new target hook that can tell whether such transformation
might not be legitimate {apart from generic reasons}.
[Bug ipa/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932 Georg-Johann Lay changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|tree-optimization |ipa --- Comment #3 from Georg-Johann Lay --- For the time being, -fno-ipa-icf-variables might be used as a work-around.
[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #5 from Georg-Johann Lay --- For the time being, -fno-ipa-icf-variables might do as a work-around.
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #6 from Georg-Johann Lay --- Author: gjl Date: Thu Dec 19 08:59:28 2019 New Revision: 279564 URL: https://gcc.gnu.org/viewcvs?rev=279564&root=gcc&view=rev Log: Backport support for some AVR devices from avrxmega3 family from SVN trunk r279309, r278387, r278389, r278478. PR target/92545 * config/avr/avr-arch.h (avr_mcu_t) : New field. * config/avr/avr-devices.c (avr_mcu_types): Adjust initializers. * config/avr/avr-mcus.def (AVR_MCU): Add respective field. * config/avr/gen-avr-mmcu-specs.c (print_mcu) <*cpp, *cpp_mcu, *cpp_avrlibc, *link_pm_base_address>: Emit code for spec definitions. * config/avr/gen-avr-mmcu-texi.c: Rewrite. * doc/avr-mmcu.texi: Regenerate. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/avr/avr-arch.h branches/gcc-9-branch/gcc/config/avr/avr-devices.c branches/gcc-9-branch/gcc/config/avr/avr-mcus.def branches/gcc-9-branch/gcc/config/avr/gen-avr-mmcu-specs.c branches/gcc-9-branch/gcc/config/avr/gen-avr-mmcu-texi.c branches/gcc-9-branch/gcc/doc/avr-mmcu.texi
[Bug target/92545] avr: support ATmega devices from the 0-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92545 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Thu Dec 19 09:31:07 2019 New Revision: 279565 URL: https://gcc.gnu.org/viewcvs?rev=279565&root=gcc&view=rev Log: Backport support for some AVR devices from avrxmega3 family from SVN trunk r279309, r278387, r278389, r278478. PR target/92545 * config/avr/avr-arch.h (avr_mcu_t) : New field. * config/avr/avr-devices.c (avr_mcu_types): Adjust initializers. * config/avr/avr-mcus.def (AVR_MCU): Add respective field. * config/avr/gen-avr-mmcu-specs.c (print_mcu) <*cpp, *cpp_mcu, *cpp_avrlibc, *link_pm_base_address>: Emit code for spec definitions. * config/avr/gen-avr-mmcu-texi.c: Rewrite. * doc/avr-mmcu.texi: Regenerate. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/avr/avr-arch.h branches/gcc-8-branch/gcc/config/avr/avr-devices.c branches/gcc-8-branch/gcc/config/avr/avr-mcus.def branches/gcc-8-branch/gcc/config/avr/gen-avr-mmcu-specs.c branches/gcc-8-branch/gcc/config/avr/gen-avr-mmcu-texi.c branches/gcc-8-branch/gcc/doc/avr-mmcu.texi
[Bug target/93182] New: [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 Bug ID: 93182 Summary: [avr] Add -nodevicespecs option. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Currently, self-specs include device-specs/specs- no matter what, i.e. that specs file will always override specs from -specs=. The new option omits device-specs so that no specs from the user are overridden. In addition, bypassing device-specs allows specifying a custom device specs file without to set -B. 7
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P5
[Bug target/92055] [avr] Support 64-bit double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #13 from Georg-Johann Lay ---
Author: gjl
Date: Wed Jan 8 09:31:07 2020
New Revision: 279994
URL: https://gcc.gnu.org/viewcvs?rev=279994&root=gcc&view=rev
Log:
Implement 64-bit double functions.
gcc/
PR target/92055
* config.gcc (tm_defines) [target=avr]: Support --with-libf7,
--with-double-comparison.
* doc/install.texi: Document them.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)
: New built-in defines.
* doc/invoke.texi (AVR Built-in Macros): Document them.
* config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
* config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
* config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.
libgcc/
PR target/92055
* config.host (tmake_file) [target=avr]: Add t-libf7,
t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
* config/avr/t-avrlibc: Don't copy libgcc.a if there are modules
depending on sizeof (double) or sizeof (long double).
* config/avr/libf7: New folder.
libgcc/config/avr/libf7/
PR target/92055
* t-libf7: New file.
* t-libf7-math: New file.
* t-libf7-math-symbols: New file.
* libf7-common.mk: New file.
* libf7-asm-object.mk: New file.
* libf7-c-object.mk: New file.
* asm-defs.h: New file.
* libf7.h: New file.
* libf7.c: New file.
* libf7-asm.sx: New file.
* libf7-array.def: New file.
* libf7-const.def: New file.
* libf7-constdef.h: New file.
* f7renames.sh: New script.
* f7wraps.sh: New script.
* f7-renames.h: New generated file.
* f7-wraps.h: New generated file.
Added:
trunk/libgcc/config/avr/libf7/
trunk/libgcc/config/avr/libf7/ChangeLog (with props)
trunk/libgcc/config/avr/libf7/asm-defs.h (with props)
trunk/libgcc/config/avr/libf7/f7-renames.h (with props)
trunk/libgcc/config/avr/libf7/f7-wraps.h (with props)
trunk/libgcc/config/avr/libf7/f7renames.sh (with props)
trunk/libgcc/config/avr/libf7/f7wraps.sh (with props)
trunk/libgcc/config/avr/libf7/libf7-array.def (with props)
trunk/libgcc/config/avr/libf7/libf7-asm-object.mk (with props)
trunk/libgcc/config/avr/libf7/libf7-asm.sx (with props)
trunk/libgcc/config/avr/libf7/libf7-c-object.mk (with props)
trunk/libgcc/config/avr/libf7/libf7-common.mk (with props)
trunk/libgcc/config/avr/libf7/libf7-const.def (with props)
trunk/libgcc/config/avr/libf7/libf7-constdef.h (with props)
trunk/libgcc/config/avr/libf7/libf7.c (with props)
trunk/libgcc/config/avr/libf7/libf7.h (with props)
trunk/libgcc/config/avr/libf7/t-libf7 (with props)
trunk/libgcc/config/avr/libf7/t-libf7-math (with props)
trunk/libgcc/config/avr/libf7/t-libf7-math-symbols (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h
trunk/gcc/doc/install.texi
trunk/gcc/doc/invoke.texi
trunk/libgcc/ChangeLog
trunk/libgcc/config.host
trunk/libgcc/config/avr/t-avrlibc
Propchange: trunk/libgcc/config/avr/libf7/ChangeLog
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/ChangeLog
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/asm-defs.h
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/asm-defs.h
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/f7-renames.h
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/f7-renames.h
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/f7-wraps.h
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/f7-wraps.h
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/f7renames.sh
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/f7renames.sh
('svn:executable' added)
Propchange: trunk/libgcc/config/avr/libf7/f7renames.sh
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/f7wraps.sh
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/f7wraps.sh
('svn:executable' added)
Propchange: trunk/libgcc/config/avr/libf7/f7wraps.sh
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/libf7-array.def
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/libf7-array.def
('svn:mime-type' added)
Propchange: trunk/libgcc/config/avr/libf7/libf7-asm-object.mk
('svn:eol-style' added)
Propchange: trunk/libgcc/config/avr/libf7/libf7-asm-object.mk
('svn:mime-type' adde
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Wed Jan 8 09:41:59 2020 New Revision: 279995 URL: https://gcc.gnu.org/viewcvs?rev=279995&root=gcc&view=rev Log: gcc/ Add -nodevicespecs option for avr. PR target/93182 * config/avr/avr.opt (-nodevicespecs): New driver option. * config/avr/driver-avr.c (avr_devicespecs_file): Only issue "-specs=device-specs/..." if that option is not set. * doc/invoke.texi (AVR Options) <-nodevicespecs>: Document. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/driver-avr.c
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Wed Jan 8 09:46:07 2020 New Revision: 279996 URL: https://gcc.gnu.org/viewcvs?rev=279996&root=gcc&view=rev Log: Backport from 2020-01-08 trunk r279995. Add -nodevicespecs option for avr. PR target/93182 * config/avr/avr.opt (-nodevicespecs): New driver option. * config/avr/driver-avr.c (avr_devicespecs_file): Only issue "-specs=device-specs/..." if that option is not set. * doc/invoke.texi (AVR Options) <-nodevicespecs>: Document. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/avr/avr.opt branches/gcc-9-branch/gcc/config/avr/driver-avr.c branches/gcc-9-branch/gcc/doc/invoke.texi
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 --- Comment #3 from Georg-Johann Lay --- Author: gjl Date: Wed Jan 8 09:52:03 2020 New Revision: 279997 URL: https://gcc.gnu.org/viewcvs?rev=279997&root=gcc&view=rev Log: gcc/ Backport from 2020-01-08 trunk r279995. Add -nodevicespecs option for avr. PR target/93182 * config/avr/avr.opt (-nodevicespecs): New driver option. * config/avr/driver-avr.c (avr_devicespecs_file): Only issue "-specs=device-specs/..." if that option is not set. * doc/invoke.texi (AVR Options) <-nodevicespecs>: Document. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/avr/avr.opt branches/gcc-8-branch/gcc/config/avr/driver-avr.c branches/gcc-8-branch/gcc/doc/invoke.texi
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 Georg-Johann Lay changed: What|Removed |Added Target Milestone|9.4 |9.3
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.4 --- Comment #4 from Georg-Johann Lay --- Implemented in v9.3+ (and v8.4+).
[Bug target/93182] [avr] Add -nodevicespecs option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93182 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Wed Jan 8 14:28:56 2020 New Revision: 280005 URL: https://gcc.gnu.org/viewcvs?rev=280005&root=gcc&view=rev Log: PR target/93182 * doc/invoke.texi (AVR Options) <-nodevicespecs>: Document. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug ipa/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #7 from Georg-Johann Lay --- (In reply to Richard Biener from comment #6) > or whether the backend "forgets" to set DECL_SECTION_NAME or the like. That caused problems (don't remember which ones exactly, maybe to make -fdata-sections work). The section is set in TARGET_ASM_SELECT_SECTION so the middle-end knows the section (in principle). But presumably the middle-end concept is broken, because telling what section belongs to a decl is not enough to convince the middle-end that the section belongs to the decl... It's gcc after all. (Very) old versions did set DECL_SECTION_NAME in insert_attributes, but that's no more the case. Presumably to fix one of the 100s of FIXMEs in the avr backend. > Similarly address-spaces need to be honored (I bet avr would have one -- is > PROGMEM actually an address-space implementation-wise?) No, progmem is just an attribute and dates back to the times when there was no address-spaces in gcc. It's still supposed to be supported because old code should still work, and because g++ will never have address-spaces. > I see there's a 'progmem' target attribute but its effects might be hidden > completely from the middle-end. That's why I opened PR92932. As mentioned in comment #3, the bug also appears for address-space __flash.
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 --- Comment #18 from Georg-Johann Lay --- I am inclined to close all these PRs as invalid because there is still no valid bug report, i.e. none of the reports enabled us to reproduce the issue AND it is against a version no more supported (the 1st report was actually filed 1 1/2 years after v5 support ended) AND we were not able to find out whether the problems are due to changes introduced by the distributor. Please report this problems to Microchip. Maybe someone knows the correct bug URL to report this to Microchip and can it post here. Thanks.
[Bug ipa/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606 --- Comment #8 from Georg-Johann Lay --- Giving up on this. My work-around patch to disable the malicious data optimization for avr has effectively been rejected. http://gcc.gnu.org/ml/gcc-patches/2020-01/msg00145.html So we can enjoy code that saves some scrappy bytes at the expense that it might be incorrect...
[Bug target/56164] [avr] ICE: spill fail with __flash keyword
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56164
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed|2013-01-31 00:00:00 |2013-02-07 0:00
--- Comment #4 from Georg-Johann Lay 2013-02-07
17:45:56 UTC ---
Confirmed with:
gcc version 4.7.3 20130207 (prerelease) [gcc-4_7-branch revision 195858] (GCC)
Configured with:
../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-languages=c,c++ --enable-target-optspace=yes --with-avrlibc=yes
Invocation:
avr-gcc spill-flash-2.c -S -Os -mmcu=atmega8
spill-flash.c: In function 'psy':
spill-flash.c:18:1: error: unable to find a register to spill in class
'POINTER_REGS'
spill-flash.c:18:1: error: this is the insn:
(insn 26 25 28 2 (set (reg:SF 59 [ D.1370 ])
(unspec:SF [
(reg:HI 30 r30)
(const_int 0 [0])
] UNSPEC_LPM)) spill-flash.c:9 9 {load_sf}
(expr_list:REG_DEAD (reg:HI 30 r30)
(nil)))
spill-flash.c:18: confused by earlier errors, bailing out
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #12 from Georg-Johann Lay 2013-02-08 10:13:45 UTC --- Author: gjl Date: Fri Feb 8 10:13:37 2013 New Revision: 195878 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195878 Log: gcc/ PR target/54222 * config/avr/avr.md (unspec) : Add. * config/avr/avr-fixed.md (ALL4QA, ALL124QA): New mode iterators. (round3, round3_const): New expanders for fixed-mode. (*round3.libgcc): New insns for fixed-modes. * config/avr/builtins.def (ABSxx): Use a non-NULL LIBNAME. (ROUNDxx, COUNTLSxx, BITSxx, xxBITS): New DEF_BUILTINs. (ROUNDFX, COUNTLSFX, ABSFX): New DEF_BUILTINs. * config/avr/stdfix.h (absFX, bitsFX, FXbits): Remove inline implementations. Define to __builtin_avr_absFX, __builtin_avr_bitsFX, __builtin_avr_FXbits, respectively. (roundFX, countlsFX): Define to __builtin_avr_roundFX, __builtin_avr_countlsFX, respectively. * config/avr/avr-c.c (target.h): Include it. (enum avr_builtin_id): New enum. (avr_resolve_overloaded_builtin): New static function. (avr_register_target_pragmas): Use it to set targetm.resolve_overloaded_builtin. * config/avr/avr.c (avr_init_builtins): Supply myriads of local tree nodes used by DEF_BUILTIN. (avr_expand_builtin) : Sanity-check them. (avr_fold_builtin) : Fold to VIEW_COVERT_EXPR. : Same. libgcc/ PR target/54222 * config/avr/lib2funcs.c: New C sources for modules for libgcc.a. * config/avr/lib2-object.mk: New iterator to build objects from it. * config/avr/t-avr: Iterate lib2-object.mk to build objects from lib2funcs.c. (LIB2FUNCS_EXCLUDE): Add _clrsbdi2. (LIB1ASMFUNCS): Add: _ssabs_1, _mask1, _ret, _roundqq3, _rounduqq3, _round_s2, _round_u2, _round_2_const, _addmask_2, _round_s4, _round_u4, _round_4_const, _addmask_4, _round_x8, _rounddq3 _roundudq3, _roundda3 _rounduda3, _roundta3 _rounduta3. * config/avr/lib1funcs-fixed.S: Implement them. gcc/testsuite/ PR target/54222 * gcc.target/avr/torture/builtins-4-roundfx.c: New test. * gcc.target/avr/torture/builtins-5-countlsfx.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/builtins-4-roundfx.c trunk/gcc/testsuite/gcc.target/avr/torture/builtins-5-countlsfx.c trunk/libgcc/config/avr/lib2-object.mk trunk/libgcc/config/avr/lib2funcs.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-fixed.md trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/builtins.def trunk/gcc/config/avr/stdfix.h trunk/gcc/testsuite/ChangeLog trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs-fixed.S trunk/libgcc/config/avr/lib1funcs.S trunk/libgcc/config/avr/t-avr
[Bug target/56254] New: [avr] Support __builtin_avr_delay_cycles with non-const delays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56254 Bug #: 56254 Summary: [avr] Support __builtin_avr_delay_cycles with non-const delays Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr __builtin_avr_delay_cycles currently throws an error with non-constant argument. Non-constant arguments can be supported if delay is allowed to be a bit fuzzy.
[Bug target/56254] [avr] Support __builtin_avr_delay_cycles with non-const delays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56254 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-08 AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug tree-optimization/56064] Optimize VIEW_CONVERT_EXPR with FIXED_CST
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56064 --- Comment #3 from Georg-Johann Lay 2013-02-08 13:23:46 UTC --- Author: gjl Date: Fri Feb 8 13:23:34 2013 New Revision: 195885 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195885 Log: gcc/ PR tree-optimization/56064 * fixed-value.c (fixed_from_double_int): Sign/zero extend payload bits according to mode. * fixed-value.h (fixed_from_double_int) (const_fixed_from_double_int): Adjust comments. gcc/testsuite/ PR tree-optimization/56064 * gcc.dg/fixed-point/view-convert-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/fixed-point/view-convert-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fixed-value.c trunk/gcc/fixed-value.h trunk/gcc/testsuite/ChangeLog
[Bug target/56254] [avr] Support __builtin_avr_delay_cycles with non-const delays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56254 --- Comment #1 from Georg-Johann Lay 2013-02-08 20:52:41 UTC --- Created attachment 29400 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29400 var-delay.diff
[Bug target/56254] [avr] Support __builtin_avr_delay_cycles with non-const delays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56254 Georg-Johann Lay changed: What|Removed |Added Keywords||patch Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Comment #2 from Georg-Johann Lay 2013-02-08 20:55:48 UTC --- Closed as won't fix, cf. http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00363.html
[Bug target/56263] New: [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
Bug #: 56263
Summary: [avr] Provide strict address-space checking
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: g...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: demiurg_...@freemail.ru
Target: avr
Created attachment 29401
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29401
Test case that shall error with strict address spaces
The intrinsic address spaces introduced with PR49868 are imlemented in such a
way that each address space is a subset of each other.
This allows code like follows to operate as expected and without warnings:
char read_char (const char *address, int data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
Currently, targetm.addr_space_subset_p returns always true in order to allow
pointer casts like above without diagnostics.
avr.c:avr_addr_space_subset_p() could be implemented in such a way, that it
returns true iff the respective ASes are physical subsets of each other, and
not only if their address, regarded as number, are subsets.
In order not to change the current ABI, this can be achieved by a new command
line option like -maddr-space-subset that allows the user to pick the model of
his favor.
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-09 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
--- Comment #2 from Georg-Johann Lay 2013-02-11
15:09:40 UTC ---
Created attachment 29418
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29418
draft patch
PR target/56263
* config/avr/avr.opt (-mstrict-addr-space-subsets): New option and...
(avr_strict_addr_space_subsets)... attached variable.
* config/avr/avr.c (avr_addr_space_subset_p): Use it to determine
whether of not an address spaces are subsets.
* doc/invoke.texi (AVR Options) <-mstrict-addr-space-subsets>:
Document it.
I had a look at this.
With strict address spaces, GCC will emit zeroes as result of casts across
address spaces. This means that code like
char read_char (const char *address, int data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
will no more operate correctly. For the same reason, it is no more possible to
use PSTR from AVR-LibC with functions that get an address space pointer because
PSTR puts (and must put) the literal in generic space.
(In reply to comment #1)
> I think the next test case should also be considered.
>
> const char __flash* const __flash names[] =
> {
> "flash_str1",
> "flash_str2"
This cannot work because ISO/IEC TR18037 forces these literals into generic
space.
> };
>
> const char __flash* name1 = names[0]; // ok
> const char* name2 = names[1]; // error
Attached is the draft patch that I used. This means that in order to make this
work, the compiler proper has to be extended and the feature cannot be
implemented in the avr backend alone. Thus suspending for now and for an other
stage.
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|SUSPENDED
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #13 from Georg-Johann Lay 2013-02-12 14:55:22 UTC --- Author: gjl Date: Tue Feb 12 14:55:16 2013 New Revision: 195978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195978 Log: gcc/ PR target/54222 * config/avr/avr-dimode.md (umulsidi3, mulsidi3): New expanders. (umulsidi3_insn, mulsidi3_insn): New insns. libgcc/ PR target/54222 * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add: _usmulUHA, _usmulUSA, _ssmulHA, _ssmulSA. (LIB1ASMFUNCS): Add: _muldi3_6, _mulsidi3, _umulsidi3, _usmuluha3, _ssmulha3, _usmulusa3, _ssmulsa3. * config/avr/lib1funcs.S (__muldi3_6): Break out of __muldi3. (__muldi3): XCALL __muldi3_6 instead of rcall. (__umulsidi3, __mulsidi3): New functions. (do_prologue_saves, do_epilogue_restores): New .macros. (__divdi3_moddi3): Use them. * config/avr/lib1funcs-fixed.S (__usmuluha3, __ssmulha3) (__usmulusa3, __ssmulsa3): New functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-dimode.md trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs-fixed.S trunk/libgcc/config/avr/lib1funcs.S trunk/libgcc/config/avr/t-avr
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
--- Comment #4 from Georg-Johann Lay 2013-02-19
17:58:36 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
>
>> This cannot work because ISO/IEC TR18037 forces these literals into generic
>> space.
>>
>
> ISO/IEC TR18037
> 5.1.2 Address-space type qualifiers:
>
> If the type of an object is qualified by an address space name, the
> object is allocated in the specified address space; otherwise, the object is
> allocated in the generic address space.
>
> I just re-read the standard.
> I could not find any reason not permitted to place the data in __flash address
> space in that case:
>
> const char __flash* const __flash names[] = {"flash_str1", "flash_str2"};
The initializer at the righ side has type "const char *const[]" thus names[] is
located in flash because names[] is qualified __flash. However, the Embedded C
does not say anything about the literals like "flash_str1" of type "const
char*". Therefore, vanilla C applies which says that these literals go into
generic space.
> IAR compilers it does, and that hinders gcc do the same?
> I think it's an easy misunderstanding, preventing common sense ...
It's a shortcoming in the Embedded C paper and I agree with you that more
elaborate Embedded C paper would be more convenient here.
There are two ways out of this:
1) Extend the Embedded C paper and propose an addendum to the ISO WG14.
2) Implement this extension no matter whether Embedded C comes with this
extension. Find someone who implements this extension, supports it and makes
sure there are no conflicts with the vanilla Embedded C.
Notice that with the extension, in the following example "init" would be
located in flash but "assign" would still be located in RAM.
void f_init (void)
{
const __flash char *str = "init";
}
void f_assign (void)
{
const __flash char *str;
str = "assign";
}
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 Georg-Johann Lay changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Georg-Johann Lay 2013-02-20 08:43:57 UTC --- #
[Bug target/39760] register allocation costs are not well described on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39760 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-20 CC||gjl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay 2013-02-20 08:50:58 UTC --- Is this still an issue? What's the problem with micro-optimizations?
[Bug target/39760] register allocation costs are not well described on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39760 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180 Georg-Johann Lay changed: What|Removed |Added Priority|P2 |P4 Severity|enhancement |normal
[Bug other/56442] Could not identify that register is clobbered already
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56442
Georg-Johann Lay changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-02-25
CC||gjl at gcc dot gnu.org
Component|target |other
Ever Confirmed|0 |1
Severity|major |normal
--- Comment #2 from Georg-Johann Lay 2013-02-25
10:56:02 UTC ---
Enabling others to understand this...
In .reload dump, we have correct code:
(insn 418 417 113 3 (set (reg:HI 24 r24)
(const:HI (plus:HI (symbol_ref:HI ("array") [flags 0x2] )
(const_int 4 [0x4] 32 {*movhi}
(nil))
(insn 113 418 114 3 (set (reg:HI 14 r14 [94])
(minus:HI (reg:HI 14 r14 [94])
(reg:HI 24 r24))) 65 {subhi3}
(nil))
(insn 114 113 115 3 (set (reg:HI 14 r14 [94])
(lshiftrt:HI (reg:HI 14 r14 [94])
(const_int 2 [0x2]))) 217 {lshrhi3}
(nil))
(insn 115 114 118 3 (parallel [
(set (reg:HI 14 r14 [94])
(and:HI (reg:HI 14 r14 [94])
(const_int 3 [0x3])))
(clobber (reg:QI 25 r25))
]) 175 {andhi3}
(nil))
(insn 118 115 119 3 (set (reg:SF 18 r18 [orig:65 D.1335 ] [65])
(mem:SF (symbol_ref:HI ("array") [flags 0x2] ) [2 MEM[base: D.1358_18, offset: 0B]+0 S4 A8])) foo.c:15 37 {*movsf}
(nil))
(insn 119 118 122 3 (set (reg:HI 28 r28 [orig:96 ivtmp.10 ] [96])
(const:HI (plus:HI (symbol_ref:HI ("array") [flags 0x2] )
(const_int 4 [0x4] 32 {*movhi}
(expr_list:REG_EQUAL (const:HI (plus:HI (symbol_ref:HI ("array") [flags
0x2] )
(const_int 4 [0x4])))
(nil)))
This is changed by .postreload to:
(insn 119 118 122 3 (set (reg:HI 28 r28 [orig:96 ivtmp.10 ] [96])
(reg:HI 24 r24)) 32 {*movhi}
(expr_list:REG_EQUAL (const:HI (plus:HI (symbol_ref:HI ("array") [flags
0x2] )
(const_int 4 [0x4])))
(nil)))
This is wrong because reg:HI 24 is (partly) clobbered by insn 115 and thus
reg:HI 24 must not be used past insn 115.
Component is not target, the target description of andhi3 insn is all right.
According to S, the bad transformation happens in:
postreload.c:reload_cse_move2add()
[Bug target/56445] avr.c:11551:16: error: invoking macro FX_FTYPE_FX ar gument 1: empty macro arguments are undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56445 --- Comment #1 from Georg-Johann Lay 2013-02-28 09:16:15 UTC --- Author: gjl Date: Thu Feb 28 09:16:08 2013 New Revision: 196332 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196332 Log: PR target/56445 * config/avr/avr.c (avr_init_builtins): Use 'n' instead of empty macro parameters with: FX_FTYPE_FX, FX_FTYPE_FX_INT, INT_FTYPE_FX, INTX_FTYPE_FX, FX_FTYPE_INTX. * config/avr/builtins.def: Adjust respective DEF_BUILTIN. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/builtins.def
[Bug target/56445] avr.c:11551:16: error: invoking macro FX_FTYPE_FX ar gument 1: empty macro arguments are undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56445 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Georg-Johann Lay 2013-02-28 09:19:29 UTC --- Fixed
[Bug inline-asm/56479] Register allocator can't allocate two 4-byte variables into 8 registers for inline asm on avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED |NEW
Keywords||ice-on-valid-code, ra
Last reconfirmed||2013-03-02
CC||gjl at gcc dot gnu.org
Blocks||56183
Ever Confirmed|0 |1
Known to fail||3.4.6, 4.3.3, 4.5.2, 4.6.2,
||4.7.2, 4.8.0
--- Comment #1 from Georg-Johann Lay 2013-03-02
19:05:47 UTC ---
Confirmed with 4.8 from 2013-03-01 for any optimization level for the
following, smaller test case:
void asmfoo (long x, long y)
{
asm volatile ("" :: "a"(x), "a"(y));
}
[Bug other/54500] While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Georg-Johann Lay 2013-03-03 16:55:28 UTC --- No answer and no valid test case for 6 months now. Closed as invalid.
[Bug other/56517] New: ICE: in find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56517 Bug #: 56517 Summary: ICE: in find_valid_class, at reload.c:704 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, ra Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Blocks: 56183 Target: avr This ICE occurs for gcc.c-torture/compile/pr55921.c from the GCC test suite: /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c: In function 'foo': /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c:21:1: internal compiler error: in find_valid_class, at reload.c:704 0x850ee60 find_valid_class ../../../gcc.gnu.org/trunk/gcc/reload.c:704 0x851339d push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class, machine_mode, machine_mode, int, int, int, reload_type) ../../../gcc.gnu.org/trunk/gcc/reload.c:1152 0x8519705 find_reloads(rtx_def*, int, int, int, short*) ../../../gcc.gnu.org/trunk/gcc/reload.c:4099 0x8528544 calculate_needs_all_insns ../../../gcc.gnu.org/trunk/gcc/reload1.c:1520 0x8528544 reload(rtx_def*, int) ../../../gcc.gnu.org/trunk/gcc/reload1.c:941 0x843f543 do_reload ../../../gcc.gnu.org/trunk/gcc/ira.c:4631 0x843f543 rest_of_handle_reload ../../../gcc.gnu.org/trunk/gcc/ira.c:4731 Please submit a full bug report, == configure == Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-target-optspace=yes --enable-languages=c,c++ Thread model: single gcc version 4.8.0 20130228 (experimental) (GCC) FAIL: gcc.c-torture/compile/pr55921.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/pr55921.c -O2 -flto (internal compiler error)
[Bug other/56517] ICE: in find_valid_class, at reload.c:704
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56517 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 Ever Confirmed|0 |1
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #9 from Georg-Johann Lay 2013-03-04 11:12:42 UTC --- Author: gjl Date: Mon Mar 4 11:12:30 2013 New Revision: 196428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196428 Log: PR testsuite/52641 PR tree-optimization/52631 * gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr52631.c
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #12 from Georg-Johann Lay 2013-03-04 11:12:42 UTC --- Author: gjl Date: Mon Mar 4 11:12:30 2013 New Revision: 196428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196428 Log: PR testsuite/52641 PR tree-optimization/52631 * gcc.dg/tree-ssa/pr52631.c: Fix 16-bit int. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr52631.c
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 Georg-Johann Lay changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-06 Ever Confirmed|0 |1 Known to fail||4.6.2, 4.7.2 --- Comment #4 from Georg-Johann Lay 2013-03-06 19:29:47 UTC --- Thanks for the patch. I tested it together with a --target=avr --host=i386-mingw32 --build=i686-linux-gnu canadian cross with spaces in the install pass. Will this be backported?
[Bug target/56546] Using the divide operator on unsigned int produces incorrect code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56546
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3 |P4
Status|UNCONFIRMED |WAITING
Last reconfirmed||2013-03-07
CC||gjl at gcc dot gnu.org
Ever Confirmed|0 |1
Severity|critical|normal
--- Comment #1 from Georg-Johann Lay 2013-03-07
22:20:48 UTC ---
(In reply to comment #0)
> Created attachment 29592 [details]
> Sample code to reproduce the issue
>
> Using the divide integer on unsigned int variables on an AVR target leads to
> wrong code being generated. The generated code uses the __umulhisi3 routine
> from libgcc which is a multiplication routine and the result is always zero.
Can't confirm this using the following, slightly extended test case:
$ avr-gcc-4.7.2 -O0 -mmcu=atmega8 foo.c -o foo.elf
#include
int main (void)
{
volatile unsigned int toto = 140;
toto /= 60;
if (toto != 2)
abort();
return 0;
}
The objdump shows that __umulhisi3 is actually called: It computes the high
part of 140 * 0x8889 which is 0x004a. This value is then unsigned-shifted by 5
to the right which is 2. This, in turn, is the expectet result of 140 / 60.
Runing a simulator hits exit (by returning from main).
> [snip unrelated text]workings of gcc, I
>
> I've come up with a very simple source file that allows to reproduce
> the issue.
>
> By the way I couldn't think of any case where transforming a udiv into a mult
> operating on integers would make sense and would be glad if someone could give
> me some hints on this.
AVR has no divide instruction and / 60 is performed by a multiplication and
some adjustment.
> Here's the command line I used:
>
> avr-gcc -O0 -g -Wall -Wextra -save-temps -mmcu=atmega8 -o main.elf main.c
>
> And the version of the toolchain components:
>
> binutils: efb7cff2df30eb792d30e8afc384aa88c193932b
> gcc: ef11013858b41453c4953ca8d4c25e3b1668e536
> avr-libc: 2ac01d285e23894ef3bcc65c75b39da8157b9fd9
These are no versions.
Please show the output of avr-gcc -v.
> gcc-4.7.2, binutils 2.23.1 and avr-libc 1.8.0 give the same result.
Is this an unpatched avr-gcc?
[Bug target/56562] [AVR GCC] segmentation fault when '__attribute__((packed))' placed at front of enum declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56562 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED Known to work||4.7.2 Keywords||ice-on-valid-code CC||gjl at gcc dot gnu.org Resolution||WORKSFORME Target Milestone|--- |4.7.2 Severity|major |normal --- Comment #2 from Georg-Johann Lay 2013-03-07 22:42:08 UTC --- I can confirm this whith 4.7.1 20120322 (prerelease). It works fine with 4.7.2 and 4.8.0 (experimental): :1:32: warning: attribute ignored in declaration of 'enum FooEnum' [-Wattributes] __attribute__(( packed )) enum FooEnum ^ :1:32: note: attribute for 'enum FooEnum' must follow the 'enum' keyword It works also with the packed attribute in the right place. Whatever the issue was, it's fixed in latest 4.7, thus closing this as WORKSFORME.
[Bug target/56439] global and local register variables don't work in a useful way -- AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #8 from Georg-Johann Lay 2013-03-07 23:26:01 UTC --- (In reply to comment #3) > (In reply to comment #2) >> Any specific sections you can point me to? I'd be interested to hear a >> justification for this behavior. > > Simple answer, an interrupt can happen any time after the access/assignment of > the global register variable so it needs to be set to the value and treated as > a volatile variable. Is this really the case? There is not even a means to tag a REG as volatile. The /v flag is set but for REGs it means "user variable", see rtl.h and the docs for volatil. http://gcc.gnu.org/viewcvs/trunk/gcc/rtl.h?view=markup#l286 And qualifying foo as volatile diagnoses as expected: :1:1: warning: optimization may eliminate reads and/or writes to register variables [-Wvolatile-register-var] This issue looks rather like a fallout of reload that for some reasons spills for the shift insn. See also PR49491 Or are global registers spacial for reload? I still don't see why a spilling is needed for the shift insn...
[Bug target/56439] [avr] unnecessary spill for global and local register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56439 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization, ra Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-07 Known to work||3.4.6 Blocks||56183 Summary|global and local register |[avr] unnecessary spill for |variables don't work in a |global and local register |useful way -- AVR |variables Ever Confirmed|0 |1
[Bug target/56546] Using the divide operator on unsigned int produces incorrect code on AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56546 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Georg-Johann Lay 2013-03-11 11:50:02 UTC --- (In reply to comment #2) > (In reply to comment #1) >> Is this an unpatched avr-gcc? > > In fact I discovered the issue on a toolchain built with Gentoo's crossdev > tool. They are using a good number of patches but these are not the source of > the problem. After digging a little deeper I discovered that the problem comes > from the build options they use. After a good number of builds on an unpatched > gcc-4.7.2 I've been able to determine that the --disable-multilib option they > use is the source of the issue. --disable-multilib completely messes up the tools, thus closing this PR as INVALID. > Building with > > ../configure [...] Notice that configuring in the source tree is strongly discouraged / not supported. Read the configuring GCC documentation again. If you are using AVR-LibC, you may also want to configure with --with-avrlibc=yes and use AVR-LibC that implements http://savannah.nongnu.org/bugs/?35407
[Bug target/56591] Missing space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56591 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|NEW |WAITING CC||gjl at gcc dot gnu.org Component|translation |target --- Comment #1 from Georg-Johann Lay 2013-03-11 18:45:08 UTC --- Please supply informations and test case following the bug reporting instructions http://gcc.gnu.org/bugs/#report
[Bug target/56591] Missing space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56591 --- Comment #3 from Georg-Johann Lay 2013-03-11 18:57:35 UTC --- Author: gjl Date: Mon Mar 11 18:57:27 2013 New Revision: 196604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196604 Log: PR target/56591 * config/avr/avr.c (avr_print_operand): Add space after '%c' in output_operand_lossage message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug target/56591] Missing space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56591 Georg-Johann Lay changed: What|Removed |Added Keywords||diagnostic Priority|P4 |P5 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 Severity|normal |trivial --- Comment #4 from Georg-Johann Lay 2013-03-11 19:01:27 UTC --- Fixed.
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263 --- Comment #6 from Georg-Johann Lay 2013-03-12 11:42:30 UTC --- Author: gjl Date: Tue Mar 12 11:42:26 2013 New Revision: 196611 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196611 Log: PR target/56263 * config/avr/avr.c (TARGET_CONVERT_TO_TYPE): Define to... (avr_convert_to_type): ...this new static function. * config/avr/avr.opt (-Waddr-space-convert): New C option. * doc/invoke.texi (AVR Options): Document it. Modified: trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.opt trunk/gcc/doc/invoke.texi
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
Georg-Johann Lay changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
--- Comment #7 from Georg-Johann Lay 2013-03-12
21:21:19 UTC ---
This patch implements -Waddr-space-convert and will print diagnostics for casts
to non-containing address spaces.
It's just a quick implementation in order to get the patch into 4.8.0 which
will be frozen for release withing the next few days.
Some work still to be done:
- Try to avoid warnings for casts from PSTR ("text") to const __flash char*.
PSTR is a commonly used idion from AVR-LibC's avr/progmem.h, namely
#define PSTR(s)\
(__extension__( \
{ \
static const char __c[] __attribute__((__progmem__)) = (s); \
&__c[0];\
}))
- Try to distinguish between implicit casts and explicit casts requested
by the user
- Allow to pick a warning level for the previous kinds of casts
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> >
> > It's a shortcoming in the Embedded C paper and I agree with you that more
> > elaborate Embedded C paper would be more convenient here.
> >
> > There are two ways out of this:
> >
> > 1) Extend the Embedded C paper and propose an addendum to the ISO WG14.
> >
> > 2) Implement this extension no matter whether Embedded C comes with this
> > extension. Find someone who implements this extension, supports it and
> > makes sure there are no conflicts with the vanilla Embedded C.
> >
> > Notice that with the extension, in the following example "init" would be
> > located in flash but "assign" would still be located in RAM.
> >
> > void f_init (void)
> > {
> > const __flash char *str = "init";
> > }
> >
> > void f_assign (void)
> > {
> > const __flash char *str;
> > str = "assign";
> > }
>
> In my view, in this situation, the data must be placed in a flash ...
> Standard really needs serious improvement.
ACK. May be that is the reason for why Embedded-C did not go into C11.
However, waiting until the Embedded-C paper will be extended in that direction
is pointless. Just try to participate the ISO process; it will take years...
Maybe it's doable in the avr backend, but then we need a proper specification
and enough knowledge to decide whether or not all hooks are guaranteeing that
the BE can take the decision in every case.
> It's logical, when the right-hand and left-hand side of each other have the
> appropriate type. Moreover, for the implementation of this simple idea is not
> objective difficulties.
Sorry? I don't understand you last remark. Are you saying it is trivial to
implement in the avr backend?
Before implementing it, you'll have to specify it. What should do this code?
const __flash char* f (int i)
{
const __flash char *p = "Hallo" + i;
return p;
}
[Bug target/56792] AVR, internal compiler error on build avr-libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56792 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #2 from Georg-Johann Lay 2013-04-12 16:43:14 UTC --- Is this related to PR52472?
[Bug target/56219] avr-gcc-4.7.2 missing __uint24 loop optimisation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56219 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from Georg-Johann Lay 2013-04-12 20:05:11 UTC --- Closed as WON'T FIX It might be very well the case that code using __[u]int24 (PSImode) variables is not compiled as efficient as could be. Maybe some generic optimizations work also for PSImode so that you'll see better code for PSI operations as a byproduct of some generic optimizations in the future. But sorry, no PSI-specific optimization hacks in the avr backend for now. Remember that R0 is special and does not survive an insn, i.e. it's used like a scratch register.
[Bug target/56792] AVR, internal compiler error on build avr-libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56792 Georg-Johann Lay changed: What|Removed |Added Keywords||addr-space, ||ice-on-valid-code Target||avr Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Georg-Johann Lay 2013-04-13 14:33:19 UTC --- Duplicate according to comment #3 *** This bug has been marked as a duplicate of bug 52472 ***
[Bug middle-end/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52472 Georg-Johann Lay changed: What|Removed |Added CC||Sergey.Belyashov at gmail ||dot com --- Comment #8 from Georg-Johann Lay 2013-04-13 14:33:19 UTC --- *** Bug 56792 has been marked as a duplicate of this bug. ***
