On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote:
> I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED
> for rotates? Not all immediates are valid of course, but that is a
> separate issue.
Well, we'd need to double check all the hw rotate instructions on al
Pinging this again - while it's a tiny change, I want it to land before I
submit anything else in this area.
Also, I forgot to mention I have no commit access.
Original submission can be found at
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg6.html.
Thanks,
- Eddy B.
On Wed, Jun 26, 2019,
Hi:
I've backported this patch from trunk in order to fix a code gen error
for RISC-V port.
From a1f4984764c66c135cc385e6ea90ca24861bdcc4 Mon Sep 17 00:00:00 2001
From: kito
Date: Thu, 18 Jul 2019 07:00:32 +
Subject: [PATCH] RISC-V: Fix splitter for 32-bit AND on 64-bit target.
Fixes github.
Eric Botcazou writes:
>> I'm not sure using flags_to_condition really buys anything then,
>> since you have to think about each individual case to see whether
>> it belongs in the switch or not. I also don't have any proof
>> that the no-op cases are the common ones (since adding this
>> fast pat
On 7/17/19 8:17 PM, Marek Polacek wrote:
On Mon, Jul 08, 2019 at 08:25:25AM -0400, Nathan Sidwell wrote:
Jason, Marek,
can DEFERRED_PARSE trees survive past the in-class-context late parsing
stage? My assumption was not, but in reducing a module testcase I
encountered a situation when one survi
Steve Ellcey writes:
> This patch fixes a bug with SIMD functions on Aarch64. I found it
> while trying to run SPEC with ToT GCC and a glibc that defines vector
> math functions for aarch64. When a function is declared with the simd
> attribute GCC creates vector clones of that function with the
On Wed, Jul 17, 2019 at 10:02:18PM +0100, Kwok Cheung Yeung wrote:
> This series of patches reworks the way that OpenACC kernels regions are
> processed by GCC. Instead of relying on the parloops pass for
> auto-parallelisation of the kernel region, the contents of the region are
> transformed into
On Wed, Jul 17, 2019 at 10:04:10PM +0100, Kwok Cheung Yeung wrote:
> @@ -2319,7 +2339,8 @@ scan_omp_for (gomp_for *stmt, omp_context *outer_ctx)
> {
>omp_context *tgt = enclosing_target_ctx (outer_ctx);
>
> - if (!tgt || is_oacc_parallel (tgt))
> + if (!tgt || (is_oacc_paral
Hi all,
I played around and came up with another second way one gets a single "*"
without
'optional'.
I haven't checked whether which of those match the proposed
omp_is_optional_argument's
+&& DECL_BY_REFERENCE (decl)
+&& TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE;
nor whether
On Wed, Jul 17, 2019 at 10:06:07PM +0100, Kwok Cheung Yeung wrote:
> --- a/gcc/omp-oacc-kernels.c
> +++ b/gcc/omp-oacc-kernels.c
> @@ -30,6 +30,7 @@ along with GCC; see the file COPYING3. If not see
> #include "backend.h"
> #include "target.h"
> #include "tree.h"
> +#include "cp/cp-tree.h"
No,
On 18/07/19 07:41 +0200, François Dumont wrote:
As we adopted the sized deallocation in the new_allocator why not
doing the same in _Temporary_buffer<>.
* include/bits/stl_tempbuf.h
(__detail::__return_temporary_buffer): New.
(~_Temporary_buffer()): Use latter.
(_Temporary_buffer(
On 18/07/19 07:41 +0200, François Dumont wrote:
Since commit 5d3695d03b7bdade9f4d05d2b those tests are failing.
* testsuite/23_containers/unordered_map/48101_neg.cc: Adapt dg-error
after PR libstdc++/85965 fix.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
On 18/07/2019 10:28 am, Tobias Burnus wrote:
Hi all,
I played around and came up with another second way one gets a single "*"
without
'optional'.
I haven't checked whether which of those match the proposed
omp_is_optional_argument's
+&& DECL_BY_REFERENCE (decl)
+&& TREE_CODE
Hi,
this patch adjusts LTO tree merging to treat anonymous namespace types
as local to a given TU, so just like !TREE_PUBLIC decls they are not
merged (this is unify_scc change). This makes them to get different
canonical types and act as independent types for TBAA.
I also modified canonical type
On Thu, 18 Jul 2019, Jan Hubicka wrote:
> Hi,
> this patch adjusts LTO tree merging to treat anonymous namespace types
> as local to a given TU, so just like !TREE_PUBLIC decls they are not
> merged (this is unify_scc change). This makes them to get different
> canonical types and act as independe
> On Thu, 18 Jul 2019, Jan Hubicka wrote:
>
> > Hi,
> > this patch adjusts LTO tree merging to treat anonymous namespace types
> > as local to a given TU, so just like !TREE_PUBLIC decls they are not
> > merged (this is unify_scc change). This makes them to get different
> > canonical types and ac
>
> OK. I wonder if we can/should carve off some bits to note
> type_with_linkage_p and type_in_anonymous_namespace_p in the tree
> itself? At least in type_common there's plenty of bits left.
> Not sure how expensive / reliable (non-C++?) those tests otherwise are.
It also makes me wonder if o
The attached patch fixes an issue for msp430 where the logic to decide which
registers need to be saved in an interrupt function was unnecessarily
choosing to save all callee-saved registers regardless of whether they were
used or not. This came at a code size and performance penalty for the 430 IS
Looking through the arm backend I noticed that the modes used to pass
comparison types into subtract-with-carry operations were being
incorrectly set. The result is that the compiler is not truly
self-consistent. To clean this up I've introduced a new predicate,
arm_borrow_operation (borrowed fr
"Eduard-Mihai Burtescu" writes:
> Pinging this again - while it's a tiny change, I want it to land
> before I submit anything else in this area.
> Also, I forgot to mention I have no commit access.
>
> Original submission can be found at
> https://gcc.gnu.org/ml/gcc-patches/2019-06/msg6.html.
Jan Hubicka writes:
>>
>> OK. I wonder if we can/should carve off some bits to note
>> type_with_linkage_p and type_in_anonymous_namespace_p in the tree
>> itself? At least in type_common there's plenty of bits left.
>> Not sure how expensive / reliable (non-C++?) those tests otherwise are.
>
On Thu, Jul 18, 2019 at 07:04:05AM -0700, Ian Lance Taylor wrote:
> >> On Mon, Jun 3, 2019, at 7:23 AM, Ian Lance Taylor wrote:
> >> > On Sat, Jun 1, 2019 at 7:15 AM Eduard-Mihai Burtescu
> >> > wrote:
> >> > >
> >> > > 2019-06-01 Eduard-Mihai Burtescu
> >> > > include/ChangeLog:
> >> > > * dema
> Jan Hubicka writes:
>
> >>
> >> OK. I wonder if we can/should carve off some bits to note
> >> type_with_linkage_p and type_in_anonymous_namespace_p in the tree
> >> itself? At least in type_common there's plenty of bits left.
> >> Not sure how expensive / reliable (non-C++?) those tests oth
Hi all,
I've just realized that what we has been done recently for
gcc_jit_context_new_binary_op should be done also for the unary
version.
This patch checks at record time for the result type of
gcc_jit_context_new_unary_op to be numeric type plus add a testcase
for the new check.
make check-jit
On 17/07/2019 18:00, Segher Boessenkool wrote:
On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote:
On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote:
I'm not sure if it makes sense to have both LROTATE_EXPR and
RROTATE_EXPR on the GIMPLE level then (that CPUs only
sup
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
> > Both directions:
> >aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
>
> AArch64 is Right only.
Maybe hw-wise, but it has both rotr3 and rotl3 expanders.
At least for GPRs.
Jakub
On 18/07/2019 16:17, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
Both directions:
aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
AArch64 is Right only.
Maybe hw-wise, but it has both rotr3 and rotl3 expanders.
At least for GPRs.
On Thu, Jul 18, 2019 at 04:26:26PM +0100, Richard Earnshaw (lists) wrote:
>
>
> On 18/07/2019 16:17, Jakub Jelinek wrote:
> > On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
> > > > Both directions:
> > > > aarch64 c6x ia64 m68k nios2 parisc sh x86 xtensa
> > >
> >
On 18/07/2019 16:30, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:26:26PM +0100, Richard Earnshaw (lists) wrote:
On 18/07/2019 16:17, Jakub Jelinek wrote:
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
Both directions:
aarch64 c6x ia64 m68k nios2 parisc
Hi Sylvia,
On 7/3/19 10:31 AM, Sylvia Taylor wrote:
Greetings,
This patch fixes:
1) Ice message thrown when using the crypto_sha1h intrinsic due to
incompatible mode used for zero_extend. Removed zero extend as it is
not a good choice for vector modes and using an equivalent single
mode like T
On Thu, 2019-07-18 at 08:37 +0100, Richard Sandiford wrote:
>
> > 2019-07-17 Steve Ellcey
> >
> > * omp-simd-clone.c (simd_clone_adjust): Call targetm.simd_clone.adjust
> > after calling simd_clone_adjust_return_type.
> > (expand_simd_clones): Ditto.
>
> It should be pretty easy
Hi Sylvia,
On 7/3/19 10:36 AM, Sylvia Taylor wrote:
Greetings,
This patch removes the builtin expand handling for sha1h/c/m/p and
replaces it with expand patterns. This should make it more consistent
with how we handle intrinsic implementations and cleans up the custom
sha1 code in the arm_expa
>>> On 27.06.19 at 10:59, wrote:
> NOT on vectors of integers does not require loading a constant vector of
> all ones into a register - VPTERNLOG can be used here (and could/should
> be further used to carry out other binary and ternary logical operations
> which don't have a special purpose inst
On Thu, 2019-07-18 at 14:20 +, Andrea Corallo wrote:
> Hi all,
> I've just realized that what we has been done recently for
> gcc_jit_context_new_binary_op should be done also for the unary
> version.
> This patch checks at record time for the result type of
> gcc_jit_context_new_unary_op to be
>>> On 27.06.19 at 10:59, wrote:
> Conversion of comparison results to full vectors does, when VPMOVM2* are
> unavailable, not require any intermediate VMOVDQ{A,U}*: Simply use
> embedded masking on VPTERNLOG* right away, which is available with
> AVX512F (while VPMOVM2{D,Q} are available only wit
David Malcolm writes:
> On Thu, 2019-07-18 at 14:20 +, Andrea Corallo wrote:
>> Hi all,
>> I've just realized that what we has been done recently for
>> gcc_jit_context_new_binary_op should be done also for the unary
>> version.
>> This patch checks at record time for the result type of
>> g
This change introduces a "STANDALONE" mode where the C files of the Ada
runtime do not have any dependency on GCC include files. This is
useful for rebuilding the Ada runtime in a sandbox where GCC include files
are not available.
Also a few clean ups along the way.
Tested on x86_64-pc-linux-gnu,
This Go frontend patch by Than McIntosh fixes a buglet in the
function body importer. It adds hooks for keeping a stack of blocks
corresponding to the block nesting in the imported function. This
ensures that local variables and temps wind up correctly scoped and
don't introduce collisions.
The
On Mon, Jun 10, 2019 at 06:21:05PM +0100, Sylvia Taylor wrote:
> Greetings,
>
> This patch adds the intrinsic functions for:
> - vld1__x4
> - vst1__x4
> - vld1q__x4
> - vst1q__x4
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> Ok for trunk? If yes, I don't have any commit rights, so c
Attached patch fixes several strict_low_part insn patterns to operate
only on register outputs. Also, the patch paves the was for patterns
to handle unmatched registers (once PR82524) is fixed, and allows
patterns to operate on HImode operands.
2019-07-18 Uroš Bizjak
PR target/91188
*
On Thu, Jul 18, 2019 at 04:12:48PM +0100, Richard Earnshaw (lists) wrote:
>
>
> On 17/07/2019 18:00, Segher Boessenkool wrote:
> >On Wed, Jul 17, 2019 at 12:54:32PM +0200, Jakub Jelinek wrote:
> >>On Wed, Jul 17, 2019 at 12:37:59PM +0200, Richard Biener wrote:
> >>>I'm not sure if it makes sense
On Thu, Jul 18, 2019 at 7:23 PM Uros Bizjak wrote:
>
> Attached patch fixes several strict_low_part insn patterns to operate
> only on register outputs. Also, the patch paves the was for patterns
> to handle unmatched registers (once PR82524) is fixed, and allows
> patterns to operate on HImode op
On Tue, Jul 16, 2019 at 03:58:18PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Tue, Jul 16, 2019 at 02:19:14AM -0400, Michael Meissner wrote:
> > I have changed the TARGET_TOC to be TARGET_HAS_TOC in the aix, darwin,
> > system
> > V, and Linux 64-bit headers. Then in rs6000.h, TARGET_TOC
On Thu, Jul 18, 2019 at 02:20:43PM -0400, Michael Meissner wrote:
> On Tue, Jul 16, 2019 at 03:58:18PM -0500, Segher Boessenkool wrote:
> > > I did not move the initialization of the TOC_alias_set
> > > elsewhere, because in order to call TOC_alias_set, the code has already
> > > called
> > > forc
On Thu, Jul 18, 2019 at 09:01:13AM +0200, Jakub Jelinek wrote:
> On Wed, Jul 17, 2019 at 12:00:32PM -0500, Segher Boessenkool wrote:
> > I think we can say that *all* targets behave like SHIFT_COUNT_TRUNCATED
> > for rotates? Not all immediates are valid of course, but that is a
> > separate issue
The attached patch adds a new target macro called
CASE_INSENSITIVE_REGISTER_NAMES, which allows the case of register names
used in an asm statement clobber list, or given in a command line option, to be
disregarded when comparing with the register names defined for the target in
REGISTER_NAMES.
On Thu, Jul 18, 2019 at 01:44:36PM +0800, Kewen.Lin wrote:
> Hi Segher,
>
> on 2019/7/17 下午9:40, Segher Boessenkool wrote:
> > Hi Kewen,
> >
> > On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin wrote:
> >> Regression testing just launched, is it OK for trunk if it's bootstrapped
> >> and regre
These insn patterns are just too complex to ever match. Remove them.
2019-07-18 Uroš Bizjak
* config/i386/i386.md (*addqi_2_slp): Remove.
(*qi_2_slp): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
For the reference, the correct for
On 08.07.19 23:19, Matthias Klose wrote:
> On 14.06.19 15:09, Gaius Mulley wrote:
>>
>> Hello,
>>
>> here is version two of the patches which introduce Modula-2 into the
>> GCC trunk. The patches include:
>>
>> (*) a patch to allow all front ends to register a lang spec function.
>>(inc
Jan Hubicka writes:
>> >>
>> >> OK. I wonder if we can/should carve off some bits to note
>> >> type_with_linkage_p and type_in_anonymous_namespace_p in the tree
>> >> itself? At least in type_common there's plenty of bits left.
>> >> Not sure how expensive / reliable (non-C++?) those tests ot
Got it, it is my PR 68303 patch which was introducing this regression. I
fix it to restore those assertions.
You'll see once the awaiting hashtable patches are in...
On 7/18/19 12:18 PM, Jonathan Wakely wrote:
On 18/07/19 07:41 +0200, François Dumont wrote:
Since commit 5d3695d03b7bdade9f4d05
Hi!
On Wed, Jul 17, 2019 at 10:06:14AM -0500, Bill Seurer wrote:
> 2019-07-17 Bill Seurer
>
> * config/rs6000/rs6000.c (builtin_description, cpu_is_info,
[ ... ]
(Your mailer seems to have wrapped some changelog lines, with trailing
spaces and everything).
> rs6000_internal_arg_p
Hi!
On Thu, Jul 18, 2019 at 08:45:38PM +0100, Jozef Lawrynowicz wrote:
> PR target/70320
> * doc/tm.texi.in: Document new macro CASE_INSENSITIVE_REGISTER_NAMES.
> * doc/tm.texi: Likewise.
"Regenerate." -- or did you edit this file by hand? Don't, or don't tell
us anyway ;-)
>
on 2019/7/19 上午3:48, Segher Boessenkool wrote:
> On Thu, Jul 18, 2019 at 01:44:36PM +0800, Kewen.Lin wrote:
>> Hi Segher,
>>
>> on 2019/7/17 下午9:40, Segher Boessenkool wrote:
>>> Hi Kewen,
>>>
>>> On Wed, Jul 17, 2019 at 04:32:15PM +0800, Kewen.Lin wrote:
Regression testing just launched, is i
A non-type template parameter of class type used in an expression has
const-qualified type; the pt.c hunks deal with this difference from the
unqualified type of the parameter declaration. WAhen we use such a
parameter as an argument to another template, we don't want to confuse
things by copying
55 matches
Mail list logo
