public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity
@ 2010-12-15 21:39 kargl at gcc dot gnu.org
2010-12-17 23:15 ` [Bug fortran/46974] " kargl at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: kargl at gcc dot gnu.org @ 2010-12-15 21:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
Summary: ICE with TRANSFER using a C_PTR entity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: kargl@gcc.gnu.org
program bug1
use ISO_C_BINDING
implicit none
type(c_ptr) :: m
type mytype
integer a, b, c
end type mytype
type(mytype) x
print *, transfer(32512, x) ! Works.
print *, transfer(32512, m) ! Cause ICE.
end program bug1
laptop:kargl[206] gfc4x -c po.f90
f951: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
laptop:kargl[207] gdb
/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.6.0/f951
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd8.0"...
(gdb) run po.f90
Starting program:
/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.6.0/f951 po.f90
Program received signal SIGSEGV, Segmentation fault.
0x0814d56d in gfc_interpret_derived (buffer=0xbfbfe0e0 "", buffer_size=4,
result=0x495759e0) at ../../gcc4x/gcc/fortran/target-memory.c:486
486 ptr = TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET
(cmp->backend_decl));
(gdb) print cmp->backend_decl
$1 = (tree) 0x0
(gdb) print *cmp
$3 = {name = 0x49830a64 "__c_ptr_c_address", ts = {type = BT_INTEGER,
kind = 4, u = {derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0,
is_c_interop = 1, is_iso_c = 0, f90_type = BT_INTEGER, deferred = 0 '\0'},
attr = {allocatable = 0, dimension = 0, codimension = 0, external = 0,
intrinsic = 0, optional = 0, pointer = 0, target = 0, value = 0,
volatile_ = 0, temporary = 0, dummy = 0, result = 0, assign = 0,
threadprivate = 0, not_always_present = 0, implied_index = 0,
subref_array_pointer = 0, proc_pointer = 0, asynchronous = 0,
contiguous = 0, class_pointer = 0, save = SAVE_NONE, data = 0,
is_protected = 0, use_assoc = 0, use_only = 0, use_rename = 0,
imported = 0, host_assoc = 0, in_namelist = 0, in_common = 0,
in_equivalence = 0, function = 0, subroutine = 0, procedure = 0,
generic = 0, generic_copy = 0, implicit_type = 0, untyped = 0,
is_bind_c = 0, extension = 0, is_class = 0, class_ok = 0, vtab = 0,
vtype = 0, is_c_interop = 0, is_iso_c = 0, sequence = 0, elemental = 0,
pure = 0, recursive = 0, unmaskable = 0, masked = 0, contained = 0,
mod_proc = 0, abstract = 0, noreturn = 0, entry = 0, entry_master = 0,
mixed_entry_master = 0, always_explicit = 0, referenced = 0,
is_main_program = 0, access = ACCESS_UNKNOWN, intent = INTENT_UNKNOWN,
flavor = FL_UNKNOWN, if_source = IFSRC_UNKNOWN, proc = PROC_UNKNOWN,
cray_pointer = 0, cray_pointee = 0, alloc_comp = 0, pointer_comp = 0,
proc_pointer_comp = 0, private_comp = 0, zero_comp = 0, coarray_comp = 0,
select_type_temporary = 0, ext_attr = 0, volatile_ns = 0x0,
asynchronous_ns = 0x0}, as = 0x0, backend_decl = 0x0, loc = {
nextc = 0x495740e4, lb = 0x49574080}, initializer = 0x0, next = 0x0,
formal = 0x0, formal_ns = 0x0, tb = 0x0}
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
@ 2010-12-17 23:15 ` kargl at gcc dot gnu.org
2010-12-18 0:01 ` sgk at troutmask dot apl.washington.edu
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: kargl at gcc dot gnu.org @ 2010-12-17 23:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2010-12-17 23:15:27 UTC ---
The issues appears to have come into gfortran with pault's
initial commit of Brook's gfc_simplify_transfer. This
is revision 124759.
Consider
program z
use iso_c_binding
type(c_ptr) m
m = transfer(12345, m)
end program z
The culprit is the second test in
if (!gfc_is_constant_expr (source)
|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
|| !gfc_is_constant_expr (size))
return NULL;
Here, gfc_init_expr_flag = 0 and mold is EXPR_VARIABLE, which
yields !gfc_is_constant_expr (mold) = 1. Clearly (0 && anything)
is going to be 0. So, gfortran tries to simplify the expression.
If gfc_init_expr_flag is removed, the code compiles.
Anyone know why this flag is needed?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
2010-12-17 23:15 ` [Bug fortran/46974] " kargl at gcc dot gnu.org
@ 2010-12-18 0:01 ` sgk at troutmask dot apl.washington.edu
2010-12-18 6:45 ` sgk at troutmask dot apl.washington.edu
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2010-12-18 0:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #2 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 00:01:03 UTC ---
On Fri, Dec 17, 2010 at 11:15:44PM +0000, kargl at gcc dot gnu.org wrote:
>
> Anyone know why this flag is needed?
>
Well, the answer is to let simplify_transfer_[34].f90
in the testsuite to compile! :-)
Given
program z
use iso_c_binding
type(c_ptr) m
m = transfer(32512, m)
m = transfer(32512, C_NULL_PTR)
end program z
This patch compiles the above.
Index: simplify.c
===================================================================
--- simplify.c (revision 167949)
+++ simplify.c (working copy)
@@ -5954,6 +5954,11 @@ gfc_simplify_transfer (gfc_expr *source,
if (source->expr_type == EXPR_FUNCTION)
return NULL;
+ if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
+ && mold->ts.type == BT_DERIVED && mold->ts.u.derived
+ && strcmp(mold->ts.u.derived->name, "c_ptr") == 0)
+ return NULL;
+
/* Calculate the size of the source. */
if (source->expr_type == EXPR_ARRAY
&& gfc_array_size (source, &tmp) == FAILURE)
The tree dump looks like
z ()
--More--(74%){
void * m;
{
void * transfer.0;
integer(kind=8) D.1524;
integer(kind=8) D.1523;
static integer(kind=4) C.1522 = 32512;
integer(kind=8) D.1521;
D.1521 = 4;
D.1523 = 8;
__builtin_memcpy ((void *) &transfer.0, (void *) &C.1522,
MAX_EXPR <MIN_EXPR <D.1523, D.1521>, 0>);
m = transfer.0;
}
{
void * transfer.1;
integer(kind=8) D.1530;
integer(kind=8) D.1529;
static void * C.1528 = 0B;
static integer(kind=4) C.1527 = 32512;
integer(kind=8) D.1526;
D.1526 = 4;
D.1529 = 8;
__builtin_memcpy ((void *) &transfer.1, (void *) &C.1527,
MAX_EXPR <MIN_EXPR <D.1529, D.1526>, 0>);
m = transfer.1;
}
}
So we are assigning a void * pointer to a void * pointer. Not
sure this is the desired result.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
2010-12-17 23:15 ` [Bug fortran/46974] " kargl at gcc dot gnu.org
2010-12-18 0:01 ` sgk at troutmask dot apl.washington.edu
@ 2010-12-18 6:45 ` sgk at troutmask dot apl.washington.edu
2010-12-18 10:07 ` burnus at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2010-12-18 6:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 06:45:19 UTC ---
On Sat, Dec 18, 2010 at 12:01:13AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
>
> Index: simplify.c
> ===================================================================
> --- simplify.c (revision 167949)
> +++ simplify.c (working copy)
> @@ -5954,6 +5954,11 @@ gfc_simplify_transfer (gfc_expr *source,
> if (source->expr_type == EXPR_FUNCTION)
> return NULL;
>
> + if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> + && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> + && strcmp(mold->ts.u.derived->name, "c_ptr") == 0)
> + return NULL;
> +
> /* Calculate the size of the source. */
> if (source->expr_type == EXPR_ARRAY
> && gfc_array_size (source, &tmp) == FAILURE)
Updated patch to hand C_FUNPTR types.
Index: simplify.c
===================================================================
--- simplify.c (revision 167949)
+++ simplify.c (working copy)
@@ -5954,6 +5954,12 @@ gfc_simplify_transfer (gfc_expr *source,
if (source->expr_type == EXPR_FUNCTION)
return NULL;
+ if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
+ && mold->ts.type == BT_DERIVED && mold->ts.u.derived
+ && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
+ || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
+ return NULL;
+
/* Calculate the size of the source. */
if (source->expr_type == EXPR_ARRAY
&& gfc_array_size (source, &tmp) == FAILURE)
I suspect there may be problems with arrays and/or functions that
use these derived types.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (2 preceding siblings ...)
2010-12-18 6:45 ` sgk at troutmask dot apl.washington.edu
@ 2010-12-18 10:07 ` burnus at gcc dot gnu.org
2010-12-18 15:38 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 10:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 10:07:33 UTC ---
(In reply to comment #3)
> + if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> + && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> + && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> + || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> + return NULL;
> +
Won't this cause problems with user-defined types with the same name?
Additionally, I would rather bring C_PTR/C_FUNPTR closer a normal derived type
(which is only in the last step treated specially) than to introduce hacks like
that.
The reason for the crash is that in gfc_interpret_derived the pointer component
of "c_ptr" ("__c_ptr_c_address") has no backend declaration (cmp->backend_decl
== NULL) - and thus "ptr = TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET
(cmp->backend_decl))" crashes. Maybe it is sufficient to set it via
gfc_typenode_for_spec in that function.
I think the advantage of fixing this part of the code is that one can simplify
the code at compile time - which is usually preferred to run-time evaluation.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (3 preceding siblings ...)
2010-12-18 10:07 ` burnus at gcc dot gnu.org
@ 2010-12-18 15:38 ` burnus at gcc dot gnu.org
2010-12-18 16:21 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 15:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 15:38:18 UTC ---
Draft patch:
--- a/gcc/fortran/target-memory.c
+++ b/gcc/fortran/target-memory.c
@@ -445,6 +445,21 @@ gfc_interpret_derived (unsigned char *buffer, size_t
buffer_size, gfc_expr *resu
type = gfc_typenode_for_spec (&result->ts);
cmp = result->ts.u.derived->components;
+ if (result->ts.u.derived->from_intmod == INTMOD_ISO_C_BINDING
+ && (result->ts.u.derived->intmod_sym_id == ISOCBINDING_PTR
+ || result->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR))
+ {
+ gfc_constructor *c;
+ gfc_expr *e = gfc_get_constant_expr (cmp->ts.type, cmp->ts.kind,
+ &result->where);
+ c = gfc_constructor_append_expr (&result->value.constructor, e, NULL);
+ c->n.component = cmp;
+ gfc_target_interpret_expr (buffer, buffer_size, e);
+ e->ts = result->ts;
+ e->ts.is_iso_c = 1;
+ return int_size_in_bytes (ptr_type_node);
+ }
+
/* Run through the derived type components. */
for (;cmp; cmp = cmp->next)
{
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (4 preceding siblings ...)
2010-12-18 15:38 ` burnus at gcc dot gnu.org
@ 2010-12-18 16:21 ` burnus at gcc dot gnu.org
2010-12-18 17:11 ` sgk at troutmask dot apl.washington.edu
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 16:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 16:21:00 UTC ---
(In reply to comment #5)
> Draft patch:
Which of course does not work ...
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (5 preceding siblings ...)
2010-12-18 16:21 ` burnus at gcc dot gnu.org
@ 2010-12-18 17:11 ` sgk at troutmask dot apl.washington.edu
2010-12-18 20:19 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2010-12-18 17:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 17:10:59 UTC ---
On Sat, Dec 18, 2010 at 10:07:51AM +0000, burnus at gcc dot gnu.org wrote:
>
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 10:07:33 UTC ---
> (In reply to comment #3)
> > + if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> > + && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> > + && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> > + || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> > + return NULL;
> > +
>
> Won't this cause problems with user-defined types with the same name?
A check for mold->ts.u.derived->attr.is_iso_c could be added, but
yes I agree that this appears to somewhat hackish. In fact, the
patch fails in a interesting way with a new piece of code from
James.
program bug6
use ISO_C_BINDING
implicit none
interface
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
end function fun
end interface
type(C_PTR) array(2)
type(C_FUNPTR) result
integer(C_INTPTR_T), parameter :: const(*) = [32512,32520]
result = fun()
array = transfer([integer(C_INTPTR_T)::32512,32520],array)
! write(*,*) transfer(result,const)
! write(*,*) transfer(array,const)
end program bug6
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
fun = transfer(32512_C_INTPTR_T,fun)
end function fun
With this code, mold->ts.type is BT_INTEGER, the backend_decl
is NULL, and mold->ts.u.derived contains the information that
we need.
So, yes, creating a proper backend_decl when C_PTR or C_FUNPTR
is parsed/resolved is probably the correct solution. Unfortunately,
I don't know how or where to do that. :(
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (6 preceding siblings ...)
2010-12-18 17:11 ` sgk at troutmask dot apl.washington.edu
@ 2010-12-18 20:19 ` burnus at gcc dot gnu.org
2010-12-18 20:26 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 20:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 20:18:47 UTC ---
Author: burnus
Date: Sat Dec 18 20:18:43 2010
New Revision: 168031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168031
Log:
2010-12-18 Tobias Burnus <burnus@net-b.de>
PR fortran/46974
* target-memory.c (gfc_interpret_derived): Handle
* C_PTR/C_FUNPTR.
* trans-expr.c (gfc_trans_structure_assign): Ditto.
(gfc_conv_expr): Avoid crashes using non-C_NULL_(FUN)PTR const expr.
2010-12-18 Tobias Burnus <burnus@net-b.de>
PR fortran/46974
* gfortran.dg/c_ptr_tests_16.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/target-memory.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (7 preceding siblings ...)
2010-12-18 20:19 ` burnus at gcc dot gnu.org
@ 2010-12-18 20:26 ` burnus at gcc dot gnu.org
2010-12-19 11:25 ` burnus at gcc dot gnu.org
2010-12-20 21:44 ` burnus at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-18 20:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 20:26:07 UTC ---
FIXED on the trunk (4.6).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (8 preceding siblings ...)
2010-12-18 20:26 ` burnus at gcc dot gnu.org
@ 2010-12-19 11:25 ` burnus at gcc dot gnu.org
2010-12-20 21:44 ` burnus at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-19 11:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-19 11:24:34 UTC ---
*** Bug 34199 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/46974] ICE with TRANSFER using a C_PTR entity
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
` (9 preceding siblings ...)
2010-12-19 11:25 ` burnus at gcc dot gnu.org
@ 2010-12-20 21:44 ` burnus at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-20 21:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-20 21:44:02 UTC ---
Author: burnus
Date: Mon Dec 20 21:43:58 2010
New Revision: 168095
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168095
Log:
2010-12-20 Tobias Burnus <burnus@net-b.de>
PR fortran/46974
* gfortran.dg/c_ptr_tests_16.f90: Fix endian issue.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-12-20 21:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-15 21:39 [Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity kargl at gcc dot gnu.org
2010-12-17 23:15 ` [Bug fortran/46974] " kargl at gcc dot gnu.org
2010-12-18 0:01 ` sgk at troutmask dot apl.washington.edu
2010-12-18 6:45 ` sgk at troutmask dot apl.washington.edu
2010-12-18 10:07 ` burnus at gcc dot gnu.org
2010-12-18 15:38 ` burnus at gcc dot gnu.org
2010-12-18 16:21 ` burnus at gcc dot gnu.org
2010-12-18 17:11 ` sgk at troutmask dot apl.washington.edu
2010-12-18 20:19 ` burnus at gcc dot gnu.org
2010-12-18 20:26 ` burnus at gcc dot gnu.org
2010-12-19 11:25 ` burnus at gcc dot gnu.org
2010-12-20 21:44 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).