On Thu, May 2, 2019 at 9:02 AM Steve Kargl
wrote:
>
> The attach patch adds an additional check for the
> STOP code when -std=f2008 is used. The patch has
> been bootstrapped and regression tested on
> x86_64-*-freebsd for trunk. OK to commit?
Ok.
--
Janne Blomqvist
The attach patch adds a check that a module prefix
occurs only in a module, submodule, or interface.
C1547 (R1526) MODULE shall appear only in the function-stmt or
subroutine-stmt of a module subprogram or of a nonabstract
interface body that is declared in the scoping unit of a
module o
The attach patch adds an additional check for the
STOP code when -std=f2008 is used. The patch has
been bootstrapped and regression tested on
x86_64-*-freebsd for trunk. OK to commit?
2019-05-01 Steven G. Kargl
PR fortran/90290
* match.c (gfc_match_stopcode): Check F2008 con
From: Maciej W. Rozycki
Fix assembly errors:
.../libphobos/src/std/math.d: Assembler
messages:.../libphobos/src/std/math.d:4773: Error: unrecognized opcode `frflags
a0'
.../libphobos/src/std/math.d:4856: Error: unrecognized opcode `fsflags a5'
.../libphobos/src/std/math.d:4856: Error: unrecogn
Hi Thomas,
> …
> This also clears the ICE for my inline packing patch which
> was reported by Dominique.
> …
Not for me, I still get
% gfc pr61968.f90 -c -O3
pr61968.f90:32:0:
32 | call test_lib (a, int (sizeof (a), kind=c_size_t))
|
internal compiler error: in gfc_trans_create_te
This patch by Cherry Zhang tweaks the Go frontend to recognize and
optimize map range clear. When we see
for k := range m { delete(m, k) }
for map m, we rewrite it to runtime.mapclear, as the gc compiler does.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
This patch by Cherry Zhang changes the Go frontend and libgo to use
more direct interfaces. A direct interface is an interface whose data
word contains the actual data value, instead of a pointer to it. The
gc toolchain creates a direct interface if the value is pointer
shaped, that includes point
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
This libgo patch by Cherry Zhang adds a persistent interface table cache.
Previously, each time we do an interface conversion for which the
method table is not known at compile time, we allocate a new method
table.
This patch ports the mechanism of itab caching from the gc runtime,
adapted to our
Thanks Thomas, committed as r270777.
On Wednesday, May 1, 2019 9:35:13 PM PDT Thomas Koenig wrote:
> Hi Andrew,
>
> > Fixing this seems to be simple:
> >
> > --- gcc/fortran/module.c(revision 270772)
> > +++ gcc/fortran/module.c(working copy)
> > @@ -6052,6 +6052,9 @@ write_modul
Hi Andrew,
Fixing this seems to be simple:
--- gcc/fortran/module.c(revision 270772)
+++ gcc/fortran/module.c(working copy)
@@ -6052,6 +6052,9 @@ write_module (void)
{
int i;
+ /* Initialize the column counter. */
+ module_column = 1;
+
/* Write the operator inte
The value of 'module_column' is not initialized in write_module() before a
module file is written. As a result, the first line break in the module file
can
occur at an arbitrary column, depending on what value 'module_column' happens
to have. While this doesn't affect the behavior of the module
This fixes pr88797 by avoiding path splitting when we've got a
candidate, but the PHI feeds a conditional in the join block. ie:
# iftmp.0_11 = PHI <(3), 1112(4)>
[ ... ]
_14 = iftmp.0_11 > x_17;
These are more likely going to be if-conversion candidates and
if-conversion is generally
Hi Jakub,
> On Fri, Apr 26, 2019 at 12:11:55PM +0100, Jonathan Wakely wrote:
>> On 26/04/19 09:58 +0200, Rainer Orth wrote:
>> > It recently occured to me that almost none of the libstdc++ abi
>> > baselines have been updated for the GCC 9 release. The following patch
>> > corrects this for Solar
Hi Roman,
FAIL: gfortran.dg/inline_matmul_1.f90 scan-tree-dump-times optimized
"_gfortran_matmul" 0
With matmul, there are three versions you can get: The library version
(called as _gfortran_matmul), the inline version or a direct call
to the corresponding BLAS routine. Which one is called, a
On Tue, Apr 30, 2019 at 11:04:10AM -0500, Kelvin Nilsen wrote:
>
> In combination with a related recently committed patch
> (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached
> patch resolves the issues described in this problem report. This patch also
> includes tests to
On Wed, 01 May 2019 00:37:56 +0900,
Jeff Law wrote:
>
> On 4/30/19 7:55 AM, Yoshinori Sato wrote:
> > On Tue, 30 Apr 2019 06:48:01 +0900,
> > Jeff Law wrote:
> >>
> >> On 3/26/19 8:21 AM, Yoshinori Sato wrote:
> >>> I ported linux kernel to Renesas RX.
> >>>
> >>> rx-*-elf target output a binary d
Here's another simplification I'd accumulated. The final arg to
get_class_binding no longer needs to be tri-valued, a simple bool will
do. This results in better diagnostics in one testcase.
nathan
--
Nathan Sidwell
2019-05-01 Nathan Sidwell
gcc/cp/
* name-lookup.h (get_class_binding_di
If there is no objection, I’ll commit the patch to trunk tonight.
Dominique
> Le 27 mars 2019 à 19:48, Thomas Koenig a écrit :
>
> Hi Dominique,
>
>> Patch posted at https://gcc.gnu.org/ml/fortran/2019-03/msg00098.html
>
> I think the patch is OK. I think the patch is probably appropriate fo
Hi all,
Wilco pointed out that when the Dot Product instructions are available
we can use them
to generate an even more efficient expansion for the [us]sadv16qi optab.
Instead of the current:
uabdl2 v0.8h, v1.16b, v2.16b
uabal v0.8h, v1.8b, v2.8b
uadalp v3.4s, v0.8h
20 matches
Mail list logo
