--- Comment #5 from mikael dot morin at tele2 dot fr 2009-02-03 18:00
---
/export/home/eckerta/Desktop/objdir/./gcc/gfortran
-B/export/home/eckerta/Desktop/objdir/./gcc/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/bin/
-B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/lib/ -isystem
/usr/local/gcc
--- Comment #6 from mikael dot morin at tele2 dot fr 2009-02-03 18:01
---
(In reply to comment #1)
Only departure from defaults is --prefix
No, -prefix ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
--- Comment #2 from mikael dot morin at tele2 dot fr 2008-11-05 11:43
---
There is a reset of the expression to NULL_EXPR in case we encounter c_null_ptr
or c_null_funptr.
However, the if conditions for this relies on the is_iso_c attribute, which is
the case of c_loc.
This patch
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-11-02 17:50
---
(In reply to comment #1)
First valgrind error:
==21621== Invalid read of size 8
==21621==at 0x46AAEA: gfc_resolve_expr (resolve.c:4248)
Second valgrind error:
==21621== Address 0x65b2ef8 is 40
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-11-02 18:03
---
Created an attachment (id=16612)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16612action=view)
hackish patch
I think I got it.
When the statement is rejected, all changes are reverted.
However
--- Comment #1 from mikael dot morin at tele2 dot fr 2008-10-29 20:59
---
Reduced case:
subroutine subr (m, n, a, b, c, d, p)
implicit none
integer m, n
real a(m,n), b(m,n), c(n,n), d(m,n)
integer p(n)
d = a(:,p) - matmul(b, c)
end subroutine
The problem is with a(:,p
--- Comment #2 from mikael dot morin at tele2 dot fr 2008-10-29 21:06
---
Created an attachment (id=16585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16585action=view)
proposed patch, regression tested
This patch solves the problem by going through all the loop dimensions
--- Comment #7 from mikael dot morin at tele2 dot fr 2008-10-28 12:21
---
This is happening because
(1) gfc_trans_constant_array_constructor sets loop-temp_dim to 1.
(2) gfc_conv_loop_setup choses the last ss whose shape is known (that of i).
(3) gfc_conv_loop_setup sets loop bounds
--- Comment #9 from mikael dot morin at tele2 dot fr 2008-10-28 14:06
---
So that they are not lost, patches are here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00153.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00181.html
http://gcc.gnu.org/ml/fortran/2008-10/msg00212.html
See
--- Comment #18 from mikael dot morin at tele2 dot fr 2008-10-28 14:08
---
The final patch is here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00104.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
--- Comment #8 from mikael dot morin at tele2 dot fr 2008-10-28 14:42
---
Created an attachment (id=16573)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16573action=view)
second fix
This patch solves the problem by releasing the (4) condition, making the loop
bounds reset
--- Comment #10 from mikael dot morin at tele2 dot fr 2008-10-28 18:27
---
Created an attachment (id=16574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16574action=view)
first fix
This patch tries to solve the problem by changing the (2) condition.
It tries to use an ss whose
--- Comment #11 from mikael dot morin at tele2 dot fr 2008-10-28 18:43
---
(In reply to comment #9)
Some synchronization seems needed.
Well, may patch is made against trunk, so I will leave it as is for now.
If Daniel commits his patch for PR35861, I can provide an updated patch
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-10-23 14:37
---
(In reply to comment #3)
I am not 100% sure that the following is due to the patch in comment #1,
There is already something wrong on trunk, but I agree that the patch makes it
worse. As a side note I'm really
subscripts
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
http://gcc.gnu.org
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-10-23 21:27
---
Quickfix (understand: not regression tested):
Index: trans-array.c
===
--- trans-array.c (révision 141321)
+++ trans-array.c (copie de
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-10-23 22:31
---
There is this comment at the beginning of gfc_trans_create_temp_array.
/* TODO: Investigate why if (n loop-temp_dim)
gcc_assert (integer_zerop (loop-from[n])); fails here. */
This is the case here: n=0
--- Comment #1 from mikael dot morin at tele2 dot fr 2008-10-22 12:49
---
Created an attachment (id=16527)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16527action=view)
patch solving the problem
This patch keeps the original array descriptor from gfc_conv_subref_array_arg
--- Comment #2 from mikael dot morin at tele2 dot fr 2008-10-22 12:52
---
I forgot to say that it is regression tested on x86_64-unknown-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
--- Comment #6 from mikael dot morin at tele2 dot fr 2008-10-18 12:03
---
updated testcase :
#include complex.h
int main ()
{
float a = 1.;
complex float v;
v = I * 1.; /* works */
v = I * a; /* fails */
return 0;
}
Two conditions seem
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-10-17 12:39
---
I'm at r141174.
But I don't think it is one particular revision.
I have seen this for a couple of weeks now.
I thought it would be reverted soon.
Now, I'm not sure it is a gcc bug.
I have the feeling that my
--- Comment #5 from mikael dot morin at tele2 dot fr 2008-10-17 16:38
---
I'v just tried r140349 and r141192.
It's not better.
--
mikael dot morin at tele2 dot fr changed:
What|Removed |Added
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
--- Comment #17 from mikael dot morin at tele2 dot fr 2008-10-12 11:47
---
(In reply to comment #16)
Mikael, are you still with us? Your approach was fine.
Yep, I'm not dead yet.
I was waiting for my copyright assignment form.
Now it's on the way back, I will post to gcc-patches
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-09-14 16:42
---
Created an attachment (id=16318)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16318action=view)
proposed patch
The problem here is that the parser matches a general expression and has to
check later
--- Comment #6 from mikael dot morin at tele2 dot fr 2008-09-03 21:44
---
Created an attachment (id=16215)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16215action=view)
proposed patch
With this patch the first testcase compiles with two warnings.
It doesn't handle import
--- Comment #11 from mikael dot morin at tele2 dot fr 2008-08-31 21:16
---
(In reply to comment #10)
I think your example should be rejected, but it is not like my code, where
smooth_mesh explicitly USEs class_vector. So, I am not sure what's your
point.
My point is this:
As you
--- Comment #12 from mikael dot morin at tele2 dot fr 2008-08-31 21:52
---
Actually, my comment #7 seems to be more related to bug #36374.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
--- Comment #13 from mikael dot morin at tele2 dot fr 2008-08-31 23:34
---
(In reply to comment #12)
Actually, my comment #7 seems to be more related to bug #36374.
No, it's not
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
--- Comment #7 from mikael dot morin at tele2 dot fr 2008-08-30 11:27
---
I think this should be rejected :
module class_vector
implicit none
type vector
end type vector
end module class_vector
module tools_math
implicit none
interface lin_interp
function lin_interp_v
--- Comment #8 from mikael dot morin at tele2 dot fr 2008-08-30 12:12
---
Created an attachment (id=16171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16171action=view)
another testcase with comments telling how to get/not get the error
Look at the comments in module
--- Comment #9 from mikael dot morin at tele2 dot fr 2008-08-30 12:17
---
Forget comment #8.
I was testing with version 4.3.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33343
--- Comment #8 from mikael dot morin at tele2 dot fr 2007-06-01 10:57
---
Ok, placing the function in a contains statement still reproduces the bug with
4.1.2, but doesn't compile with 4.3, complaining about the wrong size
of the string arguments.
And using variable size strings (len
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-06-02 00:06
---
Here is an other test case.
program testCode
implicit none
type vec
real, dimension(3) :: coords
end type
integer, parameter :: n = 5
integer :: i
real
ReportedBy: mikael dot morin at tele2 dot fr
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-05-31 19:00
---
$ export FILE=test
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str1, str2
str1 = (/ string1, string2 /)
write(6,*) str1
write(str2(1),*) string1
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-05-31 19:04
---
$ export FILE=test2
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str2
write(str2(1),*) string1
write(str2(2),*) string2
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-05-31 19:18
---
$ export FILE=test3
$ cat $FILE.f
program testchar
character(len=30), dimension(2) :: str2
write(str2(1),*) string1
write(str2(2),*) string2
call
--- Comment #4 from mikael dot morin at tele2 dot fr 2007-05-31 19:26
---
$ export FILE=test6
$ cat $FILE.f
program testchar
character(len=30) :: str2
write(str2,*) string1
call test( str2 )
call test(string2
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-25 14:38
---
Created an attachment (id=13283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13283action=view)
program showing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-25 14:41
---
$ FC=gfortran; $FC -v; $FC -o test test.f; echo; ./test
Lecture des spécification à partir de
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs
Target: x86_64-pc-linux-gnu
Configuré avec: /usr/src/gcc-4.1.2/configure
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-03-26 05:58
---
Created an attachment (id=13286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13286action=view)
the working case
The problem arise when the subroutine is not defined in a contains statement in
the main
--- Comment #5 from mikael dot morin at tele2 dot fr 2007-03-18 11:58
---
Created an attachment (id=13225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13225action=view)
a test program that does not fail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
ReportedBy: mikael dot morin at tele2 dot fr
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31252
: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-17 21:58
---
Created an attachment (id=13223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13223action=view)
the test program that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-17 22:03
---
the attached program (test.f) fails to compile:
the compilation command is :
gfortran -c test.f
the error is :
test.f: In function probleme:
test.f:2: erreur interne du compilateur: dans gfc_conv_constant, à
50 matches
Mail list logo
