Hi!
As mentioned earlier, embedded_size is broken on vecs of long long, double
etc. on some platforms, which breaks bootstrap.
E.g. on i686-linux, the problem is mostly with older GCC versions being used
as stage1 compiler (GCC 4.8 to 7.* in particular), because alignas (long long)
makes U 64-bit
Hi:
For struct initialization, when it fits in a TImode, gcc will use
pinsr insn which causes poor codegen described in PR93897 and PR96562.
Bootstrap is ok, regression test is ok for i386/x86-64 backend.
Ok for trunk?
ChangeLog
gcc/
PR target/96562
PR target/93897
*
Hi Richard,
Thanks for the comments!
on 2020/8/13 上午12:10, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Segher,
>>
>> on 2020/8/7 锟斤拷锟斤拷10:42, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Fri, Aug 07, 2020 at 10:44:10AM +0800, Kewen.Lin wrote:
> I think this makes a lot of sense.
>>>
Originally I thought to bootstrap this patch on MIPS and SPARC
since they're both delayed-branch-slot targets but I
reconsidered, as neither is a TARGET_FLAGS_REGNUM target. It
seems only visium and CRIS has this feature set, and I see no
trace of visium in neither newlib nor the simulator next to
On Tue, Aug 11, 2020 at 5:56 PM Uros Bizjak wrote:
>
> On Tue, Aug 11, 2020 at 11:36 AM Hongtao Liu wrote:
> >
> > On Tue, Aug 11, 2020 at 4:38 PM Uros Bizjak wrote:
> > >
> > > On Tue, Aug 11, 2020 at 5:30 AM Hongtao Liu wrote:
> > > >
> > > > Hi:
> > > > The issue is described in the bugzil
Hi,
Add missing require-effect-target alloca directives.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Add missing require-effective-target allloca
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr92088-1.c: Add require-effective-target alloca.
* gcc.dg/torture/pr
On Thu, 2020-08-13 at 17:55 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 13, 2020 at 05:11:11PM -0500, will schmidt wrote:
> > > > That is probably a level of detail that is not
> > > > really needed in the GCC code comment. Probably best to just
> > > > change
> > > > the comment to re
On Tue, 2020-08-11 at 12:22 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 2, adds support for divide, modulo, shift, compare of 128-bit
> integers. The support adds the instruction and builtin support.
>
> Carl Love
>
>
> ---
PR analyzer/96598 reports that -fanalyzer issues a false
warning: use of NULL 'str' where non-null expected
with gcc 10.2 when used with -fsanitize=undefined.
This was fixed by g:808f4dfeb3a95f50f15e71148e5c1067f90a126d.
gcc/testsuite/ChangeLog:
PR analyzer/96598
* gcc.dg/analyz
On 8/12/20 5:19 PM, Joseph Myers wrote:
On Fri, 7 Aug 2020, Martin Sebor via Gcc-patches wrote:
I don't see anything in the tests in this patch to cover this sort of case
(arrays of pointers, including arrays of pointers to arrays etc.).
I've added a few test cases and reworked the declarator
Hi!
On Thu, Aug 13, 2020 at 05:11:11PM -0500, will schmidt wrote:
> > > That is probably a level of detail that is not
> > > really needed in the GCC code comment. Probably best to just
> > > change
> > > the comment to read something like "ISA 3.0 sign extend builtins".
> >
> > Sounds good.
>
Hi!
This is about the Power binding to some OpenMP API, right? It has
nothing to do with "vector" or "ABI" -- we have vectors already, and
we have ABIs already, more than enough of each.
It is very very VERY hard to review this without being told the proper
setting here.
On Fri, Aug 07, 2020 a
Hello-
The attached patch was discussed briefly on PR 54185 here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185#c14
The test case for this PR sometimes fails due to random failures in
pthread_create() that are not related to the original PR. This patch fixes
it up by ignoring those failures.
On Thu, 2020-08-13 at 13:29 -0500, Segher Boessenkool wrote:
> On Thu, Aug 13, 2020 at 11:09:10AM -0700, Carl Love wrote:
> > The builtins
> >
> > vector signed int vec_signexti (vector signed char a)
> > vector signed long long vec_signextll (vector signed char a)
> > vector signed int vec_signex
On Thu, Aug 13, 2020 at 01:58:31PM -0500, Peter Bergner wrote:
> On 8/12/20 8:59 PM, Peter Bergner wrote:
> > On 8/12/20 8:00 PM, Segher Boessenkool wrote:
> >> On Wed, Aug 12, 2020 at 03:32:18PM -0500, Peter Bergner wrote:
> > Ok, how about this comment then?
> >
> > @@ -6444,8 +6444,30 @@ machin
On Thu, Aug 13, 2020 at 08:40:22PM +, GT wrote:
> I'm looking at ix86_simd_clone_adjust and also aarch64_simd_clone_adjust. The
> latter is
> much simpler and I see how I would add PPC attribute "vsx" similarly. If I
> was to follow
> the ix86_simd_clone_adjust organization, then ix86_valid_t
‐‐‐ Original Message ‐‐‐
On Monday, August 10, 2020 2:07 PM, Jakub Jelinek wrote:
> On Mon, Aug 10, 2020 at 05:29:49PM +, GT wrote:
>
> > > For PowerPC, if all you want to support is b which requires VSX, then the
> > > right thing is for !TREE_PUBLIC functions return 0 if !TARGET_VSX
On 8/13/20 3:00 PM, Carl Love wrote:
> On Thu, 2020-08-13 at 14:48 -0500, Bill Schmidt wrote:
>> OK, but that was just meant as an example. We have a fair number of
>> things that changed names, so I was somewhat surprised. It could be
>> that all of these are likewise hidden via the overload m
Bill:
On Thu, 2020-08-13 at 14:48 -0500, Bill Schmidt wrote:
> OK, but that was just meant as an example. We have a fair number of
> things that changed names, so I was somewhat surprised. It could be
> that all of these are likewise hidden via the overload mechanism.
> Just
> checking to b
On 8/13/20 2:24 PM, Carl Love wrote:
Bill:
On Thu, 2020-08-13 at 13:38 -0500, Bill Schmidt wrote:
Hi Carl,
Thanks for cleaning up the consistency issue. The new names and
related
adjustments LGTM.
Are there no affected test cases that need adjusting? That
surprises
me. For example, didn't
Bill:
On Thu, 2020-08-13 at 13:38 -0500, Bill Schmidt wrote:
> Hi Carl,
>
> Thanks for cleaning up the consistency issue. The new names and
> related
> adjustments LGTM.
>
> Are there no affected test cases that need adjusting? That
> surprises
> me. For example, didn't __builtin_altivec_xx
On Fri, 2020-08-07 at 11:08 -0600, Martin Sebor via Gcc-patches wrote:
> On 7/28/20 7:16 PM, Martin Sebor wrote:
> > Patch 1 adds the basic infrastructure to support array/VLA bounds
> > in attribute access. It extends the access string specification
> > to describe function parameters of array ty
sure.
--
From: Jonathan Wakely
Sent: Thursday, August 13, 2020 11:13 AM
To: Aditya K
Cc: libstdc++ ; gcc-patches
Subject: Re: Add cold attribute to one time construction APIs
Please CC the libstdc++ list on all libstdc++ patches.
On Thu, 13 Aug 2020 at 17:51, Aditya K wrote:
>
> Revised pa
On 8/12/20 8:59 PM, Peter Bergner wrote:
> On 8/12/20 8:00 PM, Segher Boessenkool wrote:
>> On Wed, Aug 12, 2020 at 03:32:18PM -0500, Peter Bergner wrote:
> Ok, how about this comment then?
>
> @@ -6444,8 +6444,30 @@ machine_mode
> rs6000_promote_function_mode (const_tree type ATTRIBUTE_UNUSED,
>
Several fixes to CET builtin expanders:
a) Split out explicit zeroing of RDSSP output operand.
b) Use DImode memory operand for RSTORSSP and CLRSSBSY instructions.
c) Use parameterized pattern names to simplify calling of named patterns.
2020-08-13 Uroš Bizjak
gcc/ChangeLog:
* config/i38
On 8/13/20 11:12 AM, Carl Love wrote:
GCC maintainers:
The macro expansion for the bfloat convert intrinsics XVCVBF16SP and
XVCVSPBF16 need to be restricted to P10.
The macro expansions BU_P10V_0, BU_P10V_1, BU_P10V_2, BU_P10V_3 expand
the name field as "__builtin_altivec_". These macro expans
On Thu, Aug 13, 2020 at 11:09:10AM -0700, Carl Love wrote:
> The builtins
>
> vector signed int vec_signexti (vector signed char a)
> vector signed long long vec_signextll (vector signed char a)
> vector signed int vec_signexti (vector signed short a)
> vector signed long long vec_signextll (vecto
modules has uncovered some exciting issues with hidden friends, and I
need to wander into name lookup again. This is a piece I punted on the
first time round. But now I have C++11, it's better than it would have
been :)
The API for lookup_name_real is really confusing. This addresses the
p
Segher:
On Thu, 2020-08-13 at 12:36 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 11, 2020 at 12:22:37PM -0700, Carl Love wrote:
> > +/* Sign extend builtins that work on ISA 3.0, but not defined
> > until ISA 3.1. */
>
> What does this mean? Not defined in GCC before now? Does it ne
On Thu, Aug 13, 2020 at 11:44:46AM -0600, Martin Sebor via Gcc-patches wrote:
> The underlined code above zeroes out the bytes of elements with
> no initializers as well as any padding between fields. It doesn't
> consider CONSTRUCTOR_NO_CLEARING. I didn't know about that bit so
> I looked it up.
On 8/13/20 10:21 AM, Jeff Law wrote:
On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
The folders for these functions (and some others) call c_getsr
which relies on string_constant to return the representation of
constant strings. Because the function doesn't handle consta
Hi!
On Tue, Aug 11, 2020 at 12:22:37PM -0700, Carl Love wrote:
> +/* Sign extend builtins that work on ISA 3.0, but not defined until ISA 3.1.
> */
What does this mean? Not defined in GCC before now? Does it need
backporting? Not defined in older versions of the ELFv2 ABI (or vector
doc) and
Please CC the libstdc++ list on all libstdc++ patches.
On Thu, 13 Aug 2020 at 17:51, Aditya K wrote:
>
> Revised patch with _GLIBCXX_COLD added at the end.
>
> ```
> commit 3dc9f9a8461b1c88e991ceb517e5fdd81f268d1e
> Author: Aditya Kumar <1894981+hiradi...@users.noreply.github.com>
> Date: Thu A
FYI libc++ patch sent for review: https://reviews.llvm.org/D85873
On 8/13/20 11:21 AM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Jason Merrill wrote:
On 8/10/20 2:18 PM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Patrick Palka wrote:
In the below testcase, semantic analysis of the requires-expressions in
the generic lambda must be delayed until instantiatio
Revised patch with _GLIBCXX_COLD added at the end.
```
commit 3dc9f9a8461b1c88e991ceb517e5fdd81f268d1e
Author: Aditya Kumar <1894981+hiradi...@users.noreply.github.com>
Date: Thu Aug 13 09:41:34 2020 -0700
Add cold attribute to one time construction APIs
__cxa_guard_acquire is used
On Tue, 2020-07-28 at 19:24 -0600, Martin Sebor via Gcc-patches wrote:
> Patch 5 adds support for -Warray-bounds to detect out of bounds accesses
> in functions that take array/VLA arguments. The changes also enable
> the warning for dynamically allocated memory and with it the detection
> of acce
This would help compiler optimize local static objects.
```
commit e2f299679ddf56a6d6d71ea9d589cd76b2ca107b
Author: Aditya Kumar <1894981+hiradi...@users.noreply.github.com>
Date: Thu Aug 13 09:41:34 2020 -0700
Add cold attribute to one time construction APIs
__cxa_guard_acquire is
2020-08-12 Sandra Loosemore
gcc/c
* c-decl.c (c_break_label, c_cont_label): Delete, and replace
with...
(in_statement): New.
(start_function): Adjust for above change.
(c_push_function_context, c_pop_function_context): Likewise.
* c-lang.h
Switching the C++ front end to lower loops the same was as the C front
end triggered this error when bootstrapping the Fortran front end:
/path/to/gcc/fortran/interface.c:3546:12: error: '*new_arg' may be used
uninitialized [-Werror=maybe-uninitialized]
3546 | new_arg[i]->next = NULL;
|
This is a revised version of the patch set originally posted
last November:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534142.html
In addition to generally updating and rebasing the patches to reflect
other changes on mainline in the meantime, for this version I have
switched to usin
This patch moves the definitions for DO_STMT, FOR_STMT, WHILE_STMT,
SWITCH_STMT, BREAK_STMT, and CONTINUE_STMT from the C++ front end to
c-family. This includes the genericizers, pretty-printers, and dump
support as well as the tree definitions and accessors. Some related
code for OMP_FOR and sim
The C and C++ front ends used to use the same strategy of lowering
loops to gotos with the end test canonicalized to the bottom of the
loop. In 2014 the C++ front end was changed to emit LOOP_EXPRs
instead (commit 1a45860e7757ee054f6bf98bee4ebe5c661dfb90).
As part of the unification of the C and
On Tue, 2020-07-28 at 19:22 -0600, Martin Sebor via Gcc-patches wrote:
> Patch 4 adds support to the machinery behind -Wstringop-overflow
> to issue warnings for (likely) out of bounds accesses in calls to
> functions with the internal attribute access specification. This
> implements the feature
On Tue, 2020-07-28 at 19:20 -0600, Martin Sebor via Gcc-patches wrote:
> Patch 3 adjusts tree-ssa-uninit.c to the changes to attribute access but
> has only a cosmetic effect on informational notes in -Wuninitialized.
> [3/5] - Make use of new attribute access infrastructure in tree-ssa-uninit.c.
>
On Fri, 2020-07-31 at 17:55 -0600, Martin Sebor via Gcc-patches wrote:
> The folders for these functions (and some others) call c_getsr
> which relies on string_constant to return the representation of
> constant strings. Because the function doesn't handle constants
> of other types, including ag
GCC maintainers:
The macro expansion for the bfloat convert intrinsics XVCVBF16SP and
XVCVSPBF16 need to be restricted to P10.
The macro expansions BU_P10V_0, BU_P10V_1, BU_P10V_2, BU_P10V_3 expand
the name field as "__builtin_altivec_". These macro expansions are
being used for both VSX and Alt
On Fri, 2020-07-17 at 13:00 -0600, Martin Sebor via Gcc-patches wrote:
> The recent enhancement to treat the implicit this pointer argument
> as nonnull in member functions triggers spurious -Wnonnull for
> the synthesized conditional expression the C++ front end replaces
> the pointer with in some
On 13/08/20 16:39 +0100, Jonathan Wakely wrote:
On 13/08/20 16:37 +0100, Jonathan Wakely wrote:
These headers do not offer any tangible benefit compared to the default
c_global version. They are not actively maintained meaning that they
have bugs which have already been fixed for the c_global he
On 13/08/20 16:37 +0100, Jonathan Wakely wrote:
These headers do not offer any tangible benefit compared to the default
c_global version. They are not actively maintained meaning that they
have bugs which have already been fixed for the c_global headers.
This change adds a warning if they are us
These headers do not offer any tangible benefit compared to the default
c_global version. They are not actively maintained meaning that they
have bugs which have already been fixed for the c_global headers.
This change adds a warning if they are used, and requires a new
--enable-cheaders-obsolete
Hi All,
The fix for PR9601 is rather trivial and is the last chunk of the patch.
Finding the fix for PR96100 took a silly amount of time but it now looks
rather obvious. Trying to evaluate the string length by calling
gfc_conv_expr_descriptor, when this function is already failing to find it
is ki
On Mon, 10 Aug 2020, Jason Merrill wrote:
> On 8/10/20 2:18 PM, Patrick Palka wrote:
> > On Mon, 10 Aug 2020, Patrick Palka wrote:
> >
> > > In the below testcase, semantic analysis of the requires-expressions in
> > > the generic lambda must be delayed until instantiation of the lambda
> > > bec
On 8/12/20 1:02 PM, Tamar Christina wrote:
Hmm the regression on exchange2 is 11%. Or 1.22% on specint 2017 overall..
This is a rather big regression.. What would be the correct way to do this?
I can confirm that many our LNT tester configurations spotted that:
https://lnt.opensuse.org/db_defa
Hi Thomas,
thanks for the review. Committed to trunk.
That's what I am here for: to fix some issues with coarrays.
Regards,
Andre
On Wed, 12 Aug 2020 18:58:01 +0200
Thomas Koenig wrote:
> Hi Andre,
>
> > Regtests ok on FC31.x86_64. Ok for trunk?
>
> Good thing you're back! Any help w
From: Joe Ramsay
Hi,
Previously, the machine description patterns for vst1q accepted a generic memory
operand for the destination, which could lead to an unrecognised builtin when
expanding vst1q* intrinsics. This change fixes the patterns to only accept MVE
memory operands.
Tested on arm-none-
From: Joe Ramsay
Hi,
This patch fixes an issue with vmin* and vmax* intrinsics which accept
a scalar argument. Previously when the scalar was of different width
to the vector elements this would generate __ARM_undef. This change
allows the scalar argument to be implicitly converted to the correc
Richard Sandiford writes:
> Senthil Kumar via Gcc-patches writes:
>> Hi,
>>
>> I'm working on converting the AVR backend to MODE_CC, following
>> the steps described for case #2 in the CC0 transition wiki page,
>> and I've implemented the first three bullet
>> points (https://github.com
On Thu, Aug 13, 2020 at 01:55:40PM +0100, Iain Sandoe wrote:
> diff --git a/gcc/vec.h b/gcc/vec.h
> index db48e97..a8fca34 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -623,7 +623,7 @@ public:
>/* FIXME - These fields should be private, but we need to cater to
>compilers that hav
On Thu, Aug 13, 2020 at 01:46:53PM +0100, Iain Sandoe wrote:
> Jakub Jelinek via Gcc-patches wrote:
>
> > On Thu, Aug 13, 2020 at 02:06:21PM +0200, Tobias Burnus wrote:
> > > Build server is x86_64-gnu-linux, "i686-pc-linux-gnu-g++" is a
> > > native binary of GCC 5.2.0
> > > [Don't ask why i686
Iain Sandoe via Gcc-patches wrote:
Jakub Jelinek via Gcc-patches wrote:
On Thu, Aug 13, 2020 at 02:06:21PM +0200, Tobias Burnus wrote:
Build server is x86_64-gnu-linux, "i686-pc-linux-gnu-g++" is a native
binary of GCC 5.2.0
[Don't ask why i686 and not x86_64 is used.]
Ah, ok, so this b
>
> Thanks for the information :) Tamar replied that there is another
> regression *on exchange2 is 11%.*, I've also rebased my code and confirmed
> it really getting even slower than before (revert the patch could pull the
> performance back)...
Yep, we need to figure out how to fix this - the
As mentioned in the PR, we miss one initialization of ::punned
in vn_reference_lookup_call.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/96597
* tree-ssa-sccvn.c (vn_reference_lo
Jakub Jelinek via Gcc-patches wrote:
On Thu, Aug 13, 2020 at 02:06:21PM +0200, Tobias Burnus wrote:
Build server is x86_64-gnu-linux, "i686-pc-linux-gnu-g++" is a native
binary of GCC 5.2.0
[Don't ask why i686 and not x86_64 is used.]
Ah, ok, so this boils down to:
int i = alignof (long lo
On Thu, Aug 13, 2020 at 02:25:42PM +0200, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/vec.h.jj 2020-08-12 12:45:58.410686880 +0200
> +++ gcc/vec.h 2020-08-13 14:18:06.967041880 +0200
> @@ -1281,10 +1281,11 @@ template
> inline size_t
> vec::embedded_size (unsigned alloc)
> {
> - struct
On Thu, Aug 13, 2020 at 02:06:21PM +0200, Tobias Burnus wrote:
> Build server is x86_64-gnu-linux, "i686-pc-linux-gnu-g++" is a native binary
> of GCC 5.2.0
> [Don't ask why i686 and not x86_64 is used.]
Ah, ok, so this boils down to:
int i = alignof (long long int);
struct TTT { char a; long lon
Christophe Lyon writes:
> On Thu, 13 Aug 2020 at 03:54, qiaopeixin wrote:
>>
>> Thanks for the review and commit.
>>
>> All the best,
>> Peixin
>>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: 2020年8月13日 0:25
>> To: qiaopeixin
>> Cc: gcc-pat
On 8/13/20 1:52 PM, Jakub Jelinek wrote:
On Thu, Aug 13, 2020 at 01:38:07PM +0200, Tobias Burnus wrote:
I got a bit lost in this thread – but the
commit r11-2663-g82c4b78dbef6f03838e3040688c934360a09513f
"Replace std::vector<> usage in ipa-fnsummary.c with GCC's vec<>."
Causes here:
gcc-mainl
Here, the ${host} compiler was newer, supporting C++11 by default
while the ${build} compiler required -std=c++11.
Hence, the build failed.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsfüh
On Thu, Aug 13, 2020 at 01:38:07PM +0200, Tobias Burnus wrote:
> Hi,
>
> I got a bit lost in this thread – but the
> commit r11-2663-g82c4b78dbef6f03838e3040688c934360a09513f
> "Replace std::vector<> usage in ipa-fnsummary.c with GCC's vec<>."
>
> Causes here:
>
> gcc-mainline/gcc/vec.h:1287:3:
Hi,
On Thu, 13 Aug 2020 at 03:54, qiaopeixin wrote:
>
> Thanks for the review and commit.
>
> All the best,
> Peixin
>
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: 2020年8月13日 0:25
> To: qiaopeixin
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re:
Hi,
I got a bit lost in this thread – but the
commit r11-2663-g82c4b78dbef6f03838e3040688c934360a09513f
"Replace std::vector<> usage in ipa-fnsummary.c with GCC's vec<>."
Causes here:
gcc-mainline/gcc/vec.h:1287:3: error: static assertion failed:
static_assert (alignof (vec_embedded) == alig
On Thu, Aug 13, 2020 at 10:28 AM Roger Sayle wrote:
>
>
> This patch is an alternate/supplementary fix to the recent regression
> PR target/96558. Currently ix86_expand_clear may/should only be called
> with a general register DEST after reload_completed. With the simple
> change below, this fun
On 7/20/20 3:19 PM, Kwok Cheung Yeung wrote:
> On 01/07/2020 3:28 pm, Tom de Vries wrote:
>> So, I think gcc needs a copy of (some of) the
>> gcc/testsuite/gcc.dg/ia64-sync-*.c tests for effective target
>> sync_char_short.
>>
>> However, since this patch only adds partial support, we cannot enable
On 8/13/20 10:25 AM, Jose E. Marchesi wrote:
On 8/12/20 9:12 PM, Jose E. Marchesi wrote:
1) CHERRY_PICK_PREFIX = '(cherry picked from commit ' and I used
a slightly differnt wording.
Yes, you used a bit different wording :)
2) If I am not mistaken while reading the script, the CHERRY_
Doh! ENOPATCH.
-Original Message-
From: Roger Sayle
Sent: 13 August 2020 09:29
To: 'GCC Patches'
Cc: 'Uros Bizjak'
Subject: [PATCH] Alternate fix to PR target/96558: Robustify
ix86_expand_clear.
This patch is an alternate/supplementary fix to the recent regression PR
target/96558.
This patch is an alternate/supplementary fix to the recent regression
PR target/96558. Currently ix86_expand_clear may/should only be called
with a general register DEST after reload_completed. With the simple
change below, this function now checks these conditions itself, and
does the right th
> On 8/12/20 9:12 PM, Jose E. Marchesi wrote:
>> 1) CHERRY_PICK_PREFIX = '(cherry picked from commit ' and I used
>> a slightly differnt wording.
>
> Yes, you used a bit different wording :)
>
>> 2) If I am not mistaken while reading the script, the CHERRY_PICK
>> line
>> should be part o
On 8/12/20 7:03 PM, Martin Liška wrote:
There's an updated version of the patch that is approved by Honza.
I'm going to install it (and I'll backport it as well).
Martin
And there's one obvious fix that aligns code in
ipcp_bits_lattice::set_to_constant
with ipcp_bits_lattice::meet_with_1.
P
> Hi!
>
> On Wed, Aug 12, 2020 at 09:03:35PM +0200, Richard Biener wrote:
> > On August 12, 2020 7:53:07 PM GMT+02:00, Jan Hubicka wrote:
> > >> From: Xiong Hu Luo
> > >> 523.xalancbmk_r +1.32%
> > >> 541.leela_r +1.51%
> > >> 548.exchange2_r +31.87%
> > >> 507.cactuBSSN_r +0.80%
> > >> 526.
Hi!
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020-08-13 Jakub Jelinek
* gimplify.c (gimplify_omp_taskloop_expr): New function.
(gimplify_omp_for): Use it. For OMP_FOR_NON_RECTANGULAR
loops adjust in outer taskloop the var-outer decls.
On 8/12/20 9:12 PM, Jose E. Marchesi wrote:
1) CHERRY_PICK_PREFIX = '(cherry picked from commit ' and I used
a slightly differnt wording.
Yes, you used a bit different wording :)
2) If I am not mistaken while reading the script, the CHERRY_PICK line
should be part of the ChangeLog en
82 matches
Mail list logo
