Le 13/04/2013 17:44, Mikael Morin a écrit :
Indeed, that's invalid:
And then, the call to gfc_match_varspec shouldn't be there in the first
place. I'll test the following later.
Index: primary.c
===
--- primary.c (révision
Le 14/04/2013 16:21, Thomas Koenig a écrit :
Hi Mikael,
- (void) gfc_expr_walker (fcn, callback_reduction, NULL);
why remove this?
Because it is not needed, as the test case _46 shows. No need
to run this twice, it doesn't get better :-)
Indeed, that's right.
gfc_internal_error
Le 09/04/2013 20:33, Janne Blomqvist a écrit :
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
Looks good. OK. Thanks.
(IMHO the increase in compile time is modest enough that it's not
worth doing the caching of uncompressed module files that I was
previously thinking about, especially
===
--- testsuite/ChangeLog (révision 198085)
+++ testsuite/ChangeLog (révision 198086)
@@ -1,3 +1,13 @@
+2013-04-19 Thomas Koenig tkoe...@gcc.gnu.org
+ Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran/56872
+ * gfortran.dg/array_constructor_45.f90: New test
Hello,
Le 21/04/2013 23:04, Janus Weil a écrit :
Hi all,
the attached patch fixes an regression with TRANSFER, which was just
reported today. The problem was that array-valued SOURCE arguments
were not treated correctly.
To fix it properly, I had to make 'gfc_target_expr_size' behave
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
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:
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
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
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 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
), 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
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
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
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
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
Hello Paul,
have you had time to look at this again?
Mikael
Ping:
https://gcc.gnu.org/ml/fortran/2015-02/msg00045.html
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 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
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 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 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
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
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
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,
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,
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
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 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 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
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
.
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,
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
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
-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)
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
Mikael Morin mik...@gcc.gnu.org
PR fortran/61831
* trans-array.c (gfc_conv_array_parameter): Remove allocatable
component deallocation code generation.
* trans-expr.c (gfc_conv_expr_reference): Ditto.
(expr_may_alias_variables): New function
Le 14/05/2015 03:58, Jerry DeLisle a écrit :
The attached patch reverts a change I made for pr65456 which caused this
regression and adds a check for quotes farther down in the function. This
avoids treating a '!' in a string as a comment and wiping the rest of the
line.
I found the added
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)
@@
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
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, 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
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
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 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 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 20/05/2015 10:24, Andre Vehreschild a écrit :
Hi Mikael,
when I got you right on IRC, then you proposed this change about the pointer
attribute:
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 6d565ae..545f778 100644
--- a/gcc/fortran/trans-stmt.c
+++
Le 19/05/2015 10:50, Andre Vehreschild a écrit :
Hi all,
find attached latest version to fix 65548.
Bootstraps and regtests ok on x86_64-linux-gnu/f21.
OK. Thanks.
Mikael
);
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
Le 08/06/2015 17:31, Jan Hubicka a écrit :
Hi,
to furhter add to the topics to discuss, I noticed that Fortran FE seems to
be quite
ambivalent about C_CHAR type:
[jh@gcc2-power8 gcc]$ cat ../b.f90
! This testcase will abort if C_CHAR types are not interoperable
module lto_type_merge_test
for trunk/5 ?
Mikael
2015-06-18 Mikael Morin mik...@gcc.gnu.org
PR fortran/66549
* resolve.c (resolve_global_procedure): Don't save and restore
OpenMP state around the call to gfc_resolve.
(gfc_resolve): Save OpenMP state on entry and restore it on return.
2015
Le 18/06/2015 13:35, Jakub Jelinek a écrit :
On Thu, Jun 18, 2015 at 01:18:18PM +0200, Mikael Morin wrote:
I'm proposing here a fix for an OpenMP ICE regression introduced by me
at http://gcc.gnu.org/r221586
That revision changed the order in which procedures are resolved, making
it possible
Le 16/05/2015 18:43, Mikael Morin a écrit :
Hello,
this is about PR61831 where in code like:
type :: string_t
character(LEN=1), dimension(:), allocatable :: chars
end type string_t
type(string_t) :: prt_in
(...)
tmp = new_prt_spec ([prt_in
Le 10/06/2015 16:38, Jan Hubicka a écrit :
[jh@gcc2-power8 gcc]$ cat ../b.f90
! This testcase will abort if C_CHAR types are not interoperable
module lto_type_merge_test
use, intrinsic :: iso_c_binding
implicit none
contains
function types_test1(V) bind(c)
USE, INTRINSIC ::
Le 28/05/2015 17:29, Andre Vehreschild a écrit :
*** resolve_allocate_expr (gfc_expr *e, gfc_
*** 7103,7112
--- 7103,7123
if (!ref2 || ref2-type != REF_ARRAY || ref2-u.ar.type == AR_FULL
|| (dimension ref2-u.ar.dimen == 0))
{
+ /* F08:C633. */
Le 27/05/2015 16:07, Andre Vehreschild a écrit :
Hi Paul, hi Mikael,
about renaming the identifier emitted: I would like to keep it short.
Remember,
there is always a number attached to it, which makes it unique. Furthermore
does alloc_source_tmp sound unnecessarily long to me. It tastes
Le 27/05/2015 23:09, Steve Kargl a écrit :
On Wed, May 27, 2015 at 06:24:25PM +0200, Mikael Morin wrote:
Le 27/05/2015 16:07, Andre Vehreschild a ?crit :
Hi Paul, hi Mikael,
about renaming the identifier emitted: I would like to keep it short.
Remember,
there is always a number attached
Hello Andre,
comments below (out of order, sorry).
Le 29/05/2015 13:46, Andre Vehreschild a écrit :
Hi Mikael,
comments inline below:
On Thu, 28 May 2015 20:06:57 +0200
Mikael Morin mikael.mo...@sfr.fr wrote:
Le 28/05/2015 17:29, Andre Vehreschild a écrit
Le 25/05/2015 09:30, Paul Richard Thomas a écrit :
Dear All,
Lets see if I can get it right this time :-)
Note that I have changed the name of the temporary variable in
trans_allocate from 'atmp' to 'expr3' so that it is not confused with
array temporaries.
I agree with Andre willing to
hello Andre,
Le 25/05/2015 12:24, Andre Vehreschild a écrit :
Hi Paul,
I am not quite happy with the naming of the temporary variable. When I
initially set the prefix to atmp this was because the variable would be an
array most of the time and because of the number appended to it should be
Le 19/05/2015 12:26, Andre Vehreschild a écrit :
Hi all,
update based on latest 65548 (v5) patch and current trunk. Description and
issue addressed unchanged (see cite below).
Bootstrapped and regtested on x86_64-linux-gnu/f21.
Any volunteers to review? The initial version dates back to
-05-23 Mikael Morin mik...@gcc.gnu.org
PR fortran/66257
* resolve.c (resolve_actual_arglist): Don't throw an error
if the argument with procedure pointer component is not a variable.
2015-05-23 Mikael Morin mik...@gcc.gnu.org
PR fortran/66257
* typebound_call_27.f90: New file.
diff --git
Le 23/05/2015 01:04, Manuel López-Ibáñez a écrit :
PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01511.html
This only needs approval from Fortran maintainers.
I approved: https://gcc.gnu.org/ml/fortran/2015-05/msg00135.html
But it seems I replied to the fortran list only.
Mikael
Le 21/05/2015 19:51, Thomas Koenig a écrit :
Am 18.05.2015 um 00:05 schrieb Thomas Koenig:
this patch extends the inline matmul functionality to conjugate
complex numbers.
Regression-tested. OK for trunk?
OK (with the trivial change in the follow-up e-mail)?
I'd like to start extending
Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
Dear Mikael,
Thanks for your green light!
I have been mulling over the trans-decl part of the patch and having
been wondering if it is necessary.
You mean marking entities as public? Or setting the hidden visibility
attribute? Or both?
I
Le 13/08/2015 12:56, Mikael Morin a écrit :
Still, implementation-defined behavior is a progress over undefined
behaviour.
Even if it's not set in stone, the good thing about
implementation-defined behaviour is that it's known to be non-random.
So it can be checked, either with autoconf
Le 12/08/2015 22:07, Richard Sandiford a écrit :
Jeff Law l...@redhat.com writes:
On 08/12/2015 12:32 PM, Richard Biener wrote:
On August 12, 2015 8:07:13 PM GMT+02:00, Jeff Law l...@redhat.com wrote:
On 08/12/2015 11:12 AM, Richard Biener wrote:
Prec is almost never a constant and is
/= -10) call abort
+end program p
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (révision 227009)
+++ gcc/testsuite/ChangeLog (révision 227010)
@@ -1,3 +1,8 @@
+2015-08-19 Mikael Morin mik...@gcc.gnu.org
+
+ PR fortran
with clang, but I don't think it means anything.
What do you think, OK?
Mikael
2015-08-18 Mikael Morin mik...@gcc.gnu.org
PR other/67042
* hwint.h (sext_hwi): Switch to unsigned for the left shift, and
conditionalize the whole on __GNUC__. Add fallback code
2015-07-29 Bud Davis jmda...@link.com
Mikael Morin mik...@gcc.gnu.org
PR fortran/59746
* symbol.c (gfc_restore_last_undo_checkpoint): Delete a common block
symbol if it was put in the list.
2015-07-29 Bud Davis jmda...@link.com
PR fortran/59746
sets the flag.
I think it can be backported.
The test is already present on the trunk and 5 branch. I plan to add it
to 4.9 as well.
Regression tested on x86_64-unkown-linux-gnu. OK for 6/5/4.9 ?
Mikael
2015-07-29 Mikael Morin mik...@gcc.gnu.org
PR fortran/64921
* class.c
Le 29/07/2015 18:45, Steve Kargl a écrit :
On Wed, Jul 29, 2015 at 02:04:12PM +0200, Richard Biener wrote:
On Wed, Jul 29, 2015 at 1:59 PM, Mikael Morin mikael.mo...@sfr.fr wrote:
Le 29/07/2015 13:22, Richard Biener a écrit :
On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin mikael.mo...@sfr.fr
Le 29/07/2015 10:26, Richard Biener a écrit :
Did you try using vec_safe_splice?
That handles NULL retargs, not NULL or empty arglist.
I think retargs is NULL.
Le 21/07/2015 21:08, Steve Kargl a écrit :
When C++ was injected into trans-expr.c in the form of vec,
it seems whomever did the conversion to vec forgot to check
for a NULL C++ thing. This patch seems to avoid the problem,
but having zero knowledge of C++ I could be wrong.
OK for trunk?
401 - 500 of 953 matches
Mail list logo
