Jaka Močnik <j...@xlab.si> writes: > 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.
Yes. Thanks for the explanation. > 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 ... Assuming you have a copyright assignment, just send a patch to gcc-patches with the explanation. This is code which will never be used for any popular target. Ian
