--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-02 19:28 ---
(In reply to comment #1)
> Index: parse.c
> ===
> --- parse.c (revision 113473)
> +++ parse.c (working copy)
> @@ -624,6 +624,7 @@
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-02 19:30 ---
Add openmp to keywords.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-05-03 17:10 ---
Phillipe,
Your code appears to be wrong, or perhaps you've cut down a
larger code too agressively. You use the Fortran ALL intrinsic
on the allocatable NEW_NUMBER, but you have never actually
allocated memor
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Subject: Bug 26896
Author: kargl
Date: Wed May 3 21:24:11 2006
New Revision: 113502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113502
Log:
2006-03-30 Steven G. Kargl <[EMAIL PROTECTED]&g
--- Comment #8 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Subject: Bug 20248
Author: kargl
Date: Wed May 3 21:24:11 2006
New Revision: 113502
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113502
Log:
2006-03-30 Steven G. Kargl <[EMAIL PROTECTED]&g
--- Comment #3 from kargl at gcc dot gnu dot org 2006-05-03 21:24 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from kargl at gcc dot gnu dot org 2006-05-03 21:26 ---
Fixed by the additional of -fall-intrinsics option.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from kargl at gcc dot gnu dot org 2006-05-04 22:04 ---
Harald,
I've looked at the problem. The -Wall option will set the -Wnonstd-intrinsic
option. This flag appears to trigger a warning when used with -pedantic.
It does not trigger a warning if you use it with
--- Comment #16 from kargl at gcc dot gnu dot org 2006-05-05 23:19 ---
Fixed, again. ;-)
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-06 06:14 ---
Why?
Is it that difficult to write a module
to provide sind and friends?
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-12 17:43 ---
(In reply to comment #5)
> Created an attachment (id=11443)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11443&action=view) [edit]
> A simple program showing that initialization of BOZ constan
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-18 20:41 ---
Actually, transpose by itself does the right thing. It is the
combination of matmul and transpose that is screwing up indexing.
A slightly modified version of your program gives
troutmask:kargl[290] ./z
1.0 0.0 0.0
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:01 ---
Arjen,
There appears to be something strange with your report. The "Reported Against"
field in bugzilla shows 4.2.0. But, the verbose output shows that you are
linking against a 4.1.0-20050522 libgfortran
--- Comment #1 from kargl at gcc dot gnu dot org 2006-05-21 16:03 ---
The problem occurs on i386-*-freebsd
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2006-05-21 16:14 ---
Bernhard,
Your patch only addresses one aspect of the problem.
Consider
function _foo
entry _bar
end function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
--- Comment #6 from kargl at gcc dot gnu dot org 2006-05-28 16:52 ---
Guys,
Have you read 4.3.2.1.1? This defines the requirements on the
collating of the default character type. It also defines the
requirements on LGT, LGE, LLE, and LLT, which is why we use the
ascii_table in
--- Comment #4 from kargl at gcc dot gnu dot org 2006-06-05 17:40 ---
(In reply to comment #3)
> I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits
> an error, but Intel and Sun compilers don't. Uttam, do you know if that code
> is
&g
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-08 00:05 ---
(In reply to comment #2)
> I would like to work on this one. The range check is only looking for
> ARITH_OK
> when it could also see ARITH_UNDERFLOW or ARITH_OVERFLOW.
>
Jerry,
There is another PR ab
--- Comment #5 from kargl at gcc dot gnu dot org 2006-06-08 01:26 ---
(In reply to comment #4)
>
> I think the patch will be straight forward including updating the appropriate
> texi. The -fallow-inf-nan can be applied to range_check in simplify.c and
> that
> will co
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-10 05:03 ---
Erik,
Thanks for the report. This is yet another example of gfortran's
error handling code getting confused. If you remove the "if (.true.)"
then you get the error message you want. If the if state
--- Comment #2 from kargl at gcc dot gnu dot org 2006-06-10 20:27 ---
I have a tentative patch for this problem that I'm testing now.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-12 00:02 ---
Okay, your bug report says gcc 4.0.0 and the reported against
field says 4.2.0. Which is correct, because gfortran does
the right thing with gcc 4.2.0.
--
kargl at gcc dot gnu dot org changed:
What
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-12 14:23 ---
I don't see the internal error.
laptop:kargl[205] cat > r.f90
subroutine FOO
character*20 X 0
data X /'A'/0
end subroutine FOO
laptop:kargl[206] gfc -c r.f9
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-12 22:56 ---
*** This bug has been marked as a duplicate of 27980 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2006-06-12 22:56 ---
*** Bug 28006 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-17 02:06 ---
See the first two sentences in Section 8 of gfortran.info.
This is very low hanging fruit, and is placed way below
fixing actual bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-23 21:05 ---
Subject: Bug 27981
Author: kargl
Date: Fri Jun 23 21:05:04 2006
New Revision: 114950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114950
Log:
2006-06-23 Steven G. Kargl <[EMAIL PROTECTED]&g
--- Comment #4 from kargl at gcc dot gnu dot org 2006-06-23 21:12 ---
Applied to trunk. I'll apply this to 4.1 in a few days.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from kargl at gcc dot gnu dot org 2006-07-03 03:15 ---
I have a patch for this, but I want to see if I can move
it up into the parsing/matching portion of gfortran.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-07-04 02:40 ---
Patch is here
http://gcc.gnu.org/ml/fortran/2006-07/msg00015.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
--- Comment #2 from kargl at gcc dot gnu dot org 2006-07-05 21:53 ---
Confirmed.
I have a patch, but it may depend on MPFR 2.2.0.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-08 18:23 ---
FLUSH is not a subroutine in F2003. The FLUSH() subroutine extension
is excluded from the list of intrinsic procedures that gfortran
supplies when you set -std=f2003.
See the F2003 standard for the correct syntax
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-14 15:01 ---
AFAIK, there isn't a option to do what you want. However,
this works. It is even standard conforming so it's
future proof whnen you move to another compiler.
program gfcbug37
external second
a = s
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-12 20:27 ---
While gfortran should not ICE, I'd be interested in knowing if
this code compiles with any other compiler. (Hint: remove
elemental from trim_append).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-12 20:29 ---
Add ice-on-invalid-code to keywords.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-12 20:39 ---
Whoop, it is valid Fortran 2003. I forgot that
Lahey's checker does not understand the F2003
array syntax.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-12 23:02 ---
The problem appears to be with the reference to SAME() in
subroutine xmain()
call foo(trim_append(["a"],same(["b"])))
end subroutine xmain
If one changes this to
call foo(trim_append([&q
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-14 18:40 ---
(In reply to comment #0)
> The following program runs without error when compiled with g77 3.4.6 on
> Redhat
> Linux:
>
>character*72 fnint
>data fnint /'/dev/null&#
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-14 20:54 ---
(In reply to comment #2)
> It's not a bug in my program. It's a bug in NONMEM VI. That is, assuming that
> /dev/tty and /dev/null are files, which they're not. They're devices.
OK, th
--- Comment #6 from kargl at gcc dot gnu dot org 2008-11-15 17:28 ---
(In reply to comment #5)
>
> I do believe that one could write a standard conforming "layer" in Fortran to
> handle all of the OPs issues. Obviously one would have to get creative to do
&g
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-16 19:08 ---
Here's the testcase from Tobias on IRC
use iso_c_binding
complex(c_double), target :: z
type(c_ptr) :: ptr
ptr = c_loc(z)
end
Note, the standard says that c_double and c_double_complex are the
same
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-18 19:41 ---
This is a regression that appears to be caused by
r140879 | pault | 2008-10-04 22:50:00 -0700 (Sat, 04 Oct 2008) | 12 lines
2008-10-04 Paul
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-24 15:19 ---
Your shell script contains items of the form
/home/norm/design/numrec/nrTypeM.f90
which of course doesn't exist so the shell script
aborts when executed.
BTW, if it is fixed on amd64, then it is mostlikely
--- Comment #4 from kargl at gcc dot gnu dot org 2008-11-24 15:32 ---
After removing all of your full path names, I get
REMOVE:kargl[215] gfc4x WinModI.f90 -c -Wall -O3 -ffast-math -funroll-loops
-std=f2003 -fno-backslash -owinmod.o >winmod.xyz
WinModI.f90:68: Error: Can
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-24 17:00 ---
(In reply to comment #0)
> I have some legacy code that I just tried compiling with gfortan (on a
> i686-linux-slackware-12.1 box). There were a large number of warnings of the
> type:
>
> Warning: No
--- Comment #5 from kargl at gcc dot gnu dot org 2008-11-24 19:22 ---
(In reply to comment #3)
>
> Now for the more difficult part.
>
> I'll attach a tar file containing a sample program and a makefile. It turns
> out that the problem isn't with the read
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 19:52 ---
(In reply to comment #8)
> I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build
> with -malign-double, not just fortran programs, then IMHO the flag is useless
> and should be r
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 20:24 ---
(In reply to comment #8)
> > This looks like a missing or wrong initialisation.
>
> Confirmed, it's 'name' in match_deferred_characteristics:
>
> char name[GFC_MAX_SYMBOL_LEN + 1]
--- Comment #11 from kargl at gcc dot gnu dot org 2008-11-24 20:46 ---
(In reply to comment #10)
> > This should probably be
> >
> > m = gfc_match ("function% %n", name);
> >
> > > if (m == MATCH_YES && strcmp (name, gfc_curre
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-30 03:51 ---
*** Bug 38323 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-30 03:51 ---
*** This bug has been marked as a duplicate of 37469 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-05 21:02 ---
I'll take this as part of the [de]allocate work. Note, this also causes a
segfault with all versions of gfortran
program a
implicit none
integer, allocatable :: i(:)
allocate(i(4))
deallocate(i, sta
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-05 21:24 ---
I have a patch for the original problem.
deallocate_alloc_opt_1.f90:23.14-17:
deallocate(i, i)
1 2
Error: Allocate-object at (1) also appears at (2)
--
kargl at gcc dot gnu dot org changed
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-07 20:21 ---
g77 was removed from GCC more than 3.5 years ago and is no longer support.
However, ask yourself does it make sense to "first open it, then read,
then close, then write, then close again". Either re-ope
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-08 18:24 ---
Yeah, this has always bothered me. I typically use -fmax-errors=1 when
developing new code because of the run-on errors for simple mistakes.
This fixes the excessive errors in this case.
Index: symbol.c
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-08 19:31 ---
(In reply to comment #2)
> (In reply to comment #1)
> > - gfc_error (msg, sym->name, where, gfc_basic_typename
> > (sym->ts.type));
> > + gfc_fatal_e
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-11 00:16 ---
The patch I submitted, here:
http://gcc.gnu.org/ml/fortran/2008-12/msg00167.html
gives
troutmask:sgk[224] gfc4x -o z k.f90
k.f90:2.10:
ALLOCATE(i(3))
1
Error: Allocate-object at (1) is not a nonprocedure
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-11 18:58 ---
Change subject line.
Reduced test case
troutmask:sgk[204] cat pr38312.f90
SUBROUTINE S1(t1,t2,c0,n)
REAL :: t1(n),c0(n)
INTEGER :: i,j,k
DO i=1,n
co(i)=t1(i)*2
ENDDO
END SUBROUTINE S1
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-11 18:59 ---
*** Bug 37793 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-11 18:59 ---
PR 38312 has a short testcase.
*** This bug has been marked as a duplicate of 38312 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-11 20:17 ---
For some reason, init_flag in gfc_match_iterator is set to zero.
So when the matcher hits
m = init_flag ? gfc_match_init_expr (&e1) : gfc_match_expr (&e1);
gfc_match_expr() is executed in
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-12 15:15 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
>
( Ihaven't
--- Comment #5 from kargl at gcc dot gnu dot org 2008-12-12 16:03 ---
Looking at the -fdump-tree-original, I suspect that the minus sign in
the hex formatted number is redundant. To keep things short, I've removed
the dt_parm setup code. _gfortran_transfer_integer probably ou
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-12 17:42 ---
Not only do I agree that warning is bogus, I think we get it wrong even
with END IF. From Annex B,
(2) Branching to an END IF statement from outside its block.
In Fortran 77, and for consistency also in
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-12 20:07 ---
I have a semi-working patch for this. Harald's original problem is
easy to fix, but the branching into a IF block requires a little
more clean.
--
kargl at gcc dot gnu dot org changed:
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-12 22:58 ---
(In reply to comment #3)
> What is about the obsolescent DO related part? Do we need to do
> something there
> (from F95, B.2):
>
> "Shared DO termination and termination on a statement
--- Comment #6 from kargl at gcc dot gnu dot org 2008-12-15 18:58 ---
(In reply to comment #5)
> According to your readings, is the following valid?
> DO 10 I=1,10
> IF (.TRUE.) THEN
> 10 END IF
>END
>
See constraint C825, page 165 in F2003 and restricti
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-21 02:01 ---
The code compiles (well dies with an appropriate error) with
GNU Fortran (GCC) 4.2.5 20080702 (prerelease)
GNU Fortran (GCC) 4.3.3 20081120 (prerelease)
GNU Fortran (GCC) 4.4.0 20081213 (experimental) [trunk revision
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-22 00:28 ---
Please attach long files instead of embedded the code within the bug report.
It makes it harder to copy and paste from a browser.
The code works with 4.3.3, so this is a regression. Here's a reduced
testcase
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-22 00:30 ---
Created an attachment (id=16956)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16956&action=view)
iso_varying_string code.
Here's the iso_varying_string.f90 code as an attachment.
--
http:/
--- Comment #18 from kargl at gcc dot gnu dot org 2008-12-22 21:03 ---
(In reply to comment #17)
> After all the updates committed for this bug, I thought I'd try the latest,
> including updating to ggmp-4.2.4 and mpfr-2.3.2. Here's the result for the
> GCC
>
--- Comment #7 from kargl at gcc dot gnu dot org 2008-12-26 00:01 ---
(In reply to comment #6)
> Is this still current?
>
This should probably be closed as WONTFIX. The report is
against FreeBSD 5.3, which is ancient. The FreeBSD Ports
Collection currently has port/lang
--- Comment #11 from kargl at gcc dot gnu dot org 2008-12-28 21:02 ---
(In reply to comment #9)
>
> I think the tests in roundf need to be revised to minimize rounding
> issues. Patch attached. This fixes the test on hppa2.0w-hp-hpux11.11.
>
See libm on Fr
--- Comment #13 from kargl at gcc dot gnu dot org 2008-12-28 22:14 ---
(In reply to comment #12)
> Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
>
> > See libm on FreeBSD.
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_rou
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-30 21:15 ---
See PR 37469
Given the last comment. This will probably be closed with a WONTFIX.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-02 20:14 ---
(In reply to comment #2)
> Quantity of correct bits is 64, the size of long double is 128 bits.
>
> Half of quality is reached by usage of operations multiplication, divisions.
>
What does 'grep
--- Comment #6 from kargl at gcc dot gnu dot org 2009-01-03 00:42 ---
(In reply to comment #4)
> __LDBL_DIG__=18
> __DBL_DIG__=15
>
> sizeof(long double)=128 bits
> sizeof(double)=64 bits
>
You didn't show what I requested. The other piece
of the puzzle is LD
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
GCC host triplet: i386-unknown-freebsd8.0
http://gcc.gnu.org
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-04 19:41 ---
Created an attachment (id=17030)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17030&action=view)
openmp code showing segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38724
--- Comment #2 from kargl at gcc dot gnu dot org 2009-01-04 19:43 ---
gfc4x -g -o z -O -fopenmp gib.f90
(gdb) run ./z
Starting program: /usr/home/kargl/tmp/z ./z
[New LWP 100056]
[New LWP 100056]
10 10
1 1
Assertion failed: (arena != NULL
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-04 19:46 ---
Using gfortran 4.3.3, a segfault also occurs but the backtrace is different.
(gdb) run
Starting program: /usr/home/kargl/tmp/z
[New LWP 100173]
[New Thread 48301140 (LWP 100173)]
10 10
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-04 19:47 ---
Make the summary a little clear.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38763
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-08 03:24 ---
Removing the ISO C Binding stuff gives
program sizetest
implicit none
integer, parameter :: ik1 = selected_int_kind(2)
TYPE vehicle_t1
INTEGER, DIMENSION(:), ALLOCATABLE :: sensors
END TYPE
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-08 17:25 ---
Update summary to something a little less annoying.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-09 01:22 ---
See the -fno-range-check option.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-09 01:47 ---
Without a testcase, it is difficult to determine if the problem is
with gfortran or a bug in your application.
>From Section 9.2.2.1, Internal File Properties,
(8) On input, blanks are treated in the same way
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-15 06:54 ---
First, the code compiles fine on i386 with 4.4.0 20090113.
Second, I support Joost's position in that the ICE you
posted and the subsequent failure of loading f951 in dbx
suggests the problem is in your install
--- Comment #13 from kargl at gcc dot gnu dot org 2009-01-16 00:40 ---
I have a patch for this problem. I'll clean it up on Saturday and
submit it.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-16 00:55 ---
(In reply to comment #2)
> Before closing, please also check the two longer cases:
> http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
> and the older (partially incorrect?) one
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-16 02:47 ---
I think I know how to fix this. I'll note that James' clever
programs may be invoking processor defined behavior due to
the multiplication by 0 in his specification statements.
See 7.1.8.1.
--
http://g
--- Comment #6 from kargl at gcc dot gnu dot org 2009-01-16 05:26 ---
(In reply to comment #5)
> ifort (IFORT) 10.1 20080801
> Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
>
> $ ./a.out
> T F
>
> I want to get my head around this too.
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-16 16:13 ---
Jakub probably already knows this, but
2008-05-25 Tobias Burnus
PR fortran/32600
* intrinsics/iso_c_binding.c (c_f_procpointer): Remove.
* intrinsics/iso_c_binding.h (c_f_procpointer
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-18 21:44 ---
Confirmed for both ICEs.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2009-01-18 21:47 ---
Both variations of the program work with 4.2.5, so this is
a regression.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC||sgk at troutmask dot apl dot
--- Comment #14 from kargl at gcc dot gnu dot org 2009-01-19 00:36 ---
http://gcc.gnu.org/ml/fortran/2009-01/msg00231.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-19 17:56 ---
Reduced testcase. This appears to be an array section problem
with lbound().
MODULE U_above_TESTS
INTEGER, PARAMETER, DIMENSION(0:20,4) :: IP_ARRAY2_4_S = 0
INTEGER, PARAMETER, DIMENSION(2
--- Comment #7 from kargl at gcc dot gnu dot org 2009-01-20 19:22 ---
I have a patch that not only fixes the ICE, but it will issue an
error for a program of the form
troutmask:sgk[203] cat a.f90
program a
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
z = 1.
print '(5ES12.5
1 - 100 of 1408 matches
Mail list logo
