On Tue, 13 Jul 2021, guojiufu wrote:
> On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
> > On 2021-07-12 22:46, Richard Biener wrote:
> >> On Mon, 12 Jul 2021, guojiufu wrote:
> >>
> >>> On 2021-07-12 18:02, Richard Biener wrote:
> >>> > On Mon, 12 Jul 2021, guojiufu wrote:
> >>> >
> >>> >>
Hi!
The following testcase is miscompiled, because VN during cunrolli changes
__bos argument from address of a larger field to address of a smaller field
and so __builtin_object_size (, 1) then folds into smaller value than the
actually available size.
copy_reference_ops_from_ref has a hack for th
Hi Martin,
>>> while this patch does fix the libgo bootstrap failure, Go is completely
>>> broken: almost 1000 go.test failures and all libgo tests FAIL as well.
>>> Seen on both i386-pc-solaris2.11 and sparc-sun-solaris2.11.
>> FWIW, I see exactly the same failures on x86_64-pc-linux-gnu, so noth
On Tue, Jul 13, 2021 at 5:10 AM Alexandre Oliva wrote:
>
>
> If an artificial label created for a landing pad ends up being
> dropped in favor of a user-supplied label, the user-supplied label
> inherits the landing pad index, but the post_landing_pad field is not
> adjusted to point to the new la
Hi!
pot_dummy_types is a hash_set from whose traversal the code prints some type
lines. hash_set normally uses default_hash_traits which for pointer types
(the hash set hashes const char *) uses pointer_hash which hashes the
addresses of the pointers except of the least significant 3 bits.
With a
On Mon, Jul 12, 2021 at 05:29:36PM +0200, Florian Weimer wrote:
> I verifed that this change on top successfully builds GCC for all glibc
> targets:
Here is what I've committed after testing overnight:
2021-07-13 Jakub Jelinek
Florian Weimer
* config/linux/sem.h: Don't i
On Tue, Jul 13, 2021 at 5:11 AM Alexandre Oliva wrote:
>
>
> pr42739.C, complicated by some extra wrappers and cleanups from a
> feature I'm working on, got me very confused because a user label
> ended up in a cleanup introduced by my pass, where it couldn't
> possibly have been initially.
>
> Th
Hi Jason
> On 12 Jul 2021, at 20:40, Jason Merrill wrote:
>
> On 7/11/21 9:03 AM, Iain Sandoe wrote:
>> Hi Jason,
>>> On 9 Jul 2021, at 22:40, Jason Merrill wrote:
>>>
>>> On 7/9/21 2:18 PM, Iain Sandoe wrote:
>>> How about handling this in write_encoding, along the lines of the
>>> devel/c++
On Tue, Jul 13, 2021 at 5:13 AM Alexandre Oliva wrote:
>
>
> If some IPA pass replaces the only reference to a constant non-public
> non-automatic variable with its initializer, namely the address of
> another such variable, the former becomes unreferenced and it's
> discarded by symbol_table::rem
On Tue, Jul 13, 2021 at 5:15 AM Alexandre Oliva wrote:
>
>
> Odd-numbered indices describing argument access sizes in the fnspec
> string can only hold 't' or a digit, as tested in the beginning of the
> case. When checking that the size-supplying argument does not have
> additional information a
On 2021-07-13 15:09, Richard Biener wrote:
On Tue, 13 Jul 2021, guojiufu wrote:
On 2021-07-12 23:53, guojiufu via Gcc-patches wrote:
> On 2021-07-12 22:46, Richard Biener wrote:
>> On Mon, 12 Jul 2021, guojiufu wrote:
>>
>>> On 2021-07-12 18:02, Richard Biener wrote:
>>> > On Mon, 12 Jul 2021,
On Tue, 13 Jul 2021, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because VN during cunrolli changes
> __bos argument from address of a larger field to address of a smaller field
> and so __builtin_object_size (, 1) then folds into smaller value than the
> actually availa
On Tue, Jul 13, 2021 at 09:56:41AM +0200, Richard Biener wrote:
> The comment above says
>
> /* During cfg pass make sure to put orphaned labels
> into the right OMP region. */
>
> and the full guard is
>
> if ((unsigned) bb->index < bb_to_om
Hi,
When I added the support for Power10 newly introduced multiply
highpart instrutions, I noticed that currently vectorizer
doesn't try to vectorize multiply highpart pattern, I hope
this isn't intentional?
This patch is to extend the existing pattern mulhs handlings
to cover multiply highpart.
Hi,
This patch is to make Power10 newly introduced vector
multiply high (part) instructions exploited in vectorized
loops, it renames existing define_insns as standard pattern
names. It depends on that patch which enables vectorizer
to recog mul_highpart.
Tested on powerpc64le-linux-gnu P9 with
Ping?
Le ven. 2 juil. 2021 à 10:53, Christophe Lyon
a écrit :
> Hi,
>
> On Wed, 9 Jun 2021 at 17:04, Richard Sandiford
> wrote:
> >
> > Christophe Lyon writes:
> > > The problem in this PR is that we call VPSEL with a mask of vector
> > > type instead of HImode. This happens because operand 3
On Tue, Jul 13, 2021 at 10:52 AM Jakub Jelinek wrote:
>
> On Tue, Jul 13, 2021 at 09:56:41AM +0200, Richard Biener wrote:
> > The comment above says
> >
> > /* During cfg pass make sure to put orphaned labels
> > into the right OMP region. */
> >
> > and the
Richard Biener writes:
> On Thu, Jul 8, 2021 at 2:44 PM Richard Sandiford via Gcc-patches
> wrote:
>>
>> Vector reduction accumulators can differ in signedness from the
>> final scalar result. The conversions to handle that case were
>> distributed through vect_create_epilog_for_reduction; this
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2021/7/8 下午8:38, Richard Sandiford via Gcc-patches wrote:
>> Quoting from the final patch in the series:
>>
>>
>> This patch adds support for reusing a main loop's reduction accumulat
On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
>
> Hi,
>
> When I added the support for Power10 newly introduced multiply
> highpart instrutions, I noticed that currently vectorizer
> doesn't try to vectorize multiply highpart pattern, I hope
> this isn't intentional?
>
> This patch is to exten
Richard Biener writes:
> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> When I added the support for Power10 newly introduced multiply
>> highpart instrutions, I noticed that currently vectorizer
>> doesn't try to vectorize multiply highpart pattern, I hope
>> this isn't intent
On Tue, Jul 13, 2021 at 11:40 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> When I added the support for Power10 newly introduced multiply
> >> highpart instrutions, I noticed that currently vectorizer
> >> do
Richard Biener writes:
> On Tue, Jul 13, 2021 at 11:40 AM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
>> >>
>> >> Hi,
>> >>
>> >> When I added the support for Power10 newly introduced multiply
>> >> highpart instrutions, I notic
Hi Richi,
Thanks for the comments!
on 2021/7/13 下午5:35, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> When I added the support for Power10 newly introduced multiply
>> highpart instrutions, I noticed that currently vectorizer
>> doesn't try to vectoriz
When I added the new C++23 constructor I added a conditional include of
, which was already being included unconditionally.
This removes the unconditional include but changes the condition for the
other one, so it's used for C++20 as well.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
The following adds support for re-using the vector reduction def
from the main loop in vectorized epilogue loops on architectures
which use different vector sizes for the epilogue. That's only
x86 as far as I am aware.
vect.exp tested on x86_64-unknown-linux-gnu, full bootstrap &
regtest in progr
On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
>
> Hi Richi,
>
> Thanks for the comments!
>
> on 2021/7/13 下午5:35, Richard Biener wrote:
> > On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> When I added the support for Power10 newly introduced multiply
> >> highpart in
Ping :)
Major changes from v1:
* Add target hook to query preferred doloop mode.
* Recompute doloop iv base from niter under preferred mode.
Currently, doloop.xx variable is using the type as niter which may shorter
than word size. For some cases, it would be better to use word size type.
For example, on
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
free-standing environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
On 13/07/2021 15:03, Sebastian Huber wrote:
memset (list_sizes, 0, counters * sizeof (unsigned));
Sorry, I just realized that memset() cannot be used if inhibit_libc is
defined. I will send a v2 of the patch.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germa
On Mon, Jul 12, 2021 Richard Biener wrote:
> There's const-correctness pieces in your patch - those are OK under the
> obvious rule and you might want to push them separately.
Allow gimple_could_trap_p (which previously took a non-const gimple)
to be called from functions that take a const gimp
Ranger now resolves the first test in this series, so add the check.
Andrew
commit f75560398af6f1f696c820016f437af4e8b4265c
Author: Andrew MacLeod
Date: Tue Jul 13 09:41:30 2021 -0400
Adjust testcase to test the call is removed.
Ranger now handles the test.
gcc/
Ping^2
On 6/25/21 10:25 AM, Bill Schmidt wrote:
Ping / beg :-)
On 6/17/21 10:18 AM, Bill Schmidt via Gcc-patches wrote:
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/57223
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
> Somebody with more C++ knowledge than me needs to approve the
> vec.h changes - I don't feel competent to assess all effects of the change.
They look OK to me except for:
-extern vnull vNULL;
+static constexpr vnull vNULL{ };
Making vNULL hav
Richard Biener writes:
> The following adds support for re-using the vector reduction def
> from the main loop in vectorized epilogue loops on architectures
> which use different vector sizes for the epilogue. That's only
> x86 as far as I am aware.
>
> vect.exp tested on x86_64-unknown-linux-gnu
The use of npos triggers a diagnostic as described in PR c++/101361.
This change replaces the use of npos with the exact length, which is
already known. We can further simplify it by inlining the effects of
compare and substr, avoiding the redundant range checks in the latter.
Signed-off-by: Jonat
On Mon, Jul 12, 2021 at 8:59 PM Wang, Pengfei wrote:
>
> > Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
>
> Can you please explain the behavior here? Is there difference between
> _Float16 and _Complex _Float16 when return? I.e.,
> 1, In which case will _Float16 values r
Hi H.J.,
Our LLVM implementation currently use %xmm0 for both _Complex's real part and
imaginary part. Do we have special reason to use two registers?
We are using one register on X64. Considering the performance, especially the
register pressure, should it be better to use one register for _Com
Hi Martin,
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Martin Liška
> Sent: Tuesday, June 29, 2021 11:09 AM
> To: Joseph Myers
> Cc: GCC Development ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Port GCC documentation to Sphinx
>
on 2021/7/13 下午8:42, Richard Biener wrote:
> On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/7/13 下午5:35, Richard Biener wrote:
>>> On Tue, Jul 13, 2021 at 10:53 AM Kewen.Lin wrote:
Hi,
When I added the support for
On Tue, Jul 13, 2021 at 7:48 AM Wang, Pengfei wrote:
>
> Hi H.J.,
>
> Our LLVM implementation currently use %xmm0 for both _Complex's real part and
> imaginary part. Do we have special reason to use two registers?
> We are using one register on X64. Considering the performance, especially the
>
On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote:
> On Fri, 9 Jul 2021, Segher Boessenkool wrote:
> > Almost all targets just use Pmode, but there is no such guarantee I
> > think, and esp. some targets that do not have machine insns for this
> > (but want to generate different code f
On Tue, 13 Jul 2021, H.J. Lu wrote:
> On Mon, Jul 12, 2021 at 8:59 PM Wang, Pengfei wrote:
> >
> > > Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
> >
> > Can you please explain the behavior here? Is there difference between
> > _Float16 and _Complex _Float16 when return
On Tue, Jul 13, 2021 at 10:09:25AM +0800, guojiufu wrote:
> >For loop looks like:
> > do ;
> > while (n-- > 0); /* while (n-- > low); */
(This whole loop as written will be optimised away, but :-) )
> There is a patch that could mitigate "-1 +1 pair" in rtl part.
> https://gcc.gnu.org/g:8a15fa
On Tue, Jul 13, 2021 at 12:49 AM Jakub Jelinek wrote:
>
> 2021-07-13 Jakub Jelinek
>
> PR go/101407
> * godump.c (godump_str_hash): New type.
> (godump_container::pot_dummy_types): Use string_hash instead of
> ptr_hash in the hash_set.
Thanks for looking at this
On Tue, Jul 13, 2021 at 8:41 AM Joseph Myers wrote:
>
> On Tue, 13 Jul 2021, H.J. Lu wrote:
>
> > On Mon, Jul 12, 2021 at 8:59 PM Wang, Pengfei
> > wrote:
> > >
> > > > Return _Float16 and _Complex _Float16 values in %xmm0/%xmm1 registers.
> > >
> > > Can you please explain the behavior here? Is
On Mon, Jul 12, 2021 at 11:56 PM Jakub Jelinek wrote:
>
> On Mon, Jul 12, 2021 at 06:51:30PM -0700, H.J. Lu wrote:
> > @@ -404,9 +404,18 @@ const char *host_detect_local_cpu (int argc, const
> > char **argv)
> >if (argc < 1)
> > return NULL;
>
> I think it would be simpler to use 2 argum
On 7/10/21 7:39 PM, seg...@gate.crashing.org wrote:
> It is very hard to see the differences now. Don't fold the changes into
> one patch, just have the code movement in a separate trivial patch, and
> then the actual changes as a separate patch? That way it is much easier
> to review :-)
Ok, I
...and patch 2:
On 7/10/21 7:39 PM, seg...@gate.crashing.org wrote:
>> + unsigned subreg =
>> +(WORDS_BIG_ENDIAN) ? i : (nregs - reg_mode_nregs - i);
>
> This is not new code, but it caught my eye, so just for the record: the
> "=" should start a new line:
> unsig
This gives the new split_view's sentinel type a defaulted default
constructor, something which was overlooked in r12-1665. This patch
also fixes a couple of other issues with the new split_view as reported
in the PR.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc+
On Tue, 29 Jun 2021 01:11:06 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
gcc/
* gcc/config/riscv/riscv.opt (riscv_x_subext): New.
* gcc/config/riscv/riscv-opts.h (MASK_XTHEAD_C): New.
(TARGET_XTHEAD_C): Likewise.
* gcc/common/config/riscv/riscv-common.c
On Sat, 10 Jul 2021 19:31:20 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Hi,
Ping.
@Jim @kito
— Jojo
在 2021年7月9日 +0800 AM9:30，ALO ，写道：
Hi,
Ping.
— Jojo
在 2021年6月29日 +0800 PM4:11，Jojo R ，写道：
> T-HEAD extends some customized ISAs for Cores.
> The patches support ldr/str
On Tue, 29 Jun 2021 01:11:07 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
gcc/
* gcc/config/riscv/riscv-opts.h (TARGET_LDR): New.
(TARGET_LDUR): Likewise.
* gcc/config/riscv/riscv.h (INDEX_REG_CLASS): Use TARGET_LDR.
(REGNO_OK_FOR_INDEX_P): Use TARGET_LDR.
On Linux/x86_64,
f546e2b6cc5c610ae18aac274d0d6493f2da3801 is the first bad commit
commit f546e2b6cc5c610ae18aac274d0d6493f2da3801
Author: Richard Biener
Date: Tue Jul 13 08:04:34 2021 +0200
Revert "Display the number of components BB vectorized"
caused
FAIL: g++.dg/vect/slp-pr87105.cc -
On Fri, Jul 09, 2021 at 08:16:24AM +0200, Richard Biener via Gcc-patches wrote:
> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
> wrote:
> >
> > Hi Ian,
> >
> > Yesterday's enhancement to -Warray-bounds has exposed a couple of
> > issues in libgo where the code writes into an invalid
On 7/13/21 10:08 AM, Jonathan Wakely wrote:
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
Somebody with more C++ knowledge than me needs to approve the
vec.h changes - I don't feel competent to assess all effects of the change.
They look OK to me except for:
-extern vnull vNULL;
+static
On 7/13/21 12:14 PM, Peter Bergner wrote:
> ...and patch 2:
[snip]
> I'm currently bootstrapping and regtesting these two patches and
> will report back. Better now?
Ok, this along with the previous move patch bootstrapped and regtested
with no regressions on powerpc64le-linux.
Peter
On Tue, Jul 13, 2021 at 09:35:18AM -0700, H.J. Lu wrote:
> Here is the v3 patch. OK for master?
>From my POV LGTM, but please give Uros a chance to chime in.
> From ceab81ef97ab102c410830c41ba7fea911170d1a Mon Sep 17 00:00:00 2001
> From: "H.J. Lu"
> Date: Fri, 9 Jul 2021 09:16:01 -0700
> Subj
On Mon, Jul 12, 2021 at 05:24:07PM -0500, Segher Boessenkool wrote:
> On Sun, Jul 11, 2021 at 10:45:45AM -0500, Bill Schmidt wrote:
> > On 6/29/21 1:08 PM, Paul A. Clarke via Gcc-patches wrote:
> > >--- a/gcc/config/rs6000/smmintrin.h
> > >+++ b/gcc/config/rs6000/smmintrin.h
> > >@@ -116,4 +116,54
This gives the new split_view's sentinel type a defaulted default
constructor, something which was overlooked in r12-1665. This patch
also fixes a couple of other issues with the new split_view as reported
in the PR.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc+
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_v
An existing, previously xfailed test that I recently removed
the xfail from made me realize that -Wstringop-overflow doesn't
properly detect buffer overflow resulting from vectorized stores.
Because of a difference in the IL the test passes on x86_64 but
fails on targets like aarch64. Other examp
Hi!
The following gcc.dg/pr101384.c testcase is miscompiled on
powerpc64le-linux.
easy_altivec_constant has code to try construct vector constants with
different element sizes, perhaps different from CONST_VECTOR's mode. But as
written, that works fine for vspltis[bhw] cases, but not for the vspl
Hello world,
we rather shouldn't consider a presence check for a non-dummy variable.
Regtested on x86_64-pc-linux-gnu. OK for all affected branches?
Thanks,
Harald
Fortran - ICE in gfc_conv_expr_present while initializing a non-dummy
class variable
gcc/fortran/ChangeLog:
PR fortran/
On 7/13/21 4:11 AM, Iain Sandoe wrote:
Hi Jason
On 12 Jul 2021, at 20:40, Jason Merrill wrote:
On 7/11/21 9:03 AM, Iain Sandoe wrote:
Hi Jason,
On 9 Jul 2021, at 22:40, Jason Merrill wrote:
On 7/9/21 2:18 PM, Iain Sandoe wrote:
How about handling this in write_encoding, along the lines of
On 7/13/21 12:37 PM, Jason Merrill wrote:
On 7/13/21 10:08 AM, Jonathan Wakely wrote:
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
Somebody with more C++ knowledge than me needs to approve the
vec.h changes - I don't feel competent to assess all effects of the
change.
They look OK to
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
Hi!
On Tue, Jul 13, 2021 at 08:50:46PM +0800, Jiufu Guo wrote:
> * doc/tm.texi: Regenerated.
Pet peeve: "Regenerate.", no "d".
> +DEFHOOK
> +(preferred_doloop_mode,
> + "This hook returns a more preferred mode or the @var{mode} itself.",
> + machine_mode,
> + (machine_mode mode),
> + defau
This set of patches is for PR libfortran/101305, about bugs in
ISO_Fortran_binding.h's type kind/size encodings, and also incorrect
kind/size mappings in CFI_establish. For instance,
ISO_Fortran_binding.h had hard-wired encodings that ptrdiff_t and long
are 8 bytes that are clearly incorrect on a
CFI_establish was failing to set the default elem_len correctly for
CFI_type_cptr, CFI_type_cfunptr, CFI_type_long_double, and
CFI_type_long_double_Complex.
2021-07-13 Sandra Loosemore
libgfortran/
PR libfortran/101305
* runtime/ISO_Fortran_binding.c (CFI_establish): Special-ca
ISO_Fortran_binding.h had many incorrect hardwired kind encodings in
the definitions of the CFI_type_* macros. Additionally, not all
targets support all the defined type encodings, and the Fortran
standard requires those macros to have a negative value.
This patch changes ISO_Fortran_binding.h to
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path. Adjust includes in
the gfortran testsuite not to include an explicit path pointing at the
source directory.
2021-07-13 Sandra Loosemore
gcc/testsuite/
PR libfortran/10130
On Mon, Jul 12, 2021 at 08:28:55PM +, Qing Zhao wrote:
> > On Jul 12, 2021, at 12:56 PM, Kees Cook wrote:
> > On Wed, Jul 07, 2021 at 05:38:02PM +, Qing Zhao wrote:
> >> This is the 4th version of the patch for the new security feature for GCC.
> >
> > It looks like padding initialization
1. Rewrite builtin_memset_read_str and builtin_memset_gen_str with
vec_duplicate_optab to duplicate QI value to TI/OI/XI value.
2. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard
scratch register to avoid stack realignment when expanding memset.
PR middle-end/90773
Hi!
On Tue, Jul 13, 2021 at 04:58:42PM +0800, Kewen.Lin wrote:
> This patch is to make Power10 newly introduced vector
> multiply high (part) instructions exploited in vectorized
> loops, it renames existing define_insns as standard pattern
> names. It depends on that patch which enables vectoriz
On Tue, Jul 13, 2021 at 12:09:07PM -0500, Peter Bergner wrote:
> On 7/10/21 7:39 PM, seg...@gate.crashing.org wrote:
> > It is very hard to see the differences now. Don't fold the changes into
> > one patch, just have the code movement in a separate trivial patch, and
> > then the actual changes a
Hi!
On Tue, Jul 13, 2021 at 12:14:22PM -0500, Peter Bergner wrote:
> +/* If the target storage locations of arguments MEM1 and MEM2 are
> + adjacent, then return the argument that has the lower address.
> + Otherwise, return NULL_RTX. */
>
> -static bool
> +static rtx
> adjacent_mem_locati
On Tue, Jul 13, 2021 at 02:29:33PM -0700, Kees Cook wrote:
> I've extracted the kernel test to build for userspace, and it behaves
> the same way. See attached "stackinit.c".
I've adjusted this slightly (the "static" tests weren't testing the
correct thing, but the results remained the same). Here
On Tue, Jul 13, 2021 at 02:01:18PM -0500, Paul A. Clarke wrote:
> > > >+extern __inline int __attribute__((__gnu_inline__, __always_inline__,
> > > >__artificial__))
> > > Line too long, please fix here and below. (Existing cases can be left.)
> >
> > I wouldn't bother in this case. There is no
Hi, Kees,
I took a look at the kernel testing case you attached in the previous email,
and found the testing failed with the following case:
#define INIT_STRUCT_static_all = { .one = arg->one,\
.two = arg->two,\
This PR gave me a hard time: I saw multiple issues starting with
different revisions. But ultimately the root cause seems to be
the following, and the attached patch fixes all issues I've found
here.
In cxx_eval_array_reference we create a new constexpr context for the
CP_AGGREGATE_TYPE_P case, b
On Jul 13, 2021, Richard Biener wrote:
> oops - also worth backporting to affected branches.
Thanks, I took that as explicit approval and put it in.
attr fnspec is new in gcc-11, not present in gcc-10, so I'm testing a
trivial backport, just to be sure... Will install in gcc-11 when done.
>>
on 2021/7/14 上午6:07, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jul 13, 2021 at 04:58:42PM +0800, Kewen.Lin wrote:
>> This patch is to make Power10 newly introduced vector
>> multiply high (part) instructions exploited in vectorized
>> loops, it renames existing define_insns as standard pattern
>
By optimizing vector movement to broadcast in ix86_expand_vector_move
during pass_expand, pass_reload/LRA can automatically generate an avx512
embedded broadcast, pass_cpb is not needed.
Considering that in the absence of avx512f, broadcast from memory is
still slightly faster than loading the ent
On 2021-07-13 23:51, Segher Boessenkool wrote:
On Tue, Jul 13, 2021 at 10:09:25AM +0800, guojiufu wrote:
>For loop looks like:
> do ;
> while (n-- > 0); /* while (n-- > low); */
(This whole loop as written will be optimised away, but :-) )
At -O2, the loop is optimized away.
At -O1, the lo
On Tue, Jul 13, 2021 at 11:16:59PM +, Qing Zhao wrote:
> Hi, Kees,
>
> I took a look at the kernel testing case you attached in the previous email,
> and found the testing failed with the following case:
>
> #define INIT_STRUCT_static_all = { .one = arg->one,\
>
On 2021-07-13 23:38, Segher Boessenkool wrote:
On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote:
On Fri, 9 Jul 2021, Segher Boessenkool wrote:
> Almost all targets just use Pmode, but there is no such guarantee I
> think, and esp. some targets that do not have machine insns for thi
On 7/13/21 4:02 PM, Martin Sebor wrote:
On 7/13/21 12:37 PM, Jason Merrill wrote:
On 7/13/21 10:08 AM, Jonathan Wakely wrote:
On Mon, 12 Jul 2021 at 12:02, Richard Biener wrote:
Somebody with more C++ knowledge than me needs to approve the
vec.h changes - I don't feel competent to assess all e
On 7/12/21 3:58 PM, Jonathan Wakely wrote:
On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote:
On 6/26/21 10:23 AM, Andrew Sutton wrote:
I ended up taking over this work from Jeff (CC'd on his existing email
address). I scraped all the contracts changes into one big patch
against master. See a
On 7/13/21 8:15 PM, Marek Polacek wrote:
This PR gave me a hard time: I saw multiple issues starting with
different revisions. But ultimately the root cause seems to be
the following, and the attached patch fixes all issues I've found
here.
In cxx_eval_array_reference we create a new constexpr
On Wed, Jul 14, 2021 at 10:34 AM liuhongt wrote:
>
> By optimizing vector movement to broadcast in ix86_expand_vector_move
> during pass_expand, pass_reload/LRA can automatically generate an avx512
> embedded broadcast, pass_cpb is not needed.
>
> Considering that in the absence of avx512f, broadc
On 2021-07-14 04:50, Segher Boessenkool wrote:
Hi!
On Tue, Jul 13, 2021 at 08:50:46PM +0800, Jiufu Guo wrote:
* doc/tm.texi: Regenerated.
Pet peeve: "Regenerate.", no "d".
Ok, yeap. While, 'Regenerate and Regenerated' were used by commits
somewhere :)
+DEFHOOK
+(preferred_dolo
Hi:
The original problem was that some users wanted the cmdline option
-ffast-math not to act on intrinsic production code. .i.e for codes
like
#include
__m256d
foo2 (__m256d a, __m256d b, __m256d c, __m256d d)
{
__m256d tmp = _mm256_add_pd (a, b);
tmp = _mm256_sub_pd (tmp, c);
tmp = _mm256_sub_
On Jul 13, 2021, Richard Biener wrote:
> Hmm, elsewhere in this function we're not anticipating future removal but
> instead use ->global_info_ready which IIRC is when the unit was
> initially analyzed. So don't the other uses have the same issue?
Possibly.
The call to debug_hooks->late_global
On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
>
> Hi:
> The original problem was that some users wanted the cmdline option
> -ffast-math not to act on intrinsic production code. .i.e for codes
> like
>
> #include
> __m256d
> foo2 (__m256d a, __m256d b, __m256d c, __m256d d)
> {
> __m256d tm
On 7/13/21 8:41 AM, Richard Biener wrote:
> On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose wrote:
>>
>> On 3/26/19 12:52 PM, Matthias Klose wrote:
>>> On 22.03.19 23:00, David Malcolm wrote:
On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote:
> Fix PR jit/87808, the embedded driver
On Tue, Jul 13, 2021 at 8:59 PM Jakub Jelinek wrote:
>
> On Tue, Jul 13, 2021 at 09:35:18AM -0700, H.J. Lu wrote:
> > Here is the v3 patch. OK for master?
>
> From my POV LGTM, but please give Uros a chance to chime in.
>
> > From ceab81ef97ab102c410830c41ba7fea911170d1a Mon Sep 17 00:00:00 2001
On Tue, Jul 13, 2021 at 4:59 PM Kewen.Lin wrote:
>
> on 2021/7/13 下午8:42, Richard Biener wrote:
> > On Tue, Jul 13, 2021 at 12:25 PM Kewen.Lin wrote:
> >>
> >> Hi Richi,
> >>
> >> Thanks for the comments!
> >>
> >> on 2021/7/13 下午5:35, Richard Biener wrote:
> >>> On Tue, Jul 13, 2021 at 10:53 AM
On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > Hi:
> > The original problem was that some users wanted the cmdline option
> >
> > -ffast-math not to act on intrinsic production code.
This sounds like the users w
1 - 100 of 101 matches
Mail list logo
