[Bug c/80786] New: m68k: internal compiler error: in change_address_1

2017-05-16 Thread ad...@tho-otto.de
Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 41369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41369=edit bla.c When compiling the attached, small test program with m68k-elf-gcc -O2 -mpcrel bl

[Bug c/85318] New: -Wc90-c99-compat does not warn about for loop initial declarations

2018-04-10 Thread ad...@tho-otto.de
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- When compiling code that uses for loop initial declarations with -Wc90-c99-compat, no diagnostic is issued.

[Bug c/85290] New: Defining identifiers to themselves in system headers prevents diagnostics from being emitted.

2018-04-08 Thread ad...@tho-otto.de
Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: ---

[Bug c/85290] Defining identifiers to themselves in system headers prevents diagnostics from being emitted.

2018-04-08 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290 --- Comment #1 from Thorsten Otto <ad...@tho-otto.de> --- Created attachment 43879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43879=edit header file marked as system header

[Bug c/85290] Defining identifiers to themselves in system headers prevents diagnostics from being emitted.

2018-04-08 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290 --- Comment #3 from Thorsten Otto <ad...@tho-otto.de> --- When compiling the attached source file, which includes a header file marked as system header (same happens when include some real file from a system header path), specifying -Wdecla

[Bug c/85290] Defining identifiers to themselves in system headers prevents diagnostics from being emitted.

2018-04-08 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290 --- Comment #2 from Thorsten Otto <ad...@tho-otto.de> --- Created attachment 43880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43880=edit Source file

[Bug middle-end/93092] g++ takes tremendous compilation times in var-tracking

2020-01-09 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092 --- Comment #3 from Thorsten Otto --- I can confirm that -fno-var-trackings makes situation better, but it must somehow be related to generating debug infos: $ time g++ -O2 -g -c nfosmesa_init.i real4m58.028s user4m57.749s sys

[Bug target/93192] [m68k] incorrect conversion of inf and nan in __truncxfdf2

2020-01-10 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192 --- Comment #4 from Thorsten Otto --- BTW, how do you run the testsuite for m68k?

[Bug target/93192] [m68k] incorrect conversion of inf and nan in __truncxfdf2

2020-01-10 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192 --- Comment #3 from Thorsten Otto --- Created attachment 47636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47636=edit Testcase Yes, it is attached.

[Bug libgcc/93192] New: [m68k] incorrect conversion of inf and nan in __truncxfdf2

2020-01-07 Thread ad...@tho-otto.de
Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 47606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47606=edit Suggested patch The implementation of _truncxfdf2 (l

[Bug c++/93092] New: g++ takes tremendous compilation times

2019-12-28 Thread ad...@tho-otto.de
++ Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 47558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47558=edit preprocessed version of nfosmesa_init.cpp When compiling the attached, preprocessed file with

[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts

2020-08-25 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #6 from Thorsten Otto --- Created attachment 49116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49116=edit Assembler output produced by gcc 11.0.0 for arm

[Bug target/96532] New: [m68k] gcc 10.x generates calls to memset even for very small amounts

2020-08-07 Thread ad...@tho-otto.de
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 49028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49028=edit Sample program Starting with gcc 1

[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts

2020-08-07 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #1 from Thorsten Otto --- Created attachment 49029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49029=edit Asembler output produced by gcc 10

[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts

2020-08-07 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #2 from Thorsten Otto --- Created attachment 49030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49030=edit Assembler output produced by gcc 7.1.0

[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts

2020-08-08 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #4 from Thorsten Otto --- Might be caused by x86 and s390 having a machine dependant pattern for setmem/cpymem, possibly eliminating the library call again, while other target's don't have such a pattern.