https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115875
--- Comment #2 from Denis Vlasenko ---
0xUL works, although it uses
b8 ff ff ff ff mov$0x,%eax
instead of
83 c8 ffor $0x,%eax
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vda.linux at googlemail dot com
Target Milestone: ---
void sp_256_sub_8_p256_mod(unsigned long *r)
{
unsigned long reg, ooff;
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/ml/gcc
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.
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 -finsert-stop-insn-when-un
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(%rdi),%
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&action=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" and
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&action=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;
ty
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 __attri
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;
__extens
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 ---
(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), pack them into that size
> if t
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #10 from Denis Vlasenko ---
(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__ attribute. Otherwise, inline
> keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #8 from Denis Vlasenko ---
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 mention it before, but the recen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #6 from Denis Vlasenko ---
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/kernel_config2
Note that "CONFIG_CC_OPTIMIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65740
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #3 from Denis Vlasenko ---
Created attachment 35530
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35530&action=edit
Preprocessed example exhibiting a bug on gcc -4.9.2
This is a preprocessed kernel/pid.c file from kernel sourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #2 from Denis Vlasenko ---
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 | grep -iF ' t ' | uniq -c | grep -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #1 from Denis Vlasenko ---
Created attachment 35528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35528&action=edit
Preprocessed example exhibiting a bug
This is a preprocessed kernel/locking/mutex.c file from kernel source.
W
: 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
Severity: normal
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&q
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #11 from Denis Vlasenko
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 regresses very much (IRA ...), the
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21141
--- Comment #10 from Denis Vlasenko
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=21141
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
--- Comment #16 from Denis Vlasenko
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 section.
I re-ran the tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #8 from Denis Vlasenko 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 a bit, still not as good as gcc-3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
Denis Vlasenko changed:
What|Removed |Added
CC||vda.linux at googlemail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182
--- Comment #6 from Denis Vlasenko 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 with different gcc
versions
Tarball
41 matches
Mail list logo
