On 11/07/2014 02:15 AM, Janne Blomqvist wrote:
On Thu, Nov 6, 2014 at 12:38 PM, Janne Blomqvist
wrote:
On Wed, Nov 5, 2014 at 12:48 PM, Janne Blomqvist
wrote:
Hi,
the attached patch fixes a few locale related failures in libgfortran,
in the case where the POSIX 2008 extended locale functiona
On 6/14/19 3:56 PM, Steve Kargl wrote:
I have had this patch in my tree since the beginning of May.
During constant folding, gfortran would not issue an error
for overflow for integer exponentation. Bootstrapped
and regression tested multiple times on x86_64-*-freebsd?
OK to commit?
2019-06-15
I will see if I can get this one.
On 6/17/19 6:37 AM, Mark Eggleston wrote:
On 12/06/2019 19:11, Steve Kargl wrote:
On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote:
On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote:
Jim MacArthur
Mark Eggleston
Two spa
. Regression tested on
x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
* gfortran.dg/io_constraints.f90: New test.
! { dg-do compile
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing
On 12/4/18 9:04 AM, Fritz Reese wrote:
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects. So perhaps have transfer in the option name?
[...]
Wouldn't it
On 12/6/18 2:33 AM, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
accomodate some old dec fortran code. The only reason to use some other
character is if someone is writing new dec
On 12/9/18 8:11 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes the wrong-code regression by changing the
way synchronous writes are handled on files using asynchronous I/O:
The are now handled synchronously.
This also means that two places where a wait instruction was
issued in
On 12/23/18 10:49 AM, Steve Kargl wrote:
This is a re-submission of a patch I submitted 15 months ago.
See https://gcc.gnu.org/ml/fortran/2017-09/msg00124.html
At that time one reviewer OK'd the patch for committing,
and one reviewer raised objections to the patch as I
chose to remove dubious ex
On 12/28/18 10:43 AM, Steve Kargl wrote:
Ping.
On Mon, Dec 24, 2018 at 11:59:50AM -0800, Steve Kargl wrote:
All,
The IEEE modules and -ffpe-trap are to some extent orthogonal
features of gfortran. Unfortunately, some users have the
expectation of using -ffpe-trap for debugging while also usin
OK Steve,
Jerry
On 12/28/18 10:43 AM, Steve Kargl wrote:
Ping.
On Tue, Dec 25, 2018 at 01:44:10PM -0800, Steve Kargl wrote:
Here's a Holiday present for Fortranners.
2018-12-25 Steven G. Kargl
* cpp.c (gfc_cpp_init): Add pre-defined macros for INTEGER(1)
INTEGER(2), INTE
On 12/28/18 10:44 AM, Steve Kargl wrote:
Ping.
OK, thanks.
Jerry
On Tue, Dec 25, 2018 at 02:36:40PM -0800, Steve Kargl wrote:
Fortran 2018 has added IEEE_SUBNORMAL, IEEE_POSITIVE_SUBNORMAL, and
IEEE_NEGATIVE_SUBNORMAL as counterparts the same features with the
DENORMAL name. The attached p
statements. I cleared those by
throwing in an assert (false) since it cant happen unless something really goes
wrong somehow.
Regardless, regression tested on x86_64-pc-linux-gnu.
OK for trunk? No applicable test case.
Jerry
2019-09-22 Jerry DeLisle
PR libfortran/91593
* io
ck in early versions so should probably go to 7
and 8 branches. Opinions welcome.
Regards,
Jerry
2018-11-04 Jerry DeLisle
* io/transfer.c (read_sf_internal): Add support for early
comma termination of internal unit formatted reads.
diff --git a/libgfortran/io/transfe
On 11/4/18 1:51 AM, Bernhard Reutner-Fischer wrote:
On Sat, 3 Nov 2018 15:33:07 -0700
Jerry DeLisle wrote:
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 31198a3cc39..0d26101cef0 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -260,22
Committed as obvious. I had inserted this line to check effects of the
-fdec flags and forgot to delete it before my previous commit.
Author: jvdelisle
Date: Fri Nov 9 17:29:33 2018
New Revision: 265979
URL: https://gcc.gnu.org/viewcvs?rev=265979&root=gcc&view=rev
Log:
2018-11-0
On 11/11/18 7:59 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes both ICEs in the PR by adding some tests.
It was necessary to shuffle around a bit of code, plus to make sure that
double error reporting did not become too bad.
Regression-tested. OK for trunk?
Regards
Thoma
On 11/22/18 11:43 AM, Jakub Jelinek wrote:
On Thu, Nov 22, 2018 at 11:00:13AM +0100, Jakub Jelinek wrote:
Ok for trunk if it passes bootstrap/regtest (so far just checked with
make check-gfortran RUNTESTFLAGS='dg.exp=pad_source*'
)?
Note, it passed bootstrap/regtest on x86_64-linux.
OK, and
change log for the testsuite.)
Jerry
2018-11-24 Jerry DeLisle
PR libfortran/88052
* io/format.c (parse_format_list): Implement constraint which prohibits
missing commas between format specifiers unless -std=legacy is given.
diff --git a/gcc/testsuite/gfortran.dg/comma_format_extension_4.f
On 11/24/18 2:51 PM, Dominique d'Humières wrote:
Hi Jerry,
OK for trunk?
Could you give me some time to post some comments in bugzilla?
Sure, no rush.
TIA
Dominique
On 11/29/18 11:37 PM, Janne Blomqvist wrote:
PING!
LGTM,
OK and thanks
Jerry
(for the GCC-7 branch, I'll commit it after the 7.4 release)
On Thu, Nov 22, 2018 at 11:17 AM Janne Blomqvist
wrote:
From backtrace.h for backtrace_create_state:
Calling this function allocates resources
the job.
Also modified one test case and added a new to cover this in the testsuite.
Regression tested on x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-07-13 Jerry DeLisle
PR fortran/87233
* expr.c (check_restricted): Relax constraint C1279 which was
remo
Could not get the use of gfc_get_errors to work right, it missed one of the
errors in initialazation_30.f90. So I just did the deed.
Regards,
Jerry
Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ...
A gcc/testsuite/gfortran.dg/initialization_30.f90
M gc
On 7/17/19 8:32 PM, Steve Kargl wrote:
I will be away until Monday. Plenty of time for a review.
---snip --
Something not quite right here in this comment.
+/* A BOZ literal constant can appear in a limited number of contexts.
+ gfc_invalid_boz() is a help function to simplify error/war
On 2/20/19 2:34 PM, Harald Anlauf wrote:
There was a rather obvious bug in the logic for checking the arguments
to the OPEN statement when NEWUNIT= was specified, which prohibited
the generation of the appropriate error message.
Regtested successfully.
OK for trunk?
Yes and thanks for patch.
This patch is simple and obvious.
Regression tested on x86_64-pc-linux-gnu.
Test case attached. (Changelog for test case will be included)
I will commit tomorrow.
Regards,
Jerry
2019-02-23 Jerry DeLisle
PR fortran/84387
* trans-io.c (transfer_expr): Do not return if there
On 3/9/19 4:44 AM, Thomas König wrote:
Hello world,
the attached patch fixes the rest of PR 71203 (i.e. the non-character
parts). I have checked in gdb that the shape set with this patch
does indeed not create a memory leak.
Regression-tested. OK for trunk?
(This makes three patches that are c
On 2/28/19 12:14 PM, Thomas Koenig wrote:
Hello world,
the attached patch fixes a wrong-code bug for gfortran where pointers
were not marked as escaping. A C_PTR can be stashed away and reused
later (at least as long as the variable it points to remains active).
This is not a regression, but I
On 5/17/19 10:48 AM, Jeff Law wrote:
On 5/16/19 2:09 AM, Jakub Jelinek wrote:
Hi!
Fortran subroutines/functions that have CHARACTER arguments have also
hidden arguments at the end of the argument list which hold the string
length. This is something all Fortran compilers I've tried do and is
do
On 5/17/19 12:33 PM, Janne Blomqvist wrote:
--- snip ---
And yes, while I think one year might be a quite optimistic timeframe
to get this fixed, I agree we shouldn't keep the workaround
indefinitely either. I think the best way would be if CBLAS & LAPACKE
would be fixed, and then we could tell
namelist
data structures.
This patch fixes it.
Regression tested on x86-64 and manually tested with a redirection to
stdin. (cat somefile | ./a.out )
I plan to commit today as simple along with a new testcase.
Regards.
Jerry
2019-01-12 Jerry DeLisle
PR libfortran/88776
* io
On 1/12/19 2:35 PM, Jerry DeLisle wrote:
Hi all,
As stated in the PR, the problem turns out to be an ungraceful return
after an error. Most namelist errors go through nml_err_ret, The one I
am removing did not and in the unique case of UNIT=5 after the error it
falls through and hits some
On 1/19/19 7:05 AM, Thomas Koenig wrote:
Hello world,
the attached patch fixes handling of contiguous dummy arguments when
the actual arguments are not contiguous.
The patch to trans-expr.c itself was written by Paul and attached to
the PR. I just added the test case. Regression-testing reveal
Committed as simple and obvious. (With a ChangeLog Bobble fixed)
Regression tested on x86_64.
Committed r268301
M libgfortran/ChangeLog
M libgfortran/io/close.c
Regards,
Jerry
2019-01-26 Jerry DeLisle
PR libfortran/89020
* io/close.c (st_close
On 1/27/19 1:13 AM, Janne Blomqvist wrote:
On Sat, Jan 26, 2019 at 10:42 PM Jerry DeLisle
--- snip ---
Checking remove() for an error is a good idea, although speculating why
that happened might be confusing if the error happens for some other
reason? Particularly so on POSIX systems, where
The attached patch is straight-forward and self explanatory.
Regression tested on x86-64-pc-linux-gnu. Test case attached.
OK for trunk?
2019-01-31 Jerry DeLisle
PR fortran/52564
* io.c (match_io): Add check for comma after '*' without subsequent
IO l
On 2/12/19 10:22 PM, Martin Liška wrote:
PING^1.
On 2/4/19 1:46 PM, Martin Liška wrote:
On 2/4/19 10:56 AM, Martin Liška wrote:
Hi.
Starting from r266926 'switch (e->value.op.op)' is reached when
one using -fdec. That's wrong as -fdec causes to create a e->value.function.
I hope the proper fi
On 2/13/19 2:38 PM, Harald Anlauf wrote:
The attached patch moves the check for labeled DO statements to
the place where a label is referenced instead of where a label
was defined, which lead to false positives.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks Harald,
All OK with test
On 08/08/2016 04:01 AM, Janne Blomqvist wrote:
PING**2
OK, thanks for patch.
Jerry
On Sun, Jul 24, 2016 at 4:45 PM, Janne Blomqvist
wrote:
Hi,
the attached patch replaces the current random_number / random_seed
implementations with an implementation that better supports threads.
It's an i
Here is an additional test case demonstrating recursive calls.
Regards,
Jerry
! { dg-do run }
!
! Functional test of User Defined Derived Type IO.
!
! This tests recursive calls where a derived type has a member that is
! itself.
!
MODULE p
USE ISO_FORTRAN_ENV
TYPE :: person
CHARACTER (
On 08/26/2016 05:06 PM, Steve Kargl wrote:
--- snip ---
So, I've come up the following. We now need to debate whether
Dominiq's observations mean that C402 does not apply to named
constant.
See my comment in the PR. The standard gives the explicit way to accomplish what
the user wants to do
On 08/30/2016 08:00 AM, Janne Blomqvist wrote:
> On Mon, Aug 29, 2016 at 1:15 PM, Paul Richard Thomas
> wrote:
>> Hi Janne, Andre, Jerry and All,
>>
>> I am perfectly happy to adopt Janne's suggestion for
>> st_set_(dtio_)nml_var. Do the changes to the IO structures have any
>> impact? These are i
ed on x86-linux. New test case provided.
OK for trunk?
Regards,
Jerry
2016-08-31 Jerry DeLisle
PR libgfortran/77393
* io/write.c (kind_from_size): New function to calculate required buffer
size based on kind type. (select_buffer, select_string): Use new
fun
On 09/01/2016 03:25 AM, Andreas Schwab wrote:
> On Aug 31 2016, Jerry DeLisle wrote:
>
>> ! { dg-do run }
>> ! PR77393
>> program testbigf0 ! Can enormous numbers be printed with F0.0 format?
>> implicit none
>> character(1) :: str
>> write(st
tested on x86-64-linux. Test case attached.
OK for trunk?
Regards,
Jerry
2016-05-30 Jerry DeLisle
PR fortran/52393
* io.c (match_io): For READ, try to match a default character
expression. If found, set the dt format expression to this,
otherwise go back and
On 06/01/2016 12:25 AM, FX wrote:
>> 2016-05-30 Jerry DeLisle
>>
>> PR fortran/52393
>> * io.c (match_io): For READ, try to match a default character
>> expression. If found, set the dt format expression to this,
>> otherwise go back and
On 06/03/2016 12:40 PM, H.J. Lu wrote:
> On Wed, Jun 1, 2016 at 9:28 AM, Jerry DeLisle wrote:
>> On 06/01/2016 12:25 AM, FX wrote:
>>>> 2016-05-30 Jerry DeLisle
>>>>
>>>> PR fortran/52393
>>>> * io.c (match_io): For READ,
.
(changelog for test cases will be done of course)
OK for trunk?
Regards,
Jerry
2016-06-18 Jerry DeLisle
PR libgfortran/48852
* io/write.c: Cleaned up whitespace.
(write_d, write_e, write_f, write_es, write_en): Use new helper function
write_float_0. (write_float_0
I plan to commit this patch as obvious and simple.
Regression tested on x86-64. I will provide two test cases from the PR
Regards,
Jerry
2016-06-28 Jerry DeLisle
PR fortran/71686
* scanner.c (gfc_next_char_literal): Only decrement nextc if it
is not NULL.
diff
On 10/17/2017 11:33 AM, Paul Richard Thomas wrote:
> The attached patch has a comment that explains what is going on.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch?
>
Yes, looks OK for both. Thanks.
Jerry
On 10/15/2017 11:09 AM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes a regression by turning an ICE-on-invalid into
> an error message (and making sure that it fits).
>
> Regression-tested on trunk.
>
> OK for all affected branches (8/7/6)?
>
Yes, OK, thanks.
Jerry
On 10/17/2017 03:36 PM, Thomas Koenig wrote:
> Hello world,
>
> this patch fixes a regression with long compile times,
> which came about due to our handling of array constructors
> at compile time. This, togeteher with a simplification in
> front end optimization, led to long compile times and l
On 10/20/2017 11:55 AM, Paul Richard Thomas wrote:
> Dear All,
>
> In the last hour, I have added fixes for PRs 82587 and 82589. Please
> review them together with 82586.
>
> I will stop work on Gerhard's PDT bugs until this patch is committed.
> Fortunately, Steve Kargl has proposed fixes for mo
On 10/20/2017 12:17 PM, Steve Kargl wrote:
> On Fri, Oct 20, 2017 at 07:55:17PM +0100, Paul Richard Thomas wrote:
>>
>> In the last hour, I have added fixes for PRs 82587 and 82589. Please
>> review them together with 82586.
>>
>> I will stop work on Gerhard's PDT bugs until this patch is committed
On 10/21/2017 11:17 AM, Bernhard Reutner-Fischer wrote:
> On 21 October 2017 at 02:26, Damian Rouson
> wrote:
>>
>> Hi Richard,
>>
>> Attached is a revised patch that makes the downloading of Fortran
>> prerequisites optional via a new --no-fortran flag that can be passed to
>> contrib/download
On 10/26/2017 12:20 PM, Andre Vehreschild wrote:
> Hi Paul,
>
> Without having tested the patch, it looks reasonable to me. So ok from my
> side.
>
> - Andre
>
Seconded, thanks.
Jerry
On 07/11/2017 07:23 AM, Paul Richard Thomas wrote:
> Well, a bit earlier than anticipated, here is the final version that
> puts right all the wrinkles that I know about.
>
> Bootstraps and regtests - OK for trunk?
>
> Paul
Somewhere in the threads on this, there was mentioned ABI breakage/chang
On 07/23/2017 04:27 AM, Thomas Koenig wrote:
> Hello world,
>
> in PR 66102, I found a patch by Mikael which has never been applied.
> After dusting it off, finding that it looks reasonable and fixes
> the test case in question I'd like to apply this.
>
> Regression-tested. OK for trunk?
>
OK,
On 07/30/2017 11:55 AM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch performs a runtime-check for the dim arguments
> for transformational intrinsic functions.
>
> I debated with myself a bit if I should make this depend on
> bounds checking, but I finally decided against it. The t
Looks OK, thanks.
Jerry
On 08/04/2017 12:32 PM, Thomas Koenig wrote:
> Am 04.08.2017 um 14:09 schrieb Thomas Koenig:
>> Hello world,
>>
>> the attached patch
>
> This time, really attached, even with ChangeLog!
>
> Regards
>
> Thomas
>
> 2017-08-04 Thomas Koenig
>
> PR fortran
On 08/13/2017 10:35 AM, Thomas Koenig wrote:
the attached patch fixes the PR by adding a dependency check
for the case of concatenation operators.
Regression-tested. OK for trunk?
Ping?
Regards
Thomas
OK,
Thanks for patch.
Jerry
significant change in performance.
Regression tested on x86_64-linux. No new test case.
OK for trunk and then I think this should be backported to 7.
Regards,
Jerry
2017-08-20 Jerry DeLisle
PR libgfortran/78387
* io/list_read.c (nml_read_obj): Remove use of stash.
* io
?
Regards,
Jerry
2017-08-21 Jerry DeLisle
PR fortran/81296
* trans-io.c (get_dtio_proc): Add check for format label and set
formatted flag accordingly. Reorganize the code a little.
diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index c3c56f29..aa974eb3 10
On 08/26/2017 11:24 AM, Thomas Koenig wrote:
> Hello world,
>
> to relieve the boredom on the fortran mailing list and to fix
> a regression I thought I'd submit a patch :-)
>
> Apparently, a call to CONJG wasn't picking up the right
> typespec, which led to an ICE with gimplification later.
>
>
ping - I will commit if I hear no objections.
Jerry
On 08/19/2017 10:12 PM, Jerry DeLisle wrote:
> Hi all,
>
> I have decided to simply delete the internal unit stack altogether.
>
> The original intent was to save time with internal unit I/O by avoiding
> reallocating a
On 05/05/2017 01:31 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch reduces the stack usage by the blocked
> version of matmul for cases where we don't need the full buffer.
> This should improve stack usage.
>
> Regression-tested. I also added a stress test (around 3 secs of
> CP
On 05/07/2017 11:37 PM, Janne Blomqvist via fortran wrote:
> PING
>
> On Thu, Apr 27, 2017 at 9:55 PM, Janne Blomqvist
> wrote:
>> On Thu, Apr 27, 2017 at 9:50 PM, Janne Blomqvist
>> wrote:
>> [snip]
>>
>> And on top of that patch this simple typo fix:
>>
>> diff --git a/libgfortran/runtime/envi
On 05/08/2017 12:29 PM, Thomas Koenig wrote:
> Am 08.05.2017 um 18:58 schrieb Jerry DeLisle:
>
> he attached patch reduces the stack usage by the blocked
>>> version of matmul for cases where we don't need the full buffer.
>>> This should improve stack usage.
&g
On 05/08/2017 02:16 PM, Janus Weil wrote:
> Hi all,
>
> the attached patch fixes an ICE-on-valid problem with finalization by
> making sure that the finalization procedures are properly resolved.
>
> In the test case, the finalizer of the component type was not being
> resolved if the superordina
On 05/09/2017 08:37 AM, Fritz Reese wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80668
>
> All,
>
> The following fixes a bug exposed in PR 80668 in which the compiler
> attempted to generate an initializer for components of derived types
> with the POINTER attribute when compiling with
.
Several new test cases added. Regression tested on x86-64.
OK for trunk. I would like to recommend back porting to 7 after allowing some
time for testing.
Regards,
Jerry
2017-05-11 Jerry DeLisle
PR fortran/78659
* io.c (dtio_procs_present): Add new function to check for
And the actual patch ...
On 05/11/2017 08:30 AM, Jerry DeLisle wrote:
Hi all,
The attached patch fixes this issue by moving the DTIO namelist checks from
namelist resolution to READ/WRITE statement resolution. This allows the checks
to be specific to the io_kind. The dtio_procs_present
On 05/13/2017 04:06 AM, Dominique d'Humières wrote:
> Dear Jerry,
>
>> And the actual patch ...
>
> Are you sure this the right patch? It seems mostly applied on trunk.
>
> TIA
>
> Dominique
>
> PS I saw some ‘return 1;’ which should probably ‘return true;’
>
>
When I moved the checks over
On 05/13/2017 04:56 AM, Nicolas Koenig wrote:
> Ping
> Also, attached is a better test case.
>
>
> On 05/09/2017 10:49 PM, Nicolas Koenig wrote:
>> Hello everyone,
>>
>> since everybody seems to be submitting patches the last few days, I thought I
>> might as well :)
>> Attached is a patch that m
)
Regards,
Jerry
2017-05-15 Jerry DeLisle
PR libgfortran/80727
* transfer.c (read_sf_internal): Remove bogus code to detect EOR.
(read_block_form): For internal units, generate EOR if no more
bytes left in unit and we are trying to read with ADVANCE='NO'.
On 05/15/2017 04:10 AM, Paul Richard Thomas wrote:
The attached bootstraps and regtests on FC23/x86_64 - OK for trunk and
later for 7-branch?
The comment in the patch and the ChangeLog are sufficiently clear that
no further explanation is needed here.
Looks OK Paul, thanks,
Jerry
On 05/15/2017 03:51 PM, Steve Kargl wrote:
> On Mon, May 15, 2017 at 01:10:43PM -0700, Jerry DeLisle wrote:
>>
>> 2017-05-15 Jerry DeLisle
>>
>> PR libgfortran/80727
>> * transfer.c (read_sf_internal): Remove bogus code to detect EOR.
>>
for trunk and then back port to 7 in about a week?
Regards,
Jerry
2017-05-16 Jerry DeLisle
PR fortran/80741
* trans-io.c (transfer_namelist_element): Change check from
NULL_TREE to null_pointer_node.
2017-05-16 Jerry DeLisle
PR libgfortran/80741
o get that address.
(transfer_namelist_element): Set the array spec to point to the
the class data.
2017-05-18 Paul Thomas
Jerry DeLisle
PR fortran/80333
* list_read.c (nml_read_obj): Compute pointer into class/type
arrays from the nl->di
On 05/18/2017 07:06 PM, Steve Kargl wrote:
On Thu, May 18, 2017 at 05:16:45PM -0700, Jerry DeLisle wrote:
2017-05-18 Paul Thomas
PR fortran/80333
* trans-io.c (nml_get_addr_expr): If we are dealing with class
type data set tmp tree to get that address
On 05/21/2017 09:14 AM, Janus Weil wrote:
Hi all,
the attached patch fixes an ICE-on-valid regression by making sure
that the relevant vtype symbol is resolved properly (for further
discussion see the PR).
The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk and 7-branch?
Cheers,
Janus
On 05/17/2017 02:41 PM, Thomas Koenig wrote:
> Hello world,
>
> after receiving no negative feedback on my RFC patch, I have deciced
> to submit the patch.
>
> The attached patch handles MATMUL(TRANSPOSE(A),B) in inlining matmul.
> Speed is a bit faster than the library version.
>
> Regression-t
On 05/25/2017 03:45 AM, Thomas Koenig wrote:
Hello world,
the attached patch speeds up the library version of matmul for AMD chips
by selecting AVX128 instructions and, depending on which instructions
are supported, either FMA3 (aka FMA) or FMA4.
Jerry tested this on his AMD systems, and found
On 05/25/2017 10:20 AM, Janne Blomqvist wrote:
On Thu, May 25, 2017 at 1:45 PM, Thomas Koenig wrote:
Hello world,
the attached patch speeds up the library version of matmul for AMD chips
by selecting AVX128 instructions and, depending on which instructions
are supported, either FMA3 (aka FMA)
On 05/25/2017 02:57 PM, Thomas Koenig wrote:
Hi everybody,
I have committed the patch (with the corrections for the name)
as rev 248472.
The infrastructure is in place, so we will be able to make
any fine-tuning easily.
Regards
Thomas
Based on my testing I think it is close enough as i
On 05/27/2017 12:49 PM, Nicolas Koenig wrote:
Hello everyone,
attached is a patch to simplify implied do loops in io statements by replacing
them with their respective array slices. For example "WRITE (*,*) (a(i),
i=1,4,2)" becomes "WRITE (*,*) a(1:4:2)".
Ok for trunk?
Thanks for patch. C
On 05/28/2017 02:40 PM, Thomas Koenig wrote:
Hello world,
the attached patch generates some more opportunities for matmul inlining
by creating temporaries if arguments overlap, if the return is from
a function or something similar.
With this, we are pretty much coming to the end of the matmul
o
led.
Regression tested on x86_64. I have added a test case which will check the
execution time of the loop. The previous results of the REAd were correct, just
took a long time on large arrays.
OK for trunk?
Regards,
Jerry
2017-05-28 Jerry DeLisle
PR libgfortran/35
On 05/29/2017 09:51 AM, Thomas Koenig wrote:
Hi Jerry,
Regression tested on x86_64. I have added a test case which will check the
execution time of the loop. The previous results of the REAd were correct,
just took a long time on large arrays.
OK for trunk?
OK.
It might be good if you fol
On 06/03/2017 06:48 AM, Nicolas Koenig wrote:
> Hello everyone,
>
> here is a version of the patch that includes a workaround for PR 80960. I have
> also included a separate test case for the failure that Dominique detected.
> The
> style issues should be fixed.
>
> Regression-tested. OK for tru
On 06/05/2017 02:52 AM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch moves the zeroing of the result variable before the
> early return. This is done so that the result for zero-sized arguments
> is still valid.
>
> The bug was only in the library version, but I have also added a te
On 01/12/2017 03:45 AM, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes the ICE when using an event in a subroutine. The reason
> for the ICE was that the backend_decl of the symbol to event on was not set
> when accessed. The patch ensures this. Furthermore did I fix a invalid memory
On 01/12/2017 05:43 AM, Andre Vehreschild wrote:
> Hi all,
>
> *** this is no duplicate, but +1 in the PR#! ***
>
> attached patch fixes the ICE by resolving the expression in UNTIL_COUNT
> correctly. The ICE was caused by the array-specification in UNTIL_COUNT not
> correctly set.
>
> Bootstrap
On 01/13/2017 11:46 AM, David Edelsohn wrote:
> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
> wrote:
>> On Thu, Jan 12, 2017 at 10:46 AM, FX wrote:
I was finally able to get a 32-bit i686 compiler going (my attempts to
do this on a x86_64-pc-linux-gnu host failed, in the end I res
On 01/14/2017 12:46 AM, Janne Blomqvist wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>> wrote:
>>>> On Thu, Jan 12, 2017 at 10:46 AM,
On 01/18/2017 04:26 AM, Andre Vehreschild wrote:
Hi all,
the patch I proposed for this pr unfortunately did not catch all errors.
Dominique figured, that the original testcase was not resolved (thanks for
that).
This patch resolves the linker problem by putting the static token into the
parent
On 01/18/2017 06:46 AM, Andre Vehreschild wrote:
Hi all,
this patch adds undocumented parameters to caf-API functions and fixes the
documentation style in many parts of the caf-API functions. It intentionally
does not fix the last paragraph in the caf-API function's section (co_reduce),
because
On 01/18/2017 08:54 AM, Andre Vehreschild wrote:
Hi all,
during discussing some other functionality in the caf-library, it occurred to
me that gfortran is adding a caf_sync_all()-call when allocating only
allocatable or pointer components of derived typed coarrays. The attached patch
fixes the b
directed I/O we are eating the first character for some reason. I will keep
working on this issue.
In the meantime, the attached patch and test cases, regression tested on
x86_64-linux.
OK for trunk?
Jerry
2017-03-21 Jerry DeLisle
PR libgfortran/78881
* io/transfer.c (read
Hi all,
I managed to figure out the rest of this.
Attached is updated full patch. I consolidated the two previous test cases into
one which checks all four conditions I was concerned with.
Regression tested on x86_64_linux.
Ok for trunk?
Regards,
Jerry
2017-03-25 Jerry DeLisle
201 - 300 of 561 matches
Mail list logo
