This simple patch kindly provided by Marco solves the problem.
Regression tested on x86_64-Linux, Test case provided also.
OK to commit to trunk?
Jerry
2016-07-14 Jerry DeLisle
Marco Restelli
PR fortran/62125
* symbol.c (select_type_insert_tmp): Recursively call
Hi,
this patch fixes a recently discovered name-clash in gfc_build_class_symbol.
Fortunately it is quite easy to fix: just make sure that the class names of
target
classes end with "_t", and target array classes end with "[0-9]t".
This trick makes all names unique again.
I hope it is not too la
Dear all,
the following code produces a wrong invocation to libcaf for
caf_atomic_op (atomic_add):
program atomic
use iso_fortran_env
implicit none
integer :: me
integer(atomic_int_kind) :: atom[*]
me = this_image()
call atomic_define(atom[1],0)
sync all
call ATOMIC_ADD (atom[1], me)
if(me == 1)
Hello world,
the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?
Thomas
2011-05-06 Thomas König
* frontend-passes.c (optimize_assignment): Follow chains
of concatenation operators to the en
Thanks, your suggestion fixes the problem.
I just noticed that I missed the subject description; I'll send the
new patch in a different email.
2014-09-08 15:50 GMT-06:00 Tobias Burnus :
> Alessandro Fanfarillo wrote:
>
> the following code produces a wrong invocation to libcaf for
> caf_atomic_op
First, I have another pending patch, cf:
http://gcc.gnu.org/ml/fortran/2011-07/msg00142.html
The attached patch adds diagnostic in the case that a use-associated
symbol is the same as the current procedure/module name. Besides typos,
that either indicates the use of the wrong procedure (which i
While trying to clean up my working copy, I found that the trivial
patch for the ICE-on-invalid as described in the PR regtests cleanly
for 7-release on i686-pc-linux-gnu.
Here's the cleaned-up version (diffs attached).
2017-05-04 Harald Anlauf
PR fortran/70071
* array.c (gfc
Committed to master as obvious.
Thanks,
Harald
Fortran texi: Fix description of GFC_RTCHECK_* macros.
gcc/fortran/ChangeLog:
* gfortran.texi: Fix description of GFC_RTCHECK_* to match actual
code.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 453b30
Fortran: Enable inquiry references in data statements [PR98022].
This patch speaks for itself.
Regtests on FC31/x86_64 - OK for master?
Paul
2020-12-12 Paul Thomas
gcc/fortran
PR fortran/98022
* data.c (gfc_assign_data_value): Handle inquiry references in
the data statement object list.
gc
I found this 'obvious' fix, while going through PRs assigned to me.
Regtests. OK for mainline?
Cheers
Paul
Fortran: Allocatable automatic charlen must not be saved [PR64120].
2023-10-31 Paul Thomas
gcc/fortran
PR fortran/64120
* trans-decl.cc (gfc_trans_deferred_vars): Detect automatic
ch
Hi All,
The attached fixes a problem that, judging by the comments, has been looked
at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placeme
Hi,
this test case fails very often, and the reason is not in GCC but
in a missing glibc rounding support for strtod.
This patch fixes the test case, to first determine if the
rounding support is available. This is often the case for real(16)
thru the libquadmath. So even in cases where the test
l_push_char allocates memory which is freed with free_line. However,
currently, the memory is not always freed when calling generate_error.
If one aborts, that's fine. However, generate_error can also set the
iostat variable. Thus, one should ensure that the memory is always freed.
I wouldn't
Hello world,
this patch makes sure that the __def_init variables, which have been
generated for normal allocatable arrays for quite some time, do not fill
up huge amounts of space in the object files with zeros. This is done by
not marking them read-only, which means that they are put into the BS
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 (using the same error messages that the
library does),
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).
The surprising thing was that the current code generated for the
array descriptor for
subroutine foo(a, b, n, m)
integer
Hi all,
this patch fixes Alan's issue with IMPLICIT followed by ";". I am not
sure whether using the _eos machinery is really needed – especially as
"!" seem to be already handled.
Additionally, I missed the inner "[...]" for the new:
R563 implicit-stmt is IMPLICIT implicit-spec-list
This patch adds some more checks and the actual implementation (compiler
side and libcaf_single) for CO_REDUCE. It also rejects coindexed
variables elsewhere, in line with the recent J3 changes. I also updated
the API documentation (adding doc for collectives.)
Still unsupported as elsewhere a
This patch moves -Wtabs closer to the common diagnostics - and changed
the odd reversed logic of flags = 0 meaning off.
This brings nice common diagnostic features to fixed-form source code
for the initial indentation [tab = 6 spaces] (which doesn't show a
location), but not to free-form sourc
This patch depends on Manuel's %L patch.
It converts the remaining fatal error calls to the common diagnostic
infrastructure and retires (removes) the old gfc_fatal_error_1.
I will build and regtest it after Manuel's commit.
OK, when it succeeds?
Tobias
2014-11-23 Tobias Burnus
* error.c
Hello world,
Merry Christmas everybody!
This patch resolves one of the remaining F95 bugs by introducing a
temporary for the case
c(:)(1:2) = c(2)(2:3)
It does have the disadvantage that
c(:)(1:2) = c(2)(3:4)
now also creates an unnecessary temporary because gfc_check_dependency
is not smart
Jakub,
For the oacc kernels patch series I need a fortran builtin with fn spec
attribute (as mentioned here: https://gcc.gnu.org/ml/gcc/2014-12/msg1.html ).
Attached patch adds a function gfc_define_builtin_with_spec that allows me to
define such a builtin.
At this point there's no user
This patch adds a CO_BROADCAST and prepares a bit for CO_REDUCE.
Both functions permit arguments with allocatable components
(nonpolymophic or polymorphic), CO_BROADCAST also permits polymorphic
arguments. This patch doesn't support allocatable/polymorphic arguments
but otherwise CO_BROADCAST
This patch adds run-time support for the RANK intrinsic. That's
currently a bit pointless as the rank is known at compile time and,
thus, the new code is unreachable as simplify.c handles it.
However, it becomes useful for assumed-rank arrays ("dimension(..)") of
TS 29113. I tested it by disab
Am 17.07.2011 20:30, schrieb Tobias Burnus:
Build and regtested on x86-64-linux?
If you say so :-)
OK for the trunk?
Actually, I am not 100% sure whether I need approval as Thomas already
gave kind of an approval in the PR.
Well, to remove any doubt: Yes.
Thanks for the patch!
Th
Thomas Koenig:
Am 17.07.2011 20:30, schrieb Tobias Burnus:
Build and regtested on x86-64-linux?
If you say so :-)
Well, I thought you had tested the patch :-)
(I had also regtested it successfully. By the way the "?" and the
incomplete subject shows that one shouldn't click on "sent" while
Dear all,
(First, this is *not* for the 4.6/4.7 rejects-valid regression, which is
related to intent(in) pointers with allocatable components.)
When debugging an issue with with polymorphic arrays and MOVE_ALLOC, I
got lost in the code generation of move_alloc - and didn't like the
generated
After a lengthy debugging, I finally found the issue. If I hadn't be
concentrating that much on -fwhole-file and if I had had a closer look
at the test case before, I hadn't wasted hours tracking this one down ...
The problem is that a procedure pointer is used for the "interface" of a
procedu
Hi,
since some time GCC has BUILT_IN_IROUND{F,,L}, similar to lround() and
llround() but the result is returned as an integer. As there is no
corresponding libc function, this builtin is expanded to lround{f,l}
except when -ffast-math is used, in which case it enables slightly
shorter and faster c
On Thu, May 04, 2017 at 05:26:17PM +0200, Harald Anlauf wrote:
> While trying to clean up my working copy, I found that the trivial
> patch for the ICE-on-invalid as described in the PR regtests cleanly
> for 7-release on i686-pc-linux-gnu.
>
> Here's the cleaned-up version (diffs attached).
>
>
On 05/04/17 18:15, Steve Kargl wrote:
> On Thu, May 04, 2017 at 05:26:17PM +0200, Harald Anlauf wrote:
>> While trying to clean up my working copy, I found that the trivial
>> patch for the ICE-on-invalid as described in the PR regtests cleanly
>> for 7-release on i686-pc-linux-gnu.
>>
>> Here's th
The patch below has not been applied to the best of my knowledge.
Just a reminder for whoever cares.
Harald
On 05/04/17 20:19, Harald Anlauf wrote:
> On 05/04/17 18:15, Steve Kargl wrote:
>> On Thu, May 04, 2017 at 05:26:17PM +0200, Harald Anlauf wrote:
>>> While trying to clean up my working co
On Tue, Oct 31, 2023 at 02:11:08PM +, Paul Richard Thomas wrote:
> I found this 'obvious' fix, while going through PRs assigned to me.
>
> Regtests. OK for mainline?
>
Yes. Fell free to backport if you have time and desire.
--
Steve
Hi All,
I have extended the testcase - see below and have
s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.
Cheers
Paul
! { dg-do run }
!
! Fix for PR59104 in which the dependence on the old style function result
! was not taken into account in the ordering of auto array allocation a
Hi Paul,
your approach sounds entirely reasonable.
But as the following addition to the testcase shows, there seem to
be loopholes left.
When I add the following to function f:
integer :: l1(size(y))
integer :: l2(size(z))
print *, size (l1), size (l2), size (z)
I g
Hi Harald,
Thanks for the loophole detection! It is obvious now I see it, as is the
fix. I'll get on to it as soon as I find some time.
Cheers
Paul
On Sun, 9 Jun 2024 at 21:35, Harald Anlauf wrote:
> Hi Paul,
>
> your approach sounds entirely reasonable.
>
> But as the following addition to
Hi Paul,
while looking at your patch I see calls to gfc_add_init_cleanup (..., back),
while the function signature is gfc_add_init_cleanup (..., bool front). This
slightly confuses me. I would at least expect to see gfc_add_init_cleanup(...,
!back) calls. Just to get the semantics right.
Then I w
Hi Both,
Thanks for the highly constructive comments. I think that I have
incorporated them fully in the attached.
OK for mainline and ...?
Paul
On Mon, 10 Jun 2024 at 08:19, Andre Vehreschild wrote:
> Hi Paul,
>
> while looking at your patch I see calls to gfc_add_init_cleanup (...,
> back)
Hi Paul,
to me this looks fine. Thanks for the patch. Me having been away for some time
from gfortran, I recommend you wait for Harald's ok, too.
Regards,
Andre
On Thu, 13 Jun 2024 22:43:03 +0100
Paul Richard Thomas wrote:
> Hi Both,
>
> Thanks for the highly constructive comments. I t
Hi Paul,
this looks good to me and is OK for mainline. When it has survived a
week or two, backporting at least to 14-branch (ideally before 14.2
release) would be a good thing!
Regarding the following excerpt of the testcase:
+! Commented out lines give implicit type warnings with gfortran an
Bernd Edlinger wrote:
this test case fails very often, and the reason is not in GCC but
in a missing glibc rounding support for strtod.
This patch fixes the test case, to first determine if the
rounding support is available. This is often the case for real(16)
thru the libquadmath. So even in ca
On Wed, 25 Sep 2013 21:00:33, Tobias Burnus wrote:
>
> Bernd Edlinger wrote:
>> this test case fails very often, and the reason is not in GCC but
>> in a missing glibc rounding support for strtod.
>>
>> This patch fixes the test case, to first determine if the
>> rounding support is available. This
Hi all,
attached is a cleanup patch which concerns the gfc_code structure and
gfc_get_code function (in st.c). It basically does two things:
1) It replaces the many occurrences of "XCNEW (gfc_code)" in class.c
by "gfc_get_code ()", which internally sets the locus and saves us
from doing it manual
First, I am woefully aware that there several patches pending. I hope to do a
couple of reviews later today or in the next days.
Otherwise, I did run into another issue in existing code which was exposed by
the delinearization patch on the OG12 branch, but could potentially lead to
wrong code on
Found when looking at Sandra's c535b-1.f90 and playing around.
When fixing same_type_as, I spotted by code reading another issue,
related to not catering for derived types. (Untested whether it
failed indeed.)
I added now a bunch of testcases.
OK for mainline?
Tobias
-
Siemens
Hello world,
here is a patch for simplifying eoshift. Along the way, I discovered
two ICEs caused by wrong arguments to eoshift, which are now also
caught by new checks and a corresponding test case.
This already passed all of the *eoshift* tests and is
regression-testing as I write this. OK if
The attached patch removed an unused function.
OK to commit?
2018-05-10 Steven G. Kargl
* gfortran.h: Remove prototype.
* symbol.c (gfc_new_undo_checkpoint): Remove unused function.
--
Steve
Index: gcc/fortran/gfortran.h
=
Changes:
- Remove (not working) critical functions; a normal coarray of LOCK type
should be used instead. (Stub left in until it is removed the the front
end.)
- Added prototypes and stub implementations for
registering/deregistering coarray (currently unused).
- Small bug fixes.
OK for th
Hello world,
the attached patch fixes PR 48066, a regression introduced way back
when. It is pretty self-explanatory. Regression-tested.
OK for trunk?
Also OK for a 4.5 backport?
Thomas
2011-03-12 Thomas Koenig
PR libfortran/40866
* m4/ifunction.m4: If return
Hello world,
the attached patch is a front-end optimization which replaces multiple
calls to a function with identical argument lists with an assignment to
a temporary variable, and then uses that variable in the original
expression.
AFAIK, this is permitted by the Fortran standard because s
Hello world,
this patch fixes the performance regression introduced with
the fix for 71783. It also corrects an error in the logic
in realloc_string_callback by now checking if the experssion
is deferred, instead of checking for the symbol having the
allocatable attribute (which led to false pos
The bug in PR70289 is an assertion failure triggered by a static
variable used inside an offloaded acc region which doesn't have a data
clause associated with it. Basically, that static variable ends up in a
different lto partition, which was not streamed to the offloaded
compiler. I'm not sure if
Hello world,
this patch fixes the regression by always allocating a charlen.
Why we still allocate a temporary even for obviously non-overlapping
cases like the test case remains to be investigated. I'll open a
separate PR for this.
Regression-tested. OK for all affected branches?
Regards
Hello world,
this rather self-explanatory patch fixes a problem where two
function invocations with 'c' and 'c' as arguments
were considered equal.
Regression-tested. OK for trunk and 6 and 5 branches?
Regards
Thomas
2016-10-22 Thomas Koenig
PR fortran/78021
*
Hello world,
the attached, rather simple, patch, fixes a regression where
the locus was not set, leading to an ICE on a warning.
Regression-tested on trunk. OK on all affected and open branches
(7/6/5)?
Regards
Thomas
2016-11-01 Thomas Koenig
PR fortran/69544
* mat
Here's the fix and a test case for the regression PR 71047 introduced
by the DEC STRUCTURE/UNION patch (commit 235999).
Turns out I was a bit greedy about adding component refs to structure
constructors in gfc_default_initializer. Fixed to only add them to
FL_STRUCTURE and FL_UNION symbols, which
Hello world,
this patch fixes a 9/10 regression by placing the variable used to
hold a string length at function scope.
I chose to implement this version of gfc_evaluate_now as a separate
function because I have a sneaking suspicion this may not be the
last time we are going to encounter somethi
Hello world,
this patch fixes PR 91443, in which we did not warn about a mismatched
external procedure. The problem was that the module this was called in
was resolved before parsing of the procedure ever started.
The approach taken here is to move the checking of external procedures
to a stage
Hello world,
this patch fixes the 9 regression in C interop with contiguous
arguments recently reported by Reinhold Bader.
ChangeLog and patch say it all. I hope I didn't overlook any
obvious things here (Paul, maybe you can take a look).
Regression-tested. OK for trunk?
Regards
Thom
Hello world,
this patch fixes a rejects-valid 7/8/9 regression where subroutines like
_deallocate are added to a derived type in a block data, and because
they were marked PRIVATE, an error occurred.
This solution is look for this particular case by checking for an
underscore as the first letter
Hello world,
the PR pointed out an old regression because the front-end optimization
pass was substituting 2**n with ishift(1,n), where n was an array.
Simply removing the optimization for that case would have been easy,
but also introduced a performance regression.
So, for this, I moved the op
Hello world,
the attached pach does some more work in gfc_check_dependency for
the case where an identity between arguments would also lead
to problems.
It does not lead to removal of the warning with -Warray-temporaries,
because that is still generated by the call to library function.
Instead,
Hello world,
the attached patch fixes PR 90813, a regression with proc pointers.
The problem was quite complex, and I'd like to thank the people
who helped debug this; the most important clue came from Richard.
The problem was that, for a procedure pointer variable declared
in a module in the sa
Hello world,
the attached patch fixes the PR by not trying to determine the length
of the base symbol when there is a substring with a length which
is not constant. This might make the length of temporary strings
generated by the front end optimization pass shorter, while inserting
an additional
Hello world,
the attached patch fixes an error where TYPE(*) ended up in a vtab,
with not-so delectable results. The solultion is simple - do not
create a vtab if the actual argument is TYPE(*).
This also clears the ICE for my inline packing patch which
was reported by Dominique.
Regression-te
Hello world,
this new version of the inlie argument packing patch (PR 88821)
avoids the ICE on the test case for PR 61968. Otherwise it is
unchanged.
Regression-tested. OK for trunk?
Regards
Thomas
2019-05-11 Thomas Koenig
PR fortran/88821
* expr.c (gfc_is_simply_c
On Wed, Sep 25, 2019 at 10:24:51PM +0200, Thomas Koenig wrote:
>
> this patch makes sure that the __def_init variables, which have been
> generated for normal allocatable arrays for quite some time, do not fill
> up huge amounts of space in the object files with zeros. This is done by
> not markin
Hi,
Jakub, do you have any comments? After Seve's OK I plan to commit in a
couple of days unless I read anything to the contrary.
Regards
Thomas
this patch makes sure that the __def_init variables, which have been
generated for normal allocatable arrays for quite some time, do not fi
Hello world,
the attached patch builds on a long history: Tobias Burnus created
an original version in 2012. Harald Anlauf recently picked it up,
(see https://gcc.gnu.org/ml/fortran/2019-01/msg00012.html).
polished it and made it ready for gcc-9. This already worked
quite well. I added a bit o
Hello world,
the attached patch fixes a missed optimization where a substring equal
in length to the original variable currently leads to an unneeded
temporary.
Regression-tested. OK for trunk?
Regards
Thomas
2019-01-15 Thomas Koenig
PR fortran/43072
* resolve.c (r
Hello world,
the attached patch fixes PR 88871, a regression introduced by
my recent patch for removing unnecessary substrings.
Regression-tested; this now also works with valgrind on Linux,
where the failure did not show up otherwise.
No test case because, well - it did show up on a few system
Hello world,
let the regression hunt continue!
the attached patch fixes a long-time regression where a c_funptr from a
module could not be found.
The solution is a bit of a hack, but so is our whole implementation of
the C interop stuff.
Regression-tested. OK for trunk?
Regards
Thoma
Hi,
the attached patch fixes a 7/8/9 regression where a conversion warning
was emitted for DIM. The problem was that the no-warn flag had not been
passed down to the arithmetic conversion routines, which is solved here
by adding and using a flag in gfc_expr.
Regression-tested. OK for affected
Hello world,
this patch fixes a 7/8/9 regression where we tried to accept invalid
code, which led to an ICE later on.
The patch is rather straightforward. The reason why I could not
use gfc_expr_attr is that it does not actually return the
flags the way they can be found in the original attribu
Hello,
I submit the PR64921 fix I posted two days ago on bugzilla.
The problem comes from the finalization wrapper not having the
always_explicit attribute set, so that when it is called, the array
argument is passed without descriptor, but the argument declaration is a
descriptor array. Boom
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 check
I have played a little bit with the patched gfortran.
(1) gfortran.dg/coarray_lib_this_image_2.f90 is still failing
FAIL: gfortran.dg/coarray_lib_this_image_2.f90 -O scan-tree-dump-times
original "mylbound = parm...dim\\[0\\].stride >= 0 && parm...dim\\[0\\].ubound
>= parm...dim\\[0\\].lbou
Hi!
On Fri, 9 Jan 2015 16:37:00 +0100, Tom de Vries wrote:
> For the oacc kernels patch series I need a fortran builtin with fn spec
> attribute (as mentioned here:
> https://gcc.gnu.org/ml/gcc/2014-12/msg1.html ).
>
> Attached patch adds a function gfc_define_builtin_with_spec that allows
Hello Mikael and Dominique,
thanks for your helpful comments!
> To sum um, tests missing for the following:
> array(4,:,:)
> array(3:5,:)
> array(3:10:2,:)
> array(:,:)%comp
> with both lbound == 1 and lbound != 1.
> One test with lhs-rhs dependency would be good as well.
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 po
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 of ARRAY has nonzero extent,
> LBOU
Hello world,
here is a slight correction: This patch includes the change to
the test case.
Regards
Thomas
Index: fortran/simplify.c
===
--- fortran/simplify.c (Revision 222431)
+++ fortran/simplify.c (Arbeitskopie)
@@ -344
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 dime
This patch changes the coarray/coindexed check to match what the error
message already claimed.
OK for the trunk?
Tobias
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 3be4fb1..cdb5ff1 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -1022,7 +1022,7 @@ gfc_check_atomi
I have no idea if this is actually correct, but it restores bootstrap.
OK to commit?
2015-11-22 Steven G. Kargl
* openmp.c (match_oacc_clause_gang): Fix bootstrap.
Index: openmp.c
===
--- openmp.c(revision 230723)
++
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_A
On Mon, Apr 27, 2015 at 11:45 AM, Thomas Koenig wrote:
> 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
Hi Mikael,
Looks good.
In general, it is better to restrict changes to existing test cases to
the necessary minimum that they still pass, and add new code to new
test cases. This makes regressions easier to track.
So, OK with that change.
Thomas
Hello world,
this patch fixes the regression in PR 66041, plus one more case
that came up when I looked at this.
OK for trunk?
Regards, Thomas
2015-05-08 Thomas Koenig
PR fortran/66041
* frontend-passes.c (scalarized_expr): Clear as->start, as->end
and as->st
Le 03/05/2015 22:38, Thomas Koenig a écrit :
> Hi Mikael,
>
> Looks good.
>
> In general, it is better to restrict changes to existing test cases to
> the necessary minimum that they still pass, and add new code to new
> test cases. This makes regressions easier to track.
>
> So, OK with that c
On Sun, May 10, 2015 at 6:58 AM, Mikael Morin wrote:
> Le 03/05/2015 22:38, Thomas Koenig a écrit :
>> Hi Mikael,
>>
>> Looks good.
>>
>> In general, it is better to restrict changes to existing test cases to
>> the necessary minimum that they still pass, and add new code to new
>> test cases. Th
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 that error message, I got it when develo
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
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 could have.
> However, without a better idea
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-ef
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?
Regards
Thomas
2015-05-12 Thomas Koenig
PR fortran/66111
* frontend-passes.c (has_dime
On Thu, Oct 09, 2014 at 10:27:09PM +0200, Tobias Burnus wrote:
>
> this patch fixes Alan's issue with IMPLICIT followed by ";". I am not
> sure whether using the _eos machinery is really needed ??? especially as
> "!" seem to be already handled.
>
> Additionally, I missed the inner "[...]" for
Tobias Burnus writes:
> diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90
> b/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90
> new file mode 100644
> index 000..f0ab932
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90
FAIL: gfortran.dg/coarr
Hello world,
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK for trunk?
Thomas
2014-03-12 Thomas Koenig
Hello world,
this contains a straightforward fix for the regression by
not trying to do combine array constructors inside
association lists.
Regression-tested. OK for all affected open branches?
Thomas
2014-05-10 Thomas Koenig
PR fortran/60834
* frontend-passes.c (i
1 - 100 of 8199 matches
Mail list logo
