This is the mail archive of the gcc-patches@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] |
On Tue, Jun 9, 2015 at 6:21 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Tue, Jun 09, 2015 at 06:16:32PM +0200, Uros Bizjak wrote: >> > something? Would it be acceptable to just guard the changes in the patch >> > with !TARGET_X32 and let H.J. deal with that target? I'm afraid I'm lost >> > when to ZERO_EXTEND addr (if needed at all), etc. >> >> If you wish, I can take your patch and take if further. -mx32 is a >> delicate beast... > > If you could, it would be appreciated, I'm quite busy with OpenMP 4.1 stuff > now. > Note that for -m64/-mx32 it will be much harder to create a reproducer, > because to trigger the bug one has to convince the register allocator > to allocate the lhs of the load in certain registers (not that hard), > but also the index register (to be scaled, also not that hard) and > also the register holding the tls symbol immediate. Wonder if one has to > keep all but the two registers live across the load or something similar. Please find attach a patch that takes your idea slightly further. We find perhaps zero-extended UNSPEC_TP, and copy it for further use. At its place, we simply slap const0_rtx. We know that address to multi-word values has to be offsettable, which in case of x32 means that it is NOT zero-extended address. Uros.
Attachment:
r.diff.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |