--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-18 17:11 ---
(In reply to comment #2)
> So what was
> required to clarify an issue for a number of people ended up confusing you.
> Also note that every
> compiler tried (XL, ifort, g95, gfortran) had different re
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-17 21:53 ---
Could you format your bug report any more poorly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45710
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-15 21:08 ---
(In reply to comment #2)
> Hi,
>
> as it's already fixed in newer versions, please don't spend any more time on
> this.
>
OK.
Once again thanks for sending a bug report.
--
kargl at gc
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-15 18:30 ---
Thanks for the bug report. The problem appears to be fixed in
gcc version 4.6.0 20100913 (experimental) (GCC)
and
gcc version 4.5.1 20100728 (prerelease) (GCC).
It is unlikely that this will be fixed in 4.4.x
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-10 15:34 ---
(In reply to comment #3)
> (In reply to comment #1)
> > I have a slightly different result with your code.
> >
> > troutmask:sgk[212] gfc4x -c -O g.f90
> > g.f90: In function '
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-10 15:20 ---
The -fdump-tree-original for HJ's original code look like
rcrdrd (character(kind=1)[1:4] & restrict vtyp, integer(kind=4) _vtyp)
{
static character(kind=1) dbl[1:1] = "D";
(MEM[(c_char * {r
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-10 15:12 ---
I have a slightly different result with your code.
troutmask:sgk[212] gfc4x -c -O g.f90
g.f90: In function 'rcrdrd':
g.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218
Please submit
--- Comment #2 from kargl at gcc dot gnu dot org 2010-09-09 22:25 ---
There is no way to fix this problem unless you
would like +inf along the diagonal.
gfortran will constant fold 1./alpha if alpha has
the parameter attribute. After all, this attribute
tells the compiler that alpha
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-09 20:44 ---
(In reply to comment #2)
> How do I open a glibc bug?
> Although you say that the sign bit is set, thus you can have a negative NAN.
> But it does not make much sense to allow this. A negative not-a-numb
at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45619
--- Comment #6 from kargl at gcc dot gnu dot org 2010-09-09 19:02 ---
Fixed in trunk.
No plans for back port to 4.5.x branch.
I'll open a bug report about intent(out)
issues with dummy arguments.
--
kargl at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from kargl at gcc dot gnu dot org 2010-09-02 21:46 ---
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00190.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45495
--- Comment #4 from kargl at gcc dot gnu dot org 2010-09-02 20:12 ---
I may have a patch for this one.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-02 14:17 ---
(In reply to comment #2)
> Confirm: It compiles with g95 and NAG f95, but ICEs with gfortran (4.1 to 4.6)
> and a couple of other compilers.
>
> My feeling is that the program is invalid - at least in cas
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-31 19:09 ---
(In reply to comment #5)
> Thanks. I do know how to work around it with subroutine which I already did in
> my program. But it doesn't explain why 4.1.2 version allows return character
> string from
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
Closing as INVALID.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-31 17:53 ---
Try compiling with -fdump-tree-original and inspecting the
expected argument lists. You really don't want to use a
function here. Use a subroutine.
include
void requestdouble_(double*, double*, char *, int
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-31 16:49 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Sorry. When I looked after I had posted the question there was only one
> > > response and that resp
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-31 16:40 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Sorry. When I looked after I had posted the question there was only one
> > response and that response said it was a bug so I submitted this bug
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-31 13:28 ---
Did you see the responses to your post in c.l.f?
It seems that your program is non-conforming. I
leave the PR open until either I or someone else
has time to verify the conformity of the program.
--
http
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-28 00:25 ---
Reverting 163597 fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-27 23:47 ---
FX, I've added you to this pr because I think your recent patch
to start integration of the REAL(16) code is the cause.
--
kargl at gcc dot gnu dot org changed:
What|Re
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-27 23:39 ---
I believe that it is related to r163597. During the build of
libgfortran, the file kinds.h is generated. This file now
has GFC_REAL_10 and GFC_REAL_16 typedef'd to 'long double'.
--
kargl at gcc
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-19 23:28 ---
(In reply to comment #5)
> Created an attachment (id=21526)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21526&action=view) [edit]
> Run-time implementation
>
> Implementation works, but I
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 ---
*** Bug 45339 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45338
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-19 13:08 ---
*** This bug has been marked as a duplicate of 45338 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-15 18:46 ---
A patch to do the parsing and some error checking has
been posted at
http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html
It is not a complete implementation of the feature
and requires much additional work
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-10 20:19 ---
The patch in comment #4 passes regression testing on x86_64-*-freebsd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45244
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-10 17:49 ---
Might as well confirm the bug.
This patch stops the segmentation fault, but I do not know
if it is the correct fix.
Index: interface.c
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-10 02:54 ---
Does anyone know which combination of recent commits
is causing this problem? I've tried individually backing
out several of the likely offenders, but I still can't
bootstrap. So, I'm guessing that
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-10 02:37 ---
Created an attachment (id=21444)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21444&action=view)
Reduced testcase
Reduced testcase. gdb shows
Program received signal SIGSEGV, Segmentation fault.
0x0
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-08 15:15 ---
Change severity to blocker.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-07 05:49 ---
(In reply to comment #0)
> Someone has broken bootstrap on i386-*-freebsd. I've backed out
> r162837, r162
>
I meant to state that I've backout 162837, 162888, 162889, and
one other likely recent
blocker
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
GCC host triplet: i386-unknown-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45222
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-05 15:46 ---
The problem also occurs with 4.6.0.
Note, if you remove the ', only : c_ptr' in NAG_J_TYPES,
the code compiles and produces
laptop:kargl[214] gfc4x -o z tr.f90
laptop:kargl[215] ./z
C_ASSOCIATED = T
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-04 18:13 ---
>
> I must be missing something here. What does cl2 do in the above
> patch? You set it, but it is never used.
>
Nevermind, I understand what the code does. I can't even claim
that I haven&#x
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-04 18:09 ---
(In reply to comment #1)
> PATCH - lightly tested. Now regtesting.
>
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-03 02:31 ---
This statement:
character(:), allocatable :: io_message
uses a deferred type parameter (a F2003
feature), which is not supported by gfortran
at this time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-27 06:15 ---
(In reply to comment #5)
> From the error location it looks like a duplicate of PR 44857.
>
Yes, I think you're right. I've reduced it further in
comment #6. The code compiles if the array constr
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-27 06:11 ---
Here's an even shorter testcase.
MODULE FunctionTypes
IMPLICIT NONE
integer, parameter :: OpconNameLength = 4
TYPE, PUBLIC :: TTermDefinition
CHARACTER (OpconNameLength) :: termName(2)
END
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-27 04:54 ---
Reset severity to normal. Fortran bugs are rarely anything but
normal.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-27 04:53 ---
Created an attachment (id=21323)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21323&action=view)
Reduced testcase
Here's a reduced testcase.
--
kargl at gcc dot gnu dot org changed:
--- Comment #17 from kargl at gcc dot gnu dot org 2010-07-22 20:03 ---
Unassign myself. I don't have the smarts to trace through
the derive type handling.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #16 from kargl at gcc dot gnu dot org 2010-07-22 20:02 ---
Created an attachment (id=21289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21289&action=view)
Updated diff that handles intrinsics type
The attached patch handles intrinsic types in match_type_spec
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-21 22:50 ---
I'm closing this PR as FIXED such that I reverted the patch
that caused the problem and re-opened PR fortran/44929.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #15 from kargl at gcc dot gnu dot org 2010-07-21 22:49 ---
Re-opening the bug. My previous patch has been reverted due
to the problems outlined in PR fortran/45005.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from kargl at gcc dot gnu dot org 2010-07-21 22:47 ---
Subject: Bug 44929
Author: kargl
Date: Wed Jul 21 22:47:36 2010
New Revision: 162389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162389
Log:
2010-07-21 Steven G. Kargl
PR fortr
--- Comment #13 from kargl at gcc dot gnu dot org 2010-07-21 22:34 ---
Subject: Bug 44929
Author: kargl
Date: Wed Jul 21 22:34:07 2010
New Revision: 162386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162386
Log:
2010-07-21 Steven G. Kargl
PR fortr
--- Comment #12 from kargl at gcc dot gnu dot org 2010-07-20 05:40 ---
Fixed on 4,5 and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-20 05:39 ---
Subject: Bug 44929
Author: kargl
Date: Tue Jul 20 05:38:49 2010
New Revision: 162326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162326
Log:
2010-07-19 Steven G. Kargl
PR fortr
--- Comment #10 from kargl at gcc dot gnu dot org 2010-07-20 04:01 ---
Subject: Bug 44929
Author: kargl
Date: Tue Jul 20 04:01:32 2010
New Revision: 162325
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162325
Log:
2010-07-19 Steven G. Kargl
PR fortr
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 19:46 ---
Closing as WONTFIX. With trunk being for active development
and 4.4 and 4.5 under maintenance commits, I doubt anyone
will find time to investigate this further.
Thanks for the bug report.
--
kargl at gcc dot
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 18:45 ---
(In reply to comment #8)
> Here's my command line, and the results:
>
> % gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
> m_IndexBin_char.F90:12.25:
>
>
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-16 17:18 ---
(In reply to comment #3)
> I've investigated further, and can reproduce it, but with one more condition
> that I didn't mention in the original bugreport.
> Basically, it happens when we hav
--- Comment #11 from kargl at gcc dot gnu dot org 2010-07-16 14:48 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Please don't keep reopening this bug.
> > > The symbols are weak undefs because
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-16 04:28 ---
(In reply to comment #6)
> Please don't keep reopening this bug.
> The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> require) libpthread, it is thread-safe only w
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-15 17:48 ---
(In reply to comment #0)
> When compiling a generic procedure, the generic name is not entered in the
> symbol table, which then causes subsequent 'use' statements to fail.
>
> Example:
>
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-14 18:21 ---
(In reply to comment #2)
> The original code has a line
>
> REWIND I04
>
> after
>
>
> ENDFILE I04
>
> I have removed it to reduce the test, but adding it does not chang
--- Comment #9 from kargl at gcc dot gnu dot org 2010-07-13 22:20 ---
I'm working on a patch, so I might as well take
ownership of the PR.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from kargl at gcc dot gnu dot org 2010-07-13 21:01 ---
Created an attachment (id=21194)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194&action=view)
patch for original problem
Patch the fixed Satish's original problem. It simply checks
for a derive
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-13 20:41 ---
(In reply to comment #1)
> Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html
Is the original code invalid?
A type is specified in several contexts by a type specifier.
R401 type-s
--- Comment #5 from kargl at gcc dot gnu dot org 2010-07-13 20:35 ---
> Talking about (c): The following valid program is also rejected:
>
> real(8),allocatable :: r8
> allocate( real(8) :: r8)
> end
Hmm. Interesting.
real(8),allocatable :: r8
allocate(real(kin
--- Comment #2 from kargl at gcc dot gnu dot org 2010-07-09 06:02 ---
Is there a testsuite program to check this?
Perhaps, your code should be added so the
correct behavior doesn't get unfixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44879
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-08 18:07 ---
(In reply to comment #5)
> Subject: Re: INQUIRE EXIST variable must be default
> LOGICAL
>
> By the way, the NUMBER variable must be default INTEGER as well.
> Do you agree there is the same
--- Comment #4 from kargl at gcc dot gnu dot org 2010-07-05 20:24 ---
Closing as fix. The default behavior of gfortran is
to accept any logical kind supported by gfortran. If
either -std=f95 or -std=f2003 is given on the command
line, gfortran will issue an error.
Vittorio thanks for
--- Comment #2 from kargl at gcc dot gnu dot org 2010-07-04 06:07 ---
A patch has been posted here
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00291.html
laptop:kargl[208] gfc4x -o z -std=f2003 inquire_5.f90
inquire_5.f90:22.59:
inquire (file = 'inquire_5.txt', numb
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-03 16:04 ---
I believe that this is an intended extension. However,
laptop:kargl[238] gfc4x -o z -std=f95 -fall-intrinsics inquire_5.f90
laptop:kargl[239] ./z
Thus, an error should have been emitted when enforcing f95
or f2003
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-03 15:58 ---
It's an extension.
laptop:kargl[231] gfc4x -o z -std=f95 intrinsic_minmax.f90
intrinsic_minmax.f90:26.17:
if (max (4d0, r) .ne. 4d0) call abort
1
Error: Extension: Different type kinds
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 ---
(In reply to comment #11)
>
> Well, it is invalid code - based on a valid Fortran code. If you use Delta to
> reduce a test case (cf.
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
> it
--- Comment #10 from kargl at gcc dot gnu dot org 2010-06-25 06:29 ---
(In reply to comment #6)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> These previous patches don't seem to solve the problem:
> here is another reduced c
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-25 06:14 ---
(In reply to comment #5)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
> wrote:
> >
> >
&
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-25 04:42 ---
(In reply to comment #2)
> Confirmed. I came up with the exact same patch and it does pass regression
> testing, of course. Collided when I tried to post this. :)
>
:)
The mangled Fortran code caught my
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02 ---
Index: resolve.c
===
--- resolve.c (revision 161047)
+++ resolve.c (working copy)
@@ -12506,6 +12506,9 @@ resolve_equivalence (gfc_equiv *eq)
int
--- Comment #8 from kargl at gcc dot gnu dot org 2010-06-20 16:41 ---
(In reply to comment #7)
> The following occurs in the snapshot of June 19, but not in earlier snapshots:
>
> mrich...@msc545ux:~$ cat test.f90
> PROGRAM test
> END FILE 10
> END FILE 10
> END
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-20 03:53 ---
Update the summary.
AFAICT, for intrinsics procedure that specify an INTENT for its
arguments, the INTENT isn't checked.
Sigh. This is opening a can of worms. More later. :(
--
kargl at gcc dot gnu do
) variable.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: kargl at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-18 19:10 ---
(In reply to comment #4)
> O.K. I doublechecked the standard. The array declared does not need to be
> initialized in this case. So the return value could be any number. However,
> this kind of implementati
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-18 18:49 ---
(In reply to comment #2)
> it should be 0.0 always, NOT to be chaotic number like C, because when ddx is
> declared, it has to be initialized to 0.0 by fortran standard.
>
Can you point the language in th
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-17 19:08 ---
The following patch restores the 4.4.0 behavior for
STAT of not checking derived type components. This
of course now allows invalid code to compile such as
this modified version of OP's test subroutine
subro
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-17 15:26 ---
(In reply to comment #5)
> Remove [4.5/4.6 Regression] from the summary as this
> has never worked, so it can't be a regression.
>
Note, the OP's code appears to work in 4.4.0 because
prior to
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-17 15:22 ---
Remove [4.5/4.6 Regression] from the summary as this
has never worked, so it can't be a regression.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #13 from kargl at gcc dot gnu dot org 2010-06-17 05:08 ---
(In reply to comment #12)
> (In reply to comment #11)
> > Disappeared for cris-elf in (160828:r160836], which agrees i686-linux
> > results
> > on gcc100 at <http://gcc.gnu.org/ml/gcc-test
--- Comment #12 from kargl at gcc dot gnu dot org 2010-06-17 04:43 ---
(In reply to comment #11)
> Disappeared for cris-elf in (160828:r160836], which agrees i686-linux results
> on gcc100 at <http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01649.html>
> (16
--- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 ---
(In reply to comment #5)
> This makes no sense at all. Rainer, I'm really sorry if it seems that I'm
> shooting questions a bit at random, but I have a hard time imagining how to
> narrow it down.
&
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-16 14:34 ---
(In reply to comment #1)
> The following check is to simplistic, it does not work for structures but only
> for simple object names. - with structures, it gets more complicated as also
> comparing the name of
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-11 18:12 ---
Reset several to 'normal'. Fortran bugs are never 'major'.
I believe your code is invalid, and so gfortran can do
anything it wants. F2003 has
19 6.3.3.2 Deallocation of pointer tar
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 22:37 ---
This is a context free PR. Please provide details.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 ---
(In reply to comment #3)
> The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
> depending on the system. Maybe we should add some documentation in the manual
> on this. Thanks
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 04:24 ---
This is probably a bogus PR.
The BOZ literal constants are INTEGER(16) entities
(at least of x86_64). ii8 is an INTEGER(4) item.
The transfer() in the print statement is returning
a INTEGER(16) entity where only
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-09 16:39 ---
Patch has been committed to 4.4, 4.5, and trunk.
Closing.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-02 02:03 ---
Here's a dejagnu testcase.
! { dg-do run }
character(1) c, y
y = 'y'
read(y,*) c
if (c=='y') stop; if (c=='Y') stop
call abort()
end
The 'dg-do run' cou
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-02 00:42 ---
The problem is caused by gfc_match_stopcode().
if (gfc_match_eos () != MATCH_YES)
{
m = gfc_match_init_expr (&e);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
--- Comment #13 from kargl at gcc dot gnu dot org 2010-05-31 23:44 ---
Due to my confusion over the scope of 'i' and 'I',
I posted to c.l.f. As usual Richard Maine pieced
through the standard's language.
http://groups.google.com/group/comp.lang.
--- Comment #12 from kargl at gcc dot gnu dot org 2010-05-31 22:47 ---
(In reply to comment #8)
> Created an attachment (id=20787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787&action=view) [edit]
> draft patch
>
> This makes loop bounds evaluation
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 22:20 ---
Interestingly, if one does not use implicit type, one finds that
the following compiles:
integer, pointer :: p
integer, target :: q
q(i)=i
p=>q(110)
print *,p
end
--- Comment #11 from kargl at gcc dot gnu dot org 2010-05-31 21:54 ---
(In reply to comment #7)
> (In reply to comment #6)
> > because in the above 'i' and 'I' are in the same scoping unit.
> I couldn't find what mandates in the standard that i an
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-31 20:02 ---
(In reply to comment #5)
> > The question becomes whether the 'I' in the implied-do-loop is
> > being used uninitialized.
>
> From comment #3, I think the 'i' in "i,i="
--- Comment #4 from kargl at gcc dot gnu dot org 2010-05-31 18:33 ---
(In reply to comment #2)
> > Note that fortran is case insensitive, ...
>
> Indeed, but I think the implied do loop should still go from 1 to 5. Note that
> if I print 'i' after the loop
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 17:51 ---
I have a complete patch with the mvbits checking done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-31 17:22 ---
I have a patch for the IBITS() portion of the problem.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 1408 matches
Mail list logo
