Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601196.html
Thanks.
On 7/9/2022 下午 3:44, HAO CHEN GUI wrote:
> Hi,
>
> For scalar extract/insert instructions, exponent field can be stored in a
> 32-bit register. So this patch changes the mode of exponent
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
Thanks.
On 1/8/2022 上午 10:02, HAO CHEN GUI wrote:
> Hi,
> Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
> Thanks.
>
> On 4/7/2022 下午 2:33, HAO CHEN GUI wrote:
>>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
Thanks.
On 1/8/2022 上午 10:03, HAO CHEN GUI wrote:
> Hi,
>Gentle ping this:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
> Thanks.
>
>
> On 4/7/2022 下午 2:32, HAO CHEN GUI wrote:
>>
Hi,
This patch adds a new insn for vector splat with small V2DI constants on P8.
If the value of constant is in RANGE (-16, 15) and not 0 or -1, it can be loaded
with vspltisw and vupkhsw on P8. It should be efficient than loading vector from
TOC.
Bootstrapped and tested on powerpc64-linux BE
The proposed patch only makes the difference if the operand 1 is an
eliminable register and operand 2 is a splittable const int. Otherwise, it
follows the original add3 pattern.
Besides the example from pr105733 shown on the first post,
#define BUF_SIZE 5012
void saxpy( float a )
{
volatile
When init_expr is INTEGER_CST or REAL_CST, can_vec_perm_const_p is not
necessary since there's no real vec_perm needed, but
vec_gen_perm_mask_checked will gcc_assert (can_vec_perm_const_p). So
it's better to use vec_gen_perm_mask_any in
vect_create_nonlinear_iv_init.
Bootstrapped and regtested on
On Tue, Sep 20, 2022 at 05:01:53PM -0500, will schmidt wrote:
> On Tue, 2022-09-20 at 16:14 -0500, Segher Boessenkool wrote:
> > > TARGET_FCTIWUZ has a low number of uses, and can be directly
> > > replaced with TARGET_POPCNTD.
> >
> > It is a p7 (ISA 2.06) insn. Please make a TARGET_P7 or such?
On Tue, 2022-09-20 at 16:14 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Sep 19, 2022 at 06:19:15PM -0500, will schmidt wrote:
> > This is the first of a batch of changes that eliminate a number
> > of define TARGET_foo entries we have collected over time.
>
> Good good :-)
>
> >
Hi!
On Mon, Sep 19, 2022 at 06:19:15PM -0500, will schmidt wrote:
> This is the first of a batch of changes that eliminate a number
> of define TARGET_foo entries we have collected over time.
Good good :-)
> TARGET_CTZ is defined as TARGET_MODULO, and has a low number
> of uses. References
Am 19.09.22 um 22:50 schrieb Mikael Morin:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t
We ICE in the code added in r12-7117: type_build_dtor_call gets
the error_mark_node because the type of 'prev' wasn't declared.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/106983
gcc/cp/ChangeLog:
* typeck2.cc (split_nonconstant_init_1): Check TYPE_P.
Dear all,
we ICE'd in the simplification of FINDLOC when the passed
ARRAY argument had an invalid declaration. The reason was
a reference to array->shape which was NULL.
Obvious solution: then just don't attempt to simplify.
Regtested on x86_64-pc-linux-gnu and pushed to mainline as
Dear all,
Gerhard found a NULL pointer dereference in a PARAMETER declaration
that referenced the same declared parameter.
Simple & obvious enough, see attached patch.
Regtested on x86_64-pc-linux-gnu, and pushed to mainline:
https://gcc.gnu.org/g:8dbb15bc2d019488240c1e69d93121b0347ac092
On 9/20/22 15:54, Patrick Palka wrote:
This adds some recently implemented C++20/23 library headers to the
xtreme-header tests as appropriate. Also, it looks like we can safely
re-add and remove the NO_ASSOCIATED_LAMBDA workaround.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
On 9/20/22 15:54, Patrick Palka wrote:
The modules streaming code seems to rely on the invariant that a
TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE.
It does indeed.
But for a templated VAR_DECL with deduced non-dependent type, the two
TREE_TYPEs end up diverging:
Am 20.09.22 um 13:51 schrieb Tobias Burnus:
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required
'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
This adds some recently implemented C++20/23 library headers to the
xtreme-header tests as appropriate. Also, it looks like we can safely
re-add and remove the NO_ASSOCIATED_LAMBDA workaround.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/testsuite/ChangeLog:
*
The modules streaming code seems to rely on the invariant that a
TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE.
But for a templated VAR_DECL with deduced non-dependent type, the two
TREE_TYPEs end up diverging: cp_finish_decl deduces the type of the
initializer ahead of time
ping
On 8/29/22 16:11, Guillermo E. Martinez wrote:
Hello GCC team,
The following patch update BTF/CTF backend to support
BTF_KIND_ENUM64 type.
Comments will be welcomed and appreciated!,
Kind regards,
guillermo
--
BTF supports 64-bits enumerators with following encoding:
struct
Undefined ranges have undefined NAN bits. We can't depend on them,
as they may contain garbage. This patch returns false from
maybe_isnan() for undefined ranges (the empty set).
gcc/ChangeLog:
* value-range.h (frange::maybe_isnan): Return false for
undefined ranges.
---
On Mon, Sep 12, 2022 at 04:27:27PM -0400, Jason Merrill wrote:
> On 9/8/22 18:54, Marek Polacek wrote:
> > On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote:
> > > On 9/3/22 12:42, Marek Polacek wrote:
> > > > This patch implements https://wg21.link/p2266, which, once again,
> > > >
On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote:
> On 9/3/22 12:42, Marek Polacek wrote:
> > This patch implements https://wg21.link/p2266, which, once again,
> > changes the implicit move rules. Here's a brief summary of various
> > changes in this area:
> >
> > r125211:
On Tue, Sep 20, 2022 at 5:10 PM Jakub Jelinek wrote:
>
> On Tue, Sep 20, 2022 at 04:58:38PM +0200, Aldy Hernandez wrote:
> > > > > deal with NaNs just fine and is required to correctly capture the
> > > > > sign of
> > > > > 'x'. If frange::set_nonnegative is supposed to be used in such
> > >
> Hi Honza,
>
> This patch is to add attribute hot judgement for INLINE_HINT_known_hot hint.
>
> We set up INLINE_HINT_known_hot hint only when we have profile feedback,
> now add function attribute judgement for it, when both caller and callee
> have __attribute__((hot)), we will also set up
On 9/20/22 15:37, Thomas Schwinge wrote:
> |Then, make it simply call 'autoreconf' for all 'config_folders'. (Also, I'm
> not running into the issue you've stated in the script that "apparently
> automake is somehow unstable -> skip it for gotools".)|
I do support that as well.
What will be
On Tue, Sep 20, 2022 at 04:58:38PM +0200, Aldy Hernandez wrote:
> > > > deal with NaNs just fine and is required to correctly capture the sign
> > > > of
> > > > 'x'. If frange::set_nonnegative is supposed to be used in such contexts
> > > > (and I think it's a good idea if that were the case),
On Tue, Sep 20, 2022 at 2:51 PM Michael Matz wrote:
>
> Hello,
>
> On Tue, 20 Sep 2022, Aldy Hernandez wrote:
>
> > > FWIW, in IEEE, 'abs' (like 'copy, 'copysign' and 'negate') are not
> > > arithmetic, they are quiet-computational. Hence they don't rise
> > > anything, not even for sNaNs; they
It turns out that GTY(()) markers in definitions like:
GTY(()) tree scalar_types[NUM_VECTOR_TYPES];
are not effective and are silently ignored. The GTY(()) has
to come after an extern or static.
The externs associated with the SVE ACLE GTY variables are in
aarch64-sve-builtins.h. This file
PR tree-optimization/106970
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr106970.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr106970.c | 9 +
1 file changed, 9 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr106970.c
diff --git
On 9/20/22 10:08, Patrick Palka wrote:
On Tue, 20 Sep 2022, Nathan Sidwell wrote:
On 9/19/22 09:52, Patrick Palka wrote:
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream
On Tue, 20 Sep 2022, Nathan Sidwell wrote:
> On 9/19/22 09:52, Patrick Palka wrote:
> > It looks like some xtreme-header-* tests are failing after the libstdc++
> > change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
> > to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false
Hi!
> On 20 Sep 2022, at 14:37, Thomas Schwinge wrote:
> On 2022-08-25T11:42:01+0200, Martin Liška wrote:
>> I wrote a scipt that runs autoconf in all folders that have configure.ac
>> file and same for autoheader (where AC_CONFIG_HEADERS is present) and
>> this is the output.
>>
>> The
Hi Martin,
On 20.09.22 14:24, Martin Liška wrote:
On 9/20/22 14:17, Tobias Burnus wrote:
Instead of removing the links, can we rather replace it by an updated link?
[...]
Thanks for the archeological work you did.
Sure, what about the suggested patch?
LGTM. Thanks!
Tobias
Hi!
On 2022-08-25T11:42:01+0200, Martin Liška wrote:
> I wrote a scipt that runs autoconf in all folders that have configure.ac
> file and same for autoheader (where AC_CONFIG_HEADERS is present) and
> this is the output.
>
> The script can be seen here:
>
Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.
2022-09-16 Torbjörn SVENSSON
In the test cases, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By changing to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
gcc/ada/ChangeLog:
* exp_ch6.adb: Replace "the the" with "the".
* sem_ch6.adb: Likewise.
* sem_disp.ads: Likewise.
gcc/ChangeLog:
* ctfc.cc (ctf_add_string): Replace "the the" with "the".
* doc/md.texi: Likewise.
* gimple-range-infer.cc
On 7/1/22 09:20, Fangrui Song via Gcc-patches wrote:
> On 2022-07-01, Andrew Pinski wrote:
>> On Thu, Jun 30, 2022 at 11:58 PM Fangrui Song via Gcc-patches
>> wrote:
>>>
>>> From: Fangrui Song
>>>
>>> SHF_COMPRESSED style zlib has been supported since binutils 2.26
>>> and the legacy zlib-gnu
Hello,
On Tue, 20 Sep 2022, Aldy Hernandez wrote:
> > FWIW, in IEEE, 'abs' (like 'copy, 'copysign' and 'negate') are not
> > arithmetic, they are quiet-computational. Hence they don't rise
> > anything, not even for sNaNs; they copy the input bits and appropriately
> > modify the bit pattern
Prathamesh Kulkarni writes:
> On Mon, 12 Sept 2022 at 19:57, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> >> The VLA encoding encodes the first N patterns explicitly. The
>> >> npatterns/nelts_per_pattern values then describe how to extend that
>> >> initial sequence to an
I messed this up last week. Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/c_global/cstdlib [!_GLIBCXX_HOSTED] (quick_exit): Fix
missing space.
---
libstdc++-v3/include/c_global/cstdlib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 9/20/22 14:17, Tobias Burnus wrote:
> Hi Martin,
>
> On 20.09.22 14:02, Martin Liška wrote:
>> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
>> @@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
>> The Fortran 95 standard specifies in Part 2 (ISO/IEC
Hi Martin,
On 20.09.22 14:02, Martin Liška wrote:
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
@@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
varying length character strings.
PR fortran/106636
gcc/fortran/ChangeLog:
* gfortran.texi: Remove 2 dead links.
---
gcc/fortran/gfortran.texi | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 59d673bfc03..25410e6088d 100644
---
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required 'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
'dimension(*)' only permits arrays and array elements but
On 9/19/22 09:52, Patrick Palka wrote:
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false equivalences
of different partial instantiations of
Hello,
Le 19/09/2022 à 22:17, Harald Anlauf via Fortran a écrit :
Dear all,
the following patch was submitted by Jose but never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
Before, we didn't set function attributes properly when
passing polymorphic pointers, which
On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > The question is (mainly for aarch64, arm and x86 backend maintainers) if we
> > shouldn't support it, in the PR there is a partial patch to do so, but
> > the big question is if it should be supported as the __bf16 type those
> > 3
Hi Honza,
This patch is to add attribute hot judgement for INLINE_HINT_known_hot hint.
We set up INLINE_HINT_known_hot hint only when we have profile feedback,
now add function attribute judgement for it, when both caller and callee
have __attribute__((hot)), we will also set up
Le 20/09/2022 à 08:54, Thomas Koenig a écrit :
On 19.09.22 22:50, Mikael Morin wrote:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Assumed size (*) is just a contiguous hunk of memory of possibly
unknown size, which can be zero. So you couldn't set a clobber
for the a(1) actual argument.
Jojo R via Gcc-patches writes:
> * gcc/genrecog.cc (print_nonbool_test): Fix type error of
> SUBREG_BYTE
We can't do this here. The code has done nothing to prove that the
subreg offset is a compile-time constant.
Thanks,
Richard
> ---
> gcc/genrecog.cc | 1 +
> 1 file changed, 1
On Tue, Sep 20, 2022 at 07:22:03AM +0200, Aldy Hernandez wrote:
> > > Jakub actually suggested something completely different...just set +0
> > > always for !HONOR_SIGNED_ZEROS.
> >
> > Hmm, but the [-1, -0.] with known sign becomes [-1, +0.] with unknown sign?
>
> Huh. I guess that's true.
contrib/ChangeLog:
* filter-clang-warnings.py: Skip egrep: warning: egrep is
obsolescent; using grep -E.
---
contrib/filter-clang-warnings.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/filter-clang-warnings.py
Hi Jeff, Richard,
Thank you for reviewing the patch!
I have committed the patch to the gcc repo.
Can I backport this patch to prior versions of gcc, as this is an easy patch to
backport and the issue exists in prior versions too?
Regards,
Surya
On 31/08/22 9:09 pm, Jeff Law via Gcc-patches
+My intel folk phoebe working for llvm side.
On Tue, Sep 20, 2022 at 11:35 AM Hongtao Liu wrote:
>
> On Mon, Sep 12, 2022 at 4:06 PM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > Hi!
> >
> > The following patch implements the compiler part of C++23
> > P1467R9 - Extended floating-point types
On 19.09.22 22:50, Mikael Morin wrote:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it
Thanks a lot, pushed to trunk.
> Hi Richard,
>
> Thanks again for your reviewing.
>
> > Yes, use else if for the bitwise induction. Can you also make the new
> > case conditional on 'def'
> > (the compute_overall_effect_of_inner_loop) being chrec_dont_know? If
> > that call produced something
On Tue, Sep 20, 2022 at 4:15 AM liuhongt via Gcc-patches
wrote:
>
> Here's list the patch supported.
> rint/nearbyint/ceil/floor/trunc/lrint/lceil/lfloor/round/lround.
>
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/106910
>
58 matches
Mail list logo
