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
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.
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 <ad...@tho-otto.de> ---
Created attachment 43879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43879=edit
header file marked as system header
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93192
--- Comment #4 from Thorsten Otto ---
BTW, how do you run the testsuite for m68k?
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.
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
++
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
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
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
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
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
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.
16 matches
Mail list logo