--- 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=gcc&view=rev&rev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
--- 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=gcc&view=rev&rev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
--- 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=gcc&view=rev&rev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
--- 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=gcc&view=rev&rev=124256
Log:
Merged revisions 123029-123122 via svnmerge from
--- 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.
--
--- 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|Re
--- 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 s
--- 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
--- 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.)
>
--- 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 gfort
--- 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 to
--- 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 t
--- 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 #4 from kargl at gcc dot gnu dot org 2007-06-01 02:52 ---
(In reply to comment #3)
>
> What about rolling our own with mpfr? Or is that too difficult. :)
>
It could be done with mpfr, but note that at the moment gfortran
will provide either REAL(10) or REAL(1
--- Comment #5 from kargl at gcc dot gnu dot org 2007-06-03 16:35 ---
(In reply to comment #4)
> Function Alpha Generic ix86 IA64 PowerPC
>
> acosf - -- - -
> acos - -- - -
> cosf 1 -1
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-04 17:32 ---
(In reply to comment #7)
> >> [EMAIL PROTECTED]
> >> IEEE 754 does not discuss any of the functions you list above. In fact,
> >> IEEE 754 places requirements on exactly one function in
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-08 17:14 ---
(In reply to comment #0)
> I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> the
> most recent patches. My version is 2.2.1-p5.
What does p4 do?
--
kargl at gcc dot gn
--- Comment #3 from kargl at gcc dot gnu dot org 2007-06-09 17:06 ---
(In reply to comment #2)
> >> From [EMAIL PROTECTED]
> > I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> > the most recent patches. My version is 2.2.1-p5.
> >&
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-11 18:16 ---
(In reply to comment #0)
> When I compile the following function using the mips version of gfortran I get
> the message:
>
> q.f90: In function 'set_numeric_values':
> q.f90:3: in
--- Comment #3 from kargl at gcc dot gnu dot org 2007-06-11 19:08 ---
(In reply to comment #2)
> I run Debian Linux 4.0 on my SGI box. When I type "apt-get source gcc-4.1", it
> downloads a version of gcc 4.1.2 that appears to be extensively hacked up.
> This
>
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-13 05:09 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Until I know for sure, i am moving this back to the fortran component, it
> > might
> > be a front end issuse still.
> >
> And
--- Comment #18 from kargl at gcc dot gnu dot org 2007-06-13 17:52 ---
> The libm library is the least accurate and on average the fastest; though not
> fastest for every function instance. The most accurate is always CRLibm,
> sometimes it is fastest. The MPFR library is se
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-15 16:16 ---
Is mips a big endian cpu? I can't reproduce this on
i386 or x86_64 hardware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
--- Comment #21 from kargl at gcc dot gnu dot org 2007-06-15 22:22 ---
(In reply to comment #20)
> Created an attachment (id=13709)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13709&action=view) [edit]
> Specific example where libm, libcrlibm, and mpfr differ
&
--- Comment #2 from kargl at gcc dot gnu dot org 2007-06-18 01:46 ---
According to Lahey, the code is invalid.
Lahey/Fujitsu Fortran 95 Source Check Output
Compiling program unit halvestring at line 1:
Compiling program unit testspec at line 9:
2049-S: "SOURCE.F90"
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-18 03:50 ---
John,
This works for me with both a 4.2 and 4.3 (aka trunk, bleeding edge)
compilers. I think you'll find a much more pleasant gfortran
experience if you upgrade from 4.1.1..
--
kargl at gcc dot gnu do
--- Comment #6 from kargl at gcc dot gnu dot org 2007-06-18 04:26 ---
In section 7.1.6.2 (which you sight), I find
A function is a specification function if it is a pure function, is not an
intrinsic function, is not an internal function, is not a statement function,
does not
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-18 18:36 ---
There are literal hundreds of warning given by ftnchek, and there
appears to be an array bounds problem.
troutmask:sgk[231] gfc4x -o z -O -fbounds-check TMalign.f
troutmask:sgk[232] ./z 1aquA.pdb 1avaC.pdb | grep
--- Comment #12 from kargl at gcc dot gnu dot org 2007-06-18 19:16 ---
(In reply to comment #11)
> Yes, I agree that program is not beautiful
> and I know the the array 'w' of 'u3b' subroutine problem;
> I think the author of u3b use w(1) as pointer.
--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-18 20:47 ---
(In reply to comment #13)
> The '-ffloat-store' option works! Thank you.
>
> However that gave me some quenstions;
>
> Is that feature or bug?
It is a 'feature' of the
--- Comment #9 from kargl at gcc dot gnu dot org 2007-06-19 03:50 ---
John,
With your acknowledgment of pault's comment, I think this
can be closed. Thanks for the reports. These types of
potential corner cases keep us on our toes.
--
kargl at gcc dot gnu dot org ch
--- Comment #17 from kargl at gcc dot gnu dot org 2007-06-21 02:24 ---
(In reply to comment #16)
> Thank all of you.
> I could understand what make it different.
>
> There is no 'volatile' statement in fortran77 syntax of gfortran.
> Of course, volatile is
--- Comment #19 from kargl at gcc dot gnu dot org 2007-06-21 04:08 ---
(In reply to comment #18)
>
> I had ONLY HOPEd VOLATILE statement in fortran 77 EXTENSION of gfortran.
> I thought that would be convenient
> on small modification of legacy fortran 77 program.
You&
--- Comment #21 from kargl at gcc dot gnu dot org 2007-06-21 04:54 ---
(In reply to comment #20)
> $ gfortran -O1 -o TMalign TMalign.f
> In file TMalign.f:2005
>
> VOLATILE D
> 1
> Error: Unclassif
--- Comment #11 from kargl at gcc dot gnu dot org 2007-06-23 05:06 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Don't worry, it works correctly.
> > ...
> > Argument are pushed to the stack by the caller without any other
> > communicati
--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-23 17:56 ---
(In reply to comment #13)
> (In reply to comment #11)
> > (1) Try -Wformat
>
> "-Wall" includes "-Wformat" according to gcc.info. See comment 7 for the
> command lin
--- Comment #7 from kargl at gcc dot gnu dot org 2007-06-29 16:10 ---
(In reply to comment #6)
> (In reply to comment #5)
> > is this patch still OK ?
>
> The lround patch should be OK on C99 targets, but it would probably break
> things on non-C99 targets, which is w
--- Comment #4 from kargl at gcc dot gnu dot org 2007-06-30 00:32 ---
(In reply to comment #3)
> This appears to fix it but I am not sure yet. More testing.
>
> */
> #ifdef HAVE_SNPRINTF
> - snprintf (buffer, sizeof (buffer), "%+-#" STR(MIN_FIELD_
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-02 14:54 ---
*** This bug has been marked as a duplicate of 31229 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-02 14:54 ---
*** Bug 32578 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 2007-07-02 14:57 ---
Resolution of this bug requires the PROCEDURE POINTER feature
from Fortran 2003. Janus Weil, a Google SoC participant, is
working on this feature.
--
kargl at gcc dot gnu dot org changed:
What
--- Comment #6 from kargl at gcc dot gnu dot org 2007-07-02 16:44 ---
I committed a patch, yesterday.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from kargl at gcc dot gnu dot org 2007-07-02 23:29 ---
Subject: Bug 32456
Author: kargl
Date: Mon Jul 2 23:29:27 2007
New Revision: 126238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126238
Log:
2007-07-02 Steven G. Kargl <[EMAI
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-03 03:55 ---
This just an optimization request, right? The functions calls work?
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-03 16:24 ---
This a regression with respect to 4.2.
The problem is caused by the implicitly typed 'i'
in the statement function 'lit(i) = line(i:i)'
--
kargl at gcc dot gnu dot org changed:
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-03 21:46 ---
Subject: Bug 32579
Author: kargl
Date: Tue Jul 3 21:45:59 2007
New Revision: 126280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126280
Log:
2007-07-02 Christopher D. Rickett <[EMAI
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-03 22:09 ---
Fixed. Thanks for the report Joost.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-04 16:24 ---
I've compared the output of -fdump-tree-original for 4.2 and trunk, and
the only significant difference is
internal (j)
{
int4 k;
+ int4 i;
logical4 __result_internal;
That is, the implicitly typed &
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-04 16:25 ---
I thought I had confirmed this as a bug. Let's try again.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-04 16:27 ---
Add wrong-code keyword.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-07 02:55 ---
Richard,
Thanks for the bug report. Your code compiles with
gcc version 4.2.0 20070501
gcc version 4.3.0 20070704 <-- This is a recent trunk.
You can get recent binaries on the gfortran wiki. Note,
I'm
--- Comment #12 from kargl at gcc dot gnu dot org 2007-07-11 17:01 ---
(In reply to comment #11)
>
> We need to make a choice between these two, and decided whether all arguments
> have the same type (my preferred choice) or if some have a fixed type. In all
> cases, us
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-11 22:05
---
(In reply to comment #5)
>
> Furthermore, when one writes binary in C, you get exactly what your variables
> are sized to in your code. If the platform is a 32 bit machine and is IEEE
> comp
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 00:35
---
(In reply to comment #7)
>
> I realize that disagreeing with the assumptions made during the design may be
> regarded by some as "rants", but what I was attempting to do (perhaps poorly)
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 21:54
---
Confirmed. Lahey's web-based checker also accepts the code.
--
What|Removed |
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-15 00:15
---
(In reply to comment #0)
> consider the following program
> program random
> implicit none
> real :: x
> call random_seed();
> call random_number(x);
> write(*,*) x
> end progra
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:01
---
gfc_simplify_radix is used in intrinsic.c for simplification of the
RADIX intrinsic function. The standard defines RADIX for REAL and
INTEGER. See 13.14.84.
program mn
complex z
print*, radix(z)
end
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:34
---
I'm not sure what this function is really accomplishing. The
line "*dest = *src;" isn't copying src to dest. We simply
have set *dest to point to src. So, the for loop is a NOP.
O
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 16:09
---
Switch Severity to enhanacement (although I disagree the basic premise).
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 18:46
---
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01004.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23516
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-21 22:41
---
Created an attachment (id=9788)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9788&action=view)
ambiguous INTERFACE code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24005
4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: freebsd-*-amd64
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-21 22:44
---
The code checker at www.lahey.com come shows
Compiling program unit y at line 1:
Compiling program unit z at line 17:
2278-W: "SOURCE.F90", line 22: Specific procedures (f) and (f) do not e
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-21 22:45
---
GDB suggests that we are passing a NULL pointer to strcmp. Here's the
backtrace.
#0 0x000200dda110 in strcmp () from /lib/libc.so.6
#1 0x00419c0b in check_interface1 (p=0xbb6680, q=0xb
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-24 17:42
---
To add to FX's eplanation, I know libm on at least {Net,Open,Free}BSD do not
have a complete set of C99 long double functions (e.g., logl). We
need to map logl to log with a note in gfortran.info tha
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-28 23:20
---
What exactly is the problem? AFAIK, the "program" is not valid Fortran
95. What to you expect the compiler to do?
--
What|Removed
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-29 17:54
---
INTERVAL is not part of the Fortran 95 and a text search of the
final committee draft of the Fortran 2003 shows that INTERVAL is
not included in Fortran 2003. A module that implements interval
arithmetic can
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-29 18:23
---
Backport from 4.1.0 to 4.0.3.
--
What|Removed |Added
Status|UNCONFIRMED
The following program fails to compile.
program bug
implicit none
integer, parameter :: nx=4,ny=4
real, dimension(nx,ny) :: f, g
real, dimension(nx) :: x
integer :: i
x = cshift((/ (i, i = 1, nx) /), nx/2) * 2
g = spread(x, 2, ny)
!
! x and g above (which compiles) are equivalent to f bel
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-04 17:06 ---
(In reply to comment #3)
> Patch posted.
>
Ok for mainline and 4.0. Note, please cross post Fortran patches
to fortran@ mailinglist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24176
usion screws NAMELIST
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gn
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-07 17:25 ---
On amd64-*-freebsd with Jakub's patch, I get
troutmask:sgk[206] gfc41 -static -o z try.f sub.c
troutmask:sgk[207] ./z
Address of x = 0x00554000
x is aligned on a 16-byte boundary
--
http://gcc.gn
--- Comment #3 from kargl at gcc dot gnu dot org 2005-10-11 18:48 ---
I don't think this is a glibc problem. gfortran will use a GCC
builtin function. See gcc/fortran/mathbuiltins.def To confirm
this, I get
troutmask:kargl[210] ./z
( 0.00, -1.00) (-0.70
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-11 19:56 ---
This is definitely a gcc bug.
gfortran -fdump-tree-original csqrt.f
yields (with removal of IO crap and shorting of long constants)
MAIN__ ()
{
complex4 y;
complex4 x;
x = __complex__ (0.0, -1.0e+0);
y
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-11 20:11 ---
FreeBSD *does not* have a csqrt or csqrtf in libm! The problem is
in intrinsics/c99_functions.c. I'm testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
--- Comment #8 from kargl at gcc dot gnu dot org 2005-10-11 20:21 ---
Yes, I agree glibc has the bug. But, libgfortran also has the bug
and will be present on every OS that does not have a libm with csqrt
and csqrtf. I have a patch for libgfortran.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from kargl at gcc dot gnu dot org 2005-10-11 20:46 ---
Patch for libgfortran
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00626.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-12 00:32 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from kargl at gcc dot gnu dot org 2005-10-12 20:41 ---
The final committe draft of the Fortran 95 standard (and the
final coimmitte draft of Fortran 2003 is essentially the same) has
3.2.1 Names
Names are used for various entities such as variables, program units
--- Comment #1 from kargl at gcc dot gnu dot org 2005-10-12 21:00 ---
Add -std=f95 to your command line. This causes gfortran to emit
an error. The default behavior is setup to accept names of up
to 63 characters, which is the length specified in Fortran 2003.
In general, if your
--- Comment #3 from kargl at gcc dot gnu dot org 2005-10-17 18:00 ---
The code is illegal, and therefore gfortran can do anything
it wants (including start WW III).
(1) rteps is never defined, so it can't be reference in the IF
statement.
(2) Even if rteps was defined pri
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-17 18:01 ---
Forgot to add myself to the CC list.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from kargl at gcc dot gnu dot org 2005-10-19 14:59 ---
(In reply to comment #10)
> Running /home/eric/cvs/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
> FAIL: gfortran.dg/large_real_kind_2.F90 -O0 (test for excess errors)
> WARNING: gfortran.dg/large_real_kind_2
--- Comment #13 from kargl at gcc dot gnu dot org 2005-10-19 17:34 ---
FreeBSD has the same problem with missing long double math
functions. I tried to add an appropriate XFAIL clause for
FreeBSD, but dejagnu would still process the file. I'm
working on some of the FreeBSD
--- Comment #5 from kargl at gcc dot gnu dot org 2005-10-19 22:50 ---
(In reply to comment #2)
> (In reply to comment #1)
> > dimag is part of the fortran 95 standard, right?
> >
> > If not this is not a bug (or really a dup another one which says that
&g
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-19 22:57 ---
(In reply to comment #4)
> If the page I pointed to is true, then this is a dup of bug 20248.
>
It not a dup of 20248. The initial discussion there mirrors
this PR, but Harald added in a discussion with reg
--- Comment #1 from kargl at gcc dot gnu dot org 2005-10-26 17:05 ---
Here's a reduced code that shows the problem. Gfortran is
not handling the END INTERFACE OPERATOR (.EqualTo.) correctly.
This confuses the heck out of the error recovery code.
MODULE Compare_Float_Nu
--- Comment #3 from kargl at gcc dot gnu dot org 2005-10-28 20:06 ---
Subject: Bug 24545
Author: kargl
Date: Fri Oct 28 20:05:56 2005
New Revision: 105953
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105953
Log:
PR fortran/24545
* interface.c (gfc_match_end_interfa
--- Comment #5 from kargl at gcc dot gnu dot org 2005-10-28 20:57 ---
Subject: Bug 24545
Author: kargl
Date: Fri Oct 28 20:57:17 2005
New Revision: 105962
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=105962
Log:
PR fortran/24545
* interface.c (gfc_match_end_interfa
--- Comment #6 from kargl at gcc dot gnu dot org 2005-10-28 20:58 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-29 00:14 ---
Intel and PGI are wrong according to the standard. Gfortran is
doing the right thing. See section 9.4 File Connection. In
particular "The external unit identified by a particular value of
a scalar-int-expr i
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-29 02:52 ---
Can you add a short program with the problem? The
single read statement may not be sufficient to
reconstruct your problem.
--
kargl at gcc dot gnu dot org changed:
What|Removed
c
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
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=24581
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-02 18:27 ---
This has bugged me also. For a patch, see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00122.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2010-02-14 17:27 ---
> NAMELIST/TOTO/TAB
> 1
> Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1)
>
>
> Test file :
>
> PROGRAM MAIN
> R
--- Comment #3 from kargl at gcc dot gnu dot org 2010-02-15 01:29 ---
I've posted a question to c.l.f about this code. I
believe the language of the standard is contradictory
and as such the code can be interpreted as illegal or
legal.
http://groups.google.com/group/comp.lang.fo
--- Comment #5 from kargl at gcc dot gnu dot org 2010-02-15 17:04 ---
(In reply to comment #4)
> (In reply to comment #3)
> > I've posted a question to c.l.f about this code. I
> > believe the language of the standard is contradictory
> > and as such the
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-15 17:10 ---
Works for me with both 4.4.2 and trunk.
Can you attach a small self-contained example
that fails? The single line of code you posted
may have been mangled during the submission.
PS: Does the line of code you
--- Comment #7 from kargl at gcc dot gnu dot org 2010-02-15 21:47 ---
(In reply to comment #6)
> What is this?
>
> REAL, DIMENSION(:), ALLOCATABLE :: TAB
>
> If not assumed size?
>
> Also, assuming it is something else, would it be invalid to use the namelist
801 - 900 of 1408 matches
Mail list logo
