Bug 34246 - gfortran.dg/bind_c_usage_16.f03 doesn't work
Summary: gfortran.dg/bind_c_usage_16.f03 doesn't work
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, wrong-code
Depends on: 34079
Blocks: 32630
  Show dependency treegraph
 
Reported: 2007-11-27 12:05 UTC by H.J. Lu
Modified: 2007-12-16 20:37 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-11-27 12:19:54


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2007-11-27 12:05:09 UTC
From

http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01452.html

FAIL: gfortran.dg/bind_c_usage_16.f03  -O0  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O1  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O2  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O3 -fomit-frame-pointer -funroll-loops  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -O3 -g  execution test
FAIL: gfortran.dg/bind_c_usage_16.f03  -Os  execution test
Comment 1 Tobias Burnus 2007-11-27 12:19:54 UTC
Works on x86-64 with -m64, but fails with -m32.
Comment 2 Tobias Burnus 2007-11-27 12:38:55 UTC
Valgrind finds:
==26293== Use of uninitialised value of size 4
==26293==    at 0x80485D5: returnA (bind_c_usage_16.f03:14)

==26293==  Bad permissions for mapped region at address 0x8048B10
==26293==    at 0x80485C1: returnB (bind_c_usage_16.f03:17)

gimple dump (excerpt): The following <retval> looks a bit odd, but maybe I'm just not used to gimple:

--- bind_c_usage_16.f03.m32gimp
+++ bind_c_usage_16.f03.m64gimp
+  character(kind=1) D.864[1:1];
   character(kind=1) __result_foo[1:1];
   __result_foo[1]{lb: 1 sz: 1} = 66;
-  <retval> = __result_foo;
-  return <retval>;
+  D.864 = __result_foo;
+  return D.864;
Comment 3 Dominique d'Humieres 2007-11-27 20:49:54 UTC
Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.

Comment 4 Dominique d'Humieres 2007-11-27 21:39:13 UTC
> Works for me on Intel Darwin9, but fails with default (-m32) on ppc Darwin9.

More precisely, works with both -m32 and -m64 on Intel Darwin9, but fails with both on ppc Darwin9.

Comment 5 Dominique d'Humieres 2007-11-27 23:00:41 UTC
On Intel Darwin9 (working) -fdump-tree-gimple shows without -m64:

foo ()
{
  character(kind=1) __result_foo[1:1];

  __result_foo[1]{lb: 1 sz: 1} = 66;
  D.831 = __result_foo;
  return D.831;
}

bar (x)
{
  character(kind=1) D.834;
  character(kind=1) D.835[1:1];
  character(kind=1) __result_bar[1:1];

  D.834 = (*x)[1]{lb: 1 sz: 1};
  __result_bar[1]{lb: 1 sz: 1} = D.834;
  __result_bar[1]{lb: 1 sz: 1} = 65;
  D.835 = __result_bar;
  return D.835;
}

and with -m64:

foo ()
{
  character(kind=1) D.872[1:1];
  character(kind=1) __result_foo[1:1];

  __result_foo[1]{lb: 1 sz: 1} = 66;
  D.872 = __result_foo;
  return D.872;
}


bar (x)
{
  character(kind=1) D.875;
  character(kind=1) D.876[1:1];
  character(kind=1) __result_bar[1:1];

  D.875 = (*x)[1]{lb: 1 sz: 1};
  __result_bar[1]{lb: 1 sz: 1} = D.875;
  __result_bar[1]{lb: 1 sz: 1} = 65;
  D.876 = __result_bar;
  return D.876;
}

and on PPC Darwin9 (non working) without -m64:

foo ()
{
  character(kind=1) __result_foo[1:1];

  __result_foo[1]{lb: 1 sz: 1} = 66;
  <retval> = __result_foo;
  return <retval>;
}


bar (x)
{
  character(kind=1) D.951;
  character(kind=1) __result_bar[1:1];

  D.951 = (*x)[1]{lb: 1 sz: 1};
  __result_bar[1]{lb: 1 sz: 1} = D.951;
  __result_bar[1]{lb: 1 sz: 1} = 65;
  <retval> = __result_bar;
  return <retval>;
}

and with -m64:

foo ()
{
  character(kind=1) __result_foo[1:1];

  __result_foo[1]{lb: 1 sz: 1} = 66;
  <retval> = __result_foo;
  return <retval>;
}


bar (x)
{
  character(kind=1) D.966;
  character(kind=1) __result_bar[1:1];

  D.966 = (*x)[1]{lb: 1 sz: 1};
  __result_bar[1]{lb: 1 sz: 1} = D.966;
  __result_bar[1]{lb: 1 sz: 1} = 65;
  <retval> = __result_bar;
  return <retval>;
}

So it seems to follow the same pattern you see on x86-64-linux? 

working:
  +  D.864 = __result_foo;
  +  return D.864;

not working:
  -  <retval> = __result_foo;
  -  return <retval>;

Comment 6 Tobias Burnus 2007-11-27 23:12:08 UTC
   character(kind=1) __result_foo[1:1];
   <retval> = __result_foo;

As Andrew pointed out, we return an array and not a scalar.

TODO:

a) Check that we expect a scalar to be returned in gfc_conv_function_call.

b) Ensure that we return a scalar - not only for FUNCTION but also for ENTRY. Possible place to do this is gfc_generate_function_code.

c) Fix the following ICE (occurs if either the function or the entry is bind(C) or both):

function test() bind(C)
  use iso_c_binding
  implicit none
  character(len=1,kind=c_char) :: test, bar
entry bar() bind(C)
end function test

d) Find out whether we are still crashing on some systems; if yes, fix it.
Comment 7 Dominique d'Humieres 2007-11-27 23:27:12 UTC
From http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01459.html, powerpc64-unknown-linux-gnu shows the same pattern as powerpc-apple-darwin9: anything linked to endianness?

Comment 8 Tobias Burnus 2007-11-30 16:07:18 UTC
> powerpc64-unknown-linux-gnu shows the same pattern as powerpc-apple-darwin9:
> anything linked to endianness?
Well, x86-32 and x86-64 should have the same endianness.

Comment 9 Tobias Burnus 2007-12-03 23:15:28 UTC
For scalar character vs. array, see also PR 32732, which added gfc_conv_scalar_char_value(). However, I failed to get it working properly :-(
Comment 10 John David Anglin 2007-12-09 17:47:52 UTC
Also fails on hppa64-hp-hpux11.11.
Comment 11 Tobias Burnus 2007-12-09 23:11:33 UTC
Patch, which fixes the test-suite failure (arrays were replaced by scalars):
  http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00424.html

Still left to do: ENTRY functions, see comment 6.
Comment 12 Dominique d'Humieres 2007-12-10 16:11:42 UTC
The patch in comment #11, fix the problem for ppc Darwin9 without regression for ppc/Intel Darwin9.

As noted, the test in comment #6 gives an ICE (g95 gives an error 'Duplicate BIND attribute specified at (1)') that is still there if I remove one of the 'bind(C)' (the same for g95).

Comment 13 Tobias Burnus 2007-12-10 18:36:58 UTC
> As noted, the test in comment #6 gives an ICE 

The ENTRY fix needs to go into build_entry_thunks:
      if (thunk_sym->attr.function)
        {
          if (gfc_return_by_reference (ns->proc_name))
            {
This branch is entered as the master function,  proc_name, is is_bind_c == false, but it fails currently if (thunk_sym->attr.is_bind_c && thunk_sym->ts.type == BT_CHARACTER).

The proper tree should looks more or less as follows:

test2 ()
{
  character(kind=1) tmp[1:1];
  integer(kind=4) len;
  master.0.test2 (0, &tmp, len);
  return tmp[1];

That is test() itself returns a scalar character, but master.0.test2 takes the string as argument, which allows to combine bind(C) with non-bind(C) functions and allows for different string lengths of ENTRY and function (cf. PR 34421).
Comment 14 Tobias Burnus 2007-12-16 20:24:46 UTC
Subject: Bug 34246

Author: burnus
Date: Sun Dec 16 20:24:32 2007
New Revision: 130991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130991
Log:
2007-12-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34246
        * trans-types.c (gfc_init_types): Change build_type_variant
        to build_qualified_type.
        (gfc_sym_type): Return gfc_character1_type_node for
        character-returning bind(C) functions.
        * trans-expr.c (gfc_conv_function_call): Do not set
        se->string_length for character-returning bind(c) functions.
        (gfc_trans_string_copy,gfc_trans_scalar_assign):
         Support also single characters.

2007-12-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/34246
        * gfortran.dg/bind_c_usage_16.f03: Extend test.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03

Comment 15 Tobias Burnus 2007-12-16 20:37:32 UTC
FIXED on the trunk (4.3.0). Please open a new bug if there are new/remaining problems.

The Bind(C) ENTRY part of this PR is now tracked as PR 34500.