In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has handled
misaligned stores, but it didn't handle PARALLEL values, and I refer the
other part of this function, I found the PARALLEL need handled by
emit_group_* functions, so I add a check, and using emit_group_store if
storing
Hi,
As Segher's suggestion in the PR, for 128bit_direct_move, this new
version leverages vector pack insns instead of vector perms with
one control vector. The performance evaluation shows that it's on
par with the previous version for char, while it's better than the
previous for short.
Hi, Jason
> On 9/9/20 6:25 AM, Hu Jiangping wrote:
> > This patch check the command 'make check-g++' to 'make check-c++' in
> > install.texi since there is no 'make check-g++' target in the object
> > directory.
>
> make check-g++ works fine for me in the object directory. And
>
We would like to be able to use these things without having to pull in
the whole of .
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in: Regenerate.
* include/bits/align.h: New file.
* include/std/memory (align): Move definition to
On 9/9/20 7:32 AM, JonY wrote:
> On 9/9/20 7:21 AM, Richard Biener wrote:
>> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
>> wrote:
>>>
>>> Hello,
>>>
>>> The lto plugis are tied to the built GCC anyway, so there isn't much
>>> point to versioning them.
>>
>> In fact the lto plugins are
On 9/9/20 3:13 PM, Jason Merrill wrote:
My impression from Jeff's analysis in January and David's in March was
that many of the testsuite changes were from the C++ approach actually
providing better results, so the reversal here surprises me. Can you
talk more about the regressions you're
In a recent change I added an incorrect adjustment to the conversion
of an offset range with inverted bounds (i.e., upper less than lower)
that caused a regression I overlooked in testing. Attached is a fix
for this tested on x86_64-linux, and with a more comprehensive test.
I plan to commit
Excerpts from Rainer Orth's message of September 8, 2020 11:34 pm:
> Hi Iain,
>
---
libphobos/ChangeLog:
PR d/95680
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac (DCFG_ENABLE_CET): Substitute.
*
On Wed, Sep 09, 2020 at 05:30:33PM -0500, Pat Haugen wrote:
> On 9/9/20 4:41 PM, Segher Boessenkool wrote:
> > On Wed, Sep 09, 2020 at 04:14:37PM -0500, Pat Haugen wrote:
> > Can we rename mftgpr/mffgpr globally? Maybe even as mfvsr and mtvsr,
> > because that is what is actually modeled here?
On 9/9/20 4:41 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 09, 2020 at 04:14:37PM -0500, Pat Haugen wrote:
>> I noticed that some of the VSR<->GPR move instructions are not typed
>> correctly. This patch fixes those instructions so that the scheduler
>> treats them with the correct
On 9/9/20 6:25 AM, Hu Jiangping wrote:
This patch check the command 'make check-g++' to 'make check-c++' in
install.texi since there is no 'make check-g++' target in the object
directory.
make check-g++ works fine for me in the object directory. And
gcc/cp/Make-lang.in includes
# 'make
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
Aldy provided a bunch of comments on this patch but I'm still looking
for a formal approval.
Martin
On 8/24/20 10:45 AM, Martin Sebor wrote:
On 8/24/20 4:59 AM, Aldy Hernandez wrote:
On 8/21/20 1:37 AM, Martin Sebor
On 9/9/20 5:35 PM, Marek Polacek wrote:
On Wed, Sep 09, 2020 at 05:02:24PM -0400, Jason Merrill wrote:
On 9/8/20 10:34 PM, Marek Polacek wrote:
On Tue, Sep 08, 2020 at 04:19:42PM -0400, Jason Merrill wrote:
On 9/8/20 4:06 PM, Marek Polacek wrote:
On Mon, Sep 07, 2020 at 11:19:47PM -0400,
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
On 8/28/20 11:12 AM, Martin Sebor wrote:
The gimple_call_alloc_size() function that determines the range
of sizes of allocated objects and constrains the bounds in calls
to functions like memcpy calls get_range() instead of
Hi!
On Wed, Sep 09, 2020 at 04:14:37PM -0500, Pat Haugen wrote:
> I noticed that some of the VSR<->GPR move instructions are not typed
> correctly. This patch fixes those instructions so that the scheduler
> treats them with the correct latency.
> --- a/gcc/config/rs6000/rs6000.md
> +++
Joseph, do you have any concerns with or comments on the most
recent patch or is it okay as is?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
Martin
On 9/2/20 6:03 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
On 8/25/20
On Wed, Sep 09, 2020 at 05:02:24PM -0400, Jason Merrill wrote:
> On 9/8/20 10:34 PM, Marek Polacek wrote:
> > On Tue, Sep 08, 2020 at 04:19:42PM -0400, Jason Merrill wrote:
> > > On 9/8/20 4:06 PM, Marek Polacek wrote:
> > > > On Mon, Sep 07, 2020 at 11:19:47PM -0400, Jason Merrill wrote:
> > > >
This patch generalizes the state machine in sm-malloc.cc to support
multiple allocator APIs, and adds just enough support for C++ new and
delete to demonstrate the feature, allowing for detection of code
paths where the result of new in C++ can leak - for some crude examples,
at least (bearing in
I noticed that some of the VSR<->GPR move instructions are not typed
correctly. This patch fixes those instructions so that the scheduler
treats them with the correct latency.
Bootstrap/regtest on powerpc64le with no new regressions. Also ran a
CPU2017 benchmark comparison on Power9 with no major
On 8/13/20 12:34 PM, Sandra Loosemore wrote:
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
This patch is preliminary work towards generalizing sm-malloc.cc so that
it can check APIs other than just malloc/free (and e.g. detect
mismatching alloc/dealloc pairs).
Generalize states in state machines so that, rather than state_t being
just an "unsigned", it becomes a "const state *", where
This patch is yet more preliminary work towards generalizing sm-malloc.cc
beyond just malloc/free.
It eliminates sm_context::warn_for_state in terms of a new sm_context::warn
vfunc, guarded by sm_context::get_state calls.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to
This patch is further preliminary work towards generalizing sm-malloc.cc
beyond just malloc/free.
Reimplement sm_context's on_transition vfunc in terms of new get_state
and set_next_state vfuncs, so that in followup patches we can implement
richer transitions (e.g. where the states are
On 9/9/20 3:33 PM, Marek Polacek wrote:
On Mon, Sep 07, 2020 at 06:23:01PM -0400, Jason Merrill via Gcc-patches wrote:
On 9/4/20 5:39 PM, Marek Polacek wrote:
This patch fixes a long-standing bug in reshape_init_r. Since r209314
we implement DR 1467 which handles list-initialization with a
On 9/8/20 10:34 PM, Marek Polacek wrote:
On Tue, Sep 08, 2020 at 04:19:42PM -0400, Jason Merrill wrote:
On 9/8/20 4:06 PM, Marek Polacek wrote:
On Mon, Sep 07, 2020 at 11:19:47PM -0400, Jason Merrill wrote:
On 9/6/20 11:34 AM, Marek Polacek wrote:
@@ -3944,9 +3935,9 @@ build_new (location_t
libstdc++: Add std::advance overload for ostreambuf_iterator
Implement std::advance overload for ostreambuf_iterator using
basic_streambuf
pubseekof.
libstdc++-v3/ChangeLog:
* include/bits/streambuf_iterator.h (ostreambuf_iterator): Add
std::advance friend declaration.
libstdc++: Use only public basic_streambuf methods in std::advance overload
std::advance overload for istreambuf_iterator can be implemented using
basic_streambuf public pubseekoff method so that it doesn't have to be
basic_streambuf friend.
libstdc++-v3/ChangeLog:
*
libstdc++: Use only public basic_streambuf methods in __copy_move_a2
overload
__copy_move_a2 for istreambuf_iterator can be implemented using public
basic_streambuf in_avail and sgetn so that __copy_move_a2 do not need to be
basic_streambuf friend.
libstdc++-v3/ChangeLog:
*
On Wed, 9 Sep 2020, Caroline Tice via Gcc-patches wrote:
> For DWARF v5 Dwarf Package Files (.dwp files), the section identifier
> encodings have changed. This patch updates dwarf2.h to contain the new
> encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5).
>
> This patch has
Hi,
I added some fixes to binutils gas to make sure that it always
generates DWARF5 style .debug_rnglists and .debug_line with
.debug_line_str which are more efficient than the older .debug_ranges
and .debug_line data.
There is also a pending patch to make it possible to always pass
--gdwarf-N
On 9/9/2020 2:13 AM, Richard Biener wrote:
Thanks for working on this. Speaking about performance and
accuracy I spot a few opportunities to use FMAs [and eventually
vectorization] - do FMAs change anything on the accuracy analysis
(is there the chance they'd make it worse?). We might want
omp reductions are modeled as nested functions, which is a thing C++
doesn't have. Leading to much confusion until I figured out what was
happening. Not helped by some duplicate code and inconsistencies in
the dependent and non-dependent paths. This patch removes the parser
duplication and
On Mon, Sep 07, 2020 at 06:23:01PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/4/20 5:39 PM, Marek Polacek wrote:
> > This patch fixes a long-standing bug in reshape_init_r. Since r209314
> > we implement DR 1467 which handles list-initialization with a single
> > initializer of the same
Now that the documentation for partial modes says they have a known
number of bits of precision, would it make sense for extract_low_bits to
check this before attempting to extract the bits?
This would solve the problem we have been having with POImode and
extract_low_bits -- DSE tries to use it
This test uses C++14 features so is failing with -std=c++11.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wnonnull6.C: Use target c++14.
---
gcc/testsuite/g++.dg/warn/Wnonnull6.C | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
For DWARF v5 Dwarf Package Files (.dwp files), the section identifier
encodings have changed. This patch updates dwarf2.h to contain the new
encodings. (see http://dwarfstd.org/doc/DWARF5.pdf, section 7.3.5).
This patch has already been committed in binutils, but it needs to go into GCC
as well
This patch implements the Fortran support for adding "#pragma acc loop
auto" annotations to loops in OpenACC kernels regions. It implements
the same -fopenacc-kernels-annotate-loops and
-Wopenacc-kernels-annotate-loops options that were previously added
(and documented) for the C/C++ front ends.
This set of patches implements C/C++ and Fortran front end support for
adding "acc loop auto" annotations to loop nests in OpenACC kernels
regions. For background on this, refer to Thomas Schwinge's talk from
last year's cauldron, at
This patch detects loops in kernels regions that are candidates for
parallelization, and adds "#pragma acc loop auto" annotations to them.
This annotation is controlled by the -fopenacc-kernels-annotate-loops
option, which is enabled by default. -Wopenacc-kernels-annotate-loops
can be used to
This test uses a C++14 feature so fails with -std=c++11. Therefore
I've moved it to cpp1y/ and used target c++14.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/auto-96647.C: Moved to...
* g++.dg/cpp1y/auto-96647.C: ...here. Use target c++14.
---
gcc/testsuite/g++.dg/{cpp0x =>
Ping again on this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551927.html
These patches just missed making it into GCC 10 last year -- although
there seemed to be agreement in principle, they needed a bit more work
to resolve test regressions. Now that we are heading
On Wed, Sep 9, 2020 at 1:17 AM Hongtao Liu wrote:
>
> On Wed, Sep 9, 2020 at 2:35 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 09, 2020 at 10:30:46AM +0800, Hongtao Liu wrote:
> > > From 400418fadce46e7db7bd37be45ef5ff5beb08d19 Mon Sep 17 00:00:00 2001
> > > From: liuhongt
> > > Date: Tue, 8 Sep
Hi,
When building for target nvptx, we get this and similar warnings for libgcc:
...
src/libgcc/config/nvptx/atomic.c:39:1: warning: conflicting types for \
built-in function ‘__sync_val_compare_and_swap_1’; expected \
‘unsigned char(volatile void *, unsigned char, unsigned char)’ \
Excerpts from H.J. Lu's message of September 9, 2020 7:08 pm:
> On Mon, Sep 7, 2020 at 7:09 PM H.J. Lu wrote:
>>
>> On Mon, Sep 7, 2020 at 2:35 PM Iain Buclaw wrote:
>> >
>> > Hi,
>> >
>> > This patch removes whatever CET support was in the switchContext routine
>> > for x86 D runtime, and
On Mon, Sep 7, 2020 at 7:09 PM H.J. Lu wrote:
>
> On Mon, Sep 7, 2020 at 2:35 PM Iain Buclaw wrote:
> >
> > Hi,
> >
> > This patch removes whatever CET support was in the switchContext routine
> > for x86 D runtime, and instead uses the ucontext fallback, which propely
> > handles shadow stack
Hi all,
this patch is meant not to generate predication in loop when the
loop is operating only on full vectors.
Ex:
#+BEGIN_SRC C
/* Vector length is 256. */
void
f (int *restrict x, int *restrict y, unsigned int n) {
for (unsigned int i = 0; i < n * 8; ++i)
x[i] += y[i];
}
#+END_SRC
On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > > Hmm, yeah - I guess that's what should be addressed first then.
> > > I'm quite
ThunderxT2 chip has an odd property that nested scalar FP min and max are
slower than logically the same sequence of compares and branches.
Here is the patch where I'm trying to implement that transformation.
Please advise if the "combine" pass (actually after the pass itself) is the
appropriate
Hi Tom,
On 9/9/20 3:15 PM, Tom de Vries wrote:
And I observe the following fails – which seems
to be new and related to your patch (but I have not confirmed it by
reverting your libatomic patch).
Could you confirm that?
It is an indenpend issue; it is newish and I can reproduce
it on
Hello,
On Tue, 8 Sep 2020, Richard Biener wrote:
> CCing some people to double-check my graph partitioning algorithm.
I seem to not know the pre-existing data structures enough to say anything
about this, but I noticed small things which might or might not indicate
thinkos or incompleteness:
On 9/9/20 4:14 PM, Tom de Vries wrote:
> On 9/9/20 3:15 PM, Tom de Vries wrote:
>> On 9/9/20 2:36 PM, Tobias Burnus wrote:
>>> Hi Tom,
>>>
>>> On 9/8/20 5:05 PM, Tobias Burnus wrote:
>>>
On 9/8/20 8:51 AM, Tom de Vries wrote:
> PR target/96964
> * config/nvptx/nvptx.md
On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > Hmm, yeah - I guess that's what should be addressed first then.
> > I'm quite sure that in case 'v' is not on the stack but in memory like
> > in my case a
On 9/9/20 3:15 PM, Tom de Vries wrote:
> On 9/9/20 2:36 PM, Tobias Burnus wrote:
>> Hi Tom,
>>
>> On 9/8/20 5:05 PM, Tobias Burnus wrote:
>>
>>> On 9/8/20 8:51 AM, Tom de Vries wrote:
PR target/96964
* config/nvptx/nvptx.md (define_expand "atomic_test_and_set"): New
Hi,
I'm running into this warning:
...
src/gcc/config/nvptx/nvptx.c: In function \
‘void nvptx_assemble_decl_begin(FILE*, const char*, const char*, \
const_tree, long int, unsigned int, bool)’:
src/gcc/config/nvptx/nvptx.c:2229:29: warning: format ‘%d’ expects argument \
of type ‘int’, but
Hi!
On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> Hmm, yeah - I guess that's what should be addressed first then.
> I'm quite sure that in case 'v' is not on the stack but in memory like
> in my case a SImode store is better than what we get from
> vec_insert - in fact
Thank you!
Felix
-Original Message-
From: Joseph Myers
Sent: Dienstag, 8. September 2020 19:40
To: Willgerodt, Felix
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PING] floatformat.h: Add bfloat16 support.
On Tue, 8 Sep 2020, Willgerodt, Felix via Gcc-patches wrote:
> Thanks for your
On 9/9/20 2:36 PM, Tobias Burnus wrote:
> Hi Tom,
>
> On 9/8/20 5:05 PM, Tobias Burnus wrote:
>
>> On 9/8/20 8:51 AM, Tom de Vries wrote:
>>> PR target/96964
>>> * config/nvptx/nvptx.md (define_expand "atomic_test_and_set"): New
>>> expansion.
>>> * sync-builtins.def
This avoids unsharing the SLP tree when optimizing load permutations
for reductions but there is no actual permute taking place.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-09-09 Richard Biener
* tree-vect-slp.c (vect_attempt_slp_rearrange_stmts): Do
Hi Tom,
On 9/8/20 5:05 PM, Tobias Burnus wrote:
On 9/8/20 8:51 AM, Tom de Vries wrote:
PR target/96964
* config/nvptx/nvptx.md (define_expand "atomic_test_and_set"): New
expansion.
* sync-builtins.def (BUILT_IN_ATOMIC_TEST_AND_SET_1): New builtin.
I have your patch applied
Hi,
When running this libgomp testcase for nvptx accelerator:
...
/* { dg-do run } */
__uint128_t v;
int main () {
#pragma omp target
{
__uint128_t exp = 2;
__atomic_compare_exchange_n (, , 7, false, __ATOMIC_RELEASE,
__ATOMIC_ACQUIRE);
}
}
...
we
OG10 = devel/omp/gcc-10
I have merged releases/gcc-10 into that branch.
This included the
'Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690)'
commit, which differs between mainline and GCC 10 – and OG10 is closer
to mainline. Hence, the attached patch was committed as
There is no CFA information generated for instructions which manipulate the
stack during function epilogues. This means a debugger cannot determine the
position of variables on the stack whilst the epilogue is in progress.
This can cause the debugger to give erroneous information when printing a
Hi Alex,
> -Original Message-
> From: Alex Coplan
> Sent: 09 September 2020 11:15
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: [PATCH 1/2] aarch64: Add support for Armv8-R
>
> Hello,
>
> This patch adds
> -Original Message-
> From: Alex Coplan
> Sent: 09 September 2020 11:15
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: [PATCH 2/2] aarch64: Add support for Cortex-R82
>
> This patch adds support for Arm's
This patch check the command 'make check-g++' to 'make check-c++' in
install.texi since there is no 'make check-g++' target in the object
directory. It also adds some description in the above text, to clarity
and emphasis the difference of the 'make check-' targets in
between object directory and
On 9/9/20 8:54 AM, Jakub Jelinek wrote:
On Tue, Sep 08, 2020 at 12:22:57PM +0200, Tobias Burnus wrote:
gcc/testsuite/ChangeLog:
PR fortran/95109
PR fortran/94690
* gfortran.dg/gomp/combined-if.f90: Update scan-tree-dump-times for
'omp simd.*if'.
*
This removes a check preventing vectorization of live results of
vectorized comparisons. I tested it with AVX512 mask registers
(inspecting assembly) and traditional vector masks.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
One alternative to live stmt vectorization is forcing of a
This patch adds support for Arm's Cortex-R82 CPU to GCC. For more
information about this CPU, see [0].
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu, no regressions.
[0] : https://developer.arm.com/ip-products/processors/cortex-r/cortex-r82
OK for trunk?
---
gcc/ChangeLog:
Hello,
This patch adds support for Armv8-R AArch64 to GCC. It adds the -march
value armv8-r and sets the ACLE feature macro __ARM_ARCH_PROFILE
correctly when -march is set to armv8-r.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
* New unit test to check ACLE macro.
OK for
This removes a check preventing vectorization of live results of
vectorized conditions.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-09-09 Richard Biener
* tree-vect-stmts.c (vectorizable_condition): Allow
STMT_VINFO_LIVE_P stmts.
*
Hi Segher,
Thanks for your advice. I removed macros defined in linux64.h and
linux.h. So they take relative jump tables by default. When
no-relative-jumptables is set, the absolute jump tables are taken. All
things relevant to section relocations are put in another patch. Thanks
again.
On Wed, Sep 9, 2020 at 10:43 AM Hu, Jiangping
wrote:
>
> Hi, Richard
>
> > On Tue, Sep 8, 2020 at 11:35 AM Hu Jiangping
> > wrote:
> > >
> > > This patch add a new check-g++ target to the Makefile under toplevel,
> > > as synonym of the check-c++ target.
> > >
> > > It is to be consistent with
Hi, Richard
> On Tue, Sep 8, 2020 at 11:35 AM Hu Jiangping
> wrote:
> >
> > This patch add a new check-g++ target to the Makefile under toplevel,
> > as synonym of the check-c++ target.
> >
> > It is to be consistent with the check-g++ target under the gcc
> > subdirectory. And because
> Przemyslaw Wirkus writes:
> > Hello maintainers,
> >
> > Can I backport this patch to GCC 10 please ?
>
> Sure, that's fine.
commit 41d22ec51c4190133a082197e7ff67b4741fc09b
Date: Fri Aug 28 11:31:04 2020 +0100
> Thanks,
> Richard
>
> >
> > Regards
> > Przemyslaw
> >
> >> Committed with:
>
Przemyslaw Wirkus writes:
> Hello maintainers,
>
> Can I backport this patch to GCC 10 please ?
Sure, that's fine.
Thanks,
Richard
>
> Regards
> Przemyslaw
>
>> Committed with:
>>
>> commit b648814c02eb418aaf27897c480452172ee96303
>> Date: Fri Aug 28 11:31:04 2020 +0100
>>
>> Kind regards,
Hello maintainers,
Can I backport this patch to GCC 10 please ?
Regards
Przemyslaw
> Committed with:
>
> commit b648814c02eb418aaf27897c480452172ee96303
> Date: Fri Aug 28 11:31:04 2020 +0100
>
> Kind regards,
> Przemyslaw
On Wed, Sep 9, 2020 at 2:35 PM Jakub Jelinek wrote:
>
> On Wed, Sep 09, 2020 at 10:30:46AM +0800, Hongtao Liu wrote:
> > From 400418fadce46e7db7bd37be45ef5ff5beb08d19 Mon Sep 17 00:00:00 2001
> > From: liuhongt
> > Date: Tue, 8 Sep 2020 15:44:58 +0800
> > Subject: [PATCH] Implement
Andrea Corallo writes:
> Andrea Corallo writes:
>
>> Hi Alex,
>>
>> Looking at the code I believe all these casts are meant to be supported
>> (read your intuition was correct).
>>
>> Also IMO source of confusion is that the doc is mentioning 'int' and
>> 'float' but I believe would be better
Andrea Corallo writes:
[...]
> Sure it is, thanks for reviewing.
>
> Attached the updated version of the patch.
>
> make check-jit is clean plus I tested the new entry point with the
> modified Emacs.
>
> Thanks
>
> Andrea
Ping
This avoids looking at STMT_VINFO_LIVE_P when vectorizing BBs.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2020-09-09 Richard Biener
PR tree-optimization/96978
* tree-vect-stmts.c (vectorizable_condition): Do not
look at STMT_VINFO_LIVE_P for BB
On Tue, Sep 8, 2020 at 11:35 AM Hu Jiangping wrote:
>
> This patch add a new check-g++ target to the Makefile under toplevel,
> as synonym of the check-c++ target.
>
> It is to be consistent with the check-g++ target under the gcc
> subdirectory. And because check-gcc can be performed under
On 9/9/20 7:21 AM, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
> wrote:
>>
>> Hello,
>>
>> The lto plugis are tied to the built GCC anyway, so there isn't much
>> point to versioning them.
>
> In fact the lto plugins are not tied to the built GCCs very much,
On Wed, Sep 9, 2020 at 3:47 AM luoxhu wrote:
>
>
>
> On 2020/9/8 16:26, Richard Biener wrote:
> >> Seems not only pseudo, for example "v = vec_insert (i, v, n);"
> >> the vector variable will be store to stack first, then [r112:DI] is a
> >> memory here to be processed. So the patch loads it
On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
wrote:
>
> Hello,
>
> The lto plugis are tied to the built GCC anyway, so there isn't much
> point to versioning them.
In fact the lto plugins are not tied to the built GCCs very much, instead
we try to ensure compatibility so that a single
On Tue, Sep 8, 2020 at 8:50 PM Patrick McGehearty via Gcc-patches
wrote:
>
> (Version 4)
>
> (Added in version 4)
> Fixed Changelog entry to include __divsc3, __divdc3, __divxc3, __divtc3.
> Revised description to avoid incorrect use of "ulp (units last place)".
> Modified float precison case to
On Tue, Sep 8, 2020 at 2:33 PM Nick Clifton via Gcc-patches
wrote:
>
> Hi Cary,
>
> If the lto plugin encounters a file with multiple symbol sections,
> each of which also has a v1 symbol extension section[1] then it will
> attempt to read the extension data for *every* symbol from each of
On Tue, Sep 08, 2020 at 12:22:57PM +0200, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/95109
> PR fortran/94690
> * resolve.c (gfc_resolve_code): Also call
> gfc_resolve_omp_parallel_blocks for 'distribute parallel do (simd)'.
> * openmp.c
On Wed, Sep 09, 2020 at 10:30:46AM +0800, Hongtao Liu wrote:
> From 400418fadce46e7db7bd37be45ef5ff5beb08d19 Mon Sep 17 00:00:00 2001
> From: liuhongt
> Date: Tue, 8 Sep 2020 15:44:58 +0800
> Subject: [PATCH] Implement __builtin_thread_pointer for x86 TLS.
>
> gcc/ChangeLog:
> PR
88 matches
Mail list logo
