t gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 01:22 ---
Created an attachment (id=18145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18145&action=view)
a bug in -Wstrict-aliasing=3
This is an example of a flaw in -Wstrict-aliasing=
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 01:34 ---
Created an attachment (id=18146)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146&action=view)
a bug in -Wstrict-aliasing=3
This is an example of a flaw in -Wstrict-aliasing=
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:31 ---
> > extern int c;
> > int a(void)
> > {
> >return *(short *)(void *)&c;
> > }
>
> This is a very bad example of a false positive as you a
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:48 ---
"Why do you limit your stack boundary artificially?"
Because if I don't use FP code there is no point in aligning the stack.
Aligning the stack wastes stack space and code s
--- Comment #8 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 16:45 ---
> Thus code is undefined you have an acess of a char array as a struct.
> Yes you are only taking the address of an element but it is still
> considered an acess by the standards.
--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 18:07 ---
So you mean that that ->x operator is invalid and break the standard?
Anyway the standard means "if you write your code according to the standard =>
the code will run correctl
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-07 19:40 ---
So if there was char *buffer = malloc(512) instead of char buffer[512], would
it be correct to cast it to the pointer to structure?
> And it is not about the cast between the pointer ty
--- Comment #15 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 11:12 ---
The patch just walks around the problem and doesn't really fix it. It is simply
a hack that disables frame generation for long long, while for the other types
the same problem per
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 11:18 ---
In the above example, the output of assembler is:
f:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fldl8(%ebp)
fstpl (%esp)
callg
--- Comment #18 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 12:16 ---
The bug is this: you don't align the stack and you generate the frame. Why?
Why don't you do one of these?:
* generate the frame and align
* don't generate the frame and don
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet:
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:15 ---
What I would propose to fix this and bug #40667:
Each type has required alignment and preferred alignment. Enforced alignment is
what is needed to not crash and not violate the ABI, preferred
--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:19 ---
"Linux/ix86 ABI says that stack must be 16 byte aligned."
No it doesn't. There is a plenty of Linux code that doesn't have the stack
aligned on 16-byte boundary. (at lea
--- Comment #20 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:28 ---
I see, if it gets spilled to the stack as a local variable, it realigns the
stack, if it doesn't get spilled, it doesn't. But shouldn't "passing the
variable as an argum
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 13:49 ---
See bug #27537, quoting "GNU/Linux follows the SYSV x86 ABI which is
documented, maybe you cannot find it but it does exist. The SYSV x86 ABI says
the stack is aligned 4 byte aligned.&q
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 14:34 ---
So, Joseph is basically arguing that it doesn't make sense to follow bad
standards. Fine. So let's ignore the "i386 ABI standard" thing for a moment a
look at the chang
--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-23 14:36 ---
Jakub: so try that "test $15, %esp; jnz abort" at every function, as I proposed
in bug #38496. There are much more places that will trigger this. Just go catch
them.
--
http://g
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-29 17:07 ---
Created an attachment (id=18270)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18270&action=view)
A patch for the bug
A patch for the problem.
1. reverse the direc
--- Comment #11 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:00 ---
So I did this experiment whether the stack is aligned in current Linux
binaries.
I applied this patch for gcc, so that it crashes on function entry if the
function has stack not aligned on 16
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:04 ---
Created an attachment (id=18276)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18276&action=view)
Crash because gcc assumes false stack alignment
Here I'm submitting an
--- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:18 ---
Very unfortunatelly, gcc does assume stack alignment.
The problem is not technical (the code to realign the stack is already there,
it's easy to activate it), the problem is ideolo
--- Comment #14 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 13:54 ---
Jakub: And how many other "bugs" like this are there? 75% of binaries in /bin
are "buggy". Do you think it is really sensible to declare that majority of
Linux software is
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 15:22 ---
H.J. Lu: No, you only have to align the stack in functions that do 16-byte SSE.
I mean this:
there are two possible reasons for aligning the stack
1) improved performance (double, long
--- Comment #17 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 15:31 ---
"Even if we align the incoming stack properly, we still have to align the
outgoing stack to 16byte"
I'm not opposing it. What I mean is: every function will have stack fra
--- Comment #19 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 16:17 ---
(In reply to comment #18)
Yes. But not an option. Make it default and make it optional to disable the
alignment. Make it default, because such option would be useless if all
libraries didn&#
ncing
uninitialized pointers
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin do
instructions
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-06 04:12 ---
Created an attachment (id=18310)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18310&action=view)
A failing example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-06 04:15 ---
Assembler output:
f:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movq%mm0, -8(%ebp)
movq%mm1, -16(%ebp)
emms
fldla
--- Comment #21 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 10:41 ---
Hmm, it still generates the stack frame (and the alignment itself) when there
are structures containing long long and with -malign-double.
Example, compile with -O2 -fomit-frame-pointer
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 14:15 ---
(In reply to comment #22)
> It is because -malign-double will align long long to 8 byte.
Yes, it aligns it in the structures ... but why on the stack? Those people who
were writing it rea
--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-08 17:30 ---
(In reply to comment #21)
Unfortunatelly, that patch is wrong. It aligns when there is some vector type
in the function but it doesn't align if the autovectorizer creates SSE
instruc
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-09 13:39 ---
"an argument that has integer type" should really be "an argument that has
integer or pointer type" ... pointers are passed in registers too. Anything
else isn'
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzil
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-09 18:40 ---
Created an attachment (id=18331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18331&action=view)
a proposed patch. Fixed bug 41013 as well.
Change it so that all the aggregat
--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-09 21:16 ---
Regparm changed between gcc 3.x -> 4.x (I remember it too painfully, I had to
rewrite some assembler files). In 3.x, all arguments were incrementing register
count, even if they were on st
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-10 19:36 ---
Worse, try to return these structures with -freg-struct-return and it also
follows this inconsistent pattern, some are returned in EAX:EDX, some are
returned in ST(0).
It is even inconsistent
--- Comment #8 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:38 ---
Created an attachment (id=18341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18341&action=view)
A patch for -freg-struct-return
Another patch that makes -freg-struct-return con
--- Comment #9 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:40 ---
The Basic rule implemented in both patches is: when you have aggregate type,
you MUST NOT look at mode to infer parameter or return method. It is
unreliable.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 20:48 ---
Another inconsistency: struct { float f }; is returned in ST(0) in GCC and in
EAX on Windows. struct { double f }; is returned in ST(0) in GCC and in EDX:EAX
on Windows. See PR 41017 for more
--- Comment #24 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-11 21:01 ---
Another case when stack frame is spuriously generated:
/* -O2 -fomit-frame-pointer -mno-accumulate-outgoing-args */
void __attribute__((__noreturn__)) crash(__const__ char *, ...);
void F
Summary: Complilation success depends on optimization being used
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikula
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2008-03-08 04:51 ---
Created an attachment (id=15279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15279&action=view)
A testcase for the bug
A testcase for thunk functions with all calling conventi
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2008-03-08 04:55 ---
Created an attachment (id=15280)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15280&action=view)
a patch for the bug
A patch for gcc 4.3.0. When the function returns an aggregat
--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-23 19:18 ---
The patch works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
--- Comment #30 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-08-23 19:28 ---
I tested the 4.4 patch and it works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #32 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-13 13:58 ---
Created an attachment (id=18578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578&action=view)
A bug example for 4.4 patch
Shows a bug in 4.4 patch
--
http://gcc.
--- Comment #33 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-13 13:59 ---
Created an attachment (id=18579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579&action=view)
Another bug in 4.4 patch
Another bug in 4.4 patch.
--
http://gcc.gnu.org/b
--- Comment #34 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-13 14:07 ---
So I posted these two examples that show that the patch is insufficient:
1) if the array is embedded in a structure and that structure is on the stack,
the stack is not aligned. (if the array
--- Comment #39 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-20 06:30 ---
The updated patch fixes align-counterexample1.c, but not
align-counterexample2.c. Note that you must align the stack for all functions
that have some SSE operations, because you never know if
--- Comment #43 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-23 16:28 ---
With the patch from comment #41, my test examples pass but seamonkey is still
miscompiled, the function pow5mult still doesn't align the stack and spills
xmm0 on it.
--
http://gcc.gn
--- Comment #46 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-25 00:56 ---
Created an attachment (id=18646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18646&action=view)
A patch for gcc 4.4.1
I decided to make a patch on my own. Seamonkey works with
ent: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41475
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:05 ---
Created an attachment (id=18653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18653&action=view)
the first file
The first file of a two-file program. Compile with gcc -c -O3
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:06 ---
Created an attachment (id=18654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18654&action=view)
the second file
The second file. Compile with gcc -c -Os. Then, link both objec
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:14 ---
BTW. this bug is in both gcc 4.3 and 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41475
--- Comment #48 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:25 ---
It can be seen from the patch. I don't know how to detect that a structure
contains an array with required SSE align, so I realign the stack for all types
BLKmode with alignment >=
--- Comment #50 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 15:44 ---
> Please find a testcase first. Otherwise, nothing will be done. Thanks.
I don't want anything to be done (unless the patch causes generation of wrong
code --- I am not aware of s
--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 15:27 ---
Richard Guenther: the bug caused by common symbol (in file commonalign1.o) with
the same name as data section symbol (in file commonalign2.o). In this case,
the linker redirects the common
--- Comment #54 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:03 ---
(In reply to comment #51)
For 4.4, the designers held two wrong assumptions:
1) the incoming stack is always aligned on -mincoming-stack-boundary (wrong for
functions called from assembler
--- Comment #55 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:07 ---
"If we assume incoming stack is 4byte aligned, we have to realign stack for
every function due to #2, which isn't acceptable."
No, you don't. All you have to do is to allo
--- Comment #56 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:36 ---
As for this "old code that assumes 16-byte alignment": this is wrong code
generated by old versions of gcc. It only works as long as it is called from
other gcc >= 3 code (call it
--- Comment #9 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-27 09:51 ---
The common linker definitions were made to exactly to make code like this work
and share the array between two object.
So if you think it is undefined, don't support it (make -fno-c
--- Comment #58 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-10-15 20:24 ---
(In reply to comment #53)
> Created an attachment (id=18656)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656&action=view) [edit]
> An updated patch for gcc 4.4
Seamonk
--- Comment #61 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-10-16 02:10 ---
> Why should gcc align the stack when SSE registers aren't used
> at all?
Because it passes pointer to the structure containing vector entries to someone
else who expects it to
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900
ereferencing of void *
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni do
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-11-11 21:06 ---
You can dereference void * in asm arguments --- i.e.
void *p; ... asm volatile ("prefetch %0"::"m"(*p));
gcc warns in this case about the dereference and maybe it shouldn
--- Comment #6 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-11-11 23:06 ---
I think you can commit it to gcc. I don't see a reason why it shouldn't be
committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
--- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-02-15 10:34 ---
Comment #25: I don't understand your logic, what does attribute((noreturn))
have to do with a stack frame?
The only valid reasons for generating a stack frame are alloca() or needed
--- Comment #68 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-04-20 07:48 ---
gcc 4.5 is affected too. It would be nice if they fixed it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #80 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-08-17 20:17 ---
Comment #79:
-mpreferred-stack-boundary=2 adheres to the sysv ABI but it doesn't adhere to
the Linux ABI (that requires 16-byte alignment), so if you compile anything
with -mpreferred-
--- Comment #82 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-08-17 21:17 ---
-mstackrealign is available from gcc 4.5.0. For gcc 4.4 you can use my patch
GCC-4.4.1-ALIGN-PATCH from this bugzilla or H.J.Lu's last patch. It basically
does the same as -mstackrealign
--- Comment #84 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-08-25 21:27 ---
(In reply to comment #83)
If the bug is not related to stack alignment (i.e. it crashes not on unaligned
SSE access), simplify it and file another bugzilla entry.
--
http://gcc.gnu.org
--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz
2007-10-28 16:09 ---
Subject: Re: Gcc can't be compiled with -mregparm=3
> arguments the function receives. We have gen_* functions taking 0, 1, 2, 3,
> ...
> arguments and with GCC being designed
er
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: sparc64-unknown-linux-gnu
GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36781
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linu
iority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triple
--- Additional Comments From mikulas at artax dot karlin dot mff dot cuni dot cz
2004-10-19 17:32 ---
Subject: Re: Gcc doesn't check overflowed size of structure
If you rewrite it to
int main(void)
{
size_t c = sizeof(struct a);
struct a *b = malloc(c);
r
84 matches
Mail list logo
