[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 05:13 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-23 05:15 --- Subject: Bug 29410 Author: pinskia Date: Tue Jan 23 05:15:21 2007 New Revision: 121076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121076 Log: 2007-01-22 Andrew Pinski [EMAIL PROTECTED] PR fortran/29951 * gfortran.fortran-torture/execute/transfer2.f90: New test. PR Fortran/29410 * gfortran.fortran-torture/execute/transfer1.f90: New test. 2007-01-22 Andrew Pinski [EMAIL PROTECTED] PR fortran/29951 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Change to call memcpy instead of creating a VIEW_CONVERT_EXRP. PR fortran/29410 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Change over to create VIEW_CONVERT_EXPR instead of using an ADDR_EXPR, a cast and then an indirect reference. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/execute/transfer1.f90 - copied unchanged from r118186, trunk/gcc/testsuite/gfortran.fortran-torture/execute/transfer1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/execute/transfer2.f90 - copied unchanged from r119211, trunk/gcc/testsuite/gfortran.fortran-torture/execute/transfer2.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #11 from pinskia at gmail dot com 2007-01-22 01:08 --- Subject: Re: [4.2 only] bug with TRANSFER() and -O2 On Sun, 2007-01-14 at 11:19 +, pault at gcc dot gnu dot org wrote: Were you going to apply this to 4.2, together with revision 119211, or will you close them as fixed on 4.3? I am going to test it for 4.2 once I finish testing an objective-C patch. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #10 from pault at gcc dot gnu dot org 2007-01-14 11:19 --- (In reply to comment #9) It turns out my fix caused PR 29951 which I am testing a fix for PR 29951 now. My new patch does not break this testcase which is a good sign. Andrew, Were you going to apply this to 4.2, together with revision 119211, or will you close them as fixed on 4.3? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-24 22:48 --- It turns out my fix caused PR 29951 which I am testing a fix for PR 29951 now. My new patch does not break this testcase which is a good sign. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29951 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-12 01:31 --- Actually it turns out using VIEW_CONVERT_EXPR is ok and works correctly as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|bug with TRANSFER() and -O2 |[4.2 only] bug with ||TRANSFER() and -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
[Bug fortran/29410] [4.2 only] bug with TRANSFER() and -O2
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-07 19:34 --- apinski hi apinski PaulT: VCE means *(type*)a without the need for addressable and does not confuse aliasing PaulT apinski: Hi, yes I answered the question myself - I missed it in tree.def by only looking in tree.h apinski PaulT: this is mention in tree.def :) PaulT apinski: It's undefined if the types have different lengths? apinski yes apinski actually is transfer ok for different size types? PaulT Yes, I was just racing for the standard. apinski ok apinski I guess I have to change my patch then apinski to include a size comparision apinski The physical representation of the result is the same as SOURCE, truncated if the result is smaller or with an undefined trailing portion if the result is larger. apinski that is from IBM's docs about transfer PaulT apinski: Gee, yes. I missed that completely. apinski I can improve the truncated part also PaulT If I change the integers in your example to integer(8), I get a core dump. apinski during running? PaulT g95 and ifort do the right thing. PaulT Shucks, I'm sorry about that Andrew, I missed it completely. apinski I figured it was going to be wrong apinski lucky I only applied to the mainline :) apinski can you write something in the bug report so I don't forget to fix it this weekend? PaulT apinski: I keep telling people that that is what it is for! PaulT apinski: Sure thing - I suppose that you can safely do a kind conversion? apinski I know how to fix this correctly now apinski use __builtin_memcpy and hope that gets optimized correctly in the future :) PaulT apinski: make type of the same length as source, so that the assignment does the rest? apinski no apinski PaulT: do memcpy (dst, src, min(size1, size0)) PaulT apinski: No... you're right that won't present a bit-wise transfer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29410
