Messages in this thread |  | | Subject | Re: ALERT! Stay away from patched gcc's (was Re: 2.0.22 will be the last version) | From | Steven L Baur <> | Date | 30 Sep 1996 10:05:05 -0700 |
| |
>>>>> "Linus" == Linus Torvalds <torvalds@cc.helsinki.fi> writes:
Linus> As some people have asked me how the bad code actually looks Linus> like, I'm posting a short description of what happe with the Linus> bad gcc version.
Thank you, Bwana.
Linus> The problem is that this bad gcc doesn't take this into Linus> account, the code produced in sd_init_onedisk looks like this: ... Linus> ... Linus> call scsi_do_cmd Linus> addl $0x1c,%esp Linus> movl 16(%esp),%ecx Linus> movl 16(%esp),%eax
Linus> /* down operation starts here */ Linus> movl $0x18d9dc,%eax Linus> decl (%eax) Linus> js 0x19bfa0 <down_failed> Linus> /* end of down operations */
Linus> movl 0xf0(%edi),%esi Linus> incl %ebx Linus> testl %esi,%esi Linus> je sd_init_onedisk+633 Linus> movb 0x8a(%edi),%dl Linus> ...
I apologize for not understanding your explanation.
Are you saying that if the output doesn't look like that, the GCC is O.K.? Or just that the `decl (%eax)' is where the badness lies?
This is what my GCC 2.7.2 with a no-sr-bug patch produces (from 2.0.21 for i486):
call scsi_do_cmd addl $28,%esp movl %ebx,%ecx #APP # atomic down operation 1: movl $1b,%eax decl (%ebx) js down_failed #NO_APP movl 240(%ebp),%edi movl %edi,20(%esp) decl %esi testl %edi,%edi je .L1721 testl %esi,%esi jne .L1720
-- steve@miranova.com baur Unsolicited commercial e-mail will be billed at $250/message. What are the last two letters of "doesn't" and "can't"? Coincidence? I think not.
|  |