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
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 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:
> > > > >
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)) ==
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
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
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 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,
>
> 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
>
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 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!
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
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
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 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 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
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
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 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
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 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 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.
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:
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 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 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 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 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 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
> >>>
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 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/
*
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
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
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.
>>>
>>>
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
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:
>>
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";
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
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
*
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
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 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
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
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
---
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),
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 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
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
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
*
50 matches
Mail list logo
