On 14-12-18 20:58, Tom de Vries wrote:
> 0003-openacc-Add-target-hook-TARGET_GOACC_ADJUST_PARALLEL.patch
> 0017-nvptx-Enable-large-vectors.patch
1.
If I void nvptx_adjust_parallelism like this:
...
static unsigned
nvptx_adjust_parallelism (unsigned inner_mask, unsigned outer_mask)
{
return def
On 12/21/18 5:16 PM, Jakub Jelinek wrote:
On Fri, Dec 21, 2018 at 04:50:47PM -0700, Martin Sebor wrote:
The first revision of the patch was missing a test and didn't
completely or completely correctly handle attribute noreturn.
Attached is an update with the test included and the omission
and bu
On Fri, Dec 21, 2018 at 04:50:47PM -0700, Martin Sebor wrote:
> The first revision of the patch was missing a test and didn't
> completely or completely correctly handle attribute noreturn.
> Attached is an update with the test included and the omission
> and bug fixed.
>
> I think it makes sense
The first revision of the patch was missing a test and didn't
completely or completely correctly handle attribute noreturn.
Attached is an update with the test included and the omission
and bug fixed.
I think it makes sense to consider the patch independently of
the question whether weakrefs shou
The attached patch addresses an issue submitted by Neil
Carlson. He and I have an exchange in the PR's audit
trail hashing out the validity of his code example. I
also asked on the J3 mailing about the his code. It seems
that language of the Fortran standard may have been
misinterpreted when t
On Tue, 18 Dec 2018, Andi Kleen wrote:
> > Yes, take g++.dg/tree-prof/morefunc.C as an example:
> > - int i;
> > - for (i = 0; i < 1000; i++)
> > + int i, j;
> > + for (i = 0; i < 100; i++)
> > +for (j = 0; j < 50; j++)
> > g += tc->foo();
> > if (g<100) g++;
> > }
> > @@ -2
Am Freitag, den 21.12.2018, 16:13 -0500 schrieb Hans-Peter Nilsson:
> On Tue, 18 Dec 2018, Uecker, Martin wrote:
> > Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> > > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > > > On Tue, Dec 18, 2018 at 09:03:41AM -0700
On Tue, 18 Dec 2018, Uecker, Martin wrote:
> Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> > Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > > On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> > > > Right. This is the classic example and highlights
On 21/12/18 22:47 +0200, Ville Voutilainen wrote:
On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely wrote:
>I also explcitely define BACKTRACE_SUPPORTED to 0 to make sure
>libstdc++ has no libbacktrace dependency after usual build.
I'm concerned about the requirement to link to libbacktrace
On 29/10/18 07:06 +0100, François Dumont wrote:
Hi
Some feedback regarding this patch ?
Sorry this got missed, please resubmit during stage 1.
You haven't CC'd the original patch author (chang jc) to give them a
chance to comment on your proposed changes to the patch.
The attached PDF on
On Fri, 21 Dec 2018 at 22:35, Jonathan Wakely wrote:
> >I also explcitely define BACKTRACE_SUPPORTED to 0 to make sure
> >libstdc++ has no libbacktrace dependency after usual build.
> I'm concerned about the requirement to link to libbacktrace
> explicitly (which will break existing makefiles
On 11/12/18 00:08 +0100, François Dumont wrote:
Hi
Here is the integration of libbacktrace to provide the backtrace
on _GLIBCXX_DEBUG assertions.
I decided to integrate it without impacting the build scripts.
Users just need to install libbacktrace and once done _GLIBCXX_DEBUG
will
On 16/12/18 14:16 +0100, François Dumont wrote:
Gentle reminder, we still have this issue pending.
* include/bits/hashtable_policy.h
(_Hashtable_alloc<>::_M_deallocate_node_ptr(__node_type*)): New.
(_Hashtable_alloc<>::_M_deallocate_node(__node_type*)): Use latter.
(_ReuseOrAllocNode<>::
On Fri, Dec 21, 2018 at 07:39:45PM +, Joseph Myers wrote:
> On Fri, 21 Dec 2018, Steve Kargl wrote:
>
> > scalbln(double x, long n)
> > {
> >
> > return (scalbn(x, (n > NMAX) ? NMAX : (n < NMIN) ? NMIN : (int)n));
> > }
> >
> > A search for glibc's libm locates https://tinyurl.com/yb
On Fri, 21 Dec 2018, Steve Kargl wrote:
> scalbln(double x, long n)
> {
>
> return (scalbn(x, (n > NMAX) ? NMAX : (n < NMIN) ? NMIN : (int)n));
> }
>
> A search for glibc's libm locates https://tinyurl.com/ybcy8w4t
> which is a bit-twiddling routine. Not sure it's worth the
> effort. J
Applied as 'obvious' after regtesting on FC28/x86_64.
The second part of the patch (in simplify_ref_chain) is due to Jakub,
for which many thanks. The first is consequent on the need to deal
with more than one inquiry part ref (see the testcase) and yet be able
to return true from simplify_ref_cha
On Fri, Dec 21, 2018 at 08:59:04PM +0200, Janne Blomqvist wrote:
> On Fri, Dec 21, 2018 at 7:59 PM Steve Kargl <
> >
> > D.3853 = *i;
> > __result_foo = scalbnq (c,
> > (integer(kind=4)) MAX_EXPR ,
> > -2147483647>);
> >
> > The range [-32443,32443] is a subset of [-huge(),huge(0)].
> >
>
> Tr
On 12/21/18 3:51 AM, Jakub Jelinek wrote:
On Thu, Dec 20, 2018 at 09:49:39PM -0500, Jason Merrill wrote:
But if we need cp_fully_fold, doesn't that mean that the earlier
cxx_eval_constant_expression failed and thus the argument is not a constant
expression? Should __builtin_is_constant_evaluate
Hi,
this patch fixes polymorphic call analysis in thunks. Unlike normal
methods, thunks take THIS pointer offsetted by a known constant. This
needs t be compensated for when calculating address of outer type.
Bootstrapped/regtested x86_64-linux, also tested with Firefox where this
bug trigger mis
Hi!
As the testcase shows, even result of force_gimple_operand_gsi
might need regimplification, e.g. if it is ADDR_EXPR of a reference with
a decl with DECL_VALUE_EXPR set.
Fixed thusly. Additionally, I've noticed the OpenMP 4.5 support broke a
case where we assigned to addressable decl vback so
On Fri, Dec 21, 2018 at 06:01:56PM +, Steve Ellcey wrote:
> Here is an update to the test part of this patch. I did not change the
> actual source code part of this, just the tests, so that is all I am
> including here. I removed the x86 changes that had gotten in there by
> accident and used
On Fri, 21 Dec 2018, Martin Sebor wrote:
> That said, I'm also not sure the warning is necessarily the best way
> to deal with the attribute mismatches in these cases (declarations
> of aliases in .c files). Wouldn't it make more sense to copy
> the attributes from targets to their aliases uncond
On Fri, Dec 21, 2018 at 7:59 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Fri, Dec 21, 2018 at 11:07:08AM +0200, Janne Blomqvist wrote:
> > On Fri, Dec 21, 2018 at 8:22 AM Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > On Thu, Dec 20, 2018 at 01:47:39PM -0
Bootstrapped and regression tested on s390x (IBM z14).
Committed to mainline
gcc/ChangeLog:
2018-12-21 Andreas Krebbel
* config/s390/vector.md ("floatv2div2df2", "floatunsv2div2df2")
("fix_truncv2dfv2di2", "fixuns_truncv2dfv2di2"): New pattern
definitions.
gcc/testsu
On Fri, Dec 21, 2018 at 06:31:27PM +0100, Thomas Koenig wrote:
> Hi Steve,
>
> > No, I'm adding the missing functions to the INTERFACE.
>
> Ah, I see. What I missed was that the function is actually translated
> to something else.
>
> So, OK for trunk, and thanks for the patch!
>
Janne, Thomas
Hi All,
I have made a trivial change in the patch and will assume the OK still applies.
I have also changed it from a compile to assemble tests.
Kind Regards,
Tamar
The 12/21/2018 11:40, Kyrill Tkachov wrote:
> Hi Tamar,
>
> On 11/12/18 15:46, Tamar Christina wrote:
> > Hi All,
> >
> > This pa
Here is an update to the test part of this patch. I did not change the
actual source code part of this, just the tests, so that is all I am
including here. I removed the x86 changes that had gotten in there by
accident and used relative line numbers in the warning checks instead
of absolute line
Hi Olivier,
> I'm experimenting with the idea of adjusting the
> stack probing code using r9 today, to see if it could
> save/restore that reg if it happens to be the static chain
> as well.
>
> If that can be made to work, maybe that would be a better
> alternative than just swapping and have the
On Fri, Dec 21, 2018 at 11:07:08AM +0200, Janne Blomqvist wrote:
> On Fri, Dec 21, 2018 at 8:22 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote:
> > > The attached patch has been tested on x86_64-*-freebsd.
> > >
> > >
On Fri, Dec 21, 2018 at 06:35:14PM +0100, Richard Biener wrote:
> On Fri, Dec 21, 2018 at 5:25 PM Segher Boessenkool
> wrote:
> >
> > On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> > > On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov
> > > wrote:
> > > > On 12/20/2018 06:14 PM
Hi All,
This updated patch adds NEON intrinsics and tests for the Armv8.3-a complex
multiplication and add instructions with a rotate along the Argand plane.
The instructions are documented in the ArmARM[1] and the intrinsics
specification
will be published on the Arm website [2].
The Lane vers
Hi,
I've updated my email address in MAINTAINERS file since I'm leaving my
company. I'll do the copyright assignment paperwork before
contributing any new patches.
Best regards,
Thomas
From c486e31b10ae0ec648ba256a92d5a4bcef1ef83d Mon Sep 17 00:00:00 2001
From: thopre01
Date: Fri, 21 Dec 2018 1
Still waiting for this (I hope) last fix before gcc 9 release...
We could perhaps make:
_Pointer_adapter(element_type* __arg = 0)
explicit to find out if there are other places where we miss to properly
call pointer_traits<>::pointer_to. But I aren't sure we can do it in
this extension a
On Fri, Dec 21, 2018 at 6:35 PM Richard Biener
wrote:
>
> On Fri, Dec 21, 2018 at 5:25 PM Segher Boessenkool
> wrote:
> >
> > On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> > > On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov
> > > wrote:
> > > > On 12/20/2018 06:14 PM, Peter
On Fri, Dec 21, 2018 at 5:25 PM Segher Boessenkool
wrote:
>
> On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> > On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov
> > wrote:
> > > On 12/20/2018 06:14 PM, Peter Bergner wrote:
> > > > On 12/20/18 4:41 PM, Jeff Law wrote:
> > > >> O
Hi Steve,
No, I'm adding the missing functions to the INTERFACE.
Ah, I see. What I missed was that the function is actually translated
to something else.
So, OK for trunk, and thanks for the patch!
Regards
Thomas
It looks like IPA ICF does code generation based on the order of
a hahstable walk which is keyed on pointers. That's a no-no.
Fixing that doesn't solve the cc1 miscompare for LTO bootstrap
but at least the IPA ICF WPA dumps are now consistent between
stages.
[LTO] Bootstrapped and tested on x86
Hi all,
this patch adds me to MAINTAINERS in the Write After Approval section.
Will commit to trunk.
Thanks,
Gergö
>From 2b5e62781aadfb5d89f6b11f4c4cb8e5cfe373be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerg=C3=B6=20Barany?=
Date: Fri, 21 Dec 2018 09:05:35 -0800
Subject: [PATCH] Add myself to
Hi Jakub,
Thanks for review!
On Fri, 21 Dec 2018 14:31:19 +0100
Jakub Jelinek wrote:
> On Fri, Dec 21, 2018 at 01:23:03PM +, Julian Brown wrote:
> > 2018-xx-yy Nathan Sidwell
> >
> > PR lto/71959
> > libgomp/
> > * testsuite/libgomp.oacc-c++/pr71959-a.C: New.
> >
Hi Wilco,
(and thanks everyone for the interesting input on this)
> On 17 Dec 2018, at 14:55, Wilco Dijkstra wrote:
>
> The AArch64 ABI defines x18 as platform specific:
[...]
> Using x9 would make its use as an extra argument clearer.
I'm experimenting with the idea of adjusting the
stack pro
On Fri, Dec 21, 2018 at 04:55:28PM +0100, Richard Biener wrote:
> On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov wrote:
> > On 12/20/2018 06:14 PM, Peter Bergner wrote:
> > > On 12/20/18 4:41 PM, Jeff Law wrote:
> > >> On 12/20/18 2:30 PM, Peter Bergner wrote:
> >I am just saying that you ne
On 2018/12/19 5:03 AM, Thomas Schwinge wrote:
Hi Chung-Lin!
On Tue, 18 Dec 2018 23:06:38 +0800, Chung-Lin Tang
wrote:
this part includes some of the lookup_goacc_asyncqueue fixes we talked about.
I am still thinking about how the queue lock problem should really be solved,
so regard
this pat
On 12/21/18 3:05 AM, Jakub Jelinek wrote:
Hi!
I think the main question is whether we should accept leaf attribute
on weakrefs, despite them being marked as !TREE_PUBLIC.
I know we haven't allowed that until now, but weakrefs are weirdo things
which have both static and external effects, static
On Fri, Dec 21, 2018 at 4:25 PM Vladimir Makarov wrote:
>
>
>
> On 12/20/2018 06:14 PM, Peter Bergner wrote:
> > On 12/20/18 4:41 PM, Jeff Law wrote:
> >> On 12/20/18 2:30 PM, Peter Bergner wrote:
> >>> For stage1, I'd like to fix that conflict wart if I can. I have also
> >>> wondered about addi
On Fri, Dec 21, 2018 at 11:07:08AM +0200, Janne Blomqvist wrote:
> On Fri, Dec 21, 2018 at 8:22 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote:
> > > The attached patch has been tested on x86_64-*-freebsd.
> > >
> > >
On 12/20/2018 06:14 PM, Peter Bergner wrote:
On 12/20/18 4:41 PM, Jeff Law wrote:
On 12/20/18 2:30 PM, Peter Bergner wrote:
For stage1, I'd like to fix that conflict wart if I can. I have also
wondered about adding a copy coalesce phase just before we enter RA,
which would ensure the copies
On Fri, Dec 21, 2018 at 4:04 PM Jakub Jelinek wrote:
>
> Hi!
>
> Binutils recently changed the expected *WORD PTR sizes for AVX512
> scatter/gather insns incompatibly.
>
> If we want to stay compatible with both old and new gas, we need to
> avoid printing that *WORD PTR.
Please add a comment, w
On Fri, 21 Dec 2018, Jakub Jelinek wrote:
> Hi!
>
> In the PR57251 fixes, I've messed up the modes, convert_modes first argument
> is the to mode and second argument is the from mode, i.e. mode the third
> argument has or is assumed to have.
>
> The following patch fixes that. Additionally I've
Hi!
In the PR57251 fixes, I've messed up the modes, convert_modes first argument
is the to mode and second argument is the from mode, i.e. mode the third
argument has or is assumed to have.
The following patch fixes that. Additionally I've swapped two conditions
to avoid first convert_modes a CO
Hi!
Binutils recently changed the expected *WORD PTR sizes for AVX512
scatter/gather insns incompatibly.
If we want to stay compatible with both old and new gas, we need to
avoid printing that *WORD PTR.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
(though just with gas 2.
On 11/9/18 11:04 AM, Sam Tebbs wrote:
> On 11/02/2018 06:01 PM, Sam Tebbs wrote:
>
>> On 11/02/2018 05:35 PM, Sam Tebbs wrote:
>>
>>> Hi all,
>>>
>>> This patch adds support for the Armv8.3-A pointer authentication
>>> instructions
>>> that use the B-key (pacib*, autib* and retab). This required a
On Fri, Dec 21, 2018 at 9:08 AM Jan Beulich wrote:
>
> For 64-bit these should not be emitted without suffix in AT&T mode (as
> being ambiguous that way); the suffixes are benign for 32-bit. For
> consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ.
>
> The omission has originally (pr
Hi Gergő!
On Fri, 21 Dec 2018 13:29:09 +0100, Gergö Barany wrote:
> OpenACC 2.6 specifies `if' and `if_present' clauses on the `host_data'
> construct. These patches add support for these clauses. The first patch,
> by Thomas, reorganizes libgomp internals to turn a "device" argument
> into "f
On Fri, Dec 21, 2018 at 9:43 AM Jan Beulich wrote:
>
> While their use for masking is indeed restricted to %k1...%k7, use as
> "normal" insn operands also permits %k0. Remove the unnecessary
> limitations, requiring quite a few testsuite adjustments.
>
> Oddly enough some AVX512{F,DQ} test cases a
On Fri, Dec 21, 2018 at 01:23:03PM +, Julian Brown wrote:
> 2018-xx-yy Nathan Sidwell
>
> PR lto/71959
> libgomp/
> * testsuite/libgomp.oacc-c++/pr71959-a.C: New.
> * testsuite/libgomp.oacc-c++/pr71959.C: New.
Just nits, better use pr71959-aux.cc (*.cc files
On 20/12/18 22:53 +0100, François Dumont wrote:
On 12/20/18 9:04 AM, Ville Voutilainen wrote:
On Thu, 20 Dec 2018 at 08:29, François Dumont wrote:
Hi
I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.
The std::pair move default
Hi Gergő!
On Fri, 21 Dec 2018 13:24:34 +0100, Gergö Barany wrote:
> This fixes a conflict between two recently committed patches to
> openacc-gcc-8-branch, Maciej's "Add OpenACC 2.6 `serial' construct
> support" and my "Report errors on missing OpenACC reduction clauses in
> nested reductions"
On Fri, 21 Dec 2018 02:56:36 +
Julian Brown wrote:
> On Tue, 25 Sep 2018 14:59:18 +0200
> Martin Jambor wrote:
>
> > Hi,
> >
> > I have noticed a few things...
> >
> > On Thu, Sep 20 2018, Cesar Philippidis wrote:
> > > This is another old gomp4 patch that demotes an ICE in PR71959 to
>
On Thu, Nov 29, 2018 at 3:14 PM H.J. Lu wrote:
>
> On Wed, Oct 31, 2018 at 12:42 PM H.J. Lu wrote:
> >
> > On Thu, Sep 27, 2018 at 7:58 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Sep 27, 2018 at 3:16 PM H.J. Lu wrote:
> > > >
> > > > On Thu, Sep 27, 2018 at 6:08 AM, Szabolcs Nagy
> > >
Hi all,
Our movmem expansion currently emits TImode loads and stores when copying
128-bit chunks.
This generates X-register LDP/STP sequences as these are the most preferred
registers for that mode.
For the purpose of copying memory, however, we want to prefer Q-registers.
This uses one fewer
OpenACC 2.6 specifies `if' and `if_present' clauses on the `host_data'
construct. These patches add support for these clauses. The first patch,
by Thomas, reorganizes libgomp internals to turn a "device" argument
into "flags" that can provide more information to the runtime. The
second patch ad
This fixes a conflict between two recently committed patches to
openacc-gcc-8-branch, Maciej's "Add OpenACC 2.6 `serial' construct
support" and my "Report errors on missing OpenACC reduction clauses in
nested reductions". The former renamed a function which caused the
latter to no longer compil
On Fri, Dec 14, 2018 at 06:15:54PM -0200, Alexandre Oliva wrote:
> On Dec 6, 2018, Alexandre Oliva wrote:
>
> > Regstrapped on x86_64- and i686-linux-gnu, mistakenly along with a patch
> > with a known regression, and got only that known regression. Retesting
> > without it. Ok to install?
>
I've committed the obvious attached patch to fix the
gcc.target/arm/size-optimization-ieee-* testcase failures.
On some version of dejagnu, options in RUNTESTFLAGS are appended to the
command-line and thus any -mfloat-abi=softfp or -mfloat-abi=hard in
there overwrite the -mfloat-abi=soft in the dg
Hi Tamar,
On 11/12/18 15:46, Tamar Christina wrote:
Hi All,
This patch adds NEON intrinsics and tests for the Armv8.3-a complex
multiplication and add instructions with a rotate along the Argand plane.
The instructions are documented in the ArmARM[1] and the intrinsics
specification
will be p
On Fri, Dec 21, 2018 at 12:10:26PM +0100, Thomas Schwinge wrote:
> gcc/
> * gimplify.c (gimplify_scan_omp_clauses): Fix known_eq typo/bug.
Ok, thanks.
> ---
> gcc/gimplify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> in
Hi!
On Mon, 23 Oct 2017 18:17:38 +0100, Richard Sandiford
wrote:
> This patch makes get_inner_reference and ptr_difference_const return the
> bit size and bit position as poly_int64s rather than HOST_WIDE_INTS.
> The non-mechanical changes were handled by previous patches.
(A variant of that go
Hi Tamar,
On 11/11/18 10:27, Tamar Christina wrote:
Hi All,
This patch adds new testsuite directive for both Arm and AArch64 to support
testing of the Complex Arithmetic operations form Armv8.3-a.
Bootstrap and Regtest on aarch64-none-linux-gnu, arm-none-gnueabihf and
x86_64-pc-linux-gnu
and
Hi Tamar,
On 11/11/18 10:27, Tamar Christina wrote:
Hi All,
The AArch32 backend is currently not able to support autovectorization of
half-float values
on ARM. This is because we never told the vectorizer what the vector modes are
for Half floats.
This enables autovectorization by definiting
Ping
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Tuesday, December 11, 2018 15:47
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: [PATCH 9/9][GCC][Ar
Ping.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Sunday, November 11, 2018 10:28
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: [PATCH 7/9][GCC][Ar
Ping arm maintainers.
> -Original Message-
> From: James Greenhalgh
> Sent: Wednesday, November 28, 2018 17:18
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; ni...@redhat.com; Ramana Radhakrishnan
> ; Kyrylo Tkachov
>
> Subject: Re: [
Hi!
On Sat, 10 Nov 2018 09:11:18 -0800, Julian Brown
wrote:
> This patch (by Cesar, with some minor additional changes)
Cesar's changes we're handling separately (already approved; will commit
soon), so it remains here:
> replaces usage
> of several magic constants in target.c with named macro
On Fri, Dec 21, 2018 at 10:13 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch attempts to improve code generated for some
> integral vector comparisons and VEC_COND_EXPRs with integral comparisons.
> The only available integral vector comparison instructions are GT and
> EQ, the rest is ha
Hi!
I think the main question is whether we should accept leaf attribute
on weakrefs, despite them being marked as !TREE_PUBLIC.
I know we haven't allowed that until now, but weakrefs are weirdo things
which have both static and external effects, static for that they are a
local alias and externa
On 12/21/18 9:08 AM, Uros Bizjak wrote:
> On Thu, Dec 20, 2018 at 1:09 PM Jakub Jelinek wrote:
>>
>> On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote:
>>> Hi Mateuszb,
>>>
>>> I tested with your proposition patch and it is working right.
>>> I also added the patch with test case.
>>>
On Tue, 11 Dec 2018, Richard Biener wrote:
>
> After the previous cleanup the following is more straight-forward now.
> This should make tree-affine behave wrt the "new" GIMPLE world.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, now making
> sure there are no codegen changes as expec
On Fri, Dec 21, 2018 at 10:08:09AM +0100, Uros Bizjak wrote:
> This patch should be reviewed and evenutually approved by cygwin/mingw
> maintainer.
CCing.
Jakub
Hi!
The following patch attempts to improve code generated for some
integral vector comparisons and VEC_COND_EXPRs with integral comparisons.
The only available integral vector comparison instructions are GT and
EQ, the rest is handled either by negating the result (for vcond swapping
op_true/op_f
On Thu, Dec 20, 2018 at 1:09 PM Jakub Jelinek wrote:
>
> On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote:
> > Hi Mateuszb,
> >
> > I tested with your proposition patch and it is working right.
> > I also added the patch with test case.
> > Please let me know your thoughts/suggestion
On Fri, Dec 21, 2018 at 8:22 AM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote:
> > The attached patch has been tested on x86_64-*-freebsd.
> >
> > OK to commit?
> >
> > 2018-12-20 Steven G. Kargl
> >
> > PR fortran/69
On Fri, Dec 21, 2018 at 9:43 AM Jan Beulich wrote:
>
> They are no different from their VAESENC{,LAST} counterparts in this
> regard.
>
> gcc/
> 2018-12-21 Jan Beulich
>
> * config/i386/sse.md (vaesdec_, vaesdeclast_): Allow
> memory input.
OK.
Thanks,
Uros.
> --- a/gcc/confi
On Thu, Dec 20, 2018 at 09:49:39PM -0500, Jason Merrill wrote:
> > But if we need cp_fully_fold, doesn't that mean that the earlier
> > cxx_eval_constant_expression failed and thus the argument is not a constant
> > expression? Should __builtin_is_constant_evaluated () evaluate to true
> > even if
They are no different from their VAESENC{,LAST} counterparts in this
regard.
gcc/
2018-12-21 Jan Beulich
* config/i386/sse.md (vaesdec_, vaesdeclast_): Allow
memory input.
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -21659,7 +21659,7 @@
[(set (match_operand
While their use for masking is indeed restricted to %k1...%k7, use as
"normal" insn operands also permits %k0. Remove the unnecessary
limitations, requiring quite a few testsuite adjustments.
Oddly enough some AVX512{F,DQ} test cases already check for %k[0-7],
while others did permit {%k0} - where
For 64-bit these should not be emitted without suffix in AT&T mode (as
being ambiguous that way); the suffixes are benign for 32-bit. For
consistency also omit the suffix in Intel mode for {,V}CVTSI2SxQ.
The omission has originally (prior to rev 260691) lead to wrong code
being generated for the 6
Hello,
what shall happen, so that no reminders are necessary to move things
forward? Why does sending a reminder make a difference and are only
penetrant persons blessed?
Regards
Дилян
On Fri, 2018-12-07 at 10:55 +, Дилян Палаузов wrote:
> Hello,
>
> will it help, if Bugzilla is reprogr
87 matches
Mail list logo