Dne 10.02.2009 (tor) ob 17:14 -0800 je Ian Lance Taylor zapisal(a): > I don't quite see it. highest_outgoing_args_in_use is at least as large > as args_size.constant, and that counts the locate.size for each > argument. So it should always include the extra padding. > > That said, it would not be shocking if there were a bug in this code. > It's not particularly common to use emit_library_call_value_1 with code > that passes parameters on the stack. And it's even less common to use > it with parameters that require padding when they are pushed on the > stack. So a miscalculation in such a scenario could survive for quite > along time. consider stack slots of 8 bytes, two parameters, one 8-byte, one 4-byte (padded below), all arranged on the stack like this (low addresses at the bottom):
16 8 [ P2 ] 0 [ P1 ] P1: offset = slot_offset = 0, size = 8 P2: offset = 12, slot_offset = 8, size = 8 highest_outgoing_args_in_use = 16 (sum of sizes) buffer is allocated 16 bytes. lower bound for P2 is 12 (P2.offset). upper bound for P2 is 20 (12 + 8). the loop indexes interval [12, 20) of the buffer, but only 16 bytes were allocated. hopefully this clarifies the issue. that said, this probably belongs to gcc bugzilla: I don't have an exact way to reproduce it with a mainline gcc version, though, as I haven't really tried other targets, while mine is well ... not merged in the mainline ... regards, jaKa -- email: j...@xlab.si w3: http://www.gmajna.net/svojat/jaka
