https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100320
--- Comment #2 from Denis Vlasenko ---
The relevant code in current git seems to be:
static void
expand_set_or_cpymem_via_rep (rtx destmem, rtx srcmem,
rtx destptr, rtx srcptr, rtx value, rtx orig_value,
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
Bug 21329 has returned.
32-bit x86 memory block moves are using "movl $LEN,%ecx; rep movsl" insns.
However, for fixed short blocks it is more efficient to just re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45996
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #7 from Denis Vlasenko ---
Patch v8
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00792.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00793.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00794.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #6 from Denis Vlasenko ---
Patches v7 are posted:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00720.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00721.html
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00722.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
--- Comment #4 from Denis Vlasenko ---
This confuses object code sanity analysis tools which check that every function
ends "properly", i.e. with a return or jump (possibly padded with nops).
Can gcc get an option like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
--- Comment #2 from Denis Vlasenko ---
Without -fsanitize-coverage=trace-pc, the second, redundant check
"snic->wq_count<=1?" is not generated. This eliminates the hanging "impossible"
code path:
:
0: 8b 07 mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #5 from Denis Vlasenko ---
Patches v3 posted to the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02073.html
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02074.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
--- Comment #18 from Denis Vlasenko ---
Created attachment 38297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38297=edit
Comparison of generated code with 7.0.0.svn on i86
With div cost of 3:
:
- 0: 8b 44 24 04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
--- Comment #17 from Denis Vlasenko ---
Any chance of this being finally done?
I proposed a simple, working patch in 2007, it's 2016 now and all these years
users of -Os suffer from slow divisions in important cases usch as "signed_int
/ 16"
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
$ cat bad.c
unsigned ud_x_641_mul(unsigned x) {
/* optimized version of x / 641 */
return ((unsigned long long)x * 0x663d81) >> 32;
}
With gcc from current svn:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #4 from Denis Vlasenko ---
Created attachment 38293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38293=edit
Proposed patch
This patch implements -falign-functions=N[,M] for now, with the eye for easy
extension to other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
--- Comment #7 from Denis Vlasenko ---
Fixed at least in 4.7.2, maybe earlier. With -m32 -fomit-frame-pointer -O2:
a: movzbl v+45, %eax
xorbv+36, %al
xorbv, %al
xorbv+54, %al
xorbv+63, %al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #6 from Denis Vlasenko ---
I can collapse the chain of inlines down to this and still see the bug.
Removing "__attribute__((always_inline))", or merging __swab64p() and
wwn_to_u64(), makes bug disappear.
typedef unsigned char u8;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #5 from Denis Vlasenko ---
Even smaller reproducer.
Bug disappears if "__attribute__((always_inline))" is removed everywhere.
typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
static inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #4 from Denis Vlasenko ---
Shorter reproducer:
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
--- Comment #2 from Denis Vlasenko vda.linux at googlemail dot com ---
(In reply to Josh Triplett from comment #1)
Another alternative discussed in that thread, which seems near-ideal: align
functions to a given size (for instance, 64 bytes
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
Experimentally, compilation with
-O2 -falign-functions=17 -falign-loops=17 -falign-jumps=17 -falign-labels=17
results in the following:
- functions are aligned using .p2align 5,,16 asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #10 from Denis Vlasenko vda.linux at googlemail dot com ---
(In reply to Jakub Jelinek from comment #9)
If you expect that all functions with inline keyword must be always inlined,
then you really should use __always_inline__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #8 from Denis Vlasenko vda.linux at googlemail dot com ---
If you try to reproduce this with kernel build, be sure to not select
CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions
__always_inline).
I didn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #6 from Denis Vlasenko vda.linux at googlemail dot com ---
Got a hold on a machine with gcc version 5.1.1 20150422 (Red Hat 5.1.1-1)
Pulled current Linus kernel tree and built it with this config:
http://busybox.net/~vda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #2 from Denis Vlasenko vda.linux at googlemail dot com ---
Tested with gcc-4.9.2. The attached testcase doesn't exhibit the bug, but
compiling the same kernel tree, with the same .config, and then running
nm --size-sort vmlinux
: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
On linux kernel build, I found thousands of cases where functions which are
expected (by programmer) to be inlined, aren't actually inlined.
The following script is used to find them:
nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #3 from Denis Vlasenko vda.linux at googlemail dot com ---
Created attachment 35530
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35530action=edit
Preprocessed example exhibiting a bug on gcc -4.9.2
This is a preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #1 from Denis Vlasenko vda.linux at googlemail dot com ---
Created attachment 35528
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35528action=edit
Preprocessed example exhibiting a bug
This is a preprocessed kernel/locking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65740
Denis Vlasenko vda.linux at googlemail dot com changed:
What|Removed |Added
CC
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
void f(char *);
void g() {
char buf[12] = 1234567890;
f(buf);
}
In the above example, gcc -O2 creates buf[12] with immediate stores
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
void put_16bit(unsigned short v);
void put_32bit(unsigned v)
{
put_16bit(v);
put_16bit(v 16);
}
With gcc 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Denis Vlasenko vda.linux at googlemail dot com changed:
What|Removed |Added
CC||vda.linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #11 from Denis Vlasenko vda.linux at googlemail dot com
2013-01-20 14:39:42 UTC ---
(In reply to comment #10)
4.4.7 and 4.5.4 generate the same code (no stack use) for -D/-UNAIL_REGS.
With 4.6.3, the -DNAIL_REGS code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
--- Comment #16 from Denis Vlasenko vda.linux at googlemail dot com
2013-01-18 10:29:12 UTC ---
(In reply to comment #15)
Honza, did you find time to have a look?
I think this regressed alot in 4.6
Not really - it's just .eh_frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
Denis Vlasenko vda.linux at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21141
Denis Vlasenko vda.linux at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21141
--- Comment #10 from Denis Vlasenko vda.linux at googlemail dot com
2013-01-18 16:03:37 UTC ---
BTW, testcase needs a small fix:
-static const u64 C0[256];
+u64 C0[256];
or else gcc with optimize it almost to nothing :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #6 from Denis Vlasenko vda.linux at googlemail dot com 2013-01-18
00:48:23 UTC ---
Created attachment 29200
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29200
Updated testcase, build heper, and results of testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
Denis Vlasenko vda.linux at googlemail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #8 from Denis Vlasenko vda.linux at googlemail dot com 2013-01-18
00:55:37 UTC ---
Grrr, another mistake. Correcting again:
Conclusion:
gcc-3.4.3 -O3 was close to ideal.
^
gcc-4.2.1 is worse.
gcc-4.6.3 got better
39 matches
Mail list logo
