* [Bug fortran/30887] %VAL construct fails on 64 bit
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
@ 2007-02-20 17:29 ` pinskia at gcc dot gnu dot org
2007-02-20 17:33 ` [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex burnus at gcc dot gnu dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-02-20 17:29 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
2007-02-20 17:29 ` [Bug fortran/30887] " pinskia at gcc dot gnu dot org
@ 2007-02-20 17:33 ` burnus at gcc dot gnu dot org
2007-02-21 5:17 ` paulthomas2 at wanadoo dot fr
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-20 17:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 17:32 -------
Paul, do you remember why you have added the following restriction?
(The example is accepted by ifort, nagf95 and g95.)
resolve.c:
if (((e->ts.type == BT_REAL || e->ts.type == BT_COMPLEX)
&& e->ts.kind > gfc_default_real_kind)
|| (e->ts.kind > gfc_default_integer_kind))
{
gfc_error ("Kind of by-value argument at %L is larger "
"than default kind", &e->where);
return FAILURE;
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu dot
| |org, burnus at gcc dot gnu
| |dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|x86_64-unknown-linux-gnu |
Keywords| |rejects-valid
Last reconfirmed|0000-00-00 00:00:00 |2007-02-20 17:32:54
date| |
Summary|%VAL construct fails on 64 |%VAL only accepts default-
|bit |kind integer/real/complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
2007-02-20 17:29 ` [Bug fortran/30887] " pinskia at gcc dot gnu dot org
2007-02-20 17:33 ` [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex burnus at gcc dot gnu dot org
@ 2007-02-21 5:17 ` paulthomas2 at wanadoo dot fr
2007-02-22 18:52 ` sdirkse at gams dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: paulthomas2 at wanadoo dot fr @ 2007-02-21 5:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from paulthomas2 at wanadoo dot fr 2007-02-21 05:16 -------
Subject: Re: %VAL only accepts default-kind integer/real/complex
Tobias,
> ------- Comment #1 from burnus at gcc dot gnu dot org 2007-02-20 17:32 -------
> Paul, do you remember why you have added the following restriction?
>
> (The example is accepted by ifort, nagf95 and g95.)
>
> resolve.c:
> if (((e->ts.type == BT_REAL || e->ts.type == BT_COMPLEX)
> && e->ts.kind > gfc_default_real_kind)
> || (e->ts.kind > gfc_default_integer_kind))
> {
> gfc_error ("Kind of by-value argument at %L is larger "
> "than default kind", &e->where);
> return FAILURE;
>
One of the compilers, whose implementation of %VAL I checked, had this
restriction. I now cannot find which one.
There is absolutely no reason why the restriction should not be removed.
Best regards
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (2 preceding siblings ...)
2007-02-21 5:17 ` paulthomas2 at wanadoo dot fr
@ 2007-02-22 18:52 ` sdirkse at gams dot com
2007-02-22 19:24 ` kargl at gcc dot gnu dot org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sdirkse at gams dot com @ 2007-02-22 18:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from sdirkse at gams dot com 2007-02-22 18:52 -------
I took out the restriction in resolve.c that leads to the error message, and it
does give me a clean compile, but the code does not do what I expect. For
example, passing a real(kind=8) by-value to C doesn't get me a good double,
ditto for a integer(kind=8). The examples work when using ifort/icc. I can
send them if you'd like, but they are vanilla one-liners, almost.
Enough facts, now for some ignorant speculation: I suppose there is some logic
missing to pass a value from the caller when the size of the value is not the
default size (i.e. 4 for my platform, Linux 32-bit).
--
sdirkse at gams dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sdirkse at gams dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (3 preceding siblings ...)
2007-02-22 18:52 ` sdirkse at gams dot com
@ 2007-02-22 19:24 ` kargl at gcc dot gnu dot org
2007-02-22 19:51 ` burnus at gcc dot gnu dot org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-02-22 19:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from kargl at gcc dot gnu dot org 2007-02-22 19:24 -------
(In reply to comment #3)
>
> Enough facts, now for some ignorant speculation: I suppose there is some logic
> missing to pass a value from the caller when the size of the value is not the
> default size (i.e. 4 for my platform, Linux 32-bit).
>
See conv_arglist_function in trans-expr.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (4 preceding siblings ...)
2007-02-22 19:24 ` kargl at gcc dot gnu dot org
@ 2007-02-22 19:51 ` burnus at gcc dot gnu dot org
2007-02-22 21:10 ` patchapp at dberlin dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-22 19:51 UTC (permalink / raw)
To: gcc-bugs
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-02-20 17:32:54 |2007-02-22 19:50:51
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (5 preceding siblings ...)
2007-02-22 19:51 ` burnus at gcc dot gnu dot org
@ 2007-02-22 21:10 ` patchapp at dberlin dot org
2007-02-22 21:35 ` sdirkse at gams dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: patchapp at dberlin dot org @ 2007-02-22 21:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from patchapp at dberlin dot org 2007-02-22 21:10 -------
Subject: Bug number PR30887
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01839.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (6 preceding siblings ...)
2007-02-22 21:10 ` patchapp at dberlin dot org
@ 2007-02-22 21:35 ` sdirkse at gams dot com
2007-02-23 15:44 ` p dot w dot draper at durham dot ac dot uk
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sdirkse at gams dot com @ 2007-02-22 21:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from sdirkse at gams dot com 2007-02-22 21:35 -------
(In reply to comment #4)
> (In reply to comment #3)
> >
> > Enough facts, now for some ignorant speculation: I suppose there is some logic
> > missing to pass a value from the caller when the size of the value is not the
> > default size (i.e. 4 for my platform, Linux 32-bit).
> >
>
> See conv_arglist_function in trans-expr.c.
>
Brilliant! I changed the code in there to use a size of
MAX(default_kind,expression_kind) instead of just default_kind, and it seems to
work now, i.e. the one-liner example is OK. The code was easier to read and
modify than I was expecting, a pleasant surprise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (7 preceding siblings ...)
2007-02-22 21:35 ` sdirkse at gams dot com
@ 2007-02-23 15:44 ` p dot w dot draper at durham dot ac dot uk
2007-02-28 18:18 ` burnus at gcc dot gnu dot org
2007-02-28 18:26 ` burnus at gcc dot gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: p dot w dot draper at durham dot ac dot uk @ 2007-02-23 15:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from p dot w dot draper at durham dot ac dot uk 2007-02-23 15:44 -------
Tried out the patch and it works for me under 64bit with
default sized integers. Seems to have fixed PR 30888 too.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (8 preceding siblings ...)
2007-02-23 15:44 ` p dot w dot draper at durham dot ac dot uk
@ 2007-02-28 18:18 ` burnus at gcc dot gnu dot org
2007-02-28 18:26 ` burnus at gcc dot gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-28 18:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from burnus at gcc dot gnu dot org 2007-02-28 18:17 -------
Subject: Bug 30887
Author: burnus
Date: Wed Feb 28 18:17:34 2007
New Revision: 122409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122409
Log:
2007-02-28 Tobias Burnus <burnus@net-b.de>
Paul Thomas <pault@gcc.gnu.org>
PR fortran/30888
PR fortran/30887
* resolve.c (resolve_actual_arglist): Allow by-value
arguments and non-default-kind for %VAL().
* trans-expr.c (conv_arglist_function): Allow
non-default-kind for %VAL().
testsuite/
2007-02-28 Tobias Burnus <burnus@net-b.de>
Paul Thomas <pault@gcc.gnu.org>
PR fortran/30888
PR fortran/30887
* c_by_val_1.f: Test %VAL() with non-default kind.
* c_by_val.c: Ditto.
* c_by_val_4.f: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/c_by_val_4.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_by_val.c
trunk/gcc/testsuite/gfortran.dg/c_by_val_1.f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/30887] %VAL only accepts default-kind integer/real/complex
2007-02-20 17:22 [Bug fortran/30887] New: %VAL construct fails on 64 bit p dot w dot draper at durham dot ac dot uk
` (9 preceding siblings ...)
2007-02-28 18:18 ` burnus at gcc dot gnu dot org
@ 2007-02-28 18:26 ` burnus at gcc dot gnu dot org
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-02-28 18:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from burnus at gcc dot gnu dot org 2007-02-28 18:26 -------
Fixed in GCC 4.3, not part of 4.2 => close PR.
Thanks for having reported this bug.
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30887
^ permalink raw reply [flat|nested] 12+ messages in thread