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&action=edit
Sample program
Starting with gcc 10
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&action=edit
Asembler output produced by gcc 10
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&action=edit
Assembler output produced by gcc 7.1.0
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.
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&action=edit
Assembler output produced by gcc 11.0.0 for arm
++
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&action=edit
preprocessed version of nfosmesa_init.cpp
When compiling the attached, preprocessed fi
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&action=edit
Suggested patch
The implementation of _tru
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 0m0.28
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&action=edit
Testcase
Yes, it is attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #4 from Thorsten Otto ---
BTW, how do you run the testsuite for m68k?
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #1 from Thorsten Otto ---
Created attachment 43879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43879&action=edit
header file marked as system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #2 from Thorsten Otto ---
Created attachment 43880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43880&action=edit
Source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85290
--- Comment #3 from Thorsten Otto ---
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 -Wdeclaration-after-statement, no
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.
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&action=edit
bla.c
When compiling the attached, small test program with
m68k-elf-gcc -O2
16 matches
Mail list logo