* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
@ 2010-12-22 10:28 ` burnus at gcc dot gnu.org
2011-09-20 11:47 ` florian.rathgeber at gmail dot com
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-22 10:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |janus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-22 10:28:28 UTC ---
The reason for rejecting it is:
if (verify_c_interop (&arg->ts) != SUCCESS)
{
gfc_error ("'%s' argument of '%s' intrinsic at %L must be be an "
"interoperable data entity",
If one looks at decl.c, one see that the check makes only sense for BT_DERIVED
- but not for intrinsic variables. In decl.c one afterwards prints only an
error for BT_DERIVED - otherwise only a warning is printed (which does not make
sense here). And there is additionally a check for string-length == 1.
* * *
In decl.c, I think one should additionally check for BT_CLASS and reject the
following program (currently there is just a "may not be C interoperable"
warning as it is not BT_DERIVED).
module m
use iso_c_binding
type t
integer(c_int) :: i
end type t
contains
subroutine test(a) bind(c)
class(t) :: a
end subroutine
end
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
2010-12-22 10:28 ` [Bug fortran/47023] " burnus at gcc dot gnu.org
@ 2011-09-20 11:47 ` florian.rathgeber at gmail dot com
2011-09-20 15:36 ` [Bug fortran/47023] [4.6/4.7 regression] " kargl at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: florian.rathgeber at gmail dot com @ 2011-09-20 11:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
florian.rathgeber at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |florian.rathgeber at gmail
| |dot com
--- Comment #2 from florian.rathgeber at gmail dot com 2011-09-20 10:55:48 UTC ---
I'm seeing this bug even for an explicitly interoperable type (hence I'm not
sure if this is really the same bug - I'm happy to file a new one if someone
tells me to):
print *, c_sizeof(0.0_c_double)
1
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable
data entity
GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
2010-12-22 10:28 ` [Bug fortran/47023] " burnus at gcc dot gnu.org
2011-09-20 11:47 ` florian.rathgeber at gmail dot com
@ 2011-09-20 15:36 ` kargl at gcc dot gnu.org
2011-09-20 15:40 ` kargl at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-09-20 15:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
Known to work| |4.5.4
Summary|C_Sizeof: Rejects valid |[4.6/4.7 regression]
|code |C_Sizeof: Rejects valid
| |code
Known to fail| |4.6.2, 4.7.0
--- Comment #3 from kargl at gcc dot gnu.org 2011-09-20 14:51:25 UTC ---
(In reply to comment #2)
> I'm seeing this bug even for an explicitly interoperable type (hence I'm not
> sure if this is really the same bug - I'm happy to file a new one if someone
> tells me to):
>
> print *, c_sizeof(0.0_c_double)
> 1
> Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable
> data entity
>
> GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease)
This is now a regression.
troutmask:sgk[208] gfc45 -o z foo.f90
troutmask:sgk[209] ./z
8
troutmask:sgk[210] gfc46 -o z foo.f90
foo.f90:3.25:
print '(I0)', c_sizeof(0.0_c_double)
1
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable
data entity
troutmask:sgk[211] cat foo.f90
program foo
use iso_c_binding
print '(I0)', c_sizeof(0.0_c_double)
end program foo
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2011-09-20 15:36 ` [Bug fortran/47023] [4.6/4.7 regression] " kargl at gcc dot gnu.org
@ 2011-09-20 15:40 ` kargl at gcc dot gnu.org
2011-09-20 16:49 ` dominiq at lps dot ens.fr
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-09-20 15:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #4 from kargl at gcc dot gnu.org 2011-09-20 14:57:00 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > I'm seeing this bug even for an explicitly interoperable type (hence I'm not
> > sure if this is really the same bug - I'm happy to file a new one if someone
> > tells me to):
> >
> > print *, c_sizeof(0.0_c_double)
> > 1
> > Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable
> > data entity
> >
> > GNU Fortran (Ubuntu 4.6.0-1ubuntu1~ppa2) 4.6.1 20110326 (prerelease)
>
> This is now a regression.
>
> troutmask:sgk[208] gfc45 -o z foo.f90
> troutmask:sgk[209] ./z
> 8
> troutmask:sgk[210] gfc46 -o z foo.f90
> foo.f90:3.25:
>
> print '(I0)', c_sizeof(0.0_c_double)
> 1
> Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be be an interoperable
> data entity
>
> troutmask:sgk[211] cat foo.f90
> program foo
> use iso_c_binding
> print '(I0)', c_sizeof(0.0_c_double)
> end program foo
This seems to be a bug only when the actual argument is parameter.
program foo
use iso_c_binding
real(c_double) x
print *, c_sizeof(x)
end program foo
works as expected.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2011-09-20 15:40 ` kargl at gcc dot gnu.org
@ 2011-09-20 16:49 ` dominiq at lps dot ens.fr
2011-09-29 13:12 ` burnus at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-20 16:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-20 15:35:00 UTC ---
r158253 is OK
r162456 gives the error.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2011-09-20 16:49 ` dominiq at lps dot ens.fr
@ 2011-09-29 13:12 ` burnus at gcc dot gnu.org
2011-09-29 13:20 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-29 13:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-29 13:01:49 UTC ---
Seemingly caused by the patch for PR 44649:
2010-07-08 Janus Weil <janus@gcc.gnu.org>
PR fortran/44649
* check.c (gfc_check_c_sizeof,gfc_check_storage_size): New functions.
The problem seems to be the call:
+ if (verify_c_interop (&arg->ts) != SUCCESS)
The function checks:
if (ts->type == BT_DERIVED && ts->u.derived != NULL)
return (ts->u.derived->ts.is_c_interop || ts->u.derived->attr.is_bind_c)
? SUCCESS : FAILURE;
else if (ts->is_c_interop != 1)
return FAILURE;
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2011-09-29 13:12 ` burnus at gcc dot gnu.org
@ 2011-09-29 13:20 ` rguenth at gcc dot gnu.org
2011-09-29 13:21 ` burnus at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-09-29 13:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.6.2
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2011-09-29 13:20 ` rguenth at gcc dot gnu.org
@ 2011-09-29 13:21 ` burnus at gcc dot gnu.org
2011-09-29 13:29 ` janus at gcc dot gnu.org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-29 13:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-29 13:17:46 UTC ---
"Argument. X shall be an interoperable data entity that is not an assumed-size
array."
It might be sufficient to test -- besides the obvious stuff (cf. SIZEOF) --
just for derived types that those are BIND(C).
* * *
By the way, I think one should reject proc-pointers for both SIZEOF and
C_SIZEOF. For C_SIZEOF because they are not interoperable (only type(c_funptr)
is) and for SIZEOF as the pointee size and not the pointer size is returned,
which does not make sense for functions. (gfortran currently returns 1 byte.)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2011-09-29 13:21 ` burnus at gcc dot gnu.org
@ 2011-09-29 13:29 ` janus at gcc dot gnu.org
2011-09-29 15:52 ` burnus at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-09-29 13:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.6.2 |---
--- Comment #8 from janus at gcc dot gnu.org 2011-09-29 13:25:47 UTC ---
(In reply to comment #6)
> Seemingly caused by the patch for PR 44649:
... which is:
http://gcc.gnu.org/viewcvs?view=revision&revision=161977
This patch itself doesn't do anything wrong AFAICS, it rather seems to expose
an underlying bug: Either we need to set the 'is_c_interop' flag correctly or
loosen the checks in verify_c_interop.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2011-09-29 13:29 ` janus at gcc dot gnu.org
@ 2011-09-29 15:52 ` burnus at gcc dot gnu.org
2011-10-16 8:44 ` janus at gcc dot gnu.org
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-09-29 15:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-29 15:49:32 UTC ---
(In reply to comment #8)
> This patch itself doesn't do anything wrong AFAICS, it rather seems to expose
> an underlying bug: Either we need to set the 'is_c_interop' flag correctly or
> loosen the checks in verify_c_interop.
I think the latter. I think one can allow all intrinsic types. However, one
needs to be careful with characters: kind=4 is not interoperable and, e.g., for
dummies only len=1 is allowed (while via storage association, c_char_"string"
is a valid argument for a "character(len=1,kind=c_char) :: dummy(*)").
Note, additionally, that setting attr.is_c_interop is kind of difficult for
0.0_c_int ...
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (9 preceding siblings ...)
2011-09-29 15:52 ` burnus at gcc dot gnu.org
@ 2011-10-16 8:44 ` janus at gcc dot gnu.org
2011-10-16 19:43 ` janus at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-16 8:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011-10-16
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #10 from janus at gcc dot gnu.org 2011-10-16 08:43:56 UTC ---
(In reply to comment #9)
> > This patch itself doesn't do anything wrong AFAICS, it rather seems to expose
> > an underlying bug: Either we need to set the 'is_c_interop' flag correctly or
> > loosen the checks in verify_c_interop.
>
> I think the latter. I think one can allow all intrinsic types.
On second thought, I'm not so sure about this. Is this actually allowed by the
Fortran standard? (If not, one could think about allowing it only with
--std=gnu as an extension.)
> Note, additionally, that setting attr.is_c_interop is kind of difficult for
> 0.0_c_int ...
Well, no. We don't need to set 'attr.is_c_interop', but 'ts.is_c_interop',
which can also be done for constants. I'm right now testing a patch which does
so and fixes the regression.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (10 preceding siblings ...)
2011-10-16 8:44 ` janus at gcc dot gnu.org
@ 2011-10-16 19:43 ` janus at gcc dot gnu.org
2011-10-17 9:47 ` janus at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-16 19:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #11 from janus at gcc dot gnu.org 2011-10-16 19:42:50 UTC ---
Author: janus
Date: Sun Oct 16 19:42:48 2011
New Revision: 180062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180062
Log:
2011-10-16 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* primary.c (match_kind_param): Detect ISO_C_BINDING kinds.
(get_kind): Pass on 'is_iso_c' flag.
(match_integer_constant,match_real_constant,match_logical_constant):
Set 'ts.is_c_interop'.
2011-10-16 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* gfortran.dg/c_kind_tests_3.f03: New.
Added:
trunk/gcc/testsuite/gfortran.dg/c_kind_tests_3.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (11 preceding siblings ...)
2011-10-16 19:43 ` janus at gcc dot gnu.org
@ 2011-10-17 9:47 ` janus at gcc dot gnu.org
2011-10-17 16:00 ` janus at gcc dot gnu.org
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-17 9:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #12 from janus at gcc dot gnu.org 2011-10-17 09:46:33 UTC ---
Author: janus
Date: Mon Oct 17 09:46:30 2011
New Revision: 180079
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180079
Log:
2011-10-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
PR fortran/50752
* primary.c (match_kind_param): Avoid segfault.
2011-10-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
PR fortran/50752
* gfortran.dg/kind_tests_4.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/kind_tests_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (12 preceding siblings ...)
2011-10-17 9:47 ` janus at gcc dot gnu.org
@ 2011-10-17 16:00 ` janus at gcc dot gnu.org
2011-10-17 16:16 ` [Bug fortran/47023] " janus at gcc dot gnu.org
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-17 16:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #13 from janus at gcc dot gnu.org 2011-10-17 15:59:37 UTC ---
Author: janus
Date: Mon Oct 17 15:59:32 2011
New Revision: 180099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180099
Log:
2011-10-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* primary.c (match_kind_param): Detect ISO_C_BINDING kinds.
(get_kind): Pass on 'is_iso_c' flag.
(match_integer_constant,match_real_constant,match_logical_constant):
Set 'ts.is_c_interop'.
2011-10-17 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* gfortran.dg/c_kind_tests_3.f03: New.
Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/c_kind_tests_3.f03
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/primary.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (13 preceding siblings ...)
2011-10-17 16:00 ` janus at gcc dot gnu.org
@ 2011-10-17 16:16 ` janus at gcc dot gnu.org
2011-10-17 19:11 ` janus at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-17 16:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[4.6/4.7 regression] |C_Sizeof: Rejects valid
|C_Sizeof: Rejects valid |code
|code |
--- Comment #14 from janus at gcc dot gnu.org 2011-10-17 16:15:44 UTC ---
The regression of comment #2 is fixed on 4.6 and trunk (the fix will be in
4.6.2), so I'll remove the regression marker.
However, there are some more open problems in this PR:
* the error in comment #0 could be downgraded to a warning (which one gets in
other cases similar to this)
* treat BT_CLASS in decl.c (comment #1)
* reject proc-pointers for SIZEOF and C_SIZEOF (comment #7)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (14 preceding siblings ...)
2011-10-17 16:16 ` [Bug fortran/47023] " janus at gcc dot gnu.org
@ 2011-10-17 19:11 ` janus at gcc dot gnu.org
2011-10-17 19:23 ` janus at gcc dot gnu.org
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-17 19:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #15 from janus at gcc dot gnu.org 2011-10-17 19:10:44 UTC ---
The following should fix comment #1:
Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c (revision 180078)
+++ gcc/fortran/decl.c (working copy)
@@ -1000,20 +1000,24 @@ verify_c_interop_param (gfc_symbol *sym)
{
if (sym->ns->proc_name->attr.is_bind_c == 1)
{
- is_c_interop =
- (verify_c_interop (&(sym->ts))
- == SUCCESS ? 1 : 0);
+ is_c_interop = (verify_c_interop (&(sym->ts)) == SUCCESS ? 1 : 0);
if (is_c_interop != 1)
{
/* Make personalized messages to give better feedback. */
if (sym->ts.type == BT_DERIVED)
- gfc_error ("Type '%s' at %L is a parameter to the BIND(C) "
- "procedure '%s' but is not C interoperable "
+ gfc_error ("Variable '%s' at %L is a dummy argument to the "
+ "BIND(C) procedure '%s' but is not C interoperable "
"because derived type '%s' is not C interoperable",
sym->name, &(sym->declared_at),
sym->ns->proc_name->name,
sym->ts.u.derived->name);
+ else if (sym->ts.type == BT_CLASS)
+ gfc_error ("Variable '%s' at %L is a dummy argument to the "
+ "BIND(C) procedure '%s' but is not C interoperable "
+ "because it is polymorphic",
+ sym->name, &(sym->declared_at),
+ sym->ns->proc_name->name);
else
gfc_warning ("Variable '%s' at %L is a parameter to the "
"BIND(C) procedure '%s' but may not be C "
@@ -3716,6 +3720,8 @@ verify_c_interop (gfc_typespec *ts)
if (ts->type == BT_DERIVED && ts->u.derived != NULL)
return (ts->u.derived->ts.is_c_interop || ts->u.derived->attr.is_bind_c)
? SUCCESS : FAILURE;
+ else if (ts->type == BT_CLASS)
+ return FAILURE;
else if (ts->is_c_interop != 1)
return FAILURE;
It also fixes the wording of the error message for derived types, which uses
the terms 'type' and 'parameter' in a wrong way.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (15 preceding siblings ...)
2011-10-17 19:11 ` janus at gcc dot gnu.org
@ 2011-10-17 19:23 ` janus at gcc dot gnu.org
2011-10-18 10:48 ` janus at gcc dot gnu.org
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-17 19:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #16 from janus at gcc dot gnu.org 2011-10-17 19:22:15 UTC ---
(In reply to comment #7)
> By the way, I think one should reject proc-pointers for both SIZEOF and
> C_SIZEOF. For C_SIZEOF because they are not interoperable (only type(c_funptr)
> is) and for SIZEOF as the pointee size and not the pointer size is returned,
> which does not make sense for functions. (gfortran currently returns 1 byte.)
For C_SIZEOF, proc-pointers are rejected since 4.6. Example code:
use iso_c_binding
procedure(), pointer :: pp
print *, c_sizeof(pp)
end
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable
data entity
About SIZEOF I don't worry right now. Since it is an extension, we can
basically do whatever we like.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (16 preceding siblings ...)
2011-10-17 19:23 ` janus at gcc dot gnu.org
@ 2011-10-18 10:48 ` janus at gcc dot gnu.org
2011-10-18 11:07 ` janus at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 10:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #17 from janus at gcc dot gnu.org 2011-10-18 10:48:15 UTC ---
Author: janus
Date: Tue Oct 18 10:48:12 2011
New Revision: 180130
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180130
Log:
2011-10-18 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* decl.c (verify_c_interop_param): Renamed to
'gfc_verify_c_interop_param'. Add error message for polymorphic
arguments.
(verify_c_interop): Renamed to 'gfc_verify_c_interop'. Reject
polymorphic variables.
(verify_bind_c_sym): Renamed 'verify_c_interop'.
* gfortran.h (verify_c_interop,verify_c_interop_param): Renamed.
* check.c (gfc_check_sizeof): Ditto.
* resolve.c (gfc_iso_c_func_interface,resolve_fl_procedure): Ditto.
* symbol.c (verify_bind_c_derived_type): Ditto.
2011-10-18 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* gfortran.dg/iso_c_binding_class.f03: New.
Added:
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_class.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (17 preceding siblings ...)
2011-10-18 10:48 ` janus at gcc dot gnu.org
@ 2011-10-18 11:07 ` janus at gcc dot gnu.org
2011-10-18 12:04 ` janus at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 11:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #18 from janus at gcc dot gnu.org 2011-10-18 11:06:12 UTC ---
(In reply to comment #14)
> * treat BT_CLASS in decl.c (comment #1)
Fixed with r180130.
Left to do:
> * the error in comment #0 could be downgraded to a warning (which one gets in
> other cases similar to this)
> * reject proc-pointers for SIZEOF (comment #7)
(proc-pointers in C_SIZEOF are being rejected already)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (18 preceding siblings ...)
2011-10-18 11:07 ` janus at gcc dot gnu.org
@ 2011-10-18 12:04 ` janus at gcc dot gnu.org
2011-10-18 12:18 ` janus at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 12:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #19 from janus at gcc dot gnu.org 2011-10-18 12:03:58 UTC ---
(In reply to comment #18)
> > * reject proc-pointers for SIZEOF (comment #7)
Example:
use iso_c_binding
procedure(real), pointer :: pp
procedure(real) :: proc
pp => sin
print *,sizeof(proc) ! (1)
print *,sizeof(pp) ! (2)
print *,sizeof(pp(0.)) ! (3)
end
Currently this gives the output:
1
1
4
The last one is correct, giving the size of the return value of the called
function. The first one should eventually be rejected. For the second one, it's
not completely clear where the '1' comes from, but it's certainly wrong (in any
possible interpretation).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (19 preceding siblings ...)
2011-10-18 12:04 ` janus at gcc dot gnu.org
@ 2011-10-18 12:18 ` janus at gcc dot gnu.org
2011-10-18 12:20 ` janus at gcc dot gnu.org
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 12:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #20 from janus at gcc dot gnu.org 2011-10-18 12:17:42 UTC ---
(In reply to comment #19)
> > > * reject proc-pointers for SIZEOF (comment #7)
I think one could also allow them, but then the implementation of SIZEOF needs
to be fixed to give the size of the pointer.
Draft patch:
Index: gcc/fortran/trans-intrinsic.c
===================================================================
--- gcc/fortran/trans-intrinsic.c (revision 180129)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -5088,8 +5088,11 @@ gfc_conv_intrinsic_sizeof (gfc_se *se, gfc_expr *e
gfc_conv_expr_reference (&argse, arg);
- type = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
- argse.expr));
+ if (arg->ts.type == BT_PROCEDURE)
+ type = TREE_TYPE (argse.expr);
+ else
+ type = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
+ argse.expr));
/* Obtain the source word length. */
if (arg->ts.type == BT_CHARACTER)
With this the test case in comment #19 gives:
8
8
4
which is ok, apart from the fact that sizeof(proc) should be rejected.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (20 preceding siblings ...)
2011-10-18 12:18 ` janus at gcc dot gnu.org
@ 2011-10-18 12:20 ` janus at gcc dot gnu.org
2011-10-18 12:48 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 12:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #21 from janus at gcc dot gnu.org 2011-10-18 12:19:54 UTC ---
The question is also how SIZEOF should act on data pointers:
use iso_c_binding
integer(2) :: i
integer(2), pointer :: p
print *,sizeof(i)
print *,sizeof(p)
end
Output:
2
2
Should it give the size of the pointer itself, or the size of the object it
points to?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (21 preceding siblings ...)
2011-10-18 12:20 ` janus at gcc dot gnu.org
@ 2011-10-18 12:48 ` burnus at gcc dot gnu.org
2011-10-18 13:46 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-10-18 12:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #22 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-18 12:48:31 UTC ---
(In reply to comment #21)
> The question is also how SIZEOF should act on data pointers:
> Output:
> 2
> 2
> Should it give the size of the pointer itself, or the size of the object it
> points to?
The target/pointee. Reasoning: For your example, g95, gfortran, ifort and
pathf95 all print "2". That's also what gfortran claims to do at
http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html
Regarding (comment 19, comment 20):
print *,sizeof(proc) ! (1) -- prints 1
print *,sizeof(pp) ! (2) -- prints 1
print *,sizeof(pp(0.)) ! (3) -- prints 4
ifort rejects (1) and (2) and returns "4" for (3). I think gfortran should do
likewise. Returning the pointee size for scalar variables but the pointer size
of functions is also a bit odd.
* * *
For Cray pointers/pointees:
use iso_c_binding, only: c_sizeof
implicit none
integer(2) :: a
pointer (aptr, a)
print *,sizeof (a) ! , c_sizeof (a)
print *,sizeof (aptr)! , c_sizeof (aptr)
end
This program fails to compile for c_sizeof while the sizeof version prints "2"
and "8", which I think is OK.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (22 preceding siblings ...)
2011-10-18 12:48 ` burnus at gcc dot gnu.org
@ 2011-10-18 13:46 ` janus at gcc dot gnu.org
2011-10-19 22:08 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-18 13:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #23 from janus at gcc dot gnu.org 2011-10-18 13:45:32 UTC ---
(In reply to comment #22)
> (In reply to comment #21)
> > The question is also how SIZEOF should act on data pointers:
> > Should it give the size of the pointer itself, or the size of the object it
> > points to?
>
> The target/pointee. Reasoning: For your example, g95, gfortran, ifort and
> pathf95 all print "2". That's also what gfortran claims to do at
> http://gcc.gnu.org/onlinedocs/gfortran/SIZEOF.html
Well, ok. "Wer lesen kann ist klar im Vorteil" ;)
Then this is obviously a feature and not a bug.
> Regarding (comment 19, comment 20):
> print *,sizeof(proc) ! (1) -- prints 1
> print *,sizeof(pp) ! (2) -- prints 1
> print *,sizeof(pp(0.)) ! (3) -- prints 4
>
> ifort rejects (1) and (2) and returns "4" for (3). I think gfortran should do
> likewise. Returning the pointee size for scalar variables but the pointer size
> of functions is also a bit odd.
Ok, I agree that it's better to reject it under these circumstances. How about
the following patch?
Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c (revision 180134)
+++ gcc/fortran/check.c (working copy)
@@ -3446,8 +3446,15 @@ gfc_check_size (gfc_expr *array, gfc_expr *dim, gf
gfc_try
-gfc_check_sizeof (gfc_expr *arg ATTRIBUTE_UNUSED)
+gfc_check_sizeof (gfc_expr *arg)
{
+ if (arg->ts.type == BT_PROCEDURE)
+ {
+ gfc_error ("'%s' argument of '%s' intrinsic at %L may not be a
procedure",
+ gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+ &arg->where);
+ return FAILURE;
+ }
return SUCCESS;
}
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (23 preceding siblings ...)
2011-10-18 13:46 ` janus at gcc dot gnu.org
@ 2011-10-19 22:08 ` janus at gcc dot gnu.org
2011-10-19 22:10 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-19 22:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #24 from janus at gcc dot gnu.org 2011-10-19 22:05:26 UTC ---
Author: janus
Date: Wed Oct 19 22:05:23 2011
New Revision: 180210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180210
Log:
2011-10-19 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* check.c (gfc_check_sizeof): Reject procedures as argument of SIZEOF.
* intrinsinc.texi (SIZEOF): Document it.
(STORAGE_SIZE): Fix special characters. Fix line breaks.
2011-10-19 Janus Weil <janus@gcc.gnu.org>
PR fortran/47023
* gfortran.dg/sizeof_proc.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/sizeof_proc.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (24 preceding siblings ...)
2011-10-19 22:08 ` janus at gcc dot gnu.org
@ 2011-10-19 22:10 ` janus at gcc dot gnu.org
2013-03-25 15:53 ` burnus at gcc dot gnu.org
2013-03-25 17:46 ` burnus at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: janus at gcc dot gnu.org @ 2011-10-19 22:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
--- Comment #25 from janus at gcc dot gnu.org 2011-10-19 22:10:40 UTC ---
r180210 fixes comment #7 (rejecting proc-pointers as argument of SIZEOF).
Left to do is only the original comment #0 at this point.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (25 preceding siblings ...)
2011-10-19 22:10 ` janus at gcc dot gnu.org
@ 2013-03-25 15:53 ` burnus at gcc dot gnu.org
2013-03-25 17:46 ` burnus at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-03-25 15:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #26 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-25 15:53:38 UTC ---
Author: burnus
Date: Mon Mar 25 15:40:26 2013
New Revision: 197053
URL: http://gcc.gnu.org/viewcvs?rev=197053&root=gcc&view=rev
Log:
2013-03-25 Tobias Burnus <burnus@net-b.de>
PR fortran/38536
PR fortran/38813
PR fortran/38894
PR fortran/39288
PR fortran/40963
PR fortran/45824
PR fortran/47023
PR fortran/47034
PR fortran/49023
PR fortran/50269
PR fortran/50612
PR fortran/52426
PR fortran/54263
PR fortran/55343
PR fortran/55444
PR fortran/55574
PR fortran/56079
PR fortran/56378
* check.c (gfc_var_strlen): Properly handle 0-sized string.
(gfc_check_c_sizeof): Use is_c_interoperable, add checks.
(is_c_interoperable, gfc_check_c_associated, gfc_check_c_f_pointer,
gfc_check_c_f_procpointer, gfc_check_c_funloc, gfc_check_c_loc): New
functions.
* expr.c (check_inquiry): Add c_sizeof, compiler_version and
compiler_options.
(gfc_check_pointer_assign): Refine function result check.
gfortran.h (gfc_isym_id): Add GFC_ISYM_C_ASSOCIATED,
GFC_ISYM_C_F_POINTER, GFC_ISYM_C_F_PROCPOINTER, GFC_ISYM_C_FUNLOC,
GFC_ISYM_C_LOC.
(iso_fortran_env_symbol, iso_c_binding_symbol): Handle
NAMED_SUBROUTINE.
(generate_isocbinding_symbol): Update prototype.
(get_iso_c_sym): Remove.
(gfc_isym_id_by_intmod, gfc_isym_id_by_intmod_sym): New prototypes.
* intrinsic.c (gfc_intrinsic_subroutine_by_id): New function.
(gfc_intrinsic_sub_interface): Use it.
(add_functions, add_subroutines): Add missing C-binding intrinsics.
(gfc_intrinsic_func_interface): Add special case for c_loc.
gfc_isym_id_by_intmod, gfc_isym_id_by_intmod_sym): New functions.
(gfc_intrinsic_func_interface, gfc_intrinsic_sub_interface): Use them.
* intrinsic.h (gfc_check_c_associated, gfc_check_c_f_pointer,
gfc_check_c_f_procpointer, gfc_check_c_funloc, gfc_check_c_loc,
gfc_resolve_c_loc, gfc_resolve_c_funloc): New prototypes.
* iresolve.c (gfc_resolve_c_loc, gfc_resolve_c_funloc): New
functions.
* iso-c-binding.def: Split PROCEDURE into NAMED_SUBROUTINE and
NAMED_FUNCTION.
* iso-fortran-env.def: Add NAMED_SUBROUTINE for completeness.
* module.c (create_intrinsic_function): Support subroutines and
derived-type results.
(use_iso_fortran_env_module): Update calls.
(import_iso_c_binding_module): Ditto; update calls to
generate_isocbinding_symbol.
* resolve.c (find_arglists): Skip for intrinsic symbols.
(gfc_resolve_intrinsic): Find intrinsic subs via id.
(is_scalar_expr_ptr, gfc_iso_c_func_interface,
set_name_and_label, gfc_iso_c_sub_interface): Remove.
(resolve_function, resolve_specific_s0): Remove calls to those.
(resolve_structure_cons): Fix handling.
* symbol.c (gen_special_c_interop_ptr): Update c_ptr/c_funptr
generation.
(gen_cptr_param, gen_fptr_param, gen_shape_param,
build_formal_args, get_iso_c_sym): Remove.
(std_for_isocbinding_symbol): Handle NAMED_SUBROUTINE.
(generate_isocbinding_symbol): Support hidden symbols and
using c_ptr/c_funptr symtrees for nullptr defs.
* target-memory.c (gfc_target_encode_expr): Fix handling
of c_ptr/c_funptr.
* trans-expr.c (conv_isocbinding_procedure): Remove.
(gfc_conv_procedure_call): Remove call to it.
(gfc_trans_subcomponent_assign, gfc_conv_expr): Update handling
of c_ptr/c_funptr.
* trans-intrinsic.c (conv_isocbinding_function,
conv_isocbinding_subroutine): New.
(gfc_conv_intrinsic_function, gfc_conv_intrinsic_subroutine):
Call them.
* trans-io.c (transfer_expr): Fix handling of c_ptr/c_funptr.
* trans-types.c (gfc_typenode_for_spec,
gfc_get_derived_type): Ditto.
(gfc_init_c_interop_kinds): Handle NAMED_SUBROUTINE.
2013-03-25 Tobias Burnus <burnus@net-b.de>
PR fortran/38536
PR fortran/38813
PR fortran/38894
PR fortran/39288
PR fortran/40963
PR fortran/45824
PR fortran/47023
PR fortran/47034
PR fortran/49023
PR fortran/50269
PR fortran/50612
PR fortran/52426
PR fortran/54263
PR fortran/55343
PR fortran/55444
PR fortran/55574
PR fortran/56079
PR fortran/56378
* gfortran.dg/c_assoc_2.f03: Update dg-error wording.
* gfortran.dg/c_f_pointer_shape_test.f90: Ditto.
* gfortran.dg/c_f_pointer_shape_tests_3.f03: Ditto.
* gfortran.dg/c_f_pointer_tests_5.f90: Ditto.
* gfortran.dg/c_funloc_tests_2.f03: Ditto.
* gfortran.dg/c_funloc_tests_5.f03: Ditto.
* gfortran.dg/c_funloc_tests_6.f90: Ditto.
* gfortran.dg/c_loc_tests_10.f03: Add -std=f2008.
* gfortran.dg/c_loc_tests_11.f03: Ditto, update dg-error.
* gfortran.dg/c_loc_tests_16.f90: Ditto.
* gfortran.dg/c_loc_tests_4.f03: Ditto.
* gfortran.dg/c_loc_tests_15.f90: Update dg-error wording.
* gfortran.dg/c_loc_tests_3.f03: Valid since F2003 TC5.
* gfortran.dg/c_loc_tests_8.f03: Ditto.
* gfortran.dg/c_ptr_tests_14.f90: Update scan-tree-dump-times.
* gfortran.dg/c_ptr_tests_15.f90: Ditto.
* gfortran.dg/c_sizeof_1.f90: Fix invalid code.
* gfortran.dg/iso_c_binding_init_expr.f03: Update dg-error wording.
* gfortran.dg/pr32601_1.f03: Ditto.
* gfortran.dg/storage_size_2.f08: Remove dg-error.
* gfortran.dg/blockdata_7.f90: New.
* gfortran.dg/c_assoc_4.f90: New.
* gfortran.dg/c_f_pointer_tests_6.f90: New.
* gfortran.dg/c_f_pointer_tests_7.f90: New.
* gfortran.dg/c_funloc_tests_8.f90: New.
* gfortran.dg/c_loc_test_17.f90: New.
* gfortran.dg/c_loc_test_18.f90: New.
* gfortran.dg/c_loc_test_19.f90: New.
* gfortran.dg/c_loc_test_20.f90: New.
* gfortran.dg/c_sizeof_5.f90: New.
* gfortran.dg/iso_c_binding_rename_3.f90: New.
* gfortran.dg/transfer_resolve_2.f90: New.
* gfortran.dg/transfer_resolve_3.f90: New.
* gfortran.dg/transfer_resolve_4.f90: New.
* gfortran.dg/pr32601.f03: Update dg-error.
* gfortran.dg/c_ptr_tests_13.f03: Update dg-error.
* gfortran.dg/c_ptr_tests_9.f03: Fix test case.
Added:
trunk/gcc/testsuite/gfortran.dg/blockdata_7.f90
trunk/gcc/testsuite/gfortran.dg/c_assoc_4.f90
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_6.f90
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_7.f90
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_8.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_test_17.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_test_18.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_test_19.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_test_20.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_17.f90
trunk/gcc/testsuite/gfortran.dg/c_sizeof_5.f90
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_rename_3.f90
trunk/gcc/testsuite/gfortran.dg/transfer_resolve_2.f90
trunk/gcc/testsuite/gfortran.dg/transfer_resolve_3.f90
trunk/gcc/testsuite/gfortran.dg/transfer_resolve_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/iso-c-binding.def
trunk/gcc/fortran/iso-fortran-env.def
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/target-memory.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_assoc_2.f03
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_test.f90
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_tests_3.f03
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_5.f90
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_2.f03
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_5.f03
trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_10.f03
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_11.f03
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_15.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_16.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_3.f03
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_4.f03
trunk/gcc/testsuite/gfortran.dg/c_loc_tests_8.f03
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_13.f03
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_14.f90
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_15.f90
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_9.f03
trunk/gcc/testsuite/gfortran.dg/c_sizeof_1.f90
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_init_expr.f03
trunk/gcc/testsuite/gfortran.dg/pr32601.f03
trunk/gcc/testsuite/gfortran.dg/pr32601_1.f03
trunk/gcc/testsuite/gfortran.dg/storage_size_2.f08
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug fortran/47023] C_Sizeof: Rejects valid code
2010-12-20 8:59 [Bug fortran/47023] New: C_Sizeof: Rejects valid code burnus at gcc dot gnu.org
` (26 preceding siblings ...)
2013-03-25 15:53 ` burnus at gcc dot gnu.org
@ 2013-03-25 17:46 ` burnus at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-03-25 17:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #27 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-03-25 17:46:24 UTC ---
FIXED on the 4.9 trunk.
^ permalink raw reply [flat|nested] 29+ messages in thread