http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055
--- Comment #2 from jpr at csc dot fi 2011-11-10 06:09:07 UTC ---
OK, i found and lost the PR that included this. However,
your workaround doesn't seem to work either:
program a
character(len=:),allocatable::s
integer::j=2
s=repeat(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51055
Bug #: 51055
Summary: deferred length character allocation:
allocate(character(len=i)::s) rejected
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50173
jpr at csc dot fi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050
jpr at csc dot fi changed:
What|Removed |Added
CC||jpr at csc dot fi
--- Comment #9 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50173
Bug #: 50173
Summary: ICE when allocating derived type with allocatable
component(s) and specifying lower bound
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48746
jpr at csc dot fi changed:
What|Removed |Added
CC||jpr at csc dot fi
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583
--- Comment #7 from jpr at csc dot fi 2011-02-02 12:48:37 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> Thanks a lot, at least for me this patch seems to solve the problem.
Well, that patch did break the direct_io_1.f90 tes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583
jpr at csc dot fi changed:
What|Removed |Added
CC||jpr at csc dot fi
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45828
--- Comment #4 from jpr at csc dot fi 2010-09-30 05:12:10 UTC ---
This is the patch introducing the call to gfc_has_default_initializer()
from resolve_allocate_expr():
http://gcc.gnu.org/viewcvs?view=revision&revision=164305
2010-09-15 J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45828
--- Comment #3 from jpr at csc dot fi 2010-09-30 04:50:05 UTC ---
Hi,
the problem seems to be in expr.c (called from resolve.c:
resolve_allocate_expr())
bool gfc_has_default_initializer (gfc_symbol *der)
{
gfc_component *c;
gcc_assert (der
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45828
--- Comment #1 from jpr at csc dot fi 2010-09-29 11:20:40 UTC ---
>the attached program misbehaves using gfortran 4.6 (i think). The
>supposed output is:
> 0.000
>using gfortran 4.6 i get
> 0.000
> 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45828
Summary: No default initialization of derived type members?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedT
--- Comment #2 from jpr at csc dot fi 2010-09-22 04:52 ---
somewhat simpler testcase:
MODULE m
CONTAINS
FUNCTION rnd(n)
INTEGER, INTENT(in) :: n
REAL(8), DIMENSION(n) :: rnd
CALL RANDOM_NUMBER(rnd)
END FUNCTION rnd
SUBROUTINE GeneticOptimize(n)
INTEGER :: n
--- Comment #1 from jpr at csc dot fi 2010-09-22 04:48 ---
P.S. don't mind my directory naming. This is trunk gfortran
from ~6 hours ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45744
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45744
--- Comment #7 from jpr at csc dot fi 2010-09-20 11:46 ---
Hi,
yes the stack size is relevant here, because otherwise gcc does not
call ___chkstk(), which seems to be the trouble here. 4K stack usage
is not very big IMHO.
-Juha
(In reply to comment #6)
> (In reply to comment
--- Comment #5 from jpr at csc dot fi 2010-09-20 11:36 ---
And still reduced testcase, fails at -O0.
void main()
{
char s;
void b() {
char p[4096];
if ( s!='s' ) abort();
}
s='s';
b();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
--- Comment #4 from jpr at csc dot fi 2010-09-20 11:12 ---
For the testcase in comment #3 the ___chkstk call is also
generated with -O0 (and trying to use %r10 across the call...)
Juha
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
--- Comment #3 from jpr at csc dot fi 2010-09-20 11:05 ---
Even simpler testcase, now in C.
#include
#include
void a()
{
char s[2];
void b() {
char p[4096];
if ( strcmp(s,"s")!=0 ) abort();
strcpy( p,"p");
}
strcpy( s,"s&q
--- Comment #2 from jpr at csc dot fi 2010-09-20 06:54 ---
Created an attachment (id=21842)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21842&action=view)
somewhat reduced testcase
Hi,
I tried debugging this more. Attached is a somewhat reduced testcase. I also
had a
--- Comment #1 from jpr at csc dot fi 2010-09-16 19:31 ---
Created an attachment (id=21812)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812&action=view)
failing fortran code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
variables+optimization==failure?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
GCC target tr
--- Comment #3 from jpr at csc dot fi 2009-12-18 05:43 ---
No,
this was the trunk from yesterday. Some wrinkeles seem to remain...
Juha
--
jpr at csc dot fi changed:
What|Removed |Added
--- Comment #1 from jpr at csc dot fi 2009-12-18 00:35 ---
or rather this
Index: unix.c
===
--- unix.c (revision 155325)
+++ unix.c (working copy)
@@ -781,7 +781,11 @@
static stream *
fd_to_stream (int fd
-
Summary: libgfortran fails to open large files on MINGW32
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #5 from jpr at csc dot fi 2009-09-03 10:40 ---
Adding -fstrict-aliasing to -O1 breaks the code:
gfortran -o m m.f90 -O1; ./m
y= 0.60653065945526063 2*y= 1.2130613189105213
gfortran -o m m.f90 -O1 -fstrict-aliasing ; ./m
y= 0.60653065945526063 2*y
--- Comment #4 from jpr at csc dot fi 2009-09-03 07:10 ---
FWIW: I had a look at the -fdump-tree-all files.
All seems well (to my untrained eyes), until
:
D.1412_51 = y;
D.1430_52 = D.1412_51 * 2.0e+0;
z = D.1430_52;
in m.f90.060t.phiprop
is transformed to
:
D.1412_51 = 1.0e
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
Sorry about the duplicate...
*** This bug has been marked as a duplicate of 41212 ***
--
jpr at csc dot fi changed:
What|Removed |Added
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
*** Bug 41213 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
routine b
end program m
--
Summary: miscompilation at -O2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j
routine b
end program m
--
Summary: miscompilation at -O2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j
--- Comment #2 from jpr at csc dot fi 2009-06-15 08:28 ---
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.
>
> * * *
>
> gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> print the following:
>
--- Comment #2 from jpr at csc dot fi 2008-09-19 09:25 ---
This invalid peace of code gives an ICE:
program test
integer, pointer :: a(:),b(:)
a(1) => b(1)
end program test
gfortran -c test.f90
test.f90: In function 'test':
test.f90:3: internal compiler error: in
--- Comment #1 from jpr at csc dot fi 2008-09-19 08:20 ---
Small update: this bug is already present in 4.3.1.
The 4.2.x series seems OK.
Juha
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
dBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
--- Comment #27 from jpr at csc dot fi 2008-02-14 08:12 ---
I think that the test program shown in comment #25 is invalid, as the main
program does not know about the call interface of the check_integer4_rank1()
function. If you add the module related lines in the comments, all is well
--- Comment #32 from jpr at csc dot fi 2008-02-09 06:46 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
hi,
the patch looks good to me, although from the clarity point of view and
to avoid potential problem with other thread models, i'd go all th
--- Comment #24 from jpr at csc dot fi 2008-02-08 12:12 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
> This might be desirable for other reasons, but it will not fix the problem
> completely.
Yeah well, the easy way out here would be to i
--- Comment #22 from jpr at csc dot fi 2008-02-08 05:29 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
> So if the above is really at fault then the
> leak should not manifest on Cygwin at all.
The logic there is ok i guess, as i already noted
--- Comment #16 from jpr at csc dot fi 2008-02-07 09:19 ---
Subject: Re: [Regression wrt g77] I/O leaks handles/memory
on Windows XP
Well, the internal write case is anyway a regression introduced by this
patch
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html
--- Comment #13 from jpr at csc dot fi 2008-02-07 05:07 ---
Subject: Re: I/O leaks handles/memory on Windows XP
>
> --- Comment #12 from tkoenig at gcc dot gnu dot org 2008-02-06
21:49 ---
> Just wondering... is this a regression?
At least g77 runs the two exa
--- Comment #11 from jpr at csc dot fi 2008-02-06 20:54 ---
Subject: Re: I/O leaks handles/memory on Windows XP
I had a look: the problem seems to be with the logic of mutex->counter in
gcc/config/i386/gthr-win32.c. Libgfortran makes the following calls
during an internal write
--- Comment #9 from jpr at csc dot fi 2008-02-06 11:31 ---
Subject: Re: I/O leaks handles/memory on Windows XP
just an observation: if i build gcc with "thread model=single", all seems
well.
Juha
>
>
> --- Comment #8 from jvdelisle at gcc dot gnu dot or
--- Comment #1 from jpr at csc dot fi 2008-02-03 14:38 ---
Mikko already reported this in 35063.
Sorry about the dup!
Juha
*** This bug has been marked as a duplicate of 35063 ***
--
jpr at csc dot fi changed:
What|Removed |Added
--- Comment #1 from jpr at csc dot fi 2008-02-03 14:38 ---
*** Bug 35064 has been marked as a duplicate of this bug. ***
--
jpr at csc dot fi changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
GCC host triplet: i386-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35064
--- Comment #5 from jpr at csc dot fi 2007-09-11 12:49 ---
Subject: Re: Fortran SELECT statement miscompiles
Yes, this seems to do the trick.
Thanx, Juha
>
>
> --- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-11 10:48
> ---
>> Adding a defaul
--- Comment #3 from jpr at csc dot fi 2007-09-11 10:42 ---
(In reply to comment #1)
> I'll work on that, I've re-written CHARACTER SELECT recently. However, I can't
> reproduce this on x86_64-linux. Could you run "gfortran -fdump-tree-original
> a.f90"
ding a default case gets rid of the problems, also for my real application
code.
Regards, Juha
--
Summary: Fortran SELECT statement miscompiles
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
GCC host triplet: i386 linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33386
ib/../lib64/crtn.o
./test
1.00 should be: 0.500
Regrads, Juha
--
Summary: miscompilation with gfortran -O2 -ffast-math -ftree-
vectorize
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
GCC host triplet: x86_64 linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
--- Comment #1 from jpr at csc dot fi 2007-09-04 07:49 ---
The code is invalid without explicit interface to SUB().
Modified code:
REAL X(2,3), Y(2)
Y=[1.,2.]
CALL SUB(X,Y)
DO I = 1, 3
PRINT*,X(:,I)
ENDDO
CONTAINS
SUBROUTINE SUB(A,B
gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33223
--- Comment #9 from jpr at csc dot fi 2006-11-13 08:45 ---
Subject: Re: [4.3 Regression] -O2 gives wrong
results
Hi,
i get the same with -O0 & -O1, but -O2 gives the output
1: 1 nan
2: 1 5
1: 2 5
2: 2 0.56
1: 3 0.56
2: 3 0.546798
1: 4 0.546798
2: 4 0.450496
--- Comment #7 from jpr at csc dot fi 2006-11-12 13:24 ---
Subject: Re: [4.3 Regression] -O2 gives wrong
results
In reply to comment #6)
> mine, but please can you give me the correct output? i don't see the
> regressions (comparing to a 4.1.2 compiler).
In the origin
--- Comment #4 from jpr at csc dot fi 2006-11-11 19:16 ---
Subject: Re: [4.3 Regression] -O2 gives wrong
results
Note however that the prints inside the main loop are not needed
to trigger the problem in the oroginal test code. You may freely
remove them and the problem remains. I
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
GCC host triplet: x86 linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29798
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25806
--- Comment #8 from jpr at csc dot fi 2005-12-14 06:51 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Working on a patch.
>
> Posted a pacth here: http://gcc.gnu.org/ml/fortran/2005-12/msg00116.html
>
Is anyone considering approving (or disapprovin
oduct: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25307
org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25292
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
cc dot gnu dot org
ReportedBy: jpr at csc dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25262
62 matches
Mail list logo
