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 bel
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&action=edit
non-working example
Find attached an example for which -Wconversion behaves uncompreh
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 to
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, I
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 seem
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&action=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&action=edit
C sour
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 is
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 attri
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 st
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 to
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 tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #31 from Sven ---
https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log&pathrev=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
addit
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? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #24 from Sven ---
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 increase the alignment". It goes on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #23 from Sven ---
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 guarantees. Clearly, I agree with c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133
--- Comment #3 from Sven ---
(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 ---
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 the divided syntax is used for olde
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
24 matches
Mail list logo
