[Bug libfortran/39083] stage 3 libgfortran build fails
--- 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-4.3.3/i686-pc-linux-gnu/include -isystem /usr/local/gcc-4.3.3/i686-pc-linux-gnu/sys-include -c conftest.F 5 /export/home/eckerta/Desktop/objdir/./gcc/f951: symbol lookup error: /usr/local/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions I guess it's a problem with gmp. Do you have it installed? Which versions of mpfr and gmp do you have? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug libfortran/39083] stage 3 libgfortran build fails
--- 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
[Bug fortran/35983] C_LOC in derived type constructor gives weird result
--- 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 changes this behavior by relying on the symtree names instead.
Index: trans-expr.c
===
--- trans-expr.c(révision 141583)
+++ trans-expr.c(copie de travail)
@@ -3689,15 +3682,16 @@ gfc_trans_structure_assign (tree dest, gfc_expr *
{
/* Skip absent members in default initializers. */
if (!c-expr)
-continue;
+ continue;
/* Update the type/kind of the expression if it represents either
C_NULL_PTR or C_NULL_FUNPTR. This is done here because this may
be the first place reached for initializing output variables that
have components of type C_PTR/C_FUNPTR that are initialized. */
- if (c-expr-ts.type == BT_DERIVED c-expr-ts.derived
- c-expr-ts.derived-attr.is_iso_c)
-{
+ if (c-expr-symtree c-expr-symtree-name
+ (!strcmp (c_null_ptr, c-expr-symtree-name)
+ || !strcmp (c_null_funptr, c-expr-symtree-name)))
+ {
c-expr-expr_type = EXPR_NULL;
c-expr-ts.type = c-expr-ts.derived-ts.type;
c-expr-ts.f90_type = c-expr-ts.derived-ts.f90_type;
With this patch alone, I still get wrong-code though (pointer uninitialized
instead of nullified).
I've had to revert this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150#c7
to have it working.
There is only one regression, c_loc_tests_12.f03.
That one is expected, and we are back at PR35150.
I looked at that one too, but I must admit I'm at least as confused as FX when
he fixed it.
If some middle-end gurus could take a look/give some tips there...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35983
[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x
--- 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 bytes inside a block of size 56 free'd ==21621==at 0x4C243AF: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==21621==by 0x482C6A: gfc_delete_symtree (symbol.c:2269) Those are the same error (look carefully, the second one is indented). The first part indicates where the error appears. The second one precises the error (here access to a freed block) and where (in this case) the free was. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x
--- 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, the namespace is still holding the expression for len(x) in cl_list. So, when resolving len(x) we have a pointer to len's freed symtree. This patch solves the problem by adding a old_cl_list field which is copied back to cl_list if the statement is rejected. I'm not sure it is the right way to do it though. As an inquiry function, len should always be reachable, whatever happens. What's your opinion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug fortran/37749] ICE on array section with vector subscript
--- 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) - matmul(b,c) It arises because: (1) gfc_conv_loop_setup chooses matmul's ss to setup the loop bounds. This explains why -matmul(b,c) + a(:,p) works. (2) The loop-to are asserted to be NULL in gfc_conv_loop_setup (GFC_SS_FUNCTION case) (3) gfc_add_ss_loop_code for the second dimension of a(:,p) calls gfc_set_loop_bounds_from_array_spec which sets the second dimension of the loop.to (4) in the loop setting the descriptor in gfc_trans_create_temp_array, in the first iteration, (n = 0), loop.to is NULL, and the size is set to NULL. (5) In the next iteration, (n = 1), loop.to != NULL, and the loop follows the normal path. The size however was set to NULL (condition (4)). (4) and (5) explain why it works with a(q,:) - matmul(b,c) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug fortran/37749] ICE on array section with vector subscript
--- 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 in gfc_trans_create_temp_array to look for a NULL loop-to before the actual loop execution and set size to NULL if one is found (it solves conditions (4) and (5)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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 (-1-1) according to the chosen ss (i). (4) gfc_trans_create_temp_array conditionally resets the loop bounds (if n = loop-temp_dim). (5) gfc_trans_create_temp_array later assumes that the loop starts at zero. (2) explains why it works with y(i+(/1,1,1/)) but not with y((/1,1,1/)+i) My patch in comment #3 changes the last ss to first ss and of course it doesn't work as was said in comment #6 I have two fixes almost ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/35820] internal compiler error with nested FORALL
--- 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 the follow-up threads and the mailing list archive for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35820
[Bug fortran/35840] ICE for character expression in I/O specifier
--- 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
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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 unconditional at the beginning of gfc_trans_create_temp_array. This is harmless because most of the time the loop-from is already zero (there was an assertion for that before PR31610) and the code adds nothing, while in other cases the bounds reset is executed. I had initially a problem though, because then the array indexes for accessing elements of (/1,1,1/) were wrong as the offset for that array was set too early, taking the initial loop bounds into account instead of the later zero-based ones. I looked at what happened in the case of i as its indexes were not miscalculated and found that there was a code for that at the end of gfc_conv_loop_setup. What this patch does is remove the code setting the offset according to the loop in gfc_trans_array_constructor, and allow GFC_SS_CONSTRUCTOR in gfc_conv_loop_setup's code. This patch passes the regression tests without any new failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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 starting value is zero when there is one (In this case it is that of (/1,1,1/)). The regression tests pass with both this patch applied and that one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610#c21 reverted (ICEing is better than wrong-coding). I was initially dissatisfied by this patch as it was not changing the beginning of gfc_trans_create_temp_array, which was leaving room for another case where the loop would not start at zero. I failed to find such a case though. However, I believe it is still valuable as it produces a (just a little) better code (see array indexes) than the other one. Now I suggest we apply both patches. Any comments ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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. I quickly looked at it, and it should be rather straightforward (it looks like a tabs problem only). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/36091] false positive in bounds checking with forall
--- 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 impressed by how fast you found a not-working case to my slowly and laboriously prepared code. I've been playing a bit with the testcase on trunk. This: write(*,*) foo([1]+i) produces this code fragment: integer(kind=8) A.4[2]; struct array1_integer(kind=8) atmp.3; atmp.3.dtype = 521; atmp.3.dim[0].stride = 1; atmp.3.dim[0].lbound = 0; atmp.3.dim[0].ubound = 1; atmp.3.data = (void *) A.4; atmp.3.offset = 0; while this: write(*,*) foo(i+[1]) produces this code fragment: integer(kind=8) A.4[1]; struct array1_integer(kind=8) atmp.3; atmp.3.dtype = 521; atmp.3.dim[0].stride = 1; atmp.3.dim[0].lbound = 0; atmp.3.dim[0].ubound = 0; atmp.3.data = (void *) A.4; atmp.3.offset = 0; As you can see, the first case's array temporary has a size of 2, while it should be of size 1. The code however is correct as only the first element of the array is used. With the patch, it is... wrong. To be continued. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug fortran/37903] New: wrong-code for complicated vector subscripts
Modified code from a comment for PR36091 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091#c3 integer :: i(-1:1) = 1, j(3) = 1, k(3) k = j((/1,1,1/)+i) end Wrong code, the temporary array generated is too small. -- Summary: wrong-code for complicated vector 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/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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 travail)
@@ -3380,7 +3380,7 @@
{
/* The frontend has worked out the size for us. */
loopspec[n] = ss;
- continue;
+ break;
}
if (ss-type == GFC_SS_CONSTRUCTOR)
This forces to use the array constructor's ss to setup the loop.
As it is zero-based, the upper bounds has the proper value and the array has
the proper size.
I suspect this is only hiding the problem though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- 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, loop-temp_dim=1, loop.from[0]=lbound(i)=-1 I don't understand the use of the (n = loop-temp_dim) condition preventing the loop bounds from being moved (to be zero-based). The problem arises farther in the function, when gfc_index_zero_node is used instead of loop.from, and only the (wrong) loop.to is taken into account. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/36091] false positive in bounds checking with forall
--- 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 to gfc_trans_create_temp_array so that the temporary generated can have the same bounds as the original, which is needed for bounds checking. However I'm wondering if this is the good way to solve the problem. I believe that the code generated for this: forall (i=j:k) p(p(i)) = 1 ! bounds checking problem should not be much different than the code generated for that: p(p(j:k)) = 1 ! no bounds checking problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug fortran/36091] false positive in bounds checking with forall
--- 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
[Bug c/37850] infinite recursive call to __mulsc3 when multiplying not-constant complexs
--- 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 necessary for the bug to happen:
- the testcase is compiled with -O0
- gcc is configured and bootstrapped with CFLAGS=-O0 -g (I suspect that -g
is unnecessary, but I don't want to test again)
--
mikael dot morin at tele2 dot fr changed:
What|Removed |Added
Summary|FAIL: |infinite recursive call to
|gfortran.dg/c_by_val_1.f |__mulsc3 when multiplying
|gfortran.dg/value_4.f90 |not-constant complexs
|execution test |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f gfortran.dg/value_4.f90 execution test
--- 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 system is somehow broken, but I can't figure out
where.
Here are the details:
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran --disable-multilib
Modèle de thread: posix
gcc version 4.4.0 20081016 (experimental) (GCC)
$ /usr/local/bin/gcc -O0 -g -c value_4.c
$ /usr/local/bin/gfortran -ff2c -w -O0 -g value_4.o value_4.f90 -o value_4
$ ./value_4
zsh: segmentation fault ./value_4
(gdb) bt
#0 __muldc3 (a=8, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1 0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2 0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3 0x7fb8c55fb351 in __muldc3 (a=8, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4 0x7fb8c55fb351 in __muldc3 (a=-1, b=2, c=4, d=0)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5 0x004007f7 in c_to_c__ (retval=0x7fffce012220, c1=0 + 0 * I,
c2=0x7fffce012228) at value_4.c:48
#6 0x0040092d in value_4 () at value_4.f90:39
#7 0x004009e0 in main (argc=1, argv=0x7fffce012338)
at ../../../src/libgfortran/fmain.c:21
#8 0x7fb8c52a6146 in __libc_start_main () from /lib/libc.so.6
#9 0x00400659 in _start ()
this is not fortran-related, reduced-testcase:
#include complex.h
int main ()
{
complex float u = __muldc3 (1, 2, 3, 4);
return 0;
}
(gdb) bt
#0 __muldc3 (a=10, b=0, c=0, d=1) at ../../../src/libgcc/../gcc/libgcc2.c:1834
#1 0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#2 0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#3 0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#4 0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#5 0x00400cc1 in __muldc3 (a=10, b=0, c=0, d=1)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#6 0x00400cc1 in __muldc3 (a=1, b=2, c=3, d=4)
at ../../../src/libgcc/../gcc/libgcc2.c:1889
#7 0x004004a1 in main () at value_4_f90.c:4
I looked at the offending line, but seen nothing wrong though I have never
been playing with C complex.
In fact the code looks like directly taken from the C99 standard, so I bet it's
correct.
I will see if I can find a working revision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug c/37850] FAIL: gfortran.dg/c_by_val_1.f gfortran.dg/value_4.f90 execution test
--- 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 Component|fortran |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug fortran/37850] New: FAIL: gfortran.dg/c_by_val_1.f gfortran.dg/value_4.f90 execution test
I have seen nothing about it on the list yet, so I guess I'm the only one impacted. Can someone confirm ? I'll investigate and provide more information later. FAIL: gfortran.dg/c_by_val_1.f -O0 execution test FAIL: gfortran.dg/c_by_val_1.f -O1 execution test FAIL: gfortran.dg/c_by_val_1.f -O2 execution test FAIL: gfortran.dg/c_by_val_1.f -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/c_by_val_1.f -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/c_by_val_1.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/c_by_val_1.f -O3 -g execution test FAIL: gfortran.dg/c_by_val_1.f -Os execution test FAIL: gfortran.dg/value_4.f90 -O0 execution test FAIL: gfortran.dg/value_4.f90 -O1 execution test FAIL: gfortran.dg/value_4.f90 -O2 execution test FAIL: gfortran.dg/value_4.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/value_4.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/value_4.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/value_4.f90 -O3 -g execution test FAIL: gfortran.dg/value_4.f90 -Os execution test -- Summary: FAIL: gfortran.dg/c_by_val_1.f gfortran.dg/value_4.f90 execution test 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 GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
[Bug fortran/35840] ICE for character expression in I/O specifier
--- 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 soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/35840] ICE for character expression in I/O specifier
--- 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 that it is an initialization expression. I have taken the code in gfc_match_init_expr and put it in its own function (gfc_reduce_init_expr) so that checking can be deferred. Fixing the bug is then trivial. This has just been regression tested. Should I send this to the fortran mailing list ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
[Bug fortran/36275] Binding label can be any scalar char initialisation expression
--- 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 statements as it is far less trivial ;) I'll have to see more in details what was said on the c.l.f thread. Awaiting constructive (or destructive if you prefer) comments, advices, screams, ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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 said in your first comment, there is no ambiguity in your code. vector is defined in only one module which is used when needed in other modules. Moreover you use private statements to prevent use associated entities from being exported in those modules. Doing this way, no module but class_vector exports vector. No ambiguity possible What my example shows is that tools_math (and other modules in your code) export vector as well. Ambiguities are possible. As gfortran seems to handle simple ambiguities correctly, what I'm underlying is not the bug, but it might be part of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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() use class_vector type(vector ) :: lin_interp_v end function lin_interp_v end interface end module tools_math module smooth_mesh use tools_math implicit none type(vector ) :: new_pos ! vector shouldn't be available IMHO end module smooth_mesh I find this behavior very confusing, inconsistent with the concept of scoping units. While I understand that vector should make its way to the tools_math.mod file for lin_interp_v's type checking, it should be kept local to that function. I haven't seen it explicitely in the standard though. Salvatore, as a workaround you can put a private statement in modules where you use module from within a function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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 class_bc_math. This is very strange. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- 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
[Bug fortran/33566] New: fortran : wrong rank of derived type parameters array components
gfortran seems to miscalculate the rank when trying to get a component of an array member of a derived type parameter. I think that the following program explains better than my cryptic explanations : program test_vec implicit none integer :: i real:: x type vec3 real, dimension(3) :: coords end type vec3 type(vec3),parameter :: v1 = vec3((/ 1.0, 2.0, 3.0 /)) type(vec3) :: v2 v2 = vec3((/ 1.0, 2.0, 3.0 /)) x = v1%coords(1) ! works do i=1,3 x = v1%coords(i) ! fails x = v2%coords(i) ! works end do end program test_vec Here is the error returned ... $ gfortran -c test.f test.f:27.9: x = v1%coords(i) ! fails 1 Error: Incompatible ranks 0 and 1 in assignment at (1) ... and the version of gfortran used : $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-svn/gcc/configure --enable-languages=fortran : (reconfigured) ../gcc-svn/gcc/configure --enable-languages=fortran : (reconfigured) ../gcc-svn/gcc/configure --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070926 (experimental) (GCC) -- Summary: fortran : wrong rank of derived type parameters array components Product: gcc Version: 4.3.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 GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566
[Bug fortran/33343] New: ICE (segfault) on invalid code with wrongly shaped arguments to elemental procedures
The following invalid program produces an ICE with gfortran (4.3 and 4.2.1). The program does not ICEs if we replace the invalid line by one of the (valid) commented lines. If we don't use automatic arrays (ie we use dimension(length) instead of dimension(size(vectors)), there is no ICE either. $ cat test15.f module geometry implicit none integer, parameter :: prec = 8 integer, parameter :: length = 10 contains elemental function Mul(a, b) real(kind=prec) :: a real(kind=prec) :: b, Mul intent(in) :: a, b Mul = a * b end function Mul pure subroutine calcdAcc2(vectors, angles) real(kind=prec), dimension(:) :: vectors real(kind=prec), dimension(size(vectors),2) :: angles intent(in) :: vectors, angles real(kind=prec), dimension(size(vectors)) :: ax real(kind=prec), dimension(size(vectors),2) :: tmpAcc ! tmpAcc(1,:) = Mul(angles(1,1:2),ax(1)) ! tmpAcc(:,1) = Mul(angles(:,1),ax) tmpAcc(:,:) = Mul(angles(:,:),ax) end subroutine calcdAcc2 end module geometry $ /usr/local/bin/gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-svn/gcc/configure --enable-languages=c,fortran CFLAGS='-g -O0' Thread model: posix gcc version 4.3.0 20070906 (experimental) (GCC) Here is the backtrace from gdb : (gdb) bt #0 integer_onep (expr=0x0) at ../../gcc-svn/gcc/gcc/tree.c:1337 #1 0x080d0543 in gfc_conv_loop_setup (loop=0xbf9fed24) at ../../gcc-svn/gcc/gcc/fortran/trans-array.c:3250 #2 0x080e653a in gfc_trans_assignment_1 (expr1=0x894fed8, expr2=0x8950d10, init_flag=0 '\0') at ../../gcc-svn/gcc/gcc/fortran/trans-expr.c:3972 #3 0x080e6a55 in gfc_trans_assignment (expr1=0x894fed8, expr2=0x8950d10, init_flag=36 '$') at ../../gcc-svn/gcc/gcc/fortran/trans-expr.c:4152 #4 0x080e77b1 in gfc_trans_assign (code=0x8950678) at ../../gcc-svn/gcc/gcc/fortran/trans-expr.c:4164 #5 0x080c7552 in gfc_trans_code (code=0x8950678) at ../../gcc-svn/gcc/gcc/fortran/trans.c:970 #6 0x080de492 in gfc_generate_function_code (ns=0x894f5f0) at ../../gcc-svn/gcc/gcc/fortran/trans-decl.c:3258 #7 0x080c49ca in gfc_generate_module_code (ns=0x894d8c0) at ../../gcc-svn/gcc/gcc/fortran/trans.c:1190 #8 0x080991e6 in gfc_parse_file () at ../../gcc-svn/gcc/gcc/fortran/parse.c:3316 #9 0x080c027d in gfc_be_parse_file (set_yydebug=0) at ../../gcc-svn/gcc/gcc/fortran/f95-lang.c:300 #10 0x083455c0 in toplev_main (argc=13, argv=0xbf9ff284) at ../../gcc-svn/gcc/gcc/toplev.c:1045 #11 0x08108ccf in main (argc=-1212132032, argv=0x0) at ../../gcc-svn/gcc/gcc/main.c:35 Thank you guys for all the great work you do :) -- Summary: ICE (segfault) on invalid code with wrongly shaped arguments to elemental procedures Product: gcc Version: 4.3.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/bugzilla/show_bug.cgi?id=33343
[Bug fortran/32170] string badly passed as function arguments
--- 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=*), it works as expected with both versions. Indeed, the compiler should report an error ; but it is just an improvement. Still much to learn about Fortran ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32129] ICE: Procedure call with array-section-actual to scalar dummy
--- 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, dimension(3, n), parameter :: vy = reshape( (/ (1.d0, i=1,3*n) /), shape = (/ 3, n /)) i = 1 call Sub(vec(vy(:,i))) contains subroutine Sub(xin) type(vec) :: xin intent(in) xin print*, xin end subroutine end program This program produce an ICE (in gfc_trans_call, at fortran/trans-stmt.c:321) But if vy is a normal variable (not a parameter), it works. And it works also if we use vy(:,1) instead of vy(:,i). Hoping it helps... -- mikael dot morin at tele2 dot fr changed: What|Removed |Added CC||mikael dot morin at tele2 ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
[Bug fortran/32170] New: string badly passed as function arguments
-- Summary: string badly passed as function arguments Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org 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
[Bug fortran/32170] string badly passed as function arguments
--- 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 write(str2(2),*) string2 write(6,*) str2 end program This is the working (reference case) Note the different spacing (I think it is the write function which is called twice in the second case). $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 string1 string2 string1 string2 $ export FC=/usr/local/bin/gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) string1 string2 string1 string2 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added CC||mikael dot morin at tele2 ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- 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 call test( str2 ) call test( (/ string1, string2 /) ) end program subroutine test(chars) character(len=30), dimension(2) :: chars write(6,*) chars end subroutine $ This case writes junk on the terminal $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 string1 string2 string1string2 @ @ L%Ö«* ^¤#9500;Ö«* #9670;îIÖ«* ¸â#150;Ô $ $ export FC=/usr/local/bin/gfortran [EMAIL PROTECTED] scol/ragsl/progs $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) string1 string2 string1string2#65533; @#65533; @`â#65533;#65533; l+^ $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- 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 test( str2 ) call test( (/ string1, string2 /) ) end program subroutine test(chars) character(len=30), dimension(:) :: chars write(6,*) chars end subroutine $ This case fails with gfortran 4.1.2 (segmentation fault) and does nothing with gfortran 4.3 $ export FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 zsh: segmentation fault ./$FILE $ $ export FC=/usr/local/bin/gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/32170] string badly passed as function arguments
--- 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) end program subroutine test(chars) character(len=30) :: chars write(6,*) chars end subroutine $ Actually, I could have reported this case only, because it doesn't even use string arrays. Both versions write junk on the terminal. $ FC=gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 string1 string2;0#65533;#65533;#65533;#65533;L} $ $ export FC=/usr/local/bin/gfortran $ $FC -v;$FC -o $FILE $FILE.f ; echo; ./$FILE Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070525/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070525 (experimental) string1 string2;4#65533;#65533;#65533;#65533;Pb $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32170
[Bug fortran/31346] New: wrong values for ubound and size of deferred shape arrays
size and ubound are lost when passing an array as argument of a procedure -- Summary: wrong values for ubound and size of deferred shape arrays Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal 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?id=31346
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- 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
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 size= 5 size= 25 ubound= 5 ubound= 5 5 size= 0 size= 0 ubound= 0 ubound= 2193121 0 FC=/usr/local/bin/gfortran; $FC -v; $FC -o test test.f; echo; ./test Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.3-20070316/configure --enable-languages=fortran --disable-multilib Modèle de thread: posix version gcc 4.3.0 20070316 (experimental) size= 5 size= 25 ubound= 5 ubound= 5 5 size=-250 size= 0 ubound= 0 ubound= 5222132 0 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added Known to fail||4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31346] wrong values for ubound and size of deferred shape arrays
--- 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 program. I haven't seen anything in the Fortran 2003 standard forcing the subroutines to be in the contains statement. But even if it is the case, the compiler should report an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- 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
[Bug fortran/31252] New: ICE dans gfc_conv_constant, � fortran/trans-const.c:348
-- Summary: ICE dans gfc_conv_constant, à fortran/trans-const.c:348 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: 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/bugzilla/show_bug.cgi?id=31252
[Bug fortran/31253] New: ICE in gfc_conv_constant, at fortran/trans-const.c:348
the fortran compiler crashes when trying to compile the following test program : subroutine probleme(p) real(kind=8), dimension(:) :: p integer :: nx = size(p, 1) integer :: nix nix = nx end subroutine The error reported by the compiler is : test.f: In function probleme: test.f:2: erreur interne du compilateur: dans gfc_conv_constant, à fortran/trans-const.c:348 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez URL:http://gcc.gnu.org/bugs.html pour plus de détail. The compilation command was : gfortran test.f The gfortran -v is : 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 -- Summary: ICE in gfc_conv_constant, at fortran/trans-const.c:348 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: 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/bugzilla/show_bug.cgi?id=31253
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- 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
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- 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, à fortran/trans-const.c:348 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez URL:http://gcc.gnu.org/bugs.html pour plus de détail. the fortran version is (gfortran -v) : 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 --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added CC||mikael dot morin at tele2 ||dot fr Keywords||ice-on-valid-code Known to fail||4.1.1 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
