[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-12-21 Thread mikael at gcc dot gnu dot org 


--- Comment #4 from mikael at gcc dot gnu dot org  2008-12-21 15:07 ---
Subject: Bug 35983

Author: mikael
Date: Sun Dec 21 15:06:15 2008
New Revision: 142860

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142860
Log:
2008-12-21  Mikael Morin  mikael.mo...@tele2.fr

PR fortran/35983
* trans-expr.c (gfc_trans_subcomponent_assign):
Add se's pre and post blocks to current block.
(gfc_trans_structure_assign): Remove specific handling
of C_NULL_PTR and C_NULL_FUNPTR.

2008-12-21  Mikael Morin  mikael.mo...@tele2.fr

PR fortran/35983
* gfortran.dg/pr35983.f90: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pr35983.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-12-21 Thread mikael at gcc dot gnu dot org 


--- Comment #5 from mikael at gcc dot gnu dot org  2008-12-21 15:10 ---
Fixed on trunk(4.4) and 4.3.
Thanks for the report.


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-12-09 Thread mikael at gcc dot gnu dot org 


--- Comment #3 from mikael at gcc dot gnu dot org  2008-12-09 19:13 ---
Subject: Bug 35983

Author: mikael
Date: Tue Dec  9 19:12:27 2008
New Revision: 142605

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142605
Log:
2008-12-09  Mikael Morin  [EMAIL PROTECTED]

PR fortran/35983
* trans-expr.c (gfc_trans_subcomponent_assign):
Add se's pre and post blocks to current block.
(gfc_trans_structure_assign): Remove specific handling
of C_NULL_PTR and C_NULL_FUNPTR.

2008-12-09  Mikael Morin  [EMAIL PROTECTED]

PR fortran/35983
* gfortran.dg/pr35983.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr35983.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-12-09 Thread mikael at gcc dot gnu dot org 


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-20 11:40:52 |2008-12-09 19:32:41
   date||
   Target Milestone|--- |4.4.0


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-11-05 Thread mikael dot morin at tele2 dot fr 


--- Comment #2 from mikael dot morin at tele2 dot fr  2008-11-05 11:43 
---
There is a reset of the expression to NULL_EXPR in case we encounter c_null_ptr
or c_null_funptr. 
However, the if conditions for this relies on the is_iso_c attribute, which is
the case of c_loc. 
This patch changes this behavior by relying on the symtree names instead. 

Index: trans-expr.c
===
--- trans-expr.c(révision 141583)
+++ trans-expr.c(copie de travail)
@@ -3689,15 +3682,16 @@ gfc_trans_structure_assign (tree dest, gfc_expr *
 {
   /* Skip absent members in default initializers.  */
   if (!c-expr)
-continue;
+   continue;

   /* Update the type/kind of the expression if it represents either
 C_NULL_PTR or C_NULL_FUNPTR.  This is done here because this may
 be the first place reached for initializing output variables that
 have components of type C_PTR/C_FUNPTR that are initialized.  */
-  if (c-expr-ts.type == BT_DERIVED  c-expr-ts.derived
-  c-expr-ts.derived-attr.is_iso_c)
-{
+  if (c-expr-symtree  c-expr-symtree-name
+  (!strcmp (c_null_ptr, c-expr-symtree-name)
+ || !strcmp (c_null_funptr, c-expr-symtree-name)))
+   {
  c-expr-expr_type = EXPR_NULL;
  c-expr-ts.type = c-expr-ts.derived-ts.type;
  c-expr-ts.f90_type = c-expr-ts.derived-ts.f90_type;

With this patch alone, I still get wrong-code though (pointer uninitialized
instead of nullified). 
I've had to revert this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150#c7
to have it working. 

There is only one regression, c_loc_tests_12.f03. 
That one is expected, and we are back at PR35150. 
I looked at that one too, but I must admit I'm at least as confused as FX when
he fixed it. 
If some middle-end gurus could take a look/give some tips there...


-- 


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

2008-04-20 Thread burnus at gcc dot gnu dot org 


--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-20 11:40 ---
Confirm. While for
   type(c_ptr) :: cptr
   cptr = c_loc(buf)

the dump is:
  void * D.910;
  D.910 = (void *) buf;
  dd.address = D.910;

Your structure constructor,  DD = descr(c_loc(buf)),  gives:
  struct descr descr.2;
  descr.2.address = 0B;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 11:40:52
   date||


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