--- Comment #18 from pault at gcc dot gnu dot org 2009-04-06 10:52 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pault at gcc dot gnu dot org 2009-03-31 18:42 ---
This was fixed on trunk as revision 145196 but I screwed up the commit message.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
--- Comment #16 from pault at gcc dot gnu dot org 2009-03-13 12:52 ---
Patch pending. See:
http://gcc.gnu.org/ml/fortran/2009-03/msg00050.html
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
--- Comment #15 from pault at gcc dot gnu dot org 2008-12-24 17:08 ---
(In reply to comment #13)
Dear Dominique,
> print *, len(string)
> print *, size(transfer(string,"xy",len(string)))
> yields a wrong code: the executable gives
>
>8
>4
> ab
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-20 14:27 ---
Regtested with -m32 and -m64 without other regression that
gcc/testsuite/gfortran.dg/char_length_7.f90. The offending line is:
! This was another bug, uncovered when the PR was fixed.
if (any(ccopy(z//mz(:)(i:j))
--- Comment #13 from dominiq at lps dot ens dot fr 2008-12-20 13:01 ---
The patch in comment #12 fixes the pr without causing the regressions reported
in comments #8 and #9.
Compiling gcc/testsuite/gfortran.dg/char_length_7.f90 gives an ICE:
gimplification failed:
2
constant 2>
/opt/gc
--- Comment #12 from pault at gcc dot gnu dot org 2008-12-19 23:59 ---
Created an attachment (id=16949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16949&action=view)
a not quite patch for the PR
I'm down to one regression now - the last test of char_length_7.f90.
Pah! That was
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-12-19 17:20
---
(In reply to comment #10)
> Many thanks, Dominique! At least I have something to work on. It's a cursed
> nuisance not having access to a fully functioning system, when I have time to
> work on gfortran. I think th
--- Comment #9 from dominiq at lps dot ens dot fr 2008-12-18 21:36 ---
Another bus error with
! { dg-do run }
! Test fix of PR28118, in which a substring reference to an
! actual argument with an array reference would cause a segfault.
!
! Contributed by Paul Thomas
!
program gfcbug33
--- Comment #8 from dominiq at lps dot ens dot fr 2008-12-18 21:20 ---
With the patch in comment #6, this pr is fixed but now the code
character(len=1) :: string
print *, transfer(((transfer(string,"x",1))), "x")
end
and friends (from pr31608) gives a bus error:
pr31608_1.f90: I
--- Comment #7 from pault at gcc dot gnu dot org 2008-12-18 16:38 ---
Created an attachment (id=16929)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16929&action=view)
testcase for the PR
This might have departed somewhat from the original but it does at least work
with the patch!
--- Comment #6 from pault at gcc dot gnu dot org 2008-12-18 16:35 ---
Created an attachment (id=16928)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16928&action=view)
Provisional patch for the PR
Testcase follows in next attachement.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #5 from pault at gcc dot gnu dot org 2008-12-18 09:13 ---
I am most of the way onto a solution for this so I'll assign myself.
The source of the problem is highlighted by two tests:
s/call foo(func("_"//bar()))/call foo(func(bar()))/
works fine as does a modified testcase
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-17 07:33 ---
Not a regression:
gfortran ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed source
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-16 16:03 ---
If the subroutine
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
is replaced with
subroutine xmain()
character (len=2) :: zz(2)
zz=func("_"//bar())
call foo(zz)
end subroutine xmain
the code co
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-16 15:35 ---
Yes, confirmed.
The offending line is:
call foo(func("_"//bar()))
In trans-expr.c, se->loop is NULL in the gcc_assert:
2844 else if (sym->result->attr.dimension)
2845 {
2846 gcc_assert (se->
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-16 07:24 ---
Confirmed on (powerpc|i686)-apple-darwin9 revision 142767.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
17 matches
Mail list logo
