On Jan 24, 2019, Jason Merrill wrote:
> The latter; you can't have a partial specialization in a function.
*nod* (though not entirely reflected in the patch below, I see)
>> Any suggestion of a good name for the inline function (or would you
>> prefer it to be a macro?) that tests whether a
The testcase was failing because we were trying to access
TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough
to need only a single element.
Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
OK to install?
Richard
2019-01-25 Richard Sandiford
gcc/
PR
The current translation of GIMPLE to ISL only handles do-while loops
correctly so we have to reject others.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk,
queued for backporting.
Richard.
2019-01-25 Richard Biener
PR tree-optimization/86865
*
On 15/01/2019 15:28, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds a tuning struct for the Arm Ares CPU and uses it for
> -m{cpu,tune}=ares.
> The tunings are an initial attempt and may be improved upon in the
> future, but they serve
> as a decent starting point for GCC 9.
>
> With this I
Hi.
This is one very similar patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From adf577edd5a1d2b6ed78c1cc18feaff23fbfdd1c Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 24 Jan 2019 16:07:29 +0100
Subject: [PATCH] Revert
On 24/01/2019 23:17, Steve Ellcey wrote:
> Here is my attempt at creating a couple of new instructions to
> generate more bfi instructions on aarch64. I haven't finished
> testing this but it helps with gcc.target/aarch64/combine_bfi_1.c.
>
> Before I went any further with it I wanted to see if
Hi,
On 24/01/19 23:21, Jason Merrill wrote:
On 1/24/19 2:53 PM, Paolo Carlini wrote:
Hi,
as far as I can see this ICE on invalid points to a substantive, if
minor, weakness of our implementation of the destroying operator
delete facility: we aren't implementing the bits, per 7.6.2.5/(10.1),
libgfortran/
* io/async.c (init_adv_cond): Use
__GTHREAD_COND_INIT_FUNCTION().
---
libgfortran/io/async.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c
index 3394e595a8b..e3d1d01122e 100644
---
On 1/24/19 10:24 PM, Steve Ellcey wrote:
> On Thu, 2019-01-24 at 16:25 +0100, Martin Liška wrote:
>>
>>>
+ix86_get_multilib_abi_name (void)
+{
+ if (!(TARGET_64BIT_P (ix86_isa_flags)))
+return "i386";
+ else if (TARGET_X32_P (ix86_isa_flags))
+return "x32";
On 1/25/19 12:15 AM, Jakub Jelinek wrote:
On Thu, Jan 24, 2019 at 05:16:52PM -0500, Jason Merrill wrote:
--- libcpp/expr.c.jj2019-01-01 12:38:16.132007335 +0100
+++ libcpp/expr.c 2019-01-24 14:07:10.080774120 +0100
@@ -2238,7 +2238,9 @@ parse_has_include (cpp_reader *pfile, en
On 1/24/19 7:17 PM, Marek Polacek wrote:
On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek wrote:
On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason Merrill wrote:
I was talking about digest_init, not reshape_init. digest_init calls
On 24/01/19 17:14 -0700, Sandra Loosemore wrote:
On 1/24/19 1:20 PM, Jonathan Wakely wrote:
On 24/01/19 11:53 -0700, Sandra Loosemore wrote:
BTW, I'm more worried about the link errors introduced by the
patch for PR 86756. Those are regressions and apparently a
problem that could affect
On OpenACC loop constructs, it is OK according to the OpenACC spec to
have both the "auto" clause and one or more of the "gang", "worker", or
"vector" clauses. GCC emits errors for this combination; this patch
eliminates that error.
OK for openacc-gcc-8-branch?
Thanks,
Gergö
gcc/
*
We were blindly costing all scalar stmts that appear in patterns
even if those are not relevant for vectorization. Fixed as follows.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-01-25 Richard Biener
PR tree-optimization/89049
*
On 25-01-19 01:51, Ian Lance Taylor wrote:
> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>
>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>> possibly NULL filename, with predictable results when it is.
>>
>> elf.c:3044 passes NULL as the filename parm:
>>
This patch moves OpenACC Fortan DO loop setup code from the head of a
region to just before each loop. This is in preparation for upcoming
patches reworking the handling of OpenACC kernels regions.
OK for openacc-gcc-8-branch?
Thanks,
Gergö
gcc/fortran/
* trans-openmp.c
On Fri, Jan 25, 2019 at 5:27 AM Tom de Vries wrote:
>
> On 25-01-19 14:17, Tom de Vries wrote:
> > On 25-01-19 01:51, Ian Lance Taylor wrote:
> >> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>>
> >>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >>>
Here we warn because i::dispatch has internal linkage (because l
does) and is never instantiated (because the vtable is never emitted).
The regression happened because devirtualization started adding it to
cgraph as a possible target. I think the way to fix this is to avoid
adding an
On Fri, 25 Jan 2019 at 06:40, Jakub Jelinek wrote:
>
> On Wed, Jan 23, 2019 at 11:41:55PM +, Joseph Myers wrote:
> > On Wed, 23 Jan 2019, Martin Sebor wrote:
> >
> > > Ping: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00969.html
> >
> > This patch is OK.
>
> Note, the testcase FAILs on
This patch unifies and simplifies the handling of OpenACC default
mapping clauses for parallel, serial, and kernels regions.
OK for openacc-gcc-8-branch?
Thanks,
Gergö
gcc/
* gimplify.c (oacc_default_clause): Refactor and unify computation of
default mapping clauses.
>From
pred_mov is defined for predicated loads and stores, where
exactly one of the operands is a register. However, the instruction
condition only checked for "one" rather than "exactly one", and
Prathamesh found a case in which combine could fold a predicated
pattern to an all-register pred_mov. The
On 25-01-19 14:17, Tom de Vries wrote:
> On 25-01-19 01:51, Ian Lance Taylor wrote:
>> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>>
>>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>>> possibly NULL filename, with predictable results when it is.
>>>
>>>
I've applied the patches below to aarch64/sve-acle-branch. The first
fixes the modes and oerand order of the dot_prod patterns, and the second
fixes a typo in one of the vector duplicate patterns.
Thanks,
Richard
[SVE ACLE] Fix sdot/udot modes
This patch makes the dot_prod patterns have the
The following fixes an ICE with -flto -ffat-lto-objects
-fdebug-types-section -g where optimize_external_refs does not
expect to see DW_AT_signature as made "local" by build_abbrev_table(sic!).
This is because we run optimize_external_refs twice in this setup.
The fix is to make the second
On Fri, Jan 25, 2019 at 5:17 AM Tom de Vries wrote:
>
> On 25-01-19 01:51, Ian Lance Taylor wrote:
> > On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>
> >> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >> possibly NULL filename, with predictable results when
On 1/25/19 6:20 AM, Paolo Carlini wrote:
Hi,
On 24/01/19 23:21, Jason Merrill wrote:
On 1/24/19 2:53 PM, Paolo Carlini wrote:
Hi,
as far as I can see this ICE on invalid points to a substantive, if
minor, weakness of our implementation of the destroying operator
delete facility: we aren't
On 20/10/18 12:18 +0200, Romain Geissler wrote:
Hi,
I would like to raise again the question of supporting -fuse-ld=ldd. A
patch implementing it was already submitted in
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01722.html by Davide
Italiano. This patch still applies correctly to current
On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> >
> > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > This test ICEs since r159006 which added
> > >
> > > type = ENUM_UNDERLYING_TYPE (type);
> > >
> > > to type_promotes_to. In
On Fri, Jan 25, 2019 at 12:15:28PM -0500, Nathan Sidwell wrote:
> On 1/25/19 5:28 AM, Tom de Vries wrote:
> >
> > This patch fixes it by passing "" instead of NULL, in the call to
> > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
> > line 3044 (for .gnu_debuglink)
On 1/25/19 8:48 AM, David Malcolm wrote:
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI has a bug with the handling of 128-bit bit-fields, where if the
bit-field dominates the overall alignment the back-end code may end up
passing the argument correctly. This is a regression that started in
gcc-6 when the ABI
This adds me to the Write After Approval list in MAINTAINERS.
Committed to trunk in r268276.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 268275)
+++ MAINTAINERS (working copy)
@@ -634,6 +634,7 @@ Canqun Yang
Hi!
On Wed, Jan 23, 2019 at 03:57:28AM -0600, luo...@linux.vnet.ibm.com wrote:
> The 5 new builtins vec_sbox_be, vec_cipher_be, vec_cipherlast_be,
> vec_ncipher_be
> and vec_ncipherlast_be only support vector unsigned char type parameters.
> Add new instruction crypto_vsbox_ and crypto__ to
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
On January 25, 2019 1:12:07 PM GMT+01:00, Richard Sandiford
wrote:
>The testcase was failing because we were trying to access
>TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough
>to need only a single element.
>
>Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
On 1/25/19 5:28 AM, Tom de Vries wrote:
This patch fixes it by passing "" instead of NULL, in the call to
elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at
line 3044 (for .gnu_debuglink) mentioned above.
Nathan, does this fix the problem for you? If not, can you provide
On 25 January 2019 12:44:30 CET, Sebastian Huber
wrote:
>libgfortran/
>
> * io/async.c (init_adv_cond): Use
> __GTHREAD_COND_INIT_FUNCTION().
LGTM.
Please CC the FORTRAN list for FORTRAN patches.
thanks,
>---
> libgfortran/io/async.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
>
> On 1/24/19 2:16 PM, Marek Polacek wrote:
> > This test ICEs since r159006 which added
> >
> > type = ENUM_UNDERLYING_TYPE (type);
> >
> > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we
> > haven't yet parsed
On 1/25/19 12:09 PM, Marek Polacek wrote:
On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
On 1/24/19 2:16 PM, Marek Polacek wrote:
This test ICEs since r159006 which added
type = ENUM_UNDERLYING_TYPE (type);
to
Dne 2019-01-25 19:10, Martin Jambor napsal:
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG
after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes
> Hi.
>
> The patch puts back ::get_create for a node that can be seen first time.
> It's due to -O0 optimize attribute. It was unable to write properly
> LTO test-case for it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
>
On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> On 1/25/19 8:48 AM, David Malcolm wrote:
> > PR c++/89036 reports an ICE due to this assertion failing
> >
> > 1136 /* A class should never have more than one
> > destructor. */
> > 1137 gcc_assert (!current_fns ||
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes should not attempt exaclty because of
this
> Hi.
>
> This is one very similar patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From adf577edd5a1d2b6ed78c1cc18feaff23fbfdd1c Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 24 Jan 2019 16:07:29 +0100
>
On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> On 1/24/19 7:17 PM, Marek Polacek wrote:
> > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> > > On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek wrote:
> > > >
> > > > On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268280
Index: ChangeLog
===
--- ChangeLog (revision
On Fri, 2019-01-25 at 10:32 +, Richard Earnshaw (lists) wrote:
>
> Do we need another variant pattern to handle the case where the
> insertion is into the top of the destination? In that case the
> immediate mask on the shifted operand is technically redundant as the
> bottom bits are known
It's also broken the build of the glibc testsuite, e.g.:
../time/time.h:88:15: error: mismatch in argument 1 type of built-in function
'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch]
88 | extern size_t strftime (char *__restrict __s, size_t __maxsize,
(presence or
On Thu, Jan 24, 2019 at 11:17:45PM +, Steve Ellcey wrote:
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -9294,6 +9294,44 @@ aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode
> mode, rtx mask,
>& ((HOST_WIDE_INT_1U << INTVAL (shft_amnt)) - 1)) ==
On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> On 1/25/19 12:09 PM, Marek Polacek wrote:
> > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> > > >
> > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > >
50 matches
Mail list logo