This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

[PATCH] Fix Fortran aliasing problem with EQUIVALENCE


Hi!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518#c1 testcase is miscompiled
with GCC 4.1 and trunk at least on i?86 and x86_64 with -O2.
The scheduler swaps write into DMACH(1) with read from SMALL(1):

(insn 616 22 617 3 (set (reg:DI 1 dx)
        (const_int 4801453603149578240 [0x42a2309ce5400000])) 81 {*movdi_1_rex64} (nil)
    (nil))

(insn 617 616 26 3 (set (mem/s:DI (symbol_ref:DI ("equiv.0.1269") [flags 0x2] <var_decl 0x2b68b516cb00 equiv.0>) [9 equiv.0.dmach+0 S8 A64])
        (reg:DI 1 dx)) 81 {*movdi_1_rex64} (nil)
    (expr_list:REG_DEAD (reg:DI 1 dx)
        (nil)))

(insn:HI 26 617 27 3 (set (reg:SI 0 ax [orig:76 D.1316 ] [76])
        (mem/s:SI (symbol_ref:DI ("equiv.0.1269") [flags 0x2] <var_decl 0x2b68b516cb00 equiv.0>) [2 equiv.0.small+0 S4 A64])) 40 {*movsi_1} (nil)
    (nil))

becomes after sched2 pass:

(insn:TI 26 22 616 3 (set (reg:SI 0 ax [orig:76 D.1316 ] [76])
        (mem/s:SI (symbol_ref:DI ("equiv.0.1269") [flags 0x2] <var_decl 0x2b68b516cb00 equiv.0>) [2 equiv.0.small+0 S4 A64])) 40 {*movsi_1} (nil)
    (nil))

(insn 616 26 617 3 (set (reg:DI 1 dx)
        (const_int 4801453603149578240 [0x42a2309ce5400000])) 81 {*movdi_1_rex64} (nil)
    (nil))

(insn:TI 617 616 27 3 (set (mem/s:DI (symbol_ref:DI ("equiv.0.1269") [flags 0x2] <var_decl 0x2b68b516cb00 equiv.0>) [9 equiv.0.dmach+0 S8 A64])
        (reg:DI 1 dx)) 81 {*movdi_1_rex64} (nil)
    (expr_list:REG_DEAD (reg:DI 1 dx)
        (nil)))

That's because equiv.0.dmach and equiv.0.small use different alias sets (2
vs. 9).  C/C++ in this case uses alias set 0 and I think Fortran should do
the same.  If it is a component access through UNION_TYPE in Fortran, we
know it is either access to EQUIVALENCEd variable (which can't have POINTER
attribute nor be a CRAY POINTEE fortunately), or mixed entry master return
value.  In both cases we want to allow type-punning.

Ok for trunk (and obviously modified patch for 4.1)?

I'm not including a testcase, because I don't know if we can put netlib
code in gcc testsuite and I haven't managed to distill a smaller testcase
from it (as it is scheduling related, so highly sensitive to the content of
the whole function).

	Jakub

Attachment: PP
Description: Text document


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