Am Dienstag, den 27.07.2021, 10:55 -0600 schrieb Martin Sebor:
> On 7/26/21 12:22 PM, Jeff Law via Gcc-patches wrote:
> >
> > On 7/25/2021 10:23 AM, Uecker, Martin wrote:
> > > Two arguments are switched for -Wnonnull when
> > > warning about array parameters with bounds > 0
> > > and which are NU
On 7/27/21 10:04 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> libsanitizer/ChangeLog:
>
> * configure.tgt (s390*-*-linux*): Enable LSan and TSan for
> s390x.
Ok. Thanks!
Andreas
There are also memory operands passed for in0 and in1.
Ok for mainline?
gcc/ChangeLog:
* target.def: Describe in0 and in1 as being either register or
memory operands.
* doc/tm.texi: Regenerate.
---
gcc/doc/tm.texi | 7 ---
gcc/target.def | 7 ---
2 files changed
> -Original Message-
> From: Martin Jambor
> Sent: Tuesday, July 27, 2021 5:39 PM
> To: JiangNing OS ; Richard Biener
>
> Cc: GCC Patches ; Jan Hubicka
> Subject: RE: [RFC] ipa: Adjust references to identify read-only globals
>
> Hi,
>
> On Tue, Jul 27 2021, JiangNing OS wrote:
> >>
Hi,
v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571258.html
This v3 addressed William's review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576154.html
It's mainly to deal with the bwaves_r degradation due to vector
construction fed by strided loads.
As Richi's com
Recognize __builtin_free as being equivalent to free when passed into
__attribute__((malloc ())), similar to how it is treated when it is
encountered as a call. This fixes spurious warnings in glibc where
xmalloc family of allocators as well as reallocarray, memalign,
etc. are declared to have __b
On 7/26/21 2:13 PM, Sandra Loosemore wrote:
On 7/26/21 3:45 AM, Tobias Burnus wrote:
[snip]
PS: Still, it would be nice if the proper multi-lib ISO*.h could be
found;
while it usually does not matter, it could do so in some cases.
I think I ought to fix this now instead of just sweeping it
On 7/27/21 4:06 PM, will schmidt wrote:
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
2021-06-17 Bill Schmidt
Hi,
gcc/
* config/rs6000/rs6000-call.c (rs6000_expand_new_builtin): New
forward decl.
(rs6000_invalid_new_builtin): New stub fun
On Tue, Jul 27, 2021 at 8:31 AM H.J. Lu wrote:
>
> On Mon, Jul 26, 2021 at 4:19 PM H.J. Lu wrote:
> >
> > On Mon, Jul 26, 2021 at 3:56 PM H.J. Lu wrote:
> > >
> > > On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
> > > wrote:
> > > >
> > > > "H.J. Lu via Gcc-patches" writes:
> > > > > On Mon
1. Replace scalar_int_mode with fixed_size_mode in the by-pieces
infrastructure to allow non-integer mode.
2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size
to return QI vector mode for memset.
3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the
smallest integ
Hi William,
Thanks for the review comments!
on 2021/7/28 上午6:25, will schmidt wrote:
> On Wed, 2021-05-26 at 10:59 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>
>
> Hi,
>
>
>> This is the updated version of patch to deal with the bwaves_r
>> degradation due to vector construction fed by
On Wed, Jul 28, 2021 at 10:46 AM H.J. Lu wrote:
>
> On Tue, Jul 27, 2021 at 7:02 PM Hongtao Liu wrote:
> >
> > On Tue, Jul 27, 2021 at 10:46 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > There is no SSE <-> AVX transition penalty if the upper bits of YMM/ZMM
> > > registers are unchanged and
On Tue, Jul 27, 2021 at 9:54 AM Hongtao Liu wrote:
>
> On Mon, Jul 26, 2021 at 4:49 PM Hongtao Liu wrote:
> >
> > Correct mail list, please reply under this email.
> >
> > On Mon, Jul 26, 2021 at 4:47 PM liuhongt wrote:
> > >
> > > Hi:
> > > As decribled in PR, the pinsr instruction has poor t
On Tue, Jul 27, 2021 at 7:02 PM Hongtao Liu wrote:
>
> On Tue, Jul 27, 2021 at 10:46 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > There is no SSE <-> AVX transition penalty if the upper bits of YMM/ZMM
> > registers are unchanged and YMM/ZMM store doesn't change the upper bits
> > of YMM/ZMM regis
> Copy the test for _mm_minpos_epu16 from
> gcc/testsuite/gcc.target/i386/sse4_1-phminposuw.c, with
> a few adjustments:
>
> - Adjust the dejagnu directives for powerpc platform.
> - Make the data not be monotonically increasing,
> such that some of the returned values are not
> always the first
> Add a naive implementation of the subject x86 intrinsic to
> ease porting.
>
> 2021-07-15 Paul A. Clarke
>
> gcc
> * config/rs6000/smmintrin.h (_mm_minpos_epu16): New.
Segher already approved this with the changes requested.
Thanks, David
On Tue, Jul 27, 2021 at 10:46 PM H.J. Lu via Gcc-patches
wrote:
>
> There is no SSE <-> AVX transition penalty if the upper bits of YMM/ZMM
> registers are unchanged and YMM/ZMM store doesn't change the upper bits
> of YMM/ZMM registers.
>
> 1. Since zeroing YMM/ZMM register is implemented with ze
On Tue, Jul 27, 2021 at 6:39 PM Jakub Jelinek wrote:
>
> On Tue, Jul 27, 2021 at 06:33:24PM +0800, Hongtao Liu wrote:
> > > AVX2 introduced vector >> vector shifts, but unfortunately for
> > > V{2,4}DImode
> > > it only supports logical and not arithmetic shifts, only AVX512F for
> > > V8DImode o
On Jul 27, 2021, at 10:30 AM, Martin Sebor via Gcc-patches
wrote:
> On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote:
>> Secondly, releases are not issued by the GNU Project at all, they're
>> issued by the GCC release managers.
>
> I (and I suspect most users unfamiliar with the inner
On Wed, 2021-05-26 at 10:59 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
Hi,
> This is the updated version of patch to deal with the bwaves_r
> degradation due to vector construction fed by strided loads.
>
> As Richi's comments [1], this follows the similar idea to over
> price the vector
Hi Tobias,
> > We should rather open a separate PR on auditing the related uses
> > of gfc_match.
>
> I concur – I just wanted to quickly check how many %v are there –
> besides %v, there are also direct calls to gfc_match_variable.
>
> Can you open a PR?
this is now https://gcc.gnu.org/bugzill
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
Could use a longer description.
> gcc/
> * config/rs6000/rs6000.c (rs6000_builtin_reciprocal): Use
> rs6000_builtin_decls_x when appropriate.
> (add_condition_to_bb):
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
Description could be a bit longer. :-) (Even just a duplicate of the
mail subject to fill the space would prob be fine.)
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_new_builtin_
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-gen-builtins.c (write_init_file):
> Initialize new_builtins_are_live to 1.
> ---
> gcc/config/rs6000/rs6000-gen-builtins.c | 2 +-
> 1 file changed, 1
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-10 Bill Schmidt
>
> gcc/
> * config/rs6000/altivec.h: Delete a number of #defines that are
> now superfluous; include rs6000-vecdefines.h; include some
> synonyms.
> ---
> gcc/config/rs6000/altiv
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-04-01 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_debug_type): New function.
> (def_builtin): Change debug formatting for easier parsing and
> include more information.
> (rs6
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (elemrev_icode): Implement.
> (ldv_expand_builtin): Likewise.
> (lxvrse_expand_builtin): Likewise.
> (lxvrze_expand_builtin):
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-24 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000-call.c (new_htm_spr_num): New function.
> (new_htm_expand_builtin): Implement.
> (rs6000_expand_new_builtin): Handle 32-bit and endian cases.
> --
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-17 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (new_mma_expand_builtin):
> Implement.
Ok,
> ---
> gcc/config/rs6000/rs6000-call.c | 103
> 1 file cha
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (new_cpu_expand_builtin):
> Implement.
ok
> ---
> gcc/config/rs6000/rs6000-call.c | 100
> 1 file cha
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-03-05 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_invalid_new_builtin):
> Implement.
> (rs6000_expand_ldst_mask): Likewise.
> (rs6000_init_builtins): Initialize altivec_
On Thu, 2021-06-17 at 10:19 -0500, Bill Schmidt via Gcc-patches wrote:
> 2021-06-17 Bill Schmidt
>
Hi,
> gcc/
> * config/rs6000/rs6000-call.c (rs6000_expand_new_builtin): New
> forward decl.
> (rs6000_invalid_new_builtin): New stub function.
> (rs6000_expand_builtin):
Hmm, OK. Doesn't expanding both versions up-front create the same kind of
problem that the patch is fixing, in that we expand (and therefore cost)
both the reversed and unreversed comparison? Also…
[..]
…for min/max, I would have expected this swap to create the canonical
operand order for t
When mentioning the type of the accessed object -Warray-bounds
treats singleton objects as arrays of one element for simplicity.
But because the code doesn't distinguish between function and
object pointers, a warning for an out-of-bounds index into
a singleton function pointer object attempts to
The structure of these functions likely dates from the time before G++
fully supported C++14 extended constexpr, so that the throw expression
had to be the operand of a conditional expression. That is not true now,
so we can use a more straightforward version of the code.
We can also simplify the
These tests stopped working after some libstdc++ refactoring, because
they aren't including what they use.
I committed a blank ChangeLog (I did 'git push' when I meant to push
to the compile farm, oops) so I'll fix that tomorrow.
Tested powerpc64le-linux. Committed to trunk.
commit b7195fb01fe
The fix for PR 97548 introduced the OEP_DECL_NAME flag to compare
VLA bounds that refer to function parameters, but it didn't use
it in all the places where it's needed as the test case in PR
101585 illustrates. In r12-2541 I have pushed a correction of
this oversight that I consider obvious. Te
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
libsanitizer/ChangeLog:
* configure.tgt (s390*-*-linux*): Enable LSan and TSan for
s390x.
---
libsanitizer/configure.tgt | 5 +
1 file changed, 5 insertions(+)
diff --git a/libsanitizer/configure.tgt b/libsani
On Fri, 2021-07-23 at 15:23 -0500, Pat Haugen via Gcc-patches wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555760.html
>
> I've done a current bootstrap/regtest on powerpc64/powerpc64le with
> no regressions.
>
> -Pat
That patch was previously posted by Alan Modra.
Giv
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
On 7/20/21 12:34 PM, Martin Sebor wrote:
On 7/14/21 10:23 AM, Jason Merrill wrote:
On 7/14/21 10:46 AM, Martin Sebor wrote:
On 7/13/21 9:
On Linux/x86_64,
16158c96496b537194111526d25e19f268d613b6 is the first bad commit
commit 16158c96496b537194111526d25e19f268d613b6
Author: Jonathan Wakely
Date: Thu Jul 22 14:48:27 2021 +0100
libstdc++: Remove unnecessary uses of
caused
FAIL: g++.dg/cpp0x/initlist48.C -std=c++14 (test f
On Linux/x86_64,
261d5a4a459bd49942e53bc83334ccc7154a09d5 is the first bad commit
commit 261d5a4a459bd49942e53bc83334ccc7154a09d5
Author: Jonathan Wakely
Date: Thu Jul 22 14:48:27 2021 +0100
libstdc++: Reduce header dependencies on and
caused
FAIL: g++.dg/coroutines/pr99047.C (test for
This showed up as a segfault running the gcov-threads-1.C test in qemu
system mode on our internal port.
We're passing the address of an int to pthread_join. That int object is
only guaranteed 4 byte alignment. Later when pthread_join wants to
store a pointer into that location, we natural
Hi Segher,
On 7/27/21 9:23 AM, Segher Boessenkool wrote:
On Mon, Jul 26, 2021 at 10:26:25PM -0500, Bill Schmidt wrote:
Right now I just make the two generated
.h files depend on the generated .c file, which works since they are all
generated together or none of them are generated. That seems s
On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote:
Should we make this change?
Firstly, these bullet points are full sentences and so should end with
a period (or smiley, in some cases).
I'd expect that to be relatively uncontroversial ;)
Secondly, releases are not issued by the GNU
On 7/27/2021 10:21 AM, Aldy Hernandez wrote:
On 7/27/21 5:15 PM, Jeff Law wrote:
My recollection is there's also a case where the location of the
state push/pops are highly unintuitive. I always meant to put in
some sanity checking on the push/pops, then go back and bring some
sanity to t
On 7/26/21 12:22 PM, Jeff Law via Gcc-patches wrote:
On 7/25/2021 10:23 AM, Uecker, Martin wrote:
Two arguments are switched for -Wnonnull when
warning about array parameters with bounds > 0
and which are NULL.
This patch corrects the mistake.
Martin
2021-07-25 Martin Uecker
gcc/
On 7/27/21 5:15 PM, Jeff Law wrote:
My recollection is there's also a case where the location of the state
push/pops are highly unintuitive. I always meant to put in some sanity
checking on the push/pops, then go back and bring some sanity to that
code as well. The one time I recall trying t
Hi!
I'd like to ping 3 patches:
c++: Add C++20 #__VA_OPT__ support
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
c++: Accept C++11 attribute-definition [PR
On 7/27/2021 12:27 AM, Richard Biener wrote:
On Fri, 23 Jul 2021, Jeff Law wrote:
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE check for test case, e.g. (?n)/(?p)
* U
On 7/27/21 8:20 AM, Marek Polacek wrote:
Ping for the non-libstdc++ parts.
OK.
On Mon, Jul 19, 2021 at 02:46:22PM -0400, Marek Polacek wrote:
On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote:
On 7/16/21 6:34 PM, Jakub Jelinek wrote:
On Fri, Jul 16, 2021 at 05:36:13PM -0400, Ma
On Mon, Jul 26, 2021 at 4:19 PM H.J. Lu wrote:
>
> On Mon, Jul 26, 2021 at 3:56 PM H.J. Lu wrote:
> >
> > On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
> > wrote:
> > >
> > > "H.J. Lu via Gcc-patches" writes:
> > > > On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
> > > > wrote:
> > > >
On 7/27/2021 2:50 AM, Bin.Cheng wrote:
On Mon, Jul 26, 2021 at 11:07 PM Jeff Law wrote:
On 7/25/2021 7:47 PM, Bin.Cheng wrote:
On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
wrote:
On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
Hi,
I ran into a wrong code bug in cod
On 7/26/2021 4:55 PM, Segher Boessenkool wrote:
On Fri, Jul 23, 2021 at 10:27:37AM -0600, Jeff Law wrote:
On 7/22/2021 7:04 AM, Richard Biener via Gcc-patches wrote:
On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
wrote:
Gentle ping. Any suggestions would be appreciated.
So jus
> [PATCH] PR 100168: Fix call test on power10.
>
> Fix a test that was checking for 64-bit TOC calls, to also allow for
> PC-relative calls.
>
> I have verified that this test passes when run on a power10 system configured
> with --with-cpu=power10 and it continues to pass on power9 little endian a
On 7/27/2021 3:58 AM, Aldy Hernandez wrote:
On Mon, Jul 26, 2021 at 9:10 PM Jeff Law wrote:
On 7/2/2021 2:13 AM, Aldy Hernandez wrote:
On 7/2/21 12:20 AM, Jeff Law wrote:
On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
+// Internal construct to help facilitate debugging of solver.
+#defi
Should we make this change?
Firstly, these bullet points are full sentences and so should end with
a period (or smiley, in some cases).
Secondly, releases are not issued by the GNU Project at all, they're
issued by the GCC release managers.
Finally, "releases or snapshots of GCC not issued by ..
On 7/27/2021 4:19 AM, Aldy Hernandez wrote:
The *forward* jump threader has multiple places where it pushes and
pops state, and where it sets context up for the jump threading
simplifier callback. Not only are the idioms repetitive, but the only
reason for passing const_and_copies, avail_expr
I've now pushed this wwwdocs patch, which Gerald approved at
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572796.html
commit 0e4db42cddd88d2cc6780da884021284a10b9a4b
Author: Jonathan Wakely
Date: Tue Jul 27 16:04:42 2021 +0100
Remove FSF attribution from HTML page titles
diff --gi
On 18.07.21 06:36, Sandra Loosemore wrote:
This patch fixes bugs I observed in tests for the CFI_section function
-- it turns out both the function and test cases had bugs. :-(
The bugs in CFI_section itself had to do with incorrect computation of
the base address for the result descriptor, plus
On Tue, Jul 27, 2021 at 04:26:22PM +0200, Ulrich Drepper via Gcc-patches wrote:
> I know OpenMP 5.1 is not really a focus yet but adding this new interface
> should not be problematic. I stumbled across this part of the spec and the
> functionality is really already mostly there in the form of
> O
OK?
On Wednesday, 30 June 2021 10:59:28 CEST Matthias Kretz wrote:
> Library code, especially in headers, sometimes needs to know how the
> compiler interprets / optimizes floating-point types and operations.
> This information can be used for additional optimizations or for
> ensuring correctness
There is no SSE <-> AVX transition penalty if the upper bits of YMM/ZMM
registers are unchanged and YMM/ZMM store doesn't change the upper bits
of YMM/ZMM registers.
1. Since zeroing YMM/ZMM register is implemented with zeroing XMM
register, don't set AVX_U128_DIRTY when zeroing YMM/ZMM register.
I know OpenMP 5.1 is not really a focus yet but adding this new interface
should not be problematic. I stumbled across this part of the spec and the
functionality is really already mostly there in the form of
OMP_DISPLAY_ENV=verbose etc. This is just a function interface to the same
functionality
Hi!
On Mon, Jul 26, 2021 at 10:26:25PM -0500, Bill Schmidt wrote:
> On 7/21/21 1:58 PM, Segher Boessenkool wrote:
> >On Thu, Jun 17, 2021 at 10:19:07AM -0500, Bill Schmidt wrote:
> >>+# TODO: Whenever GNU make 4.3 is the minimum required, we should use
> >>+# grouped targets on this:
> >That may b
On 27/07/2021 09:39, Richard Biener wrote:
> Yes, that's true - there could be a one-to-many relationship there. But then
> I
> wonder in which case such lookup in the DIE tree would be the correct thing
> to do. If I lookup a variable from the parent then the concrete
> instance of that
> shou
Ping for the non-libstdc++ parts.
On Mon, Jul 19, 2021 at 02:46:22PM -0400, Marek Polacek wrote:
> On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote:
> > On 7/16/21 6:34 PM, Jakub Jelinek wrote:
> > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches
> > > wrote:
libstdc++-v3/ChangeLog:
* include/bits/cow_string.h: Consistently use tab for
indentation.
Tested powerpc64le-linux. Committed to trunk.
commit 7ffba77d01a2445c73ec487ba350c7fbf75a4500
Author: Jonathan Wakely
Date: Tue Jul 27 12:13:42 2021
libstdc++: Adjust whitesp
The header includes , with a comment referring to
UK-300, a National Body comment on the C++11 draft. That comment
proposed to move std::swap to and then require to
include . The comment was rejected, so we do not need to
implement the suggestion. For backwards compatibility with C++03 we do
wa
On Mon, 26 Jul 2021, Bin.Cheng wrote:
> On Thu, Jul 22, 2021 at 6:41 PM Richard Biener wrote:
> >
> > This avoids using multiple_of_p in niter analysis when its behavior
> Hmm, but this patch actually introduces one more call to
> multiple_of_p, also it doesn't touch the below use:
> if (niter->c
This refactoring reduces the memory usage and compilation time to parse
a number of headers that depend on std::pair, std::tuple or std::array.
Previously the headers for these class templates were all intertwined,
due to the common dependency on std::tuple_size, std::tuple_element and
their std::g
Hi!
On 2021-07-27T11:41:19+0200, I wrote:
> On 2018-01-09T11:57:00+0100, Tom de Vries wrote:
>> On 01/09/2018 12:17 AM, Julian Brown wrote:
>>> +(b) modifications to the copied data between the "spawning" point of
>>> +the asynchronous kernel and when it is executed will not be seen.
>>> +
Hi Sandra, hi Thomas, hi all,
@Thomas K: Comments about the following - and of course to the
testsuite itself - are highly welcome.
In my opinion, the testsuite LGTM and can be committed.
@Sandra:
- Thoughts on the directory name? (cf. below)
- Give others/Thomas a chance to comment on this,
On Tue, Jul 27, 2021 at 06:33:24PM +0800, Hongtao Liu wrote:
> > AVX2 introduced vector >> vector shifts, but unfortunately for V{2,4}DImode
> > it only supports logical and not arithmetic shifts, only AVX512F for
> > V8DImode or AVX512VL for V{2,4}DImode fixed that omission.
> > Earlier in GCC12 c
On Tue, Jul 27, 2021 at 4:11 PM Jakub Jelinek wrote:
>
> Hi!
>
> AVX2 introduced vector >> vector shifts, but unfortunately for V{2,4}DImode
> it only supports logical and not arithmetic shifts, only AVX512F for
> V8DImode or AVX512VL for V{2,4}DImode fixed that omission.
> Earlier in GCC12 cycle
The *forward* jump threader has multiple places where it pushes and
pops state, and where it sets context up for the jump threading
simplifier callback. Not only are the idioms repetitive, but the only
reason for passing const_and_copies, avail_exprs_stack, and the evrp
engine around are so we can
OG11 = devel/omp/gcc-11, a branch with some OpenMP/OpenACC/offload patches
which are not yet on mainline. Additionally, patches in this area are
cherry-picked from mainline.
Commits since my last email on 21 June 21 which ended with commit 858d20e2945.
My commits are all only cherry-picks plus G
Hi!
On 2021-06-29T16:42:03-0700, Julian Brown wrote:
> This patch fixes several places in libgomp/target.c where "ephemeral" data
> (on the stack or in temporary heap locations) may be used as the source of
> an asynchronous host-to-device copy that may not complete before the host
> data disappe
On Mon, Jul 26, 2021 at 9:10 PM Jeff Law wrote:
>
>
>
> On 7/2/2021 2:13 AM, Aldy Hernandez wrote:
> >
> >
> > On 7/2/21 12:20 AM, Jeff Law wrote:
> >>
> >>
> >> On 6/28/2021 10:21 AM, Aldy Hernandez wrote:
> >
> >>> +// Internal construct to help facilitate debugging of solver.
> >>> +#define DEB
On Mon, Jul 26, 2021 at 7:28 PM Richard Sandiford
wrote:
>
> Aldy Hernandez writes:
> > On Mon, Jul 26, 2021 at 4:18 PM Richard Sandiford
> > wrote:
> >>
> >> Aldy Hernandez writes:
> >> > This patch replaces the evrp_range_analyzer in the loop versioning code
> >> > with an on-demand ranger.
>
Hi!
[from internal email]
On 2018-01-09T11:57:00+0100, Tom de Vries wrote:
> On 01/09/2018 12:17 AM, Julian Brown wrote:
>> + (b) modifications to the copied data between the "spawning" point of
>> + the asynchronous kernel and when it is executed will not be seen.
>> + But, that is p
Hi,
On Tue, Jul 27 2021, JiangNing OS wrote:
>> Since it has been pre-approved by Honza, I would like to commit it to master
>> soon. Nevertheless, Jiangning, I am OK to wait a day or so if you can give
>> it
>> another test on your setup.
>>
>
> I failed to apply your patch, so could you pleas
Hi!
On 2019-05-17T21:19:07+0200, I wrote:
> Committed to trunk in r271346 "OpenACC Profiling Interface (incomplete)"
There in an 'async' issue in two of the test cases added here, as figured
out during review/testing with GCN offloading Julian's patch to 'Fix
OpenACC "ephemeral" asynchronous host
Ok, so if I understand correctly Palmer and Andrew prefer
overlap_op_by_pieces to be controlled
by its own field in the riscv_tune_param struct and not by the field
slow_unaligned_access in this struct
(i.e. slow_unaligned_access==false is not enough to imply
overlap_op_by_pieces==true).
I don't h
Hi!
On 2021-06-08T19:32:22+0200, I wrote:
> Hi Chung-Lin!
>
> ;-) It's been a while:
>
> On 2018-09-10T23:04:18+0800, Chung-Lin Tang wrote:
>> * testsuite/libgomp.oacc-c-c++-common/lib-94.c: New test.
>> * testsuite/libgomp.oacc-c-c++-common/lib-95.c: New test.
>> * tes
On Tue, Jul 27, 2021 at 10:51 AM Bin.Cheng via Gcc-patches
wrote:
>
> On Mon, Jul 26, 2021 at 11:07 PM Jeff Law wrote:
> >
> >
> >
> > On 7/25/2021 7:47 PM, Bin.Cheng wrote:
> > > On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
> > > wrote:
> > >>
> > >>
> > >> On 7/14/2021 3:14 AM, bi
On Tue, Jul 27, 2021 at 5:21 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR101596 showed, vect_recog_mulhs_pattern uses target_precision to
> check the scale_term is expected or not, it could be wrong when the
> precision of the actual used new_type larger than target_precision as
> shown by the example.
>
On Mon, Jul 26, 2021 at 11:07 PM Jeff Law wrote:
>
>
>
> On 7/25/2021 7:47 PM, Bin.Cheng wrote:
> > On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
> >>> Hi,
> >>> I ran into a wrong code bug in code with d
On Fri, 23 Jul 2021, Jeff Law wrote:
>
>
> On 7/22/2021 6:34 AM, Richard Biener wrote:
> > We can improve uninit warnings from the early pass by looking
> > at PHI arguments on fallthru edges that are uninitialized and
> > have uses that are before a possible loop exit. This catches
> > some ca
The automatic regression test of Sunil wrote:
On 26.07.21 19:27, sunil.k.pandey wrote:
commit 0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor
handling
caused
FAIL: gfortran.dg/PR93963.f90 -O2 execution test
...
(That's on
This adjusts the vectorizer to cost vector_stmt for widening
arithmetic instead of vec_promote_demote in the line of telling
the target that stmt_info->stmt is the meaningful piece we cost.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-07-27 Richard Biener
PR tree-
On Mon, Jul 26, 2021 at 11:34 PM Hafiz Abid Qadeer
wrote:
>
> On 22/07/2021 12:52, Richard Biener wrote:
> > On Thu, Jul 22, 2021 at 1:48 PM Jakub Jelinek wrote:
> >>
> >> On Thu, Jul 22, 2021 at 01:43:49PM +0200, Richard Biener wrote:
> >>> So I think we need to get to an agreement between the d
Hi!
AVX2 introduced vector >> vector shifts, but unfortunately for V{2,4}DImode
it only supports logical and not arithmetic shifts, only AVX512F for
V8DImode or AVX512VL for V{2,4}DImode fixed that omission.
Earlier in GCC12 cycle I've committed vector >> scalar arithmetic shift
emulation using va
Hi Harald,
On 26.07.21 23:55, Harald Anlauf wrote:
I've updated this for ALLOCATE/DEALLOCATE and STAT/ERRMSG, see
attached patch. This required updating the error messages of
two existing files in the testsuite.
Thanks.
Also affected: Some I/O items, a bunch of other stat=%v and
errmsg=%v.
W
On Mon, 26 Jul 2021, Jakub Jelinek wrote:
> Hi!
>
> For the following testcase, B is 16-byte type, containing 8-byte
> virtual pointer and 1-byte A member, and C contains two FIELD_DECLs,
> one with B type and size of just 8-byte and then a field with type
> A and 1-byte size.
> The __builtin_cle
> Since it has been pre-approved by Honza, I would like to commit it to master
> soon. Nevertheless, Jiangning, I am OK to wait a day or so if you can give it
> another test on your setup.
>
I failed to apply your patch, so could you please provide a patch file instead?
patch: malformed pa
96 matches
Mail list logo
