This is the mail archive of the gcc-bugs@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]

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90



------- Comment #8 from jamborm at gcc dot gnu dot org  2010-09-17 15:08 -------
(In reply to comment #7)
> 
> The added MEM = SR.1_10 uses location_t of the stmt after it, as
> sra_modify_expr
> emits statements before gsi.  I'm arguing that in this case the MEM[(struct S
> *)&D.2694] = SR.1_10; stmt is not related to return D.2694, but to D.2694 = s
> that has been removed and thus I believe it should inherit its locus as well.
> 

Unfortunately no, the statement SR.1_10 = s$a_8; is produced when
replacing the original assignment, MEM[(struct S *)&D.2694] = SR.1_10;
is created when processing the return statement, it is updating the
original agregate D.2694 with data in its replacements (in this case
there is only one but there can be more) before it is used as a whole.
I can't see how it could be otherwise.

It would be difficult also to set the location of the MEM_REF
statement according to the definition of its RHS because when the
statement is built the RHS is not yet in SSA form.

Thinking about it more, the RHS in that statement, SR.1_10 has its
TREE_NO_WARNING set and so that line should not be a problem at this
stage.  So I guess s$a_8 is propagated there at some point later.
Perhaps the fwprop could change the location when it substitutes an
operand in situations like this?  I know it would be a bit ugly but
doing the same in SRA would require some aggregate data flow analysis
which would be quite hard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505


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