This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible Bug


On Mon, Mar 28, 2011 at 3:36 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 03/28/2011 02:27 PM, Michael Matz wrote:
>>>>
>>>> ? <mem_ref 0x7ffff7ff9118
>>>> ? ? ?type<record_type 0x7ffff5b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
>>>> ? ? ? ? ?size<integer_cst 0x7ffff5b256b8 constant 48>
>>>> ? ? ? ? ?unit size<integer_cst 0x7ffff5b25708 constant 6>
>>>> ? ? ? ? ?align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540
>>>>
>>>> which looks ok to me.
>>>
>>> It already isn't, why is the alignment 8 if __alignof__
>>> (GENOME_LOC_TYPE_2) is 1?
>>
>> The aligns are printed in bits. ?It really is okay, as is the MEM.
>
> Uff, I'm always confused by align being printed after the unit size.
>
>> As some digging shows, already GCC 1.35 had effectively the same code.
>> As soon as parameters are passed in registers GCC loads the parts fitting
>> into registers as full words. ?We could simply sorry() for these cases, as
>> they never worked correctly. ?Though I suppose that's quite unforgiving,
>> as most of the time (struct in question not passing page border) it works
>> fine.
>
> We should warn, I think.

We should fix the bug ;)

Richard.

> Paolo
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]