--- Comment #67 from patchapp at dberlin dot org 2007-11-20 05:07 ---
Subject: Bug number PR31608
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-11/msg00898.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #66 from patchapp at dberlin dot org 2007-11-20 05:02 ---
Subject: Bug number PR31608
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-11/msg00898.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #65 from pault at gcc dot gnu dot org 2007-11-18 17:16 ---
Well, I think that it's fixed on trunk now.
Go on, make my day and find another!
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #64 from pault at gcc dot gnu dot org 2007-11-18 17:14 ---
Subject: Bug 31608
Author: pault
Date: Sun Nov 18 17:14:40 2007
New Revision: 130271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130271
Log:
2007-11-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #63 from pault at gcc dot gnu dot org 2007-11-16 17:01 ---
I suppose that, after all, I should reassign myself.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #62 from rguenther at suse dot de 2007-11-16 09:50 ---
Subject: Re: wrong types in character array/scalar binop
On Fri, 16 Nov 2007, pault at gcc dot gnu dot org wrote:
> --- Comment #61 from pault at gcc dot gnu dot org 2007-11-16 09:23
> ---
> Richard,
>
> I b
--- Comment #61 from pault at gcc dot gnu dot org 2007-11-16 09:23 ---
Richard,
I believe that this is the right outcome for achar_4?
(*(char[0:][1:1] *) atmp.4.data)[S.5][1]{lb: 1 sz: 1} =
*(_gfortran_
compare_string (D.529, &(*(char[0:][1:1] *) atmp.2.data)[S.5][1]{lb: 1
--- Comment #60 from pault at gcc dot gnu dot org 2007-11-14 10:37 ---
(In reply to comment #59)
> 2007-11-13 Jerry DeLisle <[EMAIL PROTECTED]>
Jerry,
I see that you have spent much more time diddling with your regex than I have!
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #59 from jvdelisle at gcc dot gnu dot org 2007-11-14 01:35
---
Subject: Bug 31608
Author: jvdelisle
Date: Wed Nov 14 01:35:09 2007
New Revision: 130173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130173
Log:
2007-11-13 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #58 from dominiq at lps dot ens dot fr 2007-11-13 07:56 ---
> Can those interested test this on char_cast_1.f90 please.
Both wok on PPC and Intel Darwin8. Note that if the first change is chosen, the
comment:
! The sign that all is well is that [S.5][1] appears twice.
shou
--- Comment #57 from jvdelisle at gcc dot gnu dot org 2007-11-13 06:34
---
Regarding the suggestion in comment #55, there is an instance of [S.15][1] in
the dump. It will match if we bump the count from 2 to 3 in the dg-final scan
directive.
So either this:
! { dg-final { scan-tree-d
--- Comment #56 from jvdelisle at gcc dot gnu dot org 2007-11-13 03:46
---
On x86-64-linux-gnu the only failure I could find using
--enable-checking=yes,types was achar_4.f90.
achar_4.f90: In function up:
achar_4.f90:8: error: non-trivial conversion at assignment
char[1:1]
char
(*D.1
--- Comment #55 from pault at gcc dot gnu dot org 2007-11-12 14:04 ---
(In reply to comment #40)
> ! { dg-final { scan-tree-dump-times "\\\[S\.5\\\]\\\[1\\\]" 2 "original" } }
> The tree (dump) itself seems to be ok.
I hadn't noticed that this one had come back over the horizon. I do
--- Comment #54 from rguenther at suse dot de 2007-10-27 20:03 ---
Subject: Re: wrong types in character array/scalar binop
On Sat, 27 Oct 2007, burnus at gcc dot gnu dot org wrote:
> --- Comment #53 from burnus at gcc dot gnu dot org 2007-10-27 19:57
> ---
> > Note that I s
--- Comment #53 from burnus at gcc dot gnu dot org 2007-10-27 19:57 ---
> Note that I still see achar_4.f90 fail with type-checking and there are now
> some more testcases that also fail.
Reopened based on this comment to make sure we won't forget about this PR.
To recap:
a) We need t
--- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-27
00:29 ---
Subject: Re: wrong types in character array/scalar binop
Fixed on PA.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #51 from danglin at gcc dot gnu dot org 2007-10-27 00:21
---
Subject: Bug 31608
Author: danglin
Date: Sat Oct 27 00:21:02 2007
New Revision: 129671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129671
Log:
PR fortran/31608
* pa.h (ASM_PN_FORMAT): De
--- Comment #50 from rguenth at gcc dot gnu dot org 2007-10-26 22:17
---
Note that I still see achar_4.f90 fail with type-checking and there are now
some
more testcases that also fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
23:17 ---
Subject: Re: wrong types in character array/scalar binop
> Yes, I found this after my last mail. I need to review this. The define
> is definitely not needed on linux.
The HP assembler allows dots in s
--- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
20:57 ---
Subject: Re: wrong types in character array/scalar binop
> ./pa/pa.h:#define ASM_PN_FORMAT "%s___%lu"
> ./v850/v850.h:#define ASM_PN_FORMAT "%s___%lu"
>
> It looks like you do :-)
Yes, I found this afte
--- Comment #47 from pinskia at gmail dot com 2007-10-25 20:45 ---
Subject: Re: wrong types in character array/scalar binop
On 25 Oct 2007 19:50:54 -, Tobias dot Schlueter at physik dot
uni-muenchen dot de <[EMAIL PROTECTED]> wrote:
> I wonder why this name-mangling is necessary, i
On 25 Oct 2007 19:50:54 -, Tobias dot Schlueter at physik dot
uni-muenchen dot de <[EMAIL PROTECTED]> wrote:
> I wonder why this name-mangling is necessary, it's not like these names
> are going to appear in the assembly, is it?
Those will not but other will like:
void f(void)
{
void g(void
--- Comment #46 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-25 19:50 ---
Subject: Re: wrong types in character array/scalar binop
dave at hiauly1 dot hia dot nrc dot ca wrote:
> Subject: Re: wrong types in character array/scalar binop
>
>> ASM_FORMAT_PRIVAT
--- Comment #45 from burnus at gcc dot gnu dot org 2007-10-25 18:17 ---
(In reply to comment #44)
> # define ASM_PN_FORMAT "%s.%lu"
> # define ASM_PN_FORMAT "%s$%lu"
> # define ASM_PN_FORMAT "__%s_%lu"
>
> In any case, the test should support the three formats in ASM_PN_FORMAT.
We
--- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
18:03 ---
Subject: Re: wrong types in character array/scalar binop
> ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : "T",
I'm still don't understand how we get underscores. We have in defaults.h:
#ifndef
--- Comment #43 from rguenther at suse dot de 2007-10-25 16:01 ---
Subject: Re: wrong types in character array/scalar binop
On Thu, 25 Oct 2007, Tobias dot Schlueter at physik dot uni-muenchen dot de
wrote:
>
>
> --- Comment #42 from Tobias dot Schlueter at physik dot uni-muench
--- Comment #42 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-25 15:48 ---
Subject: Re: wrong types in character array/scalar binop
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
> 15:4
--- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
15:41 ---
Subject: Re: wrong types in character array/scalar binop
> While on x86_64-gnu-linux the dump has:
> int8 S.5;
> the variable on hppa-unknown-linux-gnu is:
> int4 S___5;
I wonder why the variables na
--- Comment #40 from burnus at gcc dot gnu dot org 2007-10-25 06:36 ---
(In reply to comment #37)
> Test is failing on hppa-unknown-linux-gnu:
> PASS: gfortran.dg/char_cast_1.f90 -O (test for excess errors)
> FAIL: gfortran.dg/char_cast_1.f90 -O scan-tree-dump-times \[S.5\]\[1\] 2
W
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Subject: Re: wrong types in character array/scalar binop
Tree dump attached.
Dave
--- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Created an attachment (id=14
--- Comment #37 from danglin at gcc dot gnu dot org 2007-10-25 02:31
---
Test is failing on hppa-unknown-linux-gnu:
Executing on host:
/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gf
ortran -B/home/dave/gnu/gcc-4.3/objdir/gcc/testsuite/gfortran/../../
/home/dave/
gnu/gcc-
--- Comment #36 from pault at gcc dot gnu dot org 2007-10-20 09:35 ---
Sorry I took a bit of time to do it - fixed on trunk.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from pault at gcc dot gnu dot org 2007-10-20 09:27 ---
Subject: Bug 31608
Author: pault
Date: Sat Oct 20 09:27:09 2007
New Revision: 129505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129505
Log:
2007-10-20 Paul Thomas <[EMAIL PROTECTED]>
FX Coud
--- Comment #34 from patchapp at dberlin dot org 2007-10-20 04:22 ---
Subject: Bug number PR31608
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-10/msg01072.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #33 from dominiq at lps dot ens dot fr 2007-10-12 20:31 ---
> It's an easy fix but let's do one thing at a time:-)
Sure! I have filled PR33759
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #32 from pault at gcc dot gnu dot org 2007-10-12 17:32 ---
(In reply to comment #31)
> Works as advertised without regression so far (PPC Darwin, 32 bit mode close
> to
> complete), but for the codelets in #30.
>
> I wonder if the code in #28 is valid: the line(s)
>
> merg
--- Comment #31 from dominiq at lps dot ens dot fr 2007-10-11 10:17 ---
Works as advertised without regression so far (PPC Darwin, 32 bit mode close to
complete), but for the codelets in #30.
I wonder if the code in #28 is valid: the line(s)
merge(transfer(string,"x",len(string)), stri
--- Comment #30 from pault at gcc dot gnu dot org 2007-10-11 05:17 ---
(In reply to comment #21)
> print *, transfer(achar([0]), 0_1)
> end
> Reducing this testcase has opened Pandora's box, I'll try to fix them one
> after
> another.
FX,
This one is highly unpleasant and seems t
--- Comment #29 from rguenther at suse dot de 2007-10-10 15:47 ---
Subject: Re: wrong types in character array/scalar binop
On Wed, 10 Oct 2007, pault at gcc dot gnu dot org wrote:
> --- Comment #28 from pault at gcc dot gnu dot org 2007-10-10 15:44
> ---
> The patch below f
--- Comment #28 from pault at gcc dot gnu dot org 2007-10-10 15:44 ---
The patch below fixes the lot. It was not necessary in the end to touch
trans-intrinsic.c. Once the appropriate, offending bit of trans-array.c was
fixed, all the casting occurred correctly. The fixes to iresolve.c
--- Comment #27 from pault at gcc dot gnu dot org 2007-10-10 07:05 ---
(In reply to comment #17)
> char.3 = (*(char[0:][1:1] *) atmp.0.data)[S.2][1]{lb: 1 sz: 1};
> (*(char[0:][1:1] *) atmp.1.data)[S.2] = char.3;
> the first line is correct, the second is not.
Fo
--- Comment #26 from rguenther at suse dot de 2007-10-08 08:47 ---
Subject: Re: wrong types in character array/scalar binop
On Sun, 7 Oct 2007, pault at gcc dot gnu dot org wrote:
>
>
> --- Comment #25 from pault at gcc dot gnu dot org 2007-10-07 12:49
> ---
> (In reply to
--- Comment #25 from pault at gcc dot gnu dot org 2007-10-07 12:49 ---
(In reply to comment #17)
>
> the first line is correct, the second is not.
>
Richard, does this do it for you?
{
char char.3[1:1];
char.3[1]{lb: 1 sz: 1} = (*(char[0:][1:1] *) atmp.0.data)[S.2][1]{lb:
--- Comment #24 from dominiq at lps dot ens dot fr 2007-10-06 21:47 ---
The patch in comment #22 fixes the 3 PR's, but cause a quite massive regression
on my tests, for instance:
INTEGER :: I
CHARACTER(LEN=100) :: data="1.0 3.0"
REAL :: C,D
READ(data,*) C,D
I=TRANSFER(C/D,I)
SELECT CASE
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-10-05 22:02
---
(In reply to comment #22)
> Created an attachment (id=14307)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14307&action=view) [edit]
> Patch for 4 testcases of this PR
It also fixes that one:
contains
C
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-10-05 21:59
---
Created an attachment (id=14307)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14307&action=view)
Patch for 4 testcases of this PR
The following three cases are fixed by the patch attached (fix resolution
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-05 17:41
---
Yet another one:
print *, transfer(achar([0]), 0_1)
end
Reducing this testcase has opened Pandora's box, I'll try to fix them one after
another.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-10-03 08:08
---
Further reduced testcase:
integer i(1)
print *, transfer(achar(i), "x")
end
The type mismatch disappears if you change the transfer statement into
transfer(["x"]), "x", so this is a problem in the return
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-11 10:25 ---
(In reply to comment #16)
> Trying to reduce the testcase, the following ICEs:
PR 31610 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-07-11 10:13
---
Built from
#0 build4_stat (code=ARRAY_REF, tt=0x2b468e0df750, arg0=0x2b468e0e4880,
arg1=0x2b468e0e7000, arg2=0x0, arg3=0x0)
at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3170
#1 0x00497ae4
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-11 10:00
---
Reduced testcase:
contains
Character (len=20) Function Up (string)
Character(len=*) string
Up = transfer(achar(iachar(transfer(string,"x",1))), "x")
return
end function Up
end
char.3
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-11 09:55
---
Trying to reduce the testcase, the following ICEs:
contains
Character (len=20) Function Up (string)
Character(len=*) string
Up =&
tran
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-11 08:52 ---
FYI, testcase is standard conforming code AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #14 from rguenther at suse dot de 2007-07-11 08:36 ---
Subject: Re: wrong types in character array/scalar binop
On Wed, 10 Jul 2007, pinskia at gcc dot gnu dot org wrote:
> --- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-10 23:36
> ---
> I think this
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-10 23:36
---
I think this was fixed with
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01471.html
aka PR32140.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-31 20:40 ---
I am not at all convinced that this is the fault of gfc_trans_array_transfer.
It is quite correctly producing &(*(char[0:][1:1] as the output type. The
problem is the comaprison between an array of character(1)'s an
57 matches
Mail list logo
