--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-03 19:00 ---
Subject: Bug 30683
Author: kargl
Date: Sat Feb 3 18:59:53 2007
New Revision: 121548
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121548
Log:
2007-02-02 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #8 from kargl at gcc dot gnu dot org 2007-02-03 19:01 ---
Fixed on 4.2.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-03 19:59 ---
This is an invalid bug report. -fdefault-integer-8 doesn't
do what you think it does. If you use this option and equivalence
is present in the code, then you invariably want to use
-fdefault-real-8.
--
kargl
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-04 02:26 ---
(In reply to comment #4)
OK, maybe gfortran is right.
It isn't that gfortran is right or wrong. :-)
The -fdefault-integer-8 changes the default integer kind to
an 8 byte integer. The default real kind is still 4
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-04 21:31 ---
Fixed on trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Summary
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-05 16:25 ---
(In reply to comment #1)
Compiling the code above with
gfortran -std=f2003
gives
In file xarithmetic_if.f90:5
if (i) 10,20,30
1
Error: Obsolete: arithmetic IF statement at (1)
which
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-05 17:46 ---
This code compiles with
troutmask:sgk[208] gfc41 --version
GNU Fortran 95 (GCC) 4.1.2 20070127 (prerelease)
troutmask:sgk[209] gfc42 --version
GNU Fortran 95 (GCC) 4.2.0 20070126 (prerelease)
troutmask:sgk[210
--- Comment #8 from kargl at gcc dot gnu dot org 2007-02-06 00:28 ---
Subject: Bug 30605
Author: kargl
Date: Tue Feb 6 00:28:14 2007
New Revision: 121631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121631
Log:
2007-02-05 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #9 from kargl at gcc dot gnu dot org 2007-02-06 00:31 ---
Fixed in trunk and 4.2. Won't fix in 4.1 or earlier.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 ---
There is no attached code. Ray can you try adding the code, again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
--- Comment #20 from kargl at gcc dot gnu dot org 2007-02-08 16:18 ---
(In reply to comment #17)
Now, if Fortran2003 allows some recursive access to the same unit
(under which conditions?),
Recursive IO to external units is simply not allowed by the Fortran
95 and Fortran 2003
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-11 17:43 ---
Works for me with these compilers:
GNU Fortran 95 (GCC) 4.3.0 20070130 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
troutmask:sgk[209] gfc42 --version
GNU Fortran 95 (GCC) 4.2.0 20070126
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-11 20:43 ---
(In reply to comment #2)
Contrary to this, the docs of g77-3.4.6 [1] state:
Status: INTEGER(KIND=1); OPTIONAL; scalar; INTENT(OUT).
INTEGER(KIND=1) in g77 is the default integer kind, which is
INTEGER(KIND=4
--- Comment #6 from kargl at gcc dot gnu dot org 2007-02-11 22:26 ---
daniel,
It's just an inconsistency in implementations. First, note that
FX and myself implemented a lot of the g77 intrinsics procedures
as our first foray into gfortran, so we may have missed some of the
finer
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-13 04:26 ---
troutmask:sgk[223] gfc4x -o z -g -ffpe-trap='precision' g.f90
troutmask:sgk[224] gdb ./z
(gdb) run
Starting program: /usr/home/sgk/tmp/z
Program received signal SIGFPE, Arithmetic exception.
0x0040a3b2
--- Comment #6 from kargl at gcc dot gnu dot org 2007-02-13 06:41 ---
(In reply to comment #5)
The exception is occurring in the print statement. Nothing to do with time.
No, there is a problem in cpu_time. -ffpe-trap='precision' is
trapping on lost precision. On x86_64, long
--- Comment #62 from kargl at gcc dot gnu dot org 2007-02-13 19:50 ---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-15 00:03 ---
Harald,
You have a knack for finding some of the weirdness bugs.
Anyway, I have a patch that detects and reports the illegal
kind type values. I'll submit it shortly to the list if
regression testing passes
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-15 00:38 ---
A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01311.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-15 02:03 ---
Subject: Bug 30799
Author: kargl
Date: Thu Feb 15 02:02:56 2007
New Revision: 121975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121975
Log:
2007-02-14 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-15 19:33 ---
Subject: Bug 30799
Author: kargl
Date: Thu Feb 15 19:33:13 2007
New Revision: 122012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122012
Log:
2007-02-15 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 19:47 ---
Fixed on 4.1, 4.2, and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-15 20:50 ---
Does this still fail for others? I can't get the ICE to occur.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-16 03:53 ---
(In reply to comment #3)
I'll try to help but I don't think this has anything to do with my patches.
Fortran was using mpfr for evaluating intrinsics way before I touched
anything,
and I believe it uses it's own
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-17 18:36 ---
Yup, these lines in gfc_arith_power make the assumption that we'll
never have an integer exponent outside the range INT_MIN to INT_MAX.
if (gfc_extract_int (op2, power) != NULL)
gfc_internal_error
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-17 21:10 ---
After looking at this a little bit, I think we may want to
change the error message to report the invalid integer exponent
value and document that INT_MIN = e = INT_MAX. Why? Well,
other than the special values
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-20 22:41 ---
(In reply to comment #2)
Has this been checked against comp.lang.fortran?
Steven,
I haven't located the relevant text, but I believe that
Joost is right. The INTERFACE defines it own scoping
unit
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-21 19:02 ---
(In reply to comment #4)
Created an attachment (id=13073)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13073action=view) [edit]
Fix for the problem
Paul, I tried to apply your patch, but it is rejected
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-22 19:24 ---
(In reply to comment #3)
Enough facts, now for some ignorant speculation: I suppose there is some logic
missing to pass a value from the caller when the size of the value is not the
default size (i.e. 4 for my
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-24 00:09 ---
This crash is with g77, which is no longer support.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-25 15:29 ---
configure:4917: /usr/gcc/host-i686-pc-linux-gnu/gcc/gfortran
-B/usr/gcc/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-B/usr/local/i686-pc-linux-gnu/lib/ -isystem
/usr/local/i686-pc-linux-gnu/include
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-26 00:14 ---
I have a patch to permit gfc_check_random_seed to deal with arguments
with the optional attribute set. I was waiting on pault's size0/size1
patch to hit the tree to see if it does the right thing.
--
http
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-27 20:46 ---
(In reply to comment #5)
Also isn't -huge()-1 undefined code for Fortran?
-huge()-1 can be defined in Fortran. The problem
comes when one tries to use that value in, e.g.,
IABS() because the standard prohibits
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-27 20:49 ---
This is a bogus PR. The are no negative numbers.
This is a unary minus operation and 2147483648
is too big for INTEGER(4). The only method to
get the most negative value is -HUGE() - 1.
--
kargl at gcc dot gnu
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-28 22:01 ---
Can you try gfortran from the 4.2 branch or from trunk? You
can get a binary package of trunk from the gfortran wiki.
Can attach the code to the bug report or a URL to the code?
Otherwise, we can't try to reproduce
--- Comment #13 from kargl at gcc dot gnu dot org 2007-02-28 23:25 ---
(In reply to comment #12)
Created an attachment (id=13127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13127action=view) [edit]
Patch looks ok to me. Note, I haven't tested.
--
kargl at gcc dot gnu
--- Comment #2 from kargl at gcc dot gnu dot org 2007-03-05 23:27 ---
The value 5008 is listed in libgfortran.h as ERROR_ENDFILE. The
-1 corresponds to ERROR_END. So, the return value of 5008 is
telling you that you are trying to (initiate a?) read beyond
the end of the file, which
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-05 23:54 ---
Subject: Bug 31050
Author: kargl
Date: Mon Mar 5 23:54:46 2007
New Revision: 122584
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122584
Log:
2007-03-05 Brooks Moses [EMAIL PROTECTED]
PR 31050
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-08 17:58 ---
Other source in the web (e.g.:
http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL )
point out the -mrtd would be the option to do the trick.
None of that works.
What g95 does is on absolutely
--- Comment #3 from kargl at gcc dot gnu dot org 2007-03-09 20:54 ---
(In reply to comment #0)
In other words, I'm after an analogue of ifort's
-mp/-fltconsistency/-mieee-fp.
GCC supports many many many more CPU architectures than ifort. This
isn't going to happen unless you
--- Comment #2 from kargl at gcc dot gnu dot org 2007-03-12 07:05 ---
(In reply to comment #1)
I don't think underscores are part of Fortran's identifier character space.
An underscore can appear in a symbol except as the first character.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from kargl at gcc dot gnu dot org 2007-03-20 03:09 ---
Tobi, this is a bogus request and the PR should be
closed. The standard does not require left to right
evaluation. It is the responsibility of the programmer
to know what she is doing. I think this should
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** Bug 31428 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** This bug has been marked as a duplicate of 31427 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31559
--- Comment #5 from kargl at gcc dot gnu dot org 2007-04-13 18:38 ---
(In reply to comment #4)
With Hex and octal numbers - there is no overflow as long as there are enough
bits - that is why g95 and Absoft do not complain.
g95 and absoft do not complain because these compilers
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-13 19:05 ---
The code is illegal, but in accordance with the error message.
You need to set WHICH to 1 via either
INTEGER :: which = 1
or
which = 1
This however doesn't fix the problem. If you change the call
--- Comment #7 from kargl at gcc dot gnu dot org 2007-04-13 20:44 ---
(In reply to comment #6)
Sorry, I cannot find another compiler that agrees with gfortran -
Then, I suggest you submit a bug report. The standard explicitly
says
If a data-stmt-constant is a boz-literal
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-18 21:03 ---
(In reply to comment #2)
Subject: Re: Inability to read ascii text with generic 'f' format
read(10,*) doesn't work. I have access to two other compilers
(SGI and Portland Group) and both of them accepted
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-21 23:51 ---
The OP doesn't understand his own program.
Closing as invalid.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2007-04-22 00:10 ---
(In reply to comment #4)
(In reply to comment #3)
The OP doesn't understand his own program.
Huh? (or did you close the wrong bug report?)
Here is a simplified testcase that does not call print:
program
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-27 22:18 ---
*** Bug 31731 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 2007-04-27 22:18 ---
*** This bug has been marked as a duplicate of 29458 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 29922
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #6 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31086
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #51 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31052
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31022
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #13 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30531
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #15 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30762
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #4 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30395
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #12 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30984
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #6 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30058
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #9 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31264
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #8 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31203
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #10 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30505
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #16 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31254
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #7 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30841
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #11 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 31245
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #7 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30907
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh://[EMAIL
--- Comment #20 from kargl at gcc dot gnu dot org 2007-04-28 05:14 ---
Subject: Bug 30590
Author: kargl
Date: Sat Apr 28 05:11:29 2007
New Revision: 124256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
svn+ssh
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-29 18:12 ---
This falls into the enhancement request category, and I agree that
these functions should be elemental. I'll also note that the gfortran
documentation claims that these functions are already elemental.
--
kargl
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-30 17:41 ---
The code does not conform to any Fortran standard. A compiler can
do whatever it wants with the tab. I'd suggest that you fix the
code.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-30 19:17 ---
Mark,
Section 3.1 of the Fortran 95 standard defines the Fortran Character
Set. tab is not a member of this set whereas space (or blank) is. One
then needs to read Section 3.3.2 that covers fixed-form source code
--- Comment #8 from kargl at gcc dot gnu dot org 2007-05-04 06:16 ---
This appears to be an alignment issue. On x86_64-*-FreeBSD, I do not
see the segfault. On i386-*-FreeBSD, I see the segfault. Here's is
the backtrace
Starting program:
/usr/home/kargl/work/4x/libexec/gcc/i386
--- Comment #5 from kargl at gcc dot gnu dot org 2007-05-04 18:14 ---
(In reply to comment #4)
(I guess I should qualify that. I don't have a copy of the standard laying
around to check, but it's legal according to the Ellis, Philips and Lahey
book.)
It is not valid code
--- Comment #2 from kargl at gcc dot gnu dot org 2007-05-10 00:47 ---
(In reply to comment #1)
Confirmed on i686-linux, for all active branches.
I'm not sure how you can confirm this. The program is invalid.
a,b,c, and e are undefined in the write statement, so gfortran
can do
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 00:51 ---
What output were you expecting?
write(*,*) ishftc(aint,1)
write(*,*) ishftc(aint,1,32)
write(*,*) ishftc(aint,1,BIT_SIZE(aint))
All three of these statements are shifting the 32-bit representation of
of 1
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 16:05 ---
Works for me. What OS are you using and where did you get
the version of gfortran? An illegal instruction error
normally means you are using a version of gfortran on the
wrong architecture (ie., i686 on amd64
--- Comment #12 from kargl at gcc dot gnu dot org 2007-05-20 16:24 ---
(In reply to comment #11)
Fixed on 4.2. Do we want to backport to 4.1?
With 4.2 finally released, I think it is time to let
4.1 go. If gfortran follows the GCC development rules,
then this would need
--- Comment #2 from kargl at gcc dot gnu dot org 2007-05-23 16:05 ---
Can't we use sleep here?
No.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
--- 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 LDBL /usr/include
--- 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 LDBL_MANT_DIG, which I'll wager
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=17030action=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 installation
--- 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 |Added
--- 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 at
http
--- 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://gcc.gnu.org
--- 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. :)
Note, there are 2 separate
--- 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 bur...@net-b.de
PR fortran/32600
* intrinsics/iso_c_binding.c (c_f_procpointer): Remove.
* intrinsics/iso_c_binding.h
--- 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
501 - 600 of 1396 matches
Mail list logo
