--- 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 results, which
--- 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 #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 #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 gcc dot gnu dot org changed
--- 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 a full bug
--- 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 * {ref-all})vtyp] = MEM
--- 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 'rcrdrd':
g.f90:1:0: internal compiler error
--- 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|Removed
gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45619
--- 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-number
--- 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-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 case the actual
--- 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 #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 #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 #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 report.
Now other
--- 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 response said it was a bug so I submitted
--- 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 stdio.h
void requestdouble_(double*, double*, char
--- 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 #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 function. Our
--- 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 dot gnu dot org
--- 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|Removed
--- 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 #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 #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 #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=21526action=view) [edit]
Run-time implementation
Implementation works, but I would like to pass
--- 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 #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 #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 #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=21444action=view)
Reduced testcase
Reduced testcase. gdb shows
Program received signal SIGSEGV, Segmentation fault.
0x080ed4c0
--- 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 I need to back
--- 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
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-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 commit to no avail
--- 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
ASSOCIATED
--- 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 (Revision 162868
--- 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't had enough coffee
--- 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 #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 TYPE
--- 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 constructor is
changed
--- 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=21323action=view)
Reduced testcase
Here's a reduced testcase.
--
kargl at gcc dot gnu dot org changed:
What
--- 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 #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=21289action=view)
Updated diff that handles intrinsics type
The attached patch handles intrinsic types in match_type_spec better
--- 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 |Added
--- 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=gccview=revrev=162386
Log:
2010-07-21 Steven G. Kargl ka...@gcc.gnu.org
PR fortran
--- 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=gccview=revrev=162389
Log:
2010-07-21 Steven G. Kargl ka...@gcc.gnu.org
PR
--- 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 #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 |Added
--- 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=gccview=revrev=162325
Log:
2010-07-19 Steven G. Kargl ka...@gcc.gnu.org
PR
--- 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=gccview=revrev=162326
Log:
2010-07-19 Steven G. Kargl ka...@gcc.gnu.org
PR
--- 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-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 libgfortran doesn't require (and
shouldn't
require
--- 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 have two modules, both defining
--- 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:
use m_die, only : die
1
--- 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 #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:
in m_die.F90 we declare
--- 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 when libpthread is linked
--- 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 change the
runtime
error. Also I doubt
--- 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(kind=8) :: r8)
end
works
--- 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-spec
--- 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=21194action=view)
patch for original problem
Patch the fixed Satish's original problem. It simply checks
for a derived type prior
--- 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 |Added
--- 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 problem
--- 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
--- 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', number = unit8
--- 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 at (1
--- 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 #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
gcc-bugzi...@gcc.gnu.org wrote:
Comment #1
--- 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 case that still fails
--- 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 simply removes lines
--- 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 #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 eye. I'm
--- 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 PROGRAM test
mrich
) 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 #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 dot org
--- 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 the Fortran
--- 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 implementation should fail
--- 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 |Added
--- 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 the commit noted
--- 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
subroutine
--- 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 the last
--- 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.
Can you try
--- 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
(160820) and http://gcc.gnu.org/ml
--- 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-testresults/2010-06/msg01649.html
--- 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 targets
If a pointer
--- 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 Steve
--- 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 #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 #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 #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)
goto
--- 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' could be changed to 'dg-do compile'
--
http
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-31 16:29 ---
Thanks for the bug report. Technically, the prohibition of
nonnegative is on the programmer, and as such the code is
illegal. gfortran can do anything it wants with the program
including starting world war iii
--- 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
--- 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 #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 I get 5.
Of course it prints 5
--- 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= should not be the same as the 'i'
in
=1,i.
Well
--- 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 and I are in a different
scoping unit
--- 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 #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=20787action=view) [edit]
draft patch
This makes loop bounds evaluation before the internal variable
1 - 100 of 1396 matches
Mail list logo
