--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-04 00:40 ---
(In reply to comment #5)
(In reply to comment #4)
Created an attachment (id=17016)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17016action=view) [edit]
fix
Does anyone know the use of the block
--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-04 01:02 ---
(In reply to comment #5)
Mikael,
Now the solutions:
(1) Add some conditions to the if before to prevent executing this.
(2) Remove the gfc_match_whatever that has nothing to do in resolve.c and
find
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-04 13:01 ---
Subject: Bug 38536
Author: mikael
Date: Sun Jan 4 13:01:12 2009
New Revision: 143050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143050
Log:
2009-01-04 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-04 19:00 ---
(In reply to comment #4)
which detects invalid permutations in the case of constant(!) arguments.
Closing as fixed.
No, it's not. Reopening.
The initial testcase is still not catch.
--
mikael at gcc dot gnu
--- Comment #27 from mikael at gcc dot gnu dot org 2009-01-04 19:12 ---
Subject: Bug 35681
Author: mikael
Date: Sun Jan 4 19:12:16 2009
New Revision: 143057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143057
Log:
2009-01-04 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-04 19:12 ---
Subject: Bug 38669
Author: mikael
Date: Sun Jan 4 19:12:16 2009
New Revision: 143057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143057
Log:
2009-01-04 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-04 19:12 ---
Subject: Bug 38487
Author: mikael
Date: Sun Jan 4 19:12:16 2009
New Revision: 143057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143057
Log:
2009-01-04 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-05 14:35 ---
(In reply to comment #2)
The .mod looks OK though - as far I can see (rearrangements; only one
testcommon1 etc. instead of two).
The test2.mod is wrong I think.
Without USE TEST3:
[...]
(('testcommon1' 2 0 0
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-05 14:54 ---
(In reply to comment #4)
With USE TEST3, sym-backend_decl is not set.
Interestingly, the backend_decl for test3's testchar is set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-05 18:44 ---
Subject: Bug 38726
Author: mikael
Date: Mon Jan 5 18:44:09 2009
New Revision: 143084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143084
Log:
2009-01-05 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-05 18:44 ---
Subject: Bug 38669
Author: mikael
Date: Mon Jan 5 18:44:09 2009
New Revision: 143084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143084
Log:
2009-01-05 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-05 15:08 ---
(In reply to comment #6)
If compiled with -fbounds-check, the executable yields:
At line 29 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90
Fortran runtime error: Array
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-05 13:37 ---
(In reply to comment #7)
It caused PR 38726
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38669
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-05 13:58 ---
(In reply to comment #0)
On Linux/ia64, revision 143058 gave
FAIL: gfortran.dg/elemental_subroutine_7.f90 -O0 execution test
According to the gcc-testresults mailing list, this is confirmed on
powerpc-ibm
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-05 14:47 ---
without USE TEST3, gfc_get_symbol_decl (sym=testchar) returns sym-backend_decl
because it is set.
With USE TEST3, sym-backend_decl is not set, and we create the declaration. As
testchar is included from test2 we set
--- Comment #29 from mikael at gcc dot gnu dot org 2009-01-05 20:10 ---
(In reply to comment #28)
I think this PR can be closed - the ICEs are gone, the TODO item is gone and
the missing warnings are tracked in PR 33037.
Closing then. It was probably fixed together with PR 37903
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-05 20:23 ---
(In reply to comment #8)
As far as I can tell, ASIS is working correctly with gfortran 4.4 and 4.3.
So, we can close?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-06 13:45 ---
Looks like it's fixed now.
Thanks for the report.
Closing.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-06 21:16 ---
(In reply to comment #2)
The line:
TYPE(C_PTR), INTENT(IN) :: CPTR ! The C address
should be:C_F_STRING(CPTR)
TYPE(C_PTR), VALUE, TARGET:: CPTR ! the C address
You are right. The call to strlen is OK
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-06 21:34 ---
(In reply to comment #1)
The variable II in CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1) is not initialized.
This is fixed at revision 143124.
Closing.
--
mikael at gcc dot gnu dot org changed:
What
--- Comment #10 from mikael at gcc dot gnu dot org 2009-01-06 21:57 ---
Subject: Bug 38669
Author: mikael
Date: Tue Jan 6 21:57:19 2009
New Revision: 143134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143134
Log:
2009-01-06 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-07 13:51 ---
(In reply to comment #4)
For TARGET, I agree because the standard says about c_f_pointer:
The value of CPTR shall not be the C address of a Fortran variable that
does
not have the TARGET attribute.
Hum
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-13 20:08 ---
(In reply to comment #2)
I think it is
a legitimate optimization to replace A**B by A**I (with I=B) when B is known
to
be an integer, hence to accept negative values for A in this case.
You can use A**I
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-14 20:07 ---
is_scalar_expr_ptr is weird.
Those are the things to change in it, IMHO:
- is_scalar_expr_ptr does not need to check whether character lengths are
equal to 1 as arbitrary length character variables are considered
--- Comment #28 from mikael at gcc dot gnu dot org 2009-01-14 20:53 ---
Subject: Bug 35681
Author: mikael
Date: Wed Jan 14 20:53:18 2009
New Revision: 143383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383
Log:
2009-01-14 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-14 20:53 ---
Subject: Bug 38487
Author: mikael
Date: Wed Jan 14 20:53:18 2009
New Revision: 143383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383
Log:
2009-01-14 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #12 from mikael at gcc dot gnu dot org 2009-01-14 20:53 ---
Subject: Bug 38669
Author: mikael
Date: Wed Jan 14 20:53:18 2009
New Revision: 143383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383
Log:
2009-01-14 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #13 from mikael at gcc dot gnu dot org 2009-01-14 21:12 ---
Fixed on trunk(4.4) and 4.3.
Thanks for the report!
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-15 21:30 ---
quick fix:
Index: simplify.c
===
--- simplify.c (révision 143354)
+++ simplify.c (copie de travail)
@@ -2253,7 +2253,8 @@ simplify_bound (gfc_expr
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-16 21:47 ---
http://gcc.gnu.org/viewcvs?root=gccview=revrev=141516 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
--- Comment #10 from mikael at gcc dot gnu dot org 2009-01-17 11:54 ---
I vote for WONTFIX.
But I can live with a patch revert. ;)
While a program could reference the symbol, it seems highly unlikely.
And anyway, 4.3 is still there in case it is needed.
--
http://gcc.gnu.org
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-17 14:59 ---
shouldn't this be fixed for 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
--- Comment #1 from mikael at gcc dot gnu dot org 2009-01-18 20:40 ---
I suspect the following is invalid as the arguments to the defined assignment
alias.
WHERE(LDA)
TLA2L = TLA2L(1:3,1:2)%L !removing this line fixes problem
TLA2L = TLA2L(1:3,1:2)%I
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-19 18:48 ---
DLA = DDA(2:3, 1:3:2, 5:4:-1, NF2, NF5:NF2:MF2)
The descriptor built for DLA has negative strides for dimension = 3.
This makes ubound fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
--- Comment #2 from mikael at gcc dot gnu dot org 2009-01-19 19:47 ---
the lbound should be simplified in simplify_bound even if the ARRAY argument is
not a full array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38914
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-19 22:18 ---
I suspect the following is invalid as the arguments to the defined
assignment
alias.
Why do you think it is invalid?
Because the arguments to the i_to_t (or l_to_t) alias. They point to the same
data
--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-19 22:19 ---
Subject: Bug 38859
Author: mikael
Date: Mon Jan 19 22:19:34 2009
New Revision: 143501
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143501
Log:
2009-01-19 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-19 22:33 ---
This removes the ICE:
Index: primary.c
===
--- primary.c (révision 143501)
+++ primary.c (copie de travail)
@@ -2370,6 +2370,8 @@
bool
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-20 19:48 ---
(In reply to comment #5)
This removes the ICE: ...
Do you understand why?
In the following:
RDA(1,2) = + S_REAL_SUM_I(1.0,2.0)
gfc_match_rvalue sets where for the rhs to the marked position below
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-20 20:00 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822#c7
real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
1
Error: Fortran 2003: Noninteger exponent in an initialization expression at (1
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-20 22:29 ---
(In reply to comment #3)
DLA = DDA(2:3, 1:3:2, 5:4:-1, NF2, NF5:NF2:MF2)
The descriptor built for DLA has negative strides for dimension = 3.
This makes ubound fail.
Forget this
DLA = DDA(2:3, 1:3:2, 5:4:-1
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-20 22:37 ---
(In reply to comment #6)
Note, this error is incorrect and will not be generated by gfortran when
my patch for pr38823 is accepted.
Your error may or may not eventually go to trunk.
But the marker
--- Comment #1 from mikael at gcc dot gnu dot org 2009-01-23 20:04 ---
(In reply to comment #0)
=== gfortran tests ===
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
-funroll-loops
--- Comment #1 from mikael at gcc dot gnu dot org 2009-01-24 20:36 ---
Confirmed.
myfortran_error(1:1) = chararr(1)
gfc_match_rvalue can't find a proper substring reference for chararr.
Thus as chararr's flavor is FL_UNKNOWN, gfc_match_rvalue tries to guess its
type
and after some
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-24 20:54 ---
Works for me at r143643.
Duplicate of PR 38152?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38831
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-24 21:04 ---
see also PR 36275.
(In reply to comment #3)
I don't see why this is rejected
gfc_match_bind_c doesn't use gfc_match_init_expr.
It matches the opening quotes, then calls gfc_match_name_C, then matches the
closing
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-24 22:09 ---
(In reply to comment #4)
This might lead to wrong code (though I don't know what f77 means for C_LOC):
I
think that instead of fsym-as-type one needs to go through the refs to the
component and do the check
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-26 18:42 ---
(In reply to comment #3)
This is not so much an error in Fortran than it is an error in the
scripting and it's ability to add it's own LD_LIBRARY_PATH components.
No. The current linking scheme links to the just
--- Comment #1 from mikael at gcc dot gnu dot org 2009-01-28 18:14 ---
*** This bug has been marked as a duplicate of 38259 ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-28 18:14 ---
*** Bug 38993 has been marked as a duplicate of this bug. ***
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-29 22:03 ---
patch http://gcc.gnu.org/ml/fortran/2009-01/msg00348.html
The failure for ik=8 is not fixed by this patch.
I thought it was ok because of the kind conversion function call.
But it seems it's not.
It is impacting
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 ---
cf PR36462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 ---
(In reply to comment #12)
don't know how to use it to compile gcc being a normal user (no root
privileges) without scrambling everything else. Any help on this direction?
Thanks
export LD_LIBRARY_PATH=/your
--- Comment #10 from mikael at gcc dot gnu dot org 2009-10-23 17:17 ---
(In reply to comment #9)
Now here we may need:
if (p == NULL)
{
skip_list ();
continue;
}
skip_list() is unnecessary here as we have parsed everything already
--- Comment #8 from mikael at gcc dot gnu dot org 2009-10-24 22:42 ---
(In reply to comment #7)
It seems that the patch in comment #2 has been silently applied
Not exactly silently. It was pr38672
Apparently the failure of the test in comment #4 is due to the fact that
c_funptr
--- Comment #2 from mikael at gcc dot gnu dot org 2009-11-20 17:59 ---
This is the same as PR 38530
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
--- Comment #10 from mikael at gcc dot gnu dot org 2008-10-31 15:38 ---
Subject: Bug 35820
Author: mikael
Date: Fri Oct 31 15:37:17 2008
New Revision: 141496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141496
Log:
2008-10-31 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #19 from mikael at gcc dot gnu dot org 2008-10-31 15:57 ---
Subject: Bug 35840
Author: mikael
Date: Fri Oct 31 15:56:21 2008
New Revision: 141497
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141497
Log:
2008-10-31 Mikael Morin [EMAIL PROTECTED]
PR
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot
|dot org
--- Comment #7 from mikael at gcc dot gnu dot org 2008-11-05 17:02 ---
(In reply to comment #6)
It should not be necessary to do anything to the cl_list. As long as nothing
points to a member, it can do nothing and gets cleaned up at the end of
compilation. The reason
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-05 17:17 ---
(In reply to comment #1)
what is the syntax from? is it wrong usage of continuation ''??
The error position is signaled by the 1 marker.
Data is a fortran keyword.
I suggest you change your variable name
--- Comment #8 from mikael at gcc dot gnu dot org 2008-11-05 18:47 ---
Patch here:
http://gcc.gnu.org/ml/fortran/2008-11/msg00032.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-05 19:43 ---
This was fixed by Paul in his patch for PR37445.
Assigning to him.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from mikael at gcc dot gnu dot org 2008-11-11 15:36 ---
(In reply to comment #13)
x is not marked as referenced, and read_cleanup makes a symtree for it with
that name @0 from gfc_get_unique_symtree.
This behavior seems expected in some cases, maybe it is here as well
--- Comment #8 from mikael at gcc dot gnu dot org 2008-11-12 22:43 ---
I tried to reduce the case.
module bar
implicit none
contains
!
elemental function trim_append(xx,yy) result(xy)
character (len=*), intent(in) :: xx,yy
character (len=len(xx) + len(yy)) :: xy
xy = xx // yy
end
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-13 19:05 ---
Maybe we can drop gfc_conv_section_upper_bound completely.
It looks redundant with how info-end[n] is calculated in
gfc_conv_section_startstride.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38033
--- Comment #6 from mikael at gcc dot gnu dot org 2008-11-14 12:54 ---
(In reply to comment #5)
I tried that and generated a load of regressions.
Fine. Let's keep it as is then.
Thanks
Thanks to you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38033
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-14 13:01 ---
(In reply to comment #17)
Unassigning myself. Mikael will probably want to take the missing part on
with
his pending patch :)
Regressions are making my life tough right now, but I will succeed in the end
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-16 11:38 ---
(In reply to comment #3)
The problem appears to be the empty SOURCE with the presence of PAD.
I agree.
There are two bugs actually:
(1) the front-end doesn't expand the reshape.
(at least in this case: reshape
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-16 13:45 ---
Index: simplify.c
===
--- simplify.c (révision 141833)
+++ simplify.c (copie de travail)
@@ -3410,9 +3410,6 @@ is_constant_array_expr (gfc_expr *e
--- Comment #7 from mikael at gcc dot gnu dot org 2008-11-16 15:22 ---
(In reply to comment #6)
I'm onto it; the problems are in reshape.m4 / reshape_generic.c .
Ok, leaving it to you.
According to my tests, sstride0 has suspicious values.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from mikael at gcc dot gnu dot org 2008-11-16 18:46 ---
(In reply to comment #8)
Are you sure this is needed ?
if (sempty)
{
- /* Switch immediately to the pad array. */
+ /* Pretend we are using the pad array the first time around, too. */
src
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 19:44 ---
(In reply to comment #9)
Those are only details, it works nicely :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 20:45 ---
Subject: Bug 37992
Author: mikael
Date: Sun Nov 16 20:44:33 2008
New Revision: 141927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141927
Log:
2008-11-16 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #11 from mikael at gcc dot gnu dot org 2008-11-16 21:05 ---
Fixed on trunk, closing
(In reply to comment #9)
Note also that there are other similar instances for which gfortran gives an
ICE after error messages and that are not fixed by the patch, see:
Those are ice
--- Comment #19 from mikael at gcc dot gnu dot org 2008-11-16 22:46 ---
Subject: Bug 35681
Author: mikael
Date: Sun Nov 16 22:45:10 2008
New Revision: 141931
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141931
Log:
2008-11-16 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-17 19:43 ---
The problem is in ByteToString.
The assignment of the transfer result is changed to a memmove.
The memmove is controlled by the size of both the lhs and the rhs.
The size of the rhs (actually the charlen=3
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-17 22:19 ---
(In reply to comment #14)
I've just discovered I was paraphrasing Janus here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00219.html
The error for comment #13 was introduced the patch in comment #10.
Knowing that, I
--- Comment #17 from mikael at gcc dot gnu dot org 2008-11-18 13:23 ---
(In reply to comment #16)
Btw it also makes comment #12 compile, while the resulting executable produces
a segfault. But I guess this is due to the weird things which this program
does(?).
Not really
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-19 20:56 ---
(In reply to comment #14)
Mikael, if you think the problem you mentioned in comment #4 warrants
its own PR, maybe you could open it.
PR 38184 opened for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-19 20:57 ---
(In reply to comment #0)
This is a clone of PR38135.
Path posted there:
Index: simplify.c
===
--- simplify.c (révision 141833)
+++ simplify.c
--- Comment #8 from mikael at gcc dot gnu dot org 2008-11-20 13:43 ---
Created an attachment (id=16727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16727action=view)
much more manageable testcase
I think the testcase is invalid as both PBit4set and PBit8set contain a
getNullSet
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-20 14:33 ---
duplicate of pr36935?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-23 21:27 ---
(In reply to comment #2)
How about packaging your patch and submitting it?
It seems you missed it.
http://gcc.gnu.org/ml/fortran/2008-11/msg00249.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
--- Comment #21 from mikael at gcc dot gnu dot org 2008-11-24 12:15 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:13:59 2008
New Revision: 142154
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142154
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #22 from mikael at gcc dot gnu dot org 2008-11-24 12:25 ---
Argh!!
elemental_dependency_1.f90 was not committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
--- Comment #23 from mikael at gcc dot gnu dot org 2008-11-24 12:38 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:37:25 2008
New Revision: 142155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142155
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #24 from mikael at gcc dot gnu dot org 2008-11-24 12:48 ---
Subject: Bug 35681
Author: mikael
Date: Mon Nov 24 12:46:57 2008
New Revision: 142156
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142156
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #25 from mikael at gcc dot gnu dot org 2008-11-24 13:10 ---
(In reply to comment #22)
Argh!!
elemental_dependency_1.f90 was not committed.
Fixed now, sorry for the noise.
(In reply to comment #20)
Mikael, Daniel: Have I missed something or is everything in this PR
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-24 15:29 ---
(In reply to comment #2)
This is probably too old:
GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]
Definitely, the bug is PR37445, which was fixed on 3rd November.
--
http
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 15:37 ---
Works for me.
$ /usr/local/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../src/configure --enable-languages=fortran
--enable-maintainer-mode --disable-multilib
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-24 19:06 ---
Subject: Bug 38184
Author: mikael
Date: Mon Nov 24 19:04:34 2008
New Revision: 142168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142168
Log:
2008-11-24 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-24 22:00 ---
Fixed on trunk, closing.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 22:52 ---
confirm
quickfix:
Index: parse.c
===
--- parse.c (révision 142172)
+++ parse.c (copie de travail)
@@ -2323,7 +2323,7 @@ parse_spec
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-24 23:12 ---
(In reply to comment #1)
I'm probably missing something
Indeed I was. :'(
FAIL: gfortran.dg/actual_array_result_1.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-25 13:28 ---
Subject: Bug 36463
Author: mikael
Date: Tue Nov 25 13:27:26 2008
New Revision: 142191
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142191
Log:
2008-11-25 Mikael Morin [EMAIL PROTECTED]
PR fortran
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-26 12:13 ---
confirmed
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-26 12:13 ---
Created an attachment (id=16775)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16775action=view)
untested fix
This is probably the way to go.
A warning should be added in some cases (didn't think much about
--- Comment #6 from mikael at gcc dot gnu dot org 2008-11-26 17:49 ---
(In reply to comment #5)
Currently not simplified are:
- ALL/ANY/COUNT
- cshift/eoshift
- dot_product/matmul
- (max|min)(loc|val) - note: (max|min)val is implemented for rank == 1 w/o dim
- pack/unpack
1 - 100 of 308 matches
Mail list logo
