https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101973
Sven changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
On Intel x86_64, the generated code for __builtin_clz(x) looks something like
this: clz(x) = 63 - bsr(x)
Since Intel does not seem to have a way to do 63-y in a single
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
With gcc 11.1 on ARM 32-bit and Intel, I don't see that __builtin_clrsb is
inlined. On AARCH64 it is inlined and the cls instruction is used, as expected.
I use the C-code below
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
Created attachment 49559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49559=edit
non-working example
Find attached an example for which -Wconversion behaves uncomprehensible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
--- Comment #3 from Sven ---
I'm not sure how you optimize the uninit use away. When running the example,
the first printf typically yields a random value. So the uninitialized value is
certainly used as a return value.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
Consider the following code:
int test53(int y) {
int z;
for (int x=0; x<10; x=x+1,y=y+1,z=z+1) {
if (y<10) {
co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48429
--- Comment #2 from Sven ---
Even 8 years later, this bug is not fixed (gcc 8.3). I believe clang/llvm has
the same problem.
Anyhow, that's not the only problem. The moment that a function is called,
registers r0 to r3 (and maybe others) have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69502
--- Comment #5 from Sven ---
(In reply to sandra from comment #4)
> Fixed on trunk.
It's good thing that the documentation reflects the behavior of gcc.
But on the other hand, having the align attribute work in both directions is a
bad idea,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #3 from Sven ---
I'm not familiar with GCC internals. So my following comments may be completely
off.
This has been classified as a "missed optimization". I would not expect the
optimizer to change 4 ldrb into a single ldr. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #1 from Sven ---
Created attachment 44548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44548=edit
the generated assembler code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
Target Milestone: ---
Created attachment 44547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44547=edit
C source c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #50 from Sven ---
(In reply to Sven from comment #49)
> This doesn't work. The aligned attribute is for providing additional
> alignment hints. The GCC documentation clearly states, that aligned can
> increase the alignment. So g_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #49 from Sven ---
(In reply to W.H. Ding from comment #47)
> Hi, everyone
>
> I wonder if this issue has to do with the bug-like problem I encountered
> when accessing an unaligned stand-alone global variable (rather than a
> member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #44 from Sven ---
(In reply to Alexey Salmin from comment #42)
> typedef struct unaligned_int128_t_ {
> __int128_t value;
> } __attribute__((packed)) unaligned_int128_t;
You can combine the packed attribute with the aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #41 from Sven ---
(In reply to Alexey Salmin from comment #39)
> .. when the packed attribute is preserved in the pointer.
What do you mean by that? GCC documentation explicitly forbids to use the
packed attribute for anything but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #35 from Sven ---
(In reply to Sven from comment #34)
> That is to be
> expected, hence gcc should warn about the fact, and the address of a
> (potentially) unaligned int is assigned to a regular int* pointer.
Sorry, typo:
That is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #34 from Sven ---
(In reply to H.J. Lu from comment #32)
> long long is aligned to 4 bytes in struct for i386.
Understood. So the aligned(4) was just added to explicitly restating the
alignment?
Anyhow, the two warnings added by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #31 from Sven ---
https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log=251180
I am reading the commit message, and the example doesn't make any sense.
The aligned attribute is for providing additional alignment guarantees in
addition to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #28 from Sven ---
(In reply to Eric Gallager from comment #27)
> gcc 8 adds -Wpacked-not-aligned; does that fix this bug?
I couldn't find documentation on what this switch is supposed to do. Can you
point me in the right direction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #23 from Sven sven.koehler at gmail dot com ---
FYI: I have asked the llvm folks to add a warning to their compiler for the
when a pointer to a member of a packed struct is assigned to an ordinary
pointer with higher alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #24 from Sven sven.koehler at gmail dot com ---
Comment #4 mentions typedef int myint __attribute__((aligned(1)));
That shouldn't even work. The GCC documentation on Type Attributes mentions
that The aligned attribute can only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133
--- Comment #3 from Sven sven.koehler at gmail dot com ---
(In reply to Richard Earnshaw from comment #2)
This is a known issue.
So what needs to be done? Where do I find the source/configuration/whatever of
the code generator for thumb mode?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133
--- Comment #1 from Sven sven.koehler at gmail dot com ---
It seems, that for targets like -mcpu=cortex-m4 the gcc does generate unified
syntax. So is the unified syntax only used for newer targets that use the
thumb2 instruction set whereas
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.koehler at gmail dot com
I'm not aware of any command line switch to make gcc generate unified syntax.
The asm code that gcc generated in thumb mode follows the old devided syntax.
All
24 matches
Mail list logo
