Le 15/05/2015 17:19, Steve Kargl a écrit :
Regression tested on trunk. OK to commit?
Hello,
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c(revision 223094)
+++ gcc/fortran/decl.c(working copy)
@@
Le 16/05/2015 12:35, Thomas Koenig a écrit :
Hello world,
this (rather obvious) patch fixes array declarations in deeply nested
BLOCKs.
Regression-tested. OK for trunk?
OK, thanks.
Mikael
Le 09/05/2015 15:12, Mikael Morin a écrit :
Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
Dear All,
By the time I went to commit, something had changed and the patch
caused a regression. I presume that the version that I had of Andre's
patch was not the same as the one committed. I'll
Hello,
Le 12/05/2015 22:07, Thomas Koenig a écrit :
Hello world,
this patch fixes a regression from the inline matmul patch by
not inlining a case that is not yet handled, namely vector
subscripts.
Regression-tested. OK for trunk?
OK with...
Index: frontend-passes.c
Le 12/05/2015 08:43, Thomas Koenig a écrit :
Hi Mikael,
To be honest, both patches look fragile to me. Yours because it leaves
gfc_current_ns to its value, leaving the door open to other problems.
Mine, well, because it's playing with a global variable, with the
possible side-effects this
Hello,
Le 30/04/2015 15:07, Andre Vehreschild a écrit :
Hi all,
this is just a service release. I encountered that the new testcase in the
previous release included the testcase of the initial patch, that is
already on trunk. I therefore replaced the testcase allocate_with_source_5.f90
by
.
The condition was assuming full object arrays, and fails with subobject
arrays.
The fix (attached) is obvious enough.
The testcase is Thomas' reduced one, which is independent on matmul
simplification.
I plan to commit this patch tonight.
Mikael
2015-05-11 Mikael Morin mik...@gcc.gnu.org
Le 11/05/2015 00:08, Thomas Koenig a écrit :
Am 10.05.2015 um 22:43 schrieb H.J. Lu:
Here is what I have committed.
It caused:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gfortran.dg/inline_matmul_3.f90:38:39:
Error: Variable 'c1' cannot appear in the expression at (1)^M
I know
Le 08/05/2015 15:29, Andre Vehreschild a écrit :
Hi all,
please find attached a patch for 66035. An ICE occurred when in a structure
constructor an allocatable component of type class was initialized with an
existing class object. This was caused by
- the size of the memory to allocate
: testsuite/ChangeLog
===
--- testsuite/ChangeLog (révision 222978)
+++ testsuite/ChangeLog (révision 222979)
@@ -1,3 +1,7 @@
+2015-05-10 Mikael Morin mik...@gcc.gnu.org
+
+ * gfortran.dg/bound_simplification_5.f90: New.
+
2015-05-09
Hello,
Le 10/05/2015 00:31, Thomas Koenig a écrit :
Am 09.05.2015 um 13:59 schrieb Mikael Morin:
+ /* We have to get rid of the shape, if thre is one. Do
+so by freeing it and calling gfc_resolve to rebuild it,
+if necessary
Hello,
Le 09/05/2015 00:11, Thomas Koenig a écrit :
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 222864)
+++ frontend-passes.c (Arbeitskopie)
@@ -2611,14 +2611,40 @@ scalarized_expr (gfc_expr *e_in, gfc_expr
Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
Dear All,
By the time I went to commit, something had changed and the patch
caused a regression. I presume that the version that I had of Andre's
patch was not the same as the one committed. I'll cast an eye over it
this weekend and see if
Le 08/05/2015 13:54, Andre Vehreschild a écrit :
Hi Mikael,
at first I tried to fix this issue with the scalarizer, too, but I could not
grasp how the scalarizer was working. Do you have any documentation, how it is
meant to be? I mean, I have read the comments in the code, but those are
Le 08/05/2015 12:54, Andre Vehreschild a écrit :
Hi Mikael,
thanks for the review. I still have some questions/remarks before commiting:
@@ -5898,8 +5900,21 @@ gfc_generate_function_code (gfc_namespace * ns)
if (TREE_TYPE (DECL_RESULT (fndecl)) != void_type_node)
{
+ bool
Hello,
I found a (unrelated) bug while playing with Andre's PR65894 patch.
The dummy argument can get out of sync with the actual argument when
there is an (optional) argument missing.
I plan to commit the attached fix as obvious later today (after testing).
Mikael
2015-05-08 Mikael Morin
-unknown-linux-gnu. OK for trunk?
Mikael
2015-05-07 Andre Vehreschild ve...@gmx.de
Mikael Morin mik...@gcc.gnu.org
PR fortran/65894
* trans-array.h (gfc_scalar_elemental_arg_saved_as_reference):
New prototype.
* trans-array.c
Hello,
Le 05/05/2015 11:00, Andre Vehreschild a écrit :
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 4c18920..0b63175 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -2158,6 +2158,8 @@ build_function_decl (gfc_symbol * sym, bool global)
Le 05/05/2015 08:25, Thomas Koenig a écrit :
Hello world,
this is an update of the matmul inline patch. The only difference to
the last version is that it has the ubound simplification taken out.
Sorry, I delayed this, but it wasn't (yet) forgotten.
Below a few answers to
Hello,
Le 30/04/2015 20:19, Mikael Morin a écrit :
As you may want to simplify in the limited scope of the matmul inlining,
I'm giving comments about the patch (otherwise you can ignore them):
- No need to check for allocatable or pointer, it should be excluded by
as-type == AS_ASSUMED_SHAPE
Le 27/04/2015 20:45, Thomas Koenig a écrit :
Am 25.04.2015 um 20:12 schrieb Mikael Morin:
I've double-checked in the standard, and it seems it is not possible to
simplify after all:
If ARRAY is a whole array and either ARRAY is an assumed-size
array of rank DIM or dimension DIM
Hello,
Le 29/04/2015 02:02, David Malcolm a écrit :
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 2c7c554..30e4eab 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -4283,7 +4283,7 @@ parse_oacc_structured_block (gfc_statement acc_st)
unexpected_eof ();
Hello,
Le 28/04/2015 12:43, Andre Vehreschild a écrit :
To get the testsuite accepting a dump-fortran-original, I had to insert a
dg-prune-output. Without the prune output, dejagnu was reporting excess
errors.
The prune removes all output after the first Namespace: that starts the
Hello,
while reviewing Thomas' bound simplification patch, I noticed that the
{l,u}bound simplification code wasn't handling array subcomponents.
Fixed by the attached patch, regression tested. OK for trunk?
Mikael
2015-04-27 Mikael Morin mik...@gcc.gnu.org
* simplify.c
Hello,
Le 13/03/2015 11:33, Andre Vehreschild a écrit :
Hi all,
this is another patch preventing a segfault. This time the segfault occurred,
when -fdump-(fortran|tree)-original was given with the program having an
implicit class set. The issue is that the _data component is assumed to be
Le 25/04/2015 13:33, Thomas Koenig a écrit :
Hello world,
this is a simplification for calculating the lboud of assumed-shape
arrays - it is usually one, or whatever the user specified as
lower bound (if constant).
Hello,
I've double-checked in the standard, and it seems it is not
Dominique reported that the trunk patch breaks class_19.f90 when applied
together with Andre's PR59678 fix.
It appears to me that even without Andre's patch, the code generated is
wrong, and I don't see any easy fix.
Thus I'm withdrawing trunk's patch, and propose the backport patch also
for
Le 19/04/2015 17:58, Thomas Koenig a écrit :
Hello world,
here is the first installation of the matmul inlining patch.
This patch calculates c=MATMUL(a,b) using DO loops where there is no
dependency between a and c/b and c loops, taking care of realloc on
assignment and bounds checking
Hello,
Le 15/04/2015 20:03, Andre Vehreschild a écrit :
by accident I patched this pr. For short, when a structure constructor for a
structure with an allocatable component or a function returning a type with an
allocatable component is passed as actual argument to a function, then
gfortran
);
to
gfc_trans_scalar_assign (...blah..., x, !foo bar);
As foo is most of the time either true or false, this is a simplification.
regression tested on x86-64-unknown-linux-gnu.
OK for post 5.1 trunk?
Mikael
2015-04-19 Mikael Morin mik...@gcc.gnu.org
* trans.h (gfc_trans_scalar_assign): Remove fourth argument
posted on the PR was
also fixing PR49324. I couldn't confirm as what seems to be the
remaining testcase there (comment #6) doesn't fail with trunk here.
2015-04-18 Mikael Morin mik...@gcc.gnu.org
PR fortran/65792
* trans-expr.c (gfc_trans_subcomponent_assign):
Don't special case non
Hello, I haven't looked at the patch in detail yet, but...
Le 11/04/2015 14:24, Thomas Koenig a écrit :
Still to do: Bounds checking (a rather big one),
... as you do a front-end to front-end transformation, you get bounds
checking for free, don't you?
Mikael
Le 07/04/2015 14:25, Mikael Morin a écrit :
Le 06/04/2015 20:26, Mikael Morin a écrit :
Regarding the patch, I don't understand why the existing symbol
restoration code doesn't work here (see
gfc_restore_last_undo_checkpoint, restore_old_symbol). I have to
investigate more.
I think
Le 08/04/2015 12:29, Mikael Morin a écrit :
Except that the following ... ahem ... doesn't work.
And it doesn't work because gfc_get_ha_symbol doesn't version
host-associated symbols.
So one has to call symbol.c's save_symbol_data by hand. And then, we
can as well keep the original
Le 06/04/2015 20:26, Mikael Morin a écrit :
Regarding the patch, I don't understand why the existing symbol
restoration code doesn't work here (see
gfc_restore_last_undo_checkpoint, restore_old_symbol). I have to
investigate more.
I think the problem is the usage of gfc_find_symbol
Le 06/04/2015 01:04, Evangelos Drikos a écrit :
Hi,
The attached patch, type 0, has been discussed a little at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Yet, the final version submitted is slightly different from the ones
discussed and tested in the above link.
Having read
Le 24/03/2015 23:39, Mikael Morin a écrit :
The patch I propose here adds a flag to remember the function has been
called, and skip it the second time.
I considered reusing the existing 'resolved' field, but I had to
slightly change its semantics to prevent regressing somewhere, and I
preferred this safer patch keeping the existing field
completely untouched.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-03-24 Mikael Morin mik...@gcc.gnu.org
PR fortran/64952
PR fortran/65532
* gfortran.h (struct gfc_namespace): New field
Le 20/03/2015 14:51, Andre Vehreschild a écrit :
Hi all,
during checking that pr 61275 is really fixed, I found a indentation issue and
a piece of my former code, that could be done nicer and more readable. This
patch addresses both these issues.
Bootstraps and regtests ok on
26/02/2015 18:17, Andre Vehreschild a écrit :
This first patch is only preparatory and does not change any of the semantics
of
gfortran at all.
Sure?
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index ab6f7a5..d28cf77 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@
Le 23/03/2015 13:43, Andre Vehreschild a écrit :
Hi Mikael,
thanks for looking at the patch. Please note, that Paul has sent an addendum
to
the patches for 60322, which I deliberately have attached.
26/02/2015 18:17, Andre Vehreschild a écrit :
This first patch is only preparatory and
Le 23/03/2015 16:49, Andre Vehreschild a écrit :
I see your point. Currently I am bootstraping and regtesting some patches for
commit. While this is running, my machine is nearly unusable. I will look into
this as soon, as my machine allows, but probably not before tomorrow.
There is no
Hello Paul,
have you had time to look at this again?
Mikael
Ping:
https://gcc.gnu.org/ml/fortran/2015-02/msg00045.html
Le 20/02/2015 22:50, Mikael Morin a écrit :
Le 16/02/2015 21:18, Bernd Edlinger a écrit :
again, with attachments,
sorry.
Hi,
this patch fixes PR64980 and PR61960 at the same time.
The unreduced test case for PR64230 is also included, because a previous
version
of this patch caused
Le 16/02/2015 21:18, Bernd Edlinger a écrit :
again, with attachments,
sorry.
Hi,
this patch fixes PR64980 and PR61960 at the same time.
The unreduced test case for PR64230 is also included, because a previous
version
of this patch caused this test to fail but the complete test
Le 15/02/2015 19:00, Jerry DeLisle a écrit :
On 02/15/2015 09:48 AM, Mikael Morin wrote:
[*] I have a few failing testcases (also without the patch), namely the
following; does this ring a bell ?
FAIL: gfortran.dg/erf_3.F90
FAIL: gfortran.dg/fmt_g0_7.f08
FAIL: gfortran.dg/fmt_en.f90
FAIL
Mikael Morin mik...@gcc.gnu.org
PR fortran/60898
* resolve.c (resolve_symbol): Check that the symbol found from
name lookup really is the current symbol being resolved.
2015-02-15 Mikael Morin mik...@gcc.gnu.org
PR fortran/60898
* gfortran.dg/entry_20
report, involving function 'Nick'
! Contributed by Nick Maclaren n...@cam.ac.uk on clf
! https://groups.google.com/forum/#!topic/comp.lang.fortran/TvVY5j3GPmg
!
! Other tests are due to Mikael Morin mikael.mo...@sfr.fr
!
MODULE M
INTEGER, PRIVATE :: i
REAL :: arraym(5) = (/ (i+0.0, i = 1,5
straightforward to my eyes, and my
attempt in that direction to sneak some orthogonality in that madness
failed.
Anyway, regression tested on x86_64-linux, OK for trunk/4.9/4.8 ?
Mikael
2015-02-09 Mikael Morin mik...@gcc.gnu.org
PR fortran/61138
* trans-expr.c
Hello Paul,
comments below
Le 08/02/2015 16:24, Paul Richard Thomas a écrit :
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h(revision 220482)
--- gcc/fortran/gfortran.h(working copy)
***
Le 07/02/2015 14:40, Dominique Dhumieres a écrit :
Dear Mikael,
Even if
use m, only: A = X
use m, only: A = X
is valid, it does not make sense to use it and it is probably a typo.
Should not gfortran emit a warning, at least with -Wall?
Yeah, why not?
I think we have to defer it
the original (symbol) name instead of the local
(symtree) name.
The fix is close to obvious, and should be safe for the branches (this
is a regression)
Regression tested on x86_64-linux. OK for trunk/4.9/4.8 ?
Mikael
2015-02-06 Mikael Morin mik...@gcc.gnu.org
PR fortran/63744
), wondering whether the renamed or
original name should be used, I decided to remove all that nonsense.
So here is the patch, regression tested on x86_64-unknown-linux-gnu.
There is a failure, graphite/pr42393.f90, also present on mainline.
OK for trunk/4.9/4.8 ?
Mikael
2015-01-25 Mikael Morin
Le 14/01/2015 19:30, Janus Weil a écrit :
Hi Mikael,
the attached patch fixes an ICE-on-invalid problem with
procedure-pointer components by making sure that we continue resolving
all components of a derived type, even after an error is thrown.
Does the fonction return false as before,
Le 15/01/2015 14:25, Mikael Morin a écrit :
Le 15/01/2015 12:37, Janus Weil a écrit :
Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
looks very similar to the Mikael's one for pr58023 at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
with retval replaved
Le 15/01/2015 12:37, Janus Weil a écrit :
Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
looks very similar to the Mikael's one for pr58023 at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
with retval replaved with success.
Was it intended?
Nope. I wasn't
Hello Janus,
Le 13/01/2015 22:18, Janus Weil a écrit :
Hi all,
the attached patch fixes an ICE-on-invalid problem with
procedure-pointer components by making sure that we continue resolving
all components of a derived type, even after an error is thrown.
Does the fonction return false as
Le 06/12/2014 14:38, Manuel López-Ibáñez a écrit :
* Tobias or other Fortran maintainers. The only test failing is
gfortran.dg/do_iterator.f90 line 7. The old code gives an Error there,
which the new one does not.
/home/manuel/test1/pristine/gcc/testsuite/gfortran.dg/do_iterator.f90:7.9:
Hello,
Le 06/08/2014 21:23, Andre Vehreschild a écrit :
Hi,
[...]
*** gcc/fortran/Changelog ***
2014-08-06 Andre Vehreschild ve...@gmx.de
PR fortran/60414
* interface.c (compare_parameter): Fixing ICE when argument
of a generic is a reference into an array.
Le 07/08/2014 15:40, Andre Vehreschild a écrit :
Hi,
in the bugtracker for PR60255 janus proposed to fix the bug by removing
the error and additionally checking if the character array length
declaration is deferred, which leaves the the charlen to be 0
(gcc/fortran/class.c
Hello,
Le 10/08/2014 13:55, Andre Vehreschild a écrit :
Hi,
I am proposing another patch, this time to resolve PR60289. The issue in the
bug
reported is, that a code like:
class(*), pointer :: P
allocate(character(20)::P)
is rejected by trunk's gfortran compiler.
Le 16/08/2014 00:10, Tobias Burnus a écrit :
This patch fixes two minor issues
a) The argument issue mentioned in
https://gcc.gnu.org/ml/fortran/2014-08/msg7.html
The main issue is that the decl uses void as argument; the FE passes
IARG() alias gfc_array_index_type while the library
Le 17/08/2014 14:26, Dominique Dhumieres a écrit :
As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
the testcase should check that the code generated is actually working,
not just that the ICE disappeared. ...
Well, this is for another patch where deferred character
Le 17/08/2014 14:46, Dominique Dhumieres a écrit :
My knowledge of unlimited polymorphic types is limited, but I think that
this is not correct.
My knowledge of unlimited polymorphic types is even more limited,
then I cannot comment about the correctness of the patch. However
The new
Le 17/08/2014 14:46, Dominique Dhumieres a écrit :
My knowledge of unlimited polymorphic types is limited, but I think that
this is not correct.
My knowledge of unlimited polymorphic types is even more limited,
then I cannot comment about the correctness of the patch. However
The new
Hello, thanks for your contribution.
here are some comments about the patch:
Le 21/07/2014 15:03, Andre Vehreschild a écrit :
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c33936b..cb01a13 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
Changelogs are
Hello,
Le 06/04/2014 18:05, Tobias Burnus a écrit :
Bernhard Reutner-Fischer wrote:
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
+bool has_final2 = false;
+if (!gfc_resolve_finalizers (c-ts.u.derived, has_final))
+ return false; /* Error. */
+
Le 06/04/2014 19:46, Tobias Burnus a écrit :
Mikael Morin wrote:
Le 06/04/2014 18:05, Tobias Burnus a écrit :
It is supposed to propagate the information whether any of the
components (c) has a derived type. However, I made a typo: It
should be has_final2 instead of has_final
Le 06/04/2014 20:30, Tobias Burnus a écrit :
Mikael Morin wrote:
Argh. great. What about the use_assoc thing? Why is that needed?
Frankly, I don't know. In terms of the code, the problem is that
attr.use_assoc is zero and, hence, the compiler generates a call to some
external version which
Le 02/04/2014 22:29, Paul Richard Thomas a écrit :
Dear All,
This fix, of itself, is quite obvious. The offset was being set to
zero for array segments, rather than that required for unity valued
lvalues.
I think that the fix could be used to clean up:
to Tobias for identifying the problem.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 208912)
+++ ChangeLog (révision 208913)
@@ -1,5 +1,11 @@
-2014-04-27 Thomas Koenig tkoe...@gcc.gnu.org
+2014-03-28 Mikael Morin mik
Le 16/03/2014 11:41, Thomas Koenig a écrit :
Hello world,
the attached patch fixes PR 60522, a regresseion where temporary
variables were incorrectly introduced in a BLOCK within a WHERE
statement.
Regression-tested on x86_64-unknown-linux-gnu.
OK for trunk and the other open
Hello,
Le 10/03/2014 03:15, jimmie.da...@l-3com.com a écrit :
Index: gcc/gcc/fortran/symbol.c
===
--- gcc/gcc/fortran/symbol.c (revision 208437)
+++ gcc/gcc/fortran/symbol.c (working copy)
@@ -3069,56 +3069,56 @@
Le 11/03/2014 10:25, Janus Weil a écrit :
Regression-tested on x86_64-unknown-linux-gnu.
This is not a regression as far as I know, but quite a severe
wrong-code, albeit limited to the corner case of transpose and
assumed shape and contiguous. OK for trunk/4.8/4.7 anyway ?
I would say it's
, I have filled the matrices one element at a
time in the testcase.
2014-03-09 Mikael Morin mik...@gcc.gnu.org
PR fortran/60392
* trans-array.c (gfc_conv_array_parameter): Don't reuse the descriptor
if it has transposed dimensions.
2014-03-09 Mikael Morin mik...@gcc.gnu.org
PR fortran
Hello,
Le 09/03/2014 13:59, jimmie.da...@l-3com.com a écrit :
The code would only remove a variable from a common block if it was just
defined in the previous statement. The PR showed a case where a pre-existing
variable was put in the common block. When it was not removed, the common
Le 09/03/2014 20:47, jimmie.da...@l-3com.com a écrit :
Comments from Mikael:
#1. Please merge the two ifs; it seems they have exactly the same scope
after the patch.
#2. This comment applies to the TOUPPER thing below...
.. so it should be put here. Also the indentation is wrong.
Le 01/03/2014 16:58, Janus Weil a écrit :
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c (revision 207896)
+++ gcc/fortran/trans-stmt.c (working copy)
@@ -5028,6 +5028,11 @@ gfc_trans_allocate (gfc_code *
===
--- gcc/testsuite/ChangeLog (révision 208248)
+++ gcc/testsuite/ChangeLog (révision 208249)
@@ -1,3 +1,8 @@
+2014-03-01 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/60341
+ * gfortran.dg/str_comp_optimize_1.f90: New test.
+
2014-03-01 Oleg Endo olege
Le 19/02/2014 16:51, Janus Weil a écrit :
The patch was not applying cleanly any more, so here is a re-diffed
version for current trunk. It works nicely on the included test case
as well as the one provided by Walter Spector in comment 12 of the PR.
Since, also in the current state,
Le 15/02/2014 11:04, Richard Biener a écrit :
On Fri, 14 Feb 2014, Mikael Morin wrote:
Hello,
this bug is not a regression, but the patch shouldn't wreck the compiler
too much on the other hand.
The problem is a wrong number of arguments while generating code for the
ichar intrinsic
the gfc_intrinsic_argument_list_length function
like it's done for other intrinsics.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8/4.7?
Mikael
2014-02-14 Mikael Morin mik...@gcc.gnu.org
PR fortran/59599
* trans-intrinsic.c (gfc_conv_intrinsic_ichar): Calculate
Le 08/02/2014 18:48, Paul Richard Thomas a écrit :
Dear All,
This is another corner of a corner case that is not a regression but
fixes a wrong-code-on-valid.
At present, an actual argument of an elemental procedure with the
VALUE attribute is not passed by value. The fix is obvious.
Le 06/02/2014 23:40, Janus Weil a écrit :
Hi Mikael,
thanks for your comments ...
attached is a small patch which fixes an ICE-on-invalid regression
with finalization. In the PR, Dominique objected to the patch, but I
think it's the correct thing to do after all. The line that I'm
Le 07/02/2014 21:42, Mikael Morin a écrit :
maybe add gcc_assert to
make it clear that fini-proc_tree should be set at this point.
Or better: a comment ;-)
Le 07/02/2014 19:18, Paul Richard Thomas a écrit :
Dear All,
I propose to add the attached to the testsuite. It is the testcase
from PR60066, which was fixed by the patch for PR59066.
OK for trunk, 4.8 and 4.7?
Yes, sure.
Mikael.
Le 06/02/2014 11:43, Janus Weil a écrit :
Hi all,
attached is a small patch which fixes an ICE-on-invalid regression
with finalization. In the PR, Dominique objected to the patch, but I
think it's the correct thing to do after all. The line that I'm
removing was added in a patch authored by
Le 02/02/2014 21:31, Janus Weil a écrit :
Hi all,
the attached patch fixes an OOP-related 4.7-only regression. Pretty
much straightforward, for details see PR.
Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
Yes, thanks.
Mikael
Le 01/02/2014 18:57, Paul Richard Thomas a écrit :
Dear All,
This regression was flagged by Harald and the trigger, r158683, was
identified by HJ. Many thanks to both. It surprises me that the bug
has lain dormant for so long.
The fix is fortunately relatively simple. CHARACTER scalars
, it seems to be correct.
regression tested on x86_64-unknown-linux-gnu; OK for trunk and then
4.8/4.7?
Mikael
2014-01-26 Mikael Morin mik...@gcc.gnu.org
PR fortran/57033
* primary.c (gfc_convert_to_structure_constructor): Avoid null pointer
dereference.
2014-01-26 Mikael
it worked even without bootstrap.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 207151)
+++ ChangeLog (révision 207152)
@@ -1,3 +1,9 @@
+2014-01-27 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/58007
+ * module.c (skip_list
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will backport in a few days to 4.8 and 4.7.
I added the following hardening to the patch on the 4.8
206759)
@@ -1,3 +1,9 @@
+2014-01-18 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/58007
+ * gfortran.dg/unresolved_fixup_1.f90: New test.
+ * gfortran.dg/unresolved_fixup_2.f90: New test.
+
2014-01-18 Jakub Jelinek ja...@redhat.com
PR target/58944
@@ -19,7 +25,7 @@
2014-01-17 Jeff Law l
Le 09/01/2014 14:33, Janus Weil a écrit :
After noticing that the bug is actually a regression (see PR 57042):
Ok to backport to 4.7 and 4.8?
Sure!
Mikael
Le 09/01/2014 16:30, Janus Weil a écrit :
Hi all,
the attached patch started out as an ICE-on-invalid regression fix,
but after the ICE had been fixed recently by other means, it was
degraded to a mere error-recovery improvement. It removes some rather
'hackish' code that was added by
Le 04/01/2014 16:35, Janus Weil a écrit :
Hi Mikael,
this patch fixes PR58007, where the compiler was not able to relate a
component pointer to any loaded derived type symbol.
The problem came from an optimization avoiding loading again a symbol
which had already been loaded, skipping by
Le 22/12/2013 11:28, Janus Weil a écrit :
Hi all,
here is a patch for a rejects-valid problem with type-bound
procedures, which is due to the fact that the PURE attribute is being
propagated too late. (I'm not sure if this problem could show up also
with other attributes, so for now I'm
.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
I plan to submit a variant that doesn't change the module format for the
branches (doing more parsing by hand).
Mikael
2014-01-02 Mikael Morin mik...@gcc.gnu.org
PR fortran/58007
* module.c (MOD_VERSION): Bump
601 - 700 of 1084 matches
Mail list logo
