--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-04 06:43
---
> I think the compiler is assuming "union myblock" has the same
> alignment as "struct b_one", which is more strictly aligned than
> "struct b_two" because of its double member.
That's right and it's prescribed b
--- Comment #2 from jason at gcc dot gnu dot org 2009-07-04 04:34 ---
Subject: Bug 40619
Author: jason
Date: Sat Jul 4 04:34:03 2009
New Revision: 149223
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149223
Log:
PR c++/40619
* cp-tree.h (struct lang_decl_parm):
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:28
---
Fixed on 4.3 and 4.4. Added new test case to 4.5 as well as 4.3 and 4.4
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:25
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:25:20 2009
New Revision: 149222
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149222
Log:
2009-07-03 Jerry DeLisle
PR fortran/40638
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:20
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:20:24 2009
New Revision: 149221
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149221
Log:
2009-07-03 Jerry DeLisle
PR fortran/40638
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:17
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:16:59 2009
New Revision: 149220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149220
Log:
2009-07-03 Jerry DeLisle
PR fortran/40638
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-07-04 04:05
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 04:05:19 2009
New Revision: 149219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149219
Log:
2009-07-03 Jerry DeLisle
PR fortran/40638
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-07-04 03:07
---
Subject: Bug 40638
Author: jvdelisle
Date: Sat Jul 4 03:07:12 2009
New Revision: 149218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149218
Log:
2009-07-03 Jerry DeLisle
PR fortran/40638
--- Comment #1 from pinskia at gmail dot com 2009-07-04 01:38 ---
Subject: Re: New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, "dentongosnell at yahoo dot com" > wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkg
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/l
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-07-03 23:24
---
Yes, I have the patch already. Its a one liner.
Index: trans-io.c
===
--- trans-io.c (revision 149123)
+++ trans-io.c (working copy)
@@ -471,7 +4
--- Comment #10 from vmakarov at gcc dot gnu dot org 2009-07-03 22:46
---
Subject: Bug 40587
Author: vmakarov
Date: Fri Jul 3 22:46:30 2009
New Revision: 149213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149213
Log:
2009-07-03 Vladimir Makarov
PR target/40587
--- Comment #9 from vmakarov at gcc dot gnu dot org 2009-07-03 22:36
---
Subject: Bug 40587
Author: vmakarov
Date: Fri Jul 3 22:36:31 2009
New Revision: 149212
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149212
Log:
2009-07-03 Vladimir Makarov
PR target/40587
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 ---
Subject: Bug 40640
Author: rguenth
Date: Fri Jul 3 22:09:12 2009
New Revision: 149211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149211
Log:
2009-07-03 Richard Guenther
PR tree-optimization/
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-03 22:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from vmakarov at redhat dot com 2009-07-03 21:30 ---
The problem was in usage of df_get_live_out in ira.c::build_insn_chain instead
of DF_LR_OUT. Later contains r58 (assigned to st0 register) and it creates
restore insn for st0 after the call and prevents reg-stack crashi
--- Comment #6 from raeburn at raeburn dot org 2009-07-03 20:06 ---
Subject: Re: not following "right-then-left" rule when compiling function
pointers
On Jul 3, 2009, at 10:42, dj2con at gmail dot com wrote:
> I don't know where you've been hiding for these past twenty years,
> Ken.
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-03 20:04 ---
(gdb) call debug_tree (limit)
constant 0>
(gdb) call vrp_val_is_max (limit)
$6 = 1 '\001'
(gdb) call vrp_val_is_min (limit)
$7 = 1 '\001'
err ...
(gdb) call debug_tree (0xb7d2aee0)
unit size
al
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-03 19:49 ---
switch-conversion triggers this, but it looks like a VRP issue after all.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 19:42 ---
Confirmed.
enum { gcr0_8259_bit = 0x2000, gcr0_reset_bit = 0x8000 };
void decode_opic_address(int *);
void hw_opic_io_read_buffer(int index)
{
unsigned reg = 0;
decode_opic_address(&index);
switch (ind
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-03 19:30 ---
Even the inline version is wrong I think.
real :: r(4), z
z = 0.0
r = (/ z/z, z/z, z/z, z/z /)
print *,r
print *, minloc(r,dim=1), minval(r,dim=1)
print *, maxloc(r,dim=1), maxval(r,dim=1)
end
Not sure what minval/max
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 19:26 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c
--- Comment #3 from aanisimov at inbox dot ru 2009-07-03 19:12 ---
>
> Try disabling prefetching.
>
Indeed, removing -fprefetch-loop-arrays made the program run in 37.534 seconds,
exactly like one compiled for i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 18:55 ---
Try -march=pentium-m -mtune=generic. Pentium-M never received any special
tuning (it is the same as for pentium-pro). So is -march=i686 btw, but
i686 does not have SSE, so it is likely vectorization and/or prefetch
--- Comment #1 from aanisimov at inbox dot ru 2009-07-03 18:28 ---
Created an attachment (id=18137)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18137&action=view)
Sample program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40644
Try compiling the attached program with the following options (they differ only
in -march specification)
1. gcc -std=c99 -march=i486 -funroll-loops -fprefetch-loop-arrays
-ftree-vectorize -O3 -o gen_weyl_group gen_weyl_group.c
2. gcc -std=c99 -march=i686 -funroll-loops -fprefetch-loop-arrays
-ftre
Per IEEE 754:2008, one has max(x,NaN) == max(NaN,x) == x. Gfortran's inline
version of maxloc, maxval and max (ditto for min*) follows this. However, the
libgfortran version does not:
real :: r(4), z
z = 0.0
r = (/ z/z, -1., -42., 849. /)
print *,r
print *, minloc(r), minval(r)
print *, maxloc(r),
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-03 17:44 ---
(In reply to comment #7)
> I will add that I suspect that the bug may be latent in 4.5 since I did change
> the error code when I added NEWUNIT to 4.5. After we get to the bottom of it,
> we need to consider backporti
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-03 17:32 ---
Btw, with a cross I cannot seem to reproduce the problem. How do non-inlined
calls look like with mips?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 17:24 ---
Does -fno-ipa-cp fix it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40641
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
gmp=/home/bangerth/bin/x86 --prefix=/home/bangerth/bin/x86/gcc-mainline
Thread model: posix
gcc version 4.5.0 20090703 (experimental) [trunk revision 149208] (GCC)
--
Summary: [4.5 regression] ICE with -fprofile-generate
Product: gcc
Version: 4.5.0
Sta
--- Comment #1 from florian at openwrt dot org 2009-07-03 16:16 ---
Created an attachment (id=18136)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18136&action=view)
ldso.Os.i preprocessed file
This file is the preprocessed file which causes problems.
--
http://gcc.gnu.org/bu
This is a bug report from an OpenWrt user that I have also noticed myself.
uClibc requires its syscalls to be inlined and therefore the attribute
always_inline was added to ensure inlining.
When gcc is called with -Os the always_inline attribute is not honored,
resulting in a non working uClibc ld
--- Comment #5 from dj2con at gmail dot com 2009-07-03 15:29 ---
I was still curious, so I re-read section 6.7.5.3 of the standard. And having
re-read it, I would like to apologize for troubling everyone -- upon re-reading
6.7.5.3, it now seems obvious that I was mis-applying the "righ
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-03 15:24 ---
Created an attachment (id=18135)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18135&action=view)
preprocessed test case (hw_opic.c
preprocessed version of gdb/sim/ppc/hw_opic.c
FAILS: gcc -O2 -c t.c
PASSES: gc
gcc (GCC) 4.5.0 20090702 (experimental) [trunk revision 149195]
building gdb head as of today. preprocessed file and coming in next update
gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS
-DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5-DWITH_TRACE=1
-DHAVE_TERMIOS_STRUCTURE -
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:20
---
I will add that I suspect that the bug may be latent in 4.5 since I did change
the error code when I added NEWUNIT to 4.5. After we get to the bottom of it,
we need to consider backporting a fix to 4.4 since this
--- Comment #4 from ubizjak at gmail dot com 2009-07-03 15:19 ---
For the interested reader: see [1].
[1]: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Unfortunately:
--quote--
First, symbols. Read
* as "pointer to" - always on the left side
[]
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-07-03 15:16
---
I can reproduce the problem on 4.3 and 4.4.
I would like to investigate further, especially regarding 4.4 and what did we
change between 4.4 and 4.5 to fix this.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #5 from dtprice at shaw dot ca 2009-07-03 15:06 ---
I stated earlier
> Identical code runs fine with same gfortran installed on a system
> equipped with an earlier Intel chip
Turns out this was wrong. The version on that system is 4.2.0
Interesting that using default integ
--- Comment #4 from dtprice at shaw dot ca 2009-07-03 14:54 ---
Sorry. In the middle of uploading the attachment I had a power cut! To respond
to your queries: Program and input file are now uploaded.
Yes it was compiled with
gfortran -Wall testfile.f
and no further options. I have
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-03 14:49
---
Adding Jason in CC for this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #3 from dj2con at gmail dot com 2009-07-03 14:42 ---
(In reply to comment #1)
> (In reply to comment #0)
> > , but it does not seem to recognize that the following is also a valid
> > prototype:
> >
> > int count * ( demo_counter * self, int count_amt );
>
> It isn't.
>
>
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-03 14:40 ---
Upgrade your compiler. The bug appears to fixed in at least trunk
while the bug is present in 4.3.3. I can't test 4.4.0 at the moment.
troutmask:sgk[203] gfc4x -o z testlun.f
troutmask:sgk[204] ./z
troutmask:sgk[20
--- Comment #2 from dtprice at shaw dot ca 2009-07-03 14:20 ---
Created an attachment (id=18134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18134&action=view)
Contains simple demo program and input file. Input file is not really needed
because program never opens it!
--
htt
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-03 14:19 ---
> gfortran 4.3.1. Attached 15 line test program reproduces the effect
Can you attach the program?
I assume you compiled it with "gfortran -Wall testfile.f" and no further option
such a -malign-double or similar?
C
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-03 14:18 ---
Yes.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from kargl at gcc dot gnu dot org 2009-07-03 14:15 ---
Closing. Bug is fixed in newer versions of gfortran.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
In C++0x mode, enums are allowed to specify an integral type for the base
representation. If the enum is inside a class template, it may be a
type-dependant expression that should not evaluate and potentially error until
instantiation time.
Example code:
//===
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 14:11
---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 14:11
---
Subject: Bug 34163
Author: rguenth
Date: Fri Jul 3 14:11:14 2009
New Revision: 149207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149207
Log:
2009-07-03 Richard Guenther
PR middle-end/34163
I find this hard to believe but a g77 code that has been in use for years
crashed at the first OPEN statement when compiled with gfortran 4.3.1. Attached
15 line test program reproduces the effect, stops at line 8 with the error
message:
At line 8 of file testlun.f
Fortran runtime error: Unit num
--- Comment #1 from laurent at guerby dot net 2009-07-03 13:26 ---
powerpc 32 bits Ada bootstraps and testresults are fine:
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00181.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
On trunk revision 149204:
/home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/bin/
-B/n/40/guerby/install-trunk/powerpc64-unknown-linux-gnu/lib/ -isystem
/n/40/gue
--- Comment #26 from burnus at gcc dot gnu dot org 2009-07-03 13:07 ---
> has a superfluous check || (pos.0 == 0 && (*D.1568)[S.3 + D.1569] == limit.2)
> at least for flag_finite_math_only. If the array cannot contain Inf or NaN
> then it either has all elements == FLT_MAX, so pos will
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-03 12:57
---
Btw, the inlined minloc
D.1570 = a.dim[0].lbound;
D.1571 = a.dim[0].ubound;
pos.0 = 0;
{
integer(kind=8) S.3;
({ S.3 = D.15
--- Comment #24 from burnus at gcc dot gnu dot org 2009-07-03 12:40 ---
> One issue is that
> ISET = MINLOC (DTEMP)
> will cause GCC to assume that DTEMP is clobbered.
The problem is that while "MINLOC" is pure, we cannot use DECL_PURE_P as the
result is passed by reference:
(voi
--- Comment #7 from vmakarov at redhat dot com 2009-07-03 12:38 ---
Thanks for reporting this. I started to work on the PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40587
GCC 4.5.0 20090702
Build failed because the static const structures in config/i386/msformat-c.c
(mingw_format_attribute_overrides and mingw_format_attributes) were optimized
out.
Also solaris target can be affected (solaris_format_types).
--
Summary: Build failed with --enable-build-
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-03 12:19
---
We are not able to vectorize the loop in
program main
implicit none
integer, volatile, dimension(1) :: n
real, allocatable :: a(:)
integer :: i
real :: t1, t2
allocate (a(100))
call random_number(a)
The following test case produces a 'may be used uninitialized' warning that
refers to a variable that isn't in scope at the point of the warning:
> cat nntpinit.c
struct hostent {
char **h_addr_list;
};
struct hostent *gethostbyname(const char*);
int socket(void);
int close(int);
int connect(i
On Debian (and probably other), if I execute:
tar xf ../update/gcc-4.4.0.tar.bz2
cd gcc-4.4.0/
tar xf ../../update/mpfr-2.4.1.tar.bz2
tar xf ../../update/gmp-4.3.1.tar.bz2
tar xf ../../update/binutils-2.19.1.tar.bz2
mv gmp-4.3.1 gmp
mv mpfr-2.4.1 mpfr
mv binutils-2.19.1 binutils
mkdir -v ../gcc-bui
The following code produces an internal compiler error:
template< typename T >
struct wrap {
enum class E { val };
};
Note that there is no problem supplying a fixed-base for a 'classic' enum, this
is purely an issue with the enum class keyword combination.
Tested under MinGW 4.4.0
--
--- Comment #12 from burnus at gcc dot gnu dot org 2009-07-03 11:33 ---
> Michael Matz fixed that for allocatable arrays, but the patch needs to be
> extended to nonallocatable arrays, cf.
> http://gcc.gnu.org/ml/fortran/2009-07/msg4.html
Actually, there it already works. Left is on
On one hand it needs a new attribute, which needs some checking that the
contiguity is not violated. It also needs the contiguous flag of the reworked
descriptor.
One place where it can be used is:
a) In functions calls
b) In assignments of the type (cf. PR 40551)
array = function()
c) In compi
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-03 11:22
---
Created an attachment (id=18133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18133&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-03 11:14
---
Before:
Time for setup 0.139
Time per iteration 0.271
Total Time 6.649
Time for setup 0.136
Time per iteration 0.265
Total Time 10.210
Time for setup
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-07-03 11:05
---
In fact, in this case we have the C equivalent
int i;
long j = (long)(i - 1);
vs.
long j = (long)i - 1;
which I believe are equivalent if overflow is undefined (or i - 1 does not
wrap).
It is just that f
--- Comment #8 from dave at treblig dot org 2009-07-03 11:03 ---
Note there are two slightly different things being asked for here:
1) Showing the horizontal position in the line
2) show the preprocessed line rather than the raw line (which was my 40228
that just got marked as a dupe
/n/51/guerby/build/./prev-gcc/xgcc -B/n/51/guerby/build/./prev-gcc/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-linux-gnu/bin/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el\
-unknown-linux-gnu/bin/
-B/mnt/lemote/home/loongson/install-trunk-149181/mips64el-unknown-l
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-03 10:13 ---
Confirmed. One first gets the error message from gfc_get_sym_tree (already been
host associated), followed by the segfault, which happens at
==12785== Use of uninitialised value of size 8
==12785==at 0x500F17: gfc
--- Comment #10 from rogermc at iinet dot net dot au 2009-07-03 10:01
---
I updated gfortran as suggested and now abavrml.F compiles OK.
Bug seems resolved.
Thanks for advice.
gfortran -v now responds with:
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: /tmp/gfo
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-03 10:00
---
One issue is that
ISET = MINLOC (DTEMP)
will cause GCC to assume that DTEMP is clobbered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-07-03 09:57
---
Fixed I suppose.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-03 09:57 ---
int count * ( demo_counter * self, int count_amt );
is not a valid prototype.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #18 from rguenther at suse dot de 2009-07-03 09:08 ---
Subject: Re: [4.3/4.4/4.5 Regression] 10% performance
regression since Nov 1 on Polyhedron's "NF" on AMD64
On Fri, 3 Jul 2009, ubizjak at gmail dot com wrote:
> --- Comment #17 from ubizjak at gmail dot com 2009-
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-03 09:00 ---
Jason, am I correct that this is now valid rather than invalid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40341
--- Comment #17 from ubizjak at gmail dot com 2009-07-03 08:46 ---
(In reply to comment #16)
> One of the cases SCEV is confused about pointer-plus offsets being sizetype:
Do we have a solution for this problem...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-03 08:18 ---
Confirmed on i686-apple-darwin9. More precisely, I get:
pr40629.f90:12.10:
END MODULE
1
Error: Symbol 'x' at (1) has already been host associated
f951: internal compiler error: Bus error
--
http://gcc
The following code (inspired from host_assoc_function_1.f90) breaks f951:
MODULE m
REAL :: x
CONTAINS
SUBROUTINE s
CONTAINS
SUBROUTINE inner
y = x(1, 1)
END SUBROUTINE
FUNCTION x(n, m)
END FUNCTION
END SUBROUTINE
END MODULE
I have an internal compiler error with f951
In assignments, such as
string = trim(string)
string(n1:n2) = trim(string)
the trim has no effect and can be optimized away.
(Note: With Fortran 2003 and allocatable strings with "len=:", the first
version cannot be optimized as on length mismatch the LHS is reallocated.)
Such code can easily
83 matches
Mail list logo
