--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-03 22:32
---
The issue is in a very twisted piece of GCC where the chances to break sth are
bigger that to fix sth ;)
And it isn't a regression, so it's not on too many peoples radar (nor does
it seem to happen in practice and
--- Comment #14 from matt at use dot net 2010-01-03 20:30 ---
Still happening on 4.5.0 20091228 (and gcc 4.4.1) on Ubuntu 9.10/amd64). I
found that it goes away in 3 separate instances when turning on
-finline-functions. The last 2 instances of memory corruption I am running into
are fun
--- Comment #13 from a dot heider at gmail dot com 2009-09-15 21:54 ---
Still present on a recent GCC snapshot:
Johannes' Code compiled with "(Ubuntu 20090912-1ubuntu2) 4.5.0 20090912
(experimental) [trunk revision 151650]" and -O0 -DTEST_SIZE=5:
subq$16, %rsp
movq
--- Comment #12 from lordhoto at gmail dot com 2009-09-15 21:24 ---
Happens for me too on Linux/AMD64 with:
gcc (Debian 4.3.4-2) 4.3.4
and
gcc (Debian 4.4.1-4) 4.4.1
It also happens with structs of sizes 3, 5 and 7 for me.
An easy (non-runtime) test case for different struct sizes c
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-03-18 09:11
---
Still broken on the trunk as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from eric dot rannaud at gmail dot com 2009-03-17 22:48
---
Witnessed in g++ 4.3.2
g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
--
eric dot rannaud at gmail dot com changed:
What|Removed |Added
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-25 16:20 ---
Index: calls.c
===
--- calls.c (revision 134659)
+++ calls.c (working copy)
@@ -2708,7 +2708,7 @@ expand_call (tree exp, rtx target, int i
--- Comment #8 from matz at gcc dot gnu dot org 2008-04-25 16:15 ---
FWIW, I think the error is in the caller of move_block_to_reg.
move_block_to_reg can make use of a load_multiple instruction, which really
loads full regs. I.e. it would be unreasonable to require changes in
move_bloc
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-25 15:43 ---
So, the problem is in move_block_to_reg that copies the argument piecewise
to regs like
for (i = 0; i < nregs; i++)
emit_move_insn (gen_rtx_REG (word_mode, regno + i),
operand_subword_force
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-25 15:29 ---
Errm. change_address_1 simply builds a DImode mem (with alignment
info properly retained)
#0 0x005e80c2 in adjust_address_1 (memref=0x2b0751d81520,
mode=DImode, offset=0, validate=0, adjust=1)
at
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 15:17 ---
Forget that. load_register_parameters converts
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
to
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
here:
else if (partial == 0 || args[i].pass_on_stack)
--- Comment #4 from matz at gcc dot gnu dot org 2008-04-25 15:12 ---
That's the layout of 'c', a pointer variable. We don't see the layout
of the record_type here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-25 15:08 ---
The problem is that struct colour is laid out like
arg 0
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x2b4f85160780>
used u
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 14:59 ---
Ahm, not exactly a dup of PR31309.
Shorter (non-runtime) testcase:
struct colour
{
unsigned short red;
unsigned short green;
unsigned short blue;
};
void print_colour(struct colour col);
void foo(struct col
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-25 14:55 ---
Hmm, didn't we fix this? ...
movw$115, (%rax)
movw$122, 2(%rax)
movw$98, 4(%rax)
movq(%rax), %rdi
callprint_colour
--
rguenth at gcc dot gnu dot org ch
15 matches
Mail list logo
