--- 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 succee
--- 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 t
--- 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.o
--- 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=gcc&view=rev&rev=141927
Log:
2008-11-16 Mikael Morin <[EMAIL PROTECTED]&g
--- 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 a
--- 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=gcc&view=rev&rev=141931
Log:
2008-11-16 Mikael Morin <[EMAIL PROTECTED]&g
--- 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 in
--- 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 th
--- 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 rea
ion: 4.4.0
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_
--- 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/sho
--- 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)
+++ simplif
--- 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=16727&action=view)
much more manageable testcase
I think the testcase is invalid as both PBit4set and PBit8set co
--- 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=gcc&view=rev&rev=142154
Log:
2008-11-24 Mikael Morin <[EMAIL PROTECTED]&g
--- 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=gcc&view=rev&rev=142155
Log:
2008-11-24 Mikael Morin <[EMAIL PROTECTED]&g
--- 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=gcc&view=rev&rev=142156
Log:
2008-11-24 Mikael Morin <[EMAIL PROTECTED]&g
--- 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 everythin
--- 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.
-
--- 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=gcc&view=rev&rev=142168
Log:
2008-11-24 Mikael Morin <[EMAIL PROTECTED]&g
--- 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=gcc&view=rev&rev=142191
Log:
2008-11-25 Mikael Morin <[EMAIL PROTECTED]&g
--- 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=16775&action=view)
untested fix
This is probably the way to go.
A warning should be added in some cases (didn't thin
--- 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
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-26 18:02 ---
(In reply to comment #3)
> (In reply to comment #2)
>
> I am on my travels right now and only have 4.4.0 20080624 on my laptop. The
> testcase works fine with that, so this regression has crept i
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-27 15:40 ---
(In reply to comment #4)
> I will investigate more next week-end (unless someone beats me ;-))
>
I'm investigating now.
The first patch was probably wrong.
I'm testing this one at the moment
--- Comment #2 from mikael at gcc dot gnu dot org 2008-11-27 21:12 ---
Is this enough?
Index: decl.c
===
--- decl.c (révision 142242)
+++ decl.c (copie de travail)
@@ -4094,6 +4094,7 @@ match_procedure_decl (void
--- Comment #21 from mikael at gcc dot gnu dot org 2008-11-28 13:24 ---
(In reply to comment #20)
> I don't see ad hoc whether PR 35810 is the problem;
With this I get no ICE, and no valgrind error either. :-)
--- pr36463_12.f90 2008-11-28 15:03:07.000
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-28 13:29 ---
Additional test cases, probably related, to be re-checked:
PR 36463, comment 12
PR 35971, comment 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-28 18:08 ---
Created an attachment (id=16790)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16790&action=view)
Mikael's dump (2008-11-28)
Can't compare with Jerry's dump (looks like it's o
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-01 19:32 ---
Subject: Bug 38252
Author: mikael
Date: Mon Dec 1 19:30:55 2008
New Revision: 142327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142327
Log:
2008-12-01 Mikael Morin <[EMAIL PROTECTED]&g
--- Comment #7 from mikael at gcc dot gnu dot org 2008-12-01 19:52 ---
I hope one day I'll be able to commit properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
--- Comment #8 from mikael at gcc dot gnu dot org 2008-12-01 19:53 ---
Subject: Bug 38252
Author: mikael
Date: Mon Dec 1 19:52:15 2008
New Revision: 142331
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142331
Log:
2008-12-01 Mikael Morin <[EMAIL PROTECTED]&g
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-02 14:30 ---
Fixed on trunk.
Let's not forget to close.
--
mikael at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-08 14:25 ---
(In reply to comment #7)
> A semi-proper place for .mod files is:
> /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
> (Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
>
Isn&#x
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 21:06 ---
reduced:
module modx
use, intrinsic :: iso_c_binding
end module modx
block data
use modx
end
A simple way to fix it would be this:
Index: resolve.c
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-08 22:10 ---
(In reply to comment #0)
Do you still see the bug ?
If so, please provide more information.
Otherwise, we will close it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37497
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-08 22:17 ---
(In reply to comment #4)
>
> Using a different object directory I was able to compile c and c++, but not
> fortran. I configured with:
> ./configure
> --prefix=/home/rkraft/apps/gcc4
> --with
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-08 22:23 ---
Is it fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:32 ---
(Sorry for the delay)
Do you still see the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37865
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 22:35 ---
(In reply to comment #4)
> Judging from the latest status reports, I'll find the time to look into it
> again in December before 4.4 is released.
>
We are in December, and 4.4 is not yet released. :
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-08 22:51 ---
Does it still happen?
If so, can you provide more information (host, version, configure options)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38062
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-08 23:03 ---
Can we close ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-09 00:50 ---
(In reply to comment #2)
> The test didn't fail in my last build on head. Was there a recent backport
> that might have fixed this PR?
Not really, I was having a look at forgotten PRs
>
> > If
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-09 13:53 ---
(In reply to comment #3)
> The patch in comment #2 fixes the ICE without regression on
> i686-apple-darwin9.
I didn't expect any regression with that patch.
However, I wonder whether we are not missin
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-09 19:13 ---
Subject: Bug 35983
Author: mikael
Date: Tue Dec 9 19:12:27 2008
New Revision: 142605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142605
Log:
2008-12-09 Mikael Morin <[EMAIL PROTECTED]&g
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-09 19:22 ---
Subject: Bug 37469
Author: mikael
Date: Tue Dec 9 19:20:18 2008
New Revision: 142606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142606
Log:
2008-12-09 Mikael Morin <[EMAIL PROTECTED]&g
--
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
--
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 #2 from mikael at gcc dot gnu dot org 2008-12-09 22:23 ---
Created an attachment (id=16867)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16867&action=view)
first patch
This was starting to rot on my computer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38259
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-10 14:02 ---
(In reply to comment #7)
> Fixed as of revision 142610.
Wait a bit before closing, I plan to backport to 4.3.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-13 14:29 ---
Both the warning and the temporary creation depend on the same dependency
checking code.
While it makes sense in the case of pointers to assume the worst (and create a
temporary, even if it's actually not neede
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-14 14:46 ---
(In reply to comment #2)
> I'm not sure what 'now' means. It's still true for release 4.3.2!
> I'm prepared to test with the live sources, but do you want me to?
Sure!
> Do you
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-15 00:14 ---
(In reply to comment #4)
> Sounds a bit like the problem from comment #0 is a duplicate or related to
> PR31537 and/or PR35034 ?
>
31537 seems definitely related.
Is there a specific option/configu
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-15 14:47 ---
Subject: Bug 38113
Author: mikael
Date: Mon Dec 15 14:46:22 2008
New Revision: 142763
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142763
Log:
2008-12-15 Mikael Morin
PR fortr
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-15 13:42 ---
explanation http://gcc.gnu.org/ml/fortran/2008-12/msg00137.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
--
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 #4 from mikael at gcc dot gnu dot org 2008-12-15 18:10 ---
Subject: Bug 38487
Author: mikael
Date: Mon Dec 15 18:08:42 2008
New Revision: 142766
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142766
Log:
2008-12-15 Mikael Morin
PR fortr
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-16 15:35 ---
Yes, confirmed.
The offending line is:
call foo(func("_"//bar()))
In trans-expr.c, se->loop is NULL in the gcc_assert:
2844 else if (sym->result->attr.dimension)
2845 {
2846
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-21 15:07 ---
Subject: Bug 35983
Author: mikael
Date: Sun Dec 21 15:06:15 2008
New Revision: 142860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142860
Log:
2008-12-21 Mikael Morin
PR fortr
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-21 15:10 ---
Fixed on trunk(4.4) and 4.3.
Thanks for the report.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mikael at gcc dot gnu dot org 2008-12-21 15:35 ---
(In reply to comment #9)
> (In reply to comment #7)
> > Fixed as of revision 142610.
> Wait a bit before closing, I plan to backport to 4.3.
... And of course I forgot. :-S
There is no gfc_reduce_init_e
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-21 15:47 ---
Subject: Bug 38113
Author: mikael
Date: Sun Dec 21 15:45:52 2008
New Revision: 142861
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142861
Log:
2008-12-21 Mikael Morin
PR fortr
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-21 16:04 ---
Subject: Bug 38487
Author: mikael
Date: Sun Dec 21 16:03:01 2008
New Revision: 142864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142864
Log:
2008-12-21 Mikael Morin
PR fortr
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-21 16:19 ---
Fixed on trunk(4.4) and 4.3.
Thanks for the report.
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-21 23:38 ---
data file missing (Please attach this time if it's big)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38602
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-22 18:51 ---
Reduced:
program test_iso
implicit none
type varying_string
character(LEN=1), dimension(:), allocatable :: chars
end type varying_string
CALL get_unit_set_ch ()
contains
subroutine
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-22 18:54 ---
(In reply to comment #5)
Generated code:
get_unit_set_ch (struct varying_string * separator)
{
if (separator->chars.data != 0B)
{
__builtin_free (separator->chars.data);
}
separator->c
--- Comment #7 from mikael at gcc dot gnu dot org 2008-12-22 18:59 ---
This was probably a bad idea:
- tmp = gfc_deallocate_alloc_comp (e->ts.derived, tmp, parm_rank);
- if (e->expr_type == EXPR_VARIABLE &&
e->symtree->n.sym->attr.optional)
-
--- Comment #12 from mikael at gcc dot gnu dot org 2008-12-23 00:18 ---
(In reply to comment #11)
> Patch committed, fixed on trunk, 4.4
I think it was the wrong PR number (35780 instead of PR34820).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38602
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-23 23:55 ---
Created an attachment (id=16976)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16976&action=view)
the patch I'm working on
(In reply to comment #1)
> explanation http://gcc.gnu.org/ml/fortran/2
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-26 21:46 ---
it works for me at revision 142908
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-26 22:54 ---
About the second error:
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33497#c3
in resolve.c:
2095 else if (parent_ref != NULL && parent_ref->type != REF_COMPONENT)
2096 gfc_internal_error (
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-26 23:04 ---
Created an attachment (id=16989)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16989&action=view)
patch, not regression-tested
This patch fixes the ICE and accepts the following (valid, I think)
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-27 18:12 ---
While the original problem is fixed on trunk and 4.3, some more marker problems
popped up as I expected.
from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536#c4
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg
--- Comment #10 from mikael at gcc dot gnu dot org 2008-12-27 23:05 ---
(In reply to comment #9)
> Closing, fixed on 4.4
>
Not yet ;-)
I'm at revision 142934, and I get this on x86_64-unknown-linux-gnu:
FAIL: gfortran.dg/fmt_g0_1.f08 -O0 execution test
FAIL: gfortran.dg/f
--- Comment #5 from mikael at gcc dot gnu dot org 2008-12-27 23:23 ---
Created an attachment (id=16994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16994&action=view)
another attempt, regression-tested
Regression-tested, but with regressions :-(.
They are probably un
--- Comment #12 from mikael at gcc dot gnu dot org 2008-12-28 19:19 ---
(In reply to comment #11)
> This test case runs fine here, maybe your trunk is not fully updated?
It works with a fresh checkout and a fresh bootstrap.
My trunk was up to date; it was probably the dirty build t
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-29 23:13 ---
failing assert line 4338:
4334 gfc_match_rvalue (&expr);
4335 gfc_clear_error ();
4336 gfc_buffer_error (0);
4337
4338 gcc_assert (expr && sym == expr->
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-30 14:04 ---
without derived types:
program gfcbu84_main
! use gfcbug84
implicit none
integer :: jplev, k_lev
real :: p(42)
real, pointer :: q(:)
jplev = 42
k_lev = 1
allocate (q(jplev))
call tq_tvgh (q
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-30 15:02 ---
At revision 142760, there is no temporary, so there is no bug.
That's something I missed in my patch, that's true.
The bug is still there however.
Change this:
call tq_tvgh (var_f% av (k_lev:,1), p(k
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-30 16:45 ---
Created an attachment (id=17016)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17016&action=view)
fix
Does anyone know the use of the block variable I remove in this patch?
--
mikael at gcc dot gnu
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-30 22:12 ---
(In reply to comment #3)
> Is backporting the fix for PR fortran/35840, or just gfc_reduce_init_expr,
> that difficult?
No, it should be manageable.
I gave up when the patch refused to apply. Sorry.
I cou
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-30 22:47 ---
An other failure:
use iso_c_binding
type t1
integer :: i(5)
end type t1
type t2
type(t1) :: t(5)
end type t2
character(len=2),target :: str(2)
type(t2), target :: tt
type(C_PTR
--- 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=17016&action=view) [edit]
> > fix
> >
> &g
--- 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 nothin
--- 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=gcc&view=rev&rev=143050
Log:
2009-01-04 Mikael Morin
PR fortr
--- 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.
--
mik
1 - 100 of 310 matches
Mail list logo
