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'
Hello,
I will try to produce a testcase for 4.8 and/or that doesn't involve OOP.
I come back to you later.
Thanks for the review.
Mikael
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 b
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, skip
Le 10/07/2015 16:51, Andre Vehreschild a écrit :
> Hi everyone,
>
> attached is a rather trivial patch to fix a linker issue when unlimited
> polymorphism is used and the vtabs of intrinsic types are referenced from two
> different locations (e.g. module and main program). Gfortran finds the vtab
Hello all,
I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any explicit mention of
allocatable variables/expressions.
For what it's worth, in my opinion, the handling of allocatable that was
proposed by Andre makes sense to me. It's
Ping: https://gcc.gnu.org/ml/fortran/2015-06/msg00075.html
Le 21/06/2015 11:48, Mikael Morin a écrit :
> Le 16/05/2015 18:43, Mikael Morin a écrit :
>> Hello,
>>
>> this is about PR61831 where in code like:
>>
>> type :: string_t
>> char
hello Andre.
Le 06/07/2015 13:54, Andre Vehreschild a écrit :
> Hi all,
>
> please find attached the next version of the patch for pr66035 fixing an ICE.
> Scope (copied from first submit):
>
> An ICE occurred when in a structure constructor an allocatable component of
> type class was initializ
Le 10/07/2015 20:57, Steve Kargl a écrit :
> On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
>>
>> I'm not completely convinced by the standard excerpts that have been
>> quoted about this topic, as they don't have any explicit mention of
>> allo
Le 11/07/2015 12:36, Andre Vehreschild a écrit :
> Hi,
>
>
>>"On completion of execution of the function, the value returned
>> is that of its function result. ... If the function result is
>> not a pointer, its value shall be defined by the function."
>
> Now we can argue whether th
Hello,
Le 13/07/2015 21:54, Thomas Schwinge a écrit :
> Original situation; _gfortran_runtime_error is not being properly
> declared (invoked via gcc/fortran/frontend-passes.c:runtime_error_ne),
> but, for example, _gfortran_error_runtime_at is being properly declared
> (invoked from elsewhere):
Hello,
Le 13/07/2015 17:31, Alessandro Fanfarillo a écrit :
> Dear all,
>
> during the implementation of co_reduce in OpenCoarrays I noticed that
> GFortran passes a pointer to function instead of the function name to
> co_reduce.
>
More exactly there are two address operators ('&') in a row (th
Le 15/07/2015 16:03, Thomas Schwinge a écrit :
> Hi!
>
> On Wed, 15 Jul 2015 13:44:38 +0200, Mikael Morin wrote:
>> Le 13/07/2015 21:54, Thomas Schwinge a écrit :
>>> Original situation; _gfortran_runtime_error is not being properly
>>> declared
Le 16/07/2015 16:34, Damian Rouson a écrit :
> Alternatively, if it’s easy, please feel free to add the directives and
> commit.
>
It's not very difficult, but there is some pain getting the number of
escape backslashes right.
Never mind, I'll take care of it all.
Mikael
Le 17/07/2015 11:02, Mikael Morin a écrit :
> Le 16/07/2015 16:34, Damian Rouson a écrit :
>> Alternatively, if it’s easy, please feel free to add the directives and
>> commit.
>>
> Never mind, I'll take care of it all.
>
This is what I have committed:
ht
Le 17/07/2015 20:40, Steve Kargl a écrit :
> On Fri, Jul 17, 2015 at 03:50:26PM +0200, Mikael Morin wrote:
>> Le 17/07/2015 11:02, Mikael Morin a écrit :
>>> Le 16/07/2015 16:34, Damian Rouson a écrit :
>>>> Alternatively, if it?s easy, please feel free to add t
Le 17/07/2015 21:39, Mikael Morin a écrit :
>> It seems that this commit has changed the scanning of
>> other testcases.
>>
> Will fix.
>
Done:
https://gcc.gnu.org/r225965 (trunk)
https://gcc.gnu.org/r225969 (5 branch)
Mikael
Index: gcc/testsuite/gfortran.dg/co
eared as '&&some_func' in
the dump, instead of the rather innocent '&some_func'.
So I propose the attached patch which does that change.
Bootstrapped and regression tested (c,c++,fortran) on x86_64-linux.
OK for trunk?
Mikael
2015-07-21 Mikael
components of array constructor elements
Index: ChangeLog
===
--- ChangeLog (révision 226037)
+++ ChangeLog (révision 226038)
@@ -1,8 +1,14 @@
+2015-07-21 Mikael Morin
+
+ PR fortran/61831
+ * gfortran.dg/derived_constructor_comps_6.f
ested on x86_64-linux. OK for trunk?
Mikael
[1]: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01389.html
2015-07-20 Mikael Morin
PR fortran/61831
PR fortran/66929
* trans-array.c (gfc_get_proc_ifc_for_expr): Use esym as procedure
symbol if available.
2015-
Le 20/07/2015 23:55, Thomas Koenig a écrit :
Hi,
I'm back from holiday, so I can finally reply.
Am 13.07.2015 um 21:54 schrieb Thomas Schwinge:
--- gcc/fortran/iresolve.c
+++ gcc/fortran/iresolve.c
@@ -2207,6 +2207,9 @@ gfc_resolve_fe_runtime_error (gfc_code *c)
a->name = "%VAL";
Le 21/07/2015 21:49, Thomas Koenig a écrit :
Am 21.07.2015 um 19:26 schrieb Mikael Morin:
I would like to avoid the hack in iresolve. So let's reuse the
frontend-passes.c part of my patch (set resolved_isym)
I would much prefer if that was put into gfc_resolve_fe_runtime_error,
next t
Hello Paul,
Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
Since all the private entities in a module have to be transmitted to
their descendant submodules, whilst keeping them hidden from normal
use statements, I have chosen to write the module file as usual and
add a second part that conta
Hello,
I committed the patch for PR64984 that I had posted on bugzilla.
It was approved by Paul:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986#c13
Mikael
Le 21/07/2015 23:10, Paul Richard Thomas a écrit :
Hi Mikael,
This looks fine to me - OK for trunk.
Thanks for the patch
Paul
On 21 July 2015 at 14:53, Mikael Morin wrote:
Hello,
The fix for PR61831 committed recently [1] introduced/uncovered a NULLL
pointer dereference with
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?
2015-
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 29/07/2015 13:22, Richard Biener a écrit :
On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin wrote:
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.
Not if the patch fixes
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
PR fortran/64921
* class.c
ikael
2015-07-29 Bud Davis
Mikael Morin
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
PR fortran/59746
* gfortran.dg/common_22.f90
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 wrote:
Le 29/07/2015 13:22, Richard Biener a écrit :
On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin
wrote:
Le 29/07/2015 10:26, Richard
Le 29/07/2015 17:08, Paul Richard Thomas a écrit :
Dear All,
On 24 July 2015 at 10:08, Damian Rouson wrote:
I love this idea and had similar thoughts as well.
:D
Sent from my iPhone
On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
wrote:
Dear Mikael,
It had crossed my mind also that a
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 th
Hello,
this renames the expr4 field of gfc_code to the more descriptive
ext.lock.acquired_lock.
Regression tested on x86_64-unkown-linux-gnu. OK for trunk?
Mikael
2015-08-05 Mikael Morin
* gfortran.h (struct gfc_code): Move expr4 field to
ext.lock.acquired_lock
Le 05/08/2015 21:24, Steve Kargl a écrit :
On Wed, Aug 05, 2015 at 08:54:21PM +0200, Mikael Morin wrote:
+/* LOCK/UNLOCK statements */
+struct
+{
+ gfc_expr *acquired_lock;
+}
+lock;
Just curious. Why add a struct with a single member?
I would have thought s/expr4
Le 19/04/2015 16:54, Mikael Morin a écrit :
Hello,
while working on pr65792, I noticed that gfc_trans_scalar_assign's
l_is_temp and dealloc flags are used only once, and at the same place.
This patch merges them together.
The calls are changed from
gfc_trans_scalar_assign (..
Le 25/07/2015 20:33, Mikael Morin a écrit :
Le 21/07/2015 23:10, Paul Richard Thomas a écrit :
On 21 July 2015 at 14:53, Mikael Morin wrote:
Hello,
The fix for PR61831 committed recently [1] introduced/uncovered a NULLL
pointer dereference with iso_varying_string, because a generic symbol
Le 29/07/2015 20:35, Mikael Morin a écrit :
Hello,
I'm unburrying the patch from the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00439.html
I provide the patch in two flavors read-only (without whitespace
changes) and write-only (with them).
This has been test
Le 21/07/2015 13:52, Mikael Morin a écrit :
Hello,
this is a followup to the bug report/patch at:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01062.html
It's a fortran quite unimportant bug, so I bet nobody cares.
However, the bug could have been detected when the co_reduce suppor
Hello,
this avoids an error found with bootstrap-ubsan.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-08-05 Mikael Morin
* hwint.h (sext_hwi): Rewrite without undefined behaviour on
negative SRC.
diff --git a/gcc/hwint.h b/gcc/hwint.h
index
Le 06/08/2015 12:53, Andre Vehreschild a écrit :
Dear all,
the attached patch fixes a regression introduced by my patches for the
F2008-style allocate(). In this case a function returning an array of BT_CLASS
objects can not be conv'ed using conv_expr_descriptor, but needs to be
conv_expr_refere
Le 06/09/2015 18:40, Paul Richard Thomas a écrit :
It helps to attach the patch :-)
Paul
On 6 September 2015 at 13:42, Paul Richard Thomas
wrote:
Dear All,
The attached patch more or less implements the assignment of
expressions to the result of a pointer function. To wit:
my_ptr_fcn (arg1,
Hello Paul,
Le 25/09/2015 14:21, Paul Richard Thomas a écrit :
Dear Mikael, dear all,
Please find attached a revised version of the patch that, I believe,
addresses all the comments. The patch is very much improved and these
improvements are verified by the two extra testcases. Thanks a
million
(révision 228151)
@@ -1,3 +1,8 @@
+2015-09-25 Mikael Morin
+
+ PR fortran/55603
+ * gfortran.dg/allocatable_function_9.f90: New.
+
2015-09-25 Oleg Endo
PR target/67675
t the deep_copy
flag passed to gfc_trans_scalar_assign is set to true.
Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2015-09-26 Mikael Morin
PR fortran/67721
* trans-expr.c (gfc_trans_assignment_1): Remove the non-constantness
condition guarding deep
Le 25/09/2015 23:41, Steve Kargl a écrit :
The attached patch has been built and regression
tested on x86_64-*-freebsd. No regression occurred.
The patch removes a conditional within an assert()
that triggers when a BLOCK construct is encountered.
What happens here, I think, is symtree is a ne
Le 01/10/2015 01:58, Steve Kargl a écrit :
When FLUSH is used with a flulsh-spec-list, a unit is required.
Thus, a statement like 'flush(iostat=i)' would lead to an ICE
because gfortran was dereference a pointer to a non-existant
unit number. The attached patch was built and tested on
x86-*-free
Le 01/10/2015 02:07, Steve Kargl a écrit :
On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote:
Patch built and regression tested on x86_64-*-freebsd.
OK to commit?
The patch prevents the dereferencing of a NULL pointer
by jumping out of the cleanup of a list of COMMON blocks.
Hold on,
Le 01/10/2015 02:03, Steve Kargl a écrit :
The attached patch was built and tested on x86_64-*-freebsd.
OK to commit?
The patch prevents an ICE in a BLOCK construct that uses
a DATA statement and default initialization. The problem
was that the derived typed was declared in the host and
was not
Le 01/10/2015 14:16, Mikael Morin a écrit :
Le 01/10/2015 02:07, Steve Kargl a écrit :
On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote:
Patch built and regression tested on x86_64-*-freebsd.
OK to commit?
The patch prevents the dereferencing of a NULL pointer
by jumping out of the
Le 01/10/2015 18:30, Steve Kargl a écrit :
I'm fine with your patch, although I find the error message
to be somewhat confusing as no procedure appears in COMMON.
Well, XX is implicitly a procedure.
The call-stmt in the code is the start of an execution-construct.
A common-stmt is not allowed
Le 02/10/2015 18:44, Steve Kargl a écrit :
On Fri, Oct 02, 2015 at 11:28:06AM +0200, Mikael Morin wrote:
Le 01/10/2015 18:30, Steve Kargl a écrit :
The call-stmt in the code is the start of an execution-construct
A common-stmt is not allowed in an execution-construct. At
least, that's
ed by
Dominique and H.J.Lu in the PR comments [6][7]
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818#c7
[7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818#c8
No new test, the failure is already in the libgomp testsuite.
OK for the 5 branch?
Mikael
2015-10-04 Mikael Morin
PR fortran/
Hello,
I found an unused variable when working on pr67758.
Committed as revision 228458.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 228457)
+++ ChangeLog (révision 228458)
@@ -1,5 +1,9 @@
2015-10-04 Mikael Morin
Le 06/10/2015 16:22, Andre Vehreschild a écrit :
Hi all,
the attached patch fixes a 6 regression when the argument of sizeof()
is a pointer to a class object, e.g., when the class object is
intent(out). The patch improves the check if the parameter is a
class object by previously checking whethe
related memory management.
- In gfc_restore_last_undo_checkpoint, when a symbol has been
removed from the common block linked list, its common_next pointer is
cleared.
Regression tested on x86_64-linux. OK for trunk?
Mikael
2015-10-06 Mikael Morin
PR fortran/67758
* gfortran.h
Le 08/10/2015 11:06, Maxim Ostapenko a écrit :
Hi,
running UBSan bootstrap on trunk, I've run to the such issue:
/home/max/workspace/downloads/svn/trunk/gcc/fortran/parse.c: In function
‘gfc_statement decode_statement()’:
/home/max/workspace/downloads/svn/trunk/gcc/fortran/parse.c:368:51:
error
Le 15/10/2015 12:18, Andre Vehreschild a écrit :
Hi Mikael, hi all,
I have checked that the patch (my initial one for pr59678) does compile
and test fine. Given that the patch lives in trunk-6 for quite some
time now, without any major complaints, I approve to commit to gcc-5.
Thanks, I'll proc
Le 16/10/2015 10:08, Christophe Lyon a écrit :
Hi,
We have noticed a few random failures in gfortran tests in our validations.
Maxim investigated some of them and noticed a possible race condition
in the streamio tests, for which he'll post a patch.
I looked for other similar cases (checking w
Le 22/10/2015 22:04, Maxim Kuvyrkov a écrit :
Hi,
And this is a similar patch for gfortran.dg/streamio_N.f90 tests.
OK to commit?
Sure.
Mikael
Le 24/10/2015 19:50, Steve Kargl a écrit :
The attached patch fixes an ICE that occurs when gfortran
is not expecting a PROTECTED attribute. Built and tested
on x86_64-*-freebsd. OK to commit?
OK. Thanks.
Mikael
Le 24/10/2015 21:29, Dominique d'Humières a écrit :
At revision r229288 compiling the following test
[...]
while it compiles without error at r229261.
I believe the accesses to ref->u.ar should be guarded with ref->type ==
REF_ARRAY.
Steve, a patch doing that is preapproved.
Mikael
Hello,
Le 30/10/2015 13:47, David Malcolm a écrit :
This patch adds an implementation of Levenshtein distance to gcc,
along with unit testing of the algorithm.
I noticed two nits while looking at it.
diff --git a/gcc/spellcheck.c b/gcc/spellcheck.c
new file mode 100644
index 000..532df5
Hello Steve,
Le 01/11/2015 22:16, Steve Kargl a écrit :
The attach patch add checking for a valid type during
matching of a CASE selector. Built and regression
tested on i386-*-freebsd. OK to commit?
[...]
Index: gcc/fortran/match.c
=
Le 01/11/2015 20:24, Steve Kargl a écrit :
The attached patch enhances the check of the shape argument
when it is a named constant. See the testcase for example.
Built and regression tested on i386-*-freebsd. OK to commit?
Looks good, yes. Thanks.
Mikael
Le 27/11/2015 13:20, Andre Vehreschild a écrit :
Hi all,
I have backported the patch for 68218 (multiple calls of the same
function, where only one call is expected and reasonable) to
gcc-5-branch and gcc-4_9-branch.
Bootstrapped and regtested on x86_64-linux-gnu/f21.
Ok for gcc-5-branch?
Ok
Le 03/12/2015 10:29, Janne Blomqvist a écrit :
On Tue, Dec 1, 2015 at 7:51 PM, Bernhard Reutner-Fischer
wrote:
As said, we could as well use a list of candidates with NULL as record marker.
Implementation cosmetics. Steve seems to not be thrilled by the
overall idea in the first place, so unles
Hello,
to get things moving again, a few comments on top of David Malcolm's:
Le 01/12/2015 13:55, Bernhard Reutner-Fischer a écrit :
David Malcolm nice Levenshtein distance spelling check helpers
were used in some parts of other frontends. This proposed patch adds
some spelling corrections to
Le 03/11/2022 à 23:03, Harald Anlauf a écrit :
Am 03.11.22 um 11:06 schrieb Mikael Morin:
Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
I do see what needs to be done in gfc_get_function_type, which seems
in fact very simple. But I get really lost in create_function_arglist
when
Hello,
Le 05/11/2022 à 23:28, Tobias Burnus a écrit :
Prior to the attached patch, there is a problem with realloc on assignment
with kind=4 characters as the string length was compared with the byte
size,
which was always true.
(...)
OK for mainline?
The trans-array.c part looks good.
A
Hello,
Le 07/11/2022 à 22:45, Harald Anlauf via Fortran a écrit :
Dear all,
Am 04.11.22 um 10:53 schrieb Mikael Morin:
Le 03/11/2022 à 23:03, Harald Anlauf a écrit :
I've spent some time not only staring at create_function_arglist,
but trying several variations handling the declared h
Le 08/11/2022 à 21:31, Harald Anlauf a écrit :
Hi Mikael,
Am 08.11.22 um 11:32 schrieb Mikael Morin:
this is mostly good.
There is one last corner case that is not properly handled:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 63515b9072a..94988b8690e 100644
--- a
Hello,
Le 10/11/2022 à 22:56, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch is a follow-up to the fix for PR107441,
as it finally fixes the treatment of character dummy arguments
that have the value,optional attribute, and allows for checking
of the presence of such a
Le 09/11/2022 à 21:50, Harald Anlauf via Fortran a écrit :
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html
I think the diagnostics improvement is helpful, as it adjusts
to the changes from F2003 to F2008.
The patch suf
Le 15/11/2022 à 21:45, Harald Anlauf via Fortran a écrit :
Dear all,
when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.
Debugging of the testcase showed we call the proper typ
Hello,
--- gcc/gimple-range-op.cc.jj 2023-04-21 17:09:48.250367999 +0200
+++ gcc/gimple-range-op.cc 2023-04-21 18:37:26.048325391 +0200
@@ -439,20 +436,38 @@ public:
r.set_varying (type);
return true;
}
+
// Results outside of [-1.0, +1.0] are impossible.
Hello,
Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE attribute is a *value*
that itself does not have the ALLOCATABLE attribute.
For those interested: there was
Le 22/04/2023 à 15:52, Steve Kargl a écrit :
On Sat, Apr 22, 2023 at 11:25:41AM +0200, Mikael Morin wrote:
Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE
Le 22/04/2023 à 20:19, Harald Anlauf a écrit :
Hi Mikael,
Am 22.04.23 um 11:25 schrieb Mikael Morin:
Hello,
Le 20/04/2023 à 22:01, Harald Anlauf via Fortran a écrit :
Dear all,
Fortran 2018 added a clarification that the *result* of a function
whose result *variable* has the ALLOCATABLE
Hello,
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 3b397ae2941..b8add24f874 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -150,6 +150,49 @@ static tree fold_convert_const (enum tree_code, tree,
tree);
static tree fold_view_convert_expr (tree, tree);
static tree fold
Hello,
Le 05/05/2023 à 10:00, Jakub Jelinek via Gcc-patches a écrit :
Hi!
The previous patch just added basic intrinsic ranges for sqrt
([-0.0, +Inf] +-NAN being the general result range of the function
and [-0.0, +Inf] the general operand range if result isn't NAN etc.),
the following patch in
Hello,
Le 01/05/2023 à 18:29, Harald Anlauf via Fortran a écrit :
Dear all,
the attached patch is mostly self-explaining: we mishandled the
overloading of intrinsic binary operators in the case the actual
operands were of intrinsic numeric type and the ranks of the
operands were not conformable
Hello,
Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit :
(...)
Proposed ChangeLog entry using git gcc-commit-mklog:
Author: Jerry DeLisle
Date: Sat Jan 21 15:47:19 2023 -0800
Revise the line end tests to pass on certain windows test environments
which inject spurious /r charac
Le 28/01/2023 à 03:47, Jerry D a écrit :
It is not apparent to me that the testsuite/ChangeLog was updated. Maybe
there is a time delay on that?
Yes, it's done daily as part of the "daily bump" commit.
You can see it in the git log:
$ git log -- gcc/testsuite/ChangeLog
commit f457a62e63a86d
?From e61e2a51e1859f884125670010337f34265997b8 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 29 Jan 2023 14:38:08 +0100
Subject: [PATCH] fortran: Set name for *LOC default BACK argument [PR108450]
This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which
Le 29/01/2023 à 05:17, Jerry DeLisle via Fortran a écrit :
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Yes, thanks.
Hello,
I don’t like the _Float128 vs __float128 business, it’s confusing.
And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
they seem to be basically the same thing, so it’s also redundant.
Is there a reason why the standard one, _Float128, can’t be used everywhere?
Mikae
Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.
I agree with that.
I was implicitly suggesting to change the libquadmath API to use the
standar
Le 17/11/2022 à 21:48, Harald Anlauf via Fortran a écrit :
Dear all,
one cannot pass a NULL actual argument to a procedure without an
explicit interface. This is detected and reported by NAG and Intel.
(Cray accepts this silently, and some other brands ICE.)
The testcase by Gerhard even tricke
Hello,
Le 10/11/2022 à 11:20, Bernhard Reutner-Fischer via Fortran a écrit :
Tiny cleanup opportunity since we now have ext_attr_args in
struct symbol_attribute.
Bootstrapped and regtested on x86_64-unknown-linux with no new
regressions.
Ok for trunk if the prerequisite was approved ([PATCH 2/2]
Le 10/11/2022 à 11:20, Bernhard Reutner-Fischer via Fortran a écrit :
Bootstrapped and regtested cleanly on x86_unknown-linux.
The document bits will be rewritten for rst.
Ok for trunk if the prerequisite target_clones patch is approved?
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_gcc_a
Hello,
Le 17/11/2022 à 09:02, Bernhard Reutner-Fischer via Fortran a écrit :
Hi Honza, Ping.
Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++
Ok?
I'd need this for attribute target_clones for the Fortran FE.
thanks,
On Wed, 9 Nov 2022 20:02:24 +0100
Bernhard Reutner-Fischer wrote:
Hello,
Le 09/11/2022 à 20:02, Bernhard Reutner-Fischer via Fortran a écrit :
Hi!
Add support for attribute target_clones:
!GCC$ ATTRIBUTES target_clones("arch1", "arch3","default") :: mysubroutine
Bootstrapped and regtested on x86_64-unknown-linux with
--target_board=unix'{-m32,-m64}'.
OK for
Le 21/11/2022 à 21:34, Bernhard Reutner-Fischer a écrit :
On Mon, 21 Nov 2022 12:08:20 +0100
Mikael Morin wrote:
* gfortran.h (struct ext_attr_t): Remove middle_end_name.
* trans-decl.cc (add_attributes_to_decl): Move building
tree_list to ...
* decl.cc
Le 21/11/2022 à 23:26, Bernhard Reutner-Fischer a écrit :
On Mon, 21 Nov 2022 20:13:40 +0100
Mikael Morin wrote:
Hello,
Le 09/11/2022 à 20:02, Bernhard Reutner-Fischer via Fortran a écrit :
Hi!
(...)
+ if (allow_multiple && gfc_match_char (')') != MATCH_YES)
+
Le 27/11/2022 à 21:32, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
in dependency checking of arguments of elemental prodecures
we should treat dummy arguments with the value attribute as
implicitly having intent(in). This is simple and obvious.
The PR by Gerhard provides a series of
Le 01/12/2022 à 21:25, Harald Anlauf via Fortran a écrit :
Dear all,
we did not properly handle the case of insufficient array-valued
FIELD when trying to simplify UNPACK and could run into a NULL
pointer dereference. The fix is obvious.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The
Le 13/12/2021 à 21:27, Harald Anlauf via Fortran a écrit :
Works better with patch attached...
Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches:
The code is so similar (for good reason) that it makes sense to keep
it synchronous. I added code for 'zero_sized' array with the minor
di
Le 20/12/2021 à 23:05, Harald Anlauf via Fortran a écrit :
Dear all,
we need to check the arguments of the elemental MASKL and MASKR
intrinsics also before simplifying.
Testcase by Gerhard. The fix is almost obvious, but I'm happy to
get feedback in case there is something I overlooked. (Ther
301 - 400 of 1075 matches
Mail list logo
