Hi Robin,
on 2021/11/12 下午5:56, Robin Dapp wrote:
> Hi Kewen and Richard,
>
> the attached v3 addresses the comments to v2, among others:
>
> - Rename to load_store where appropriate.
> - Save the adjusted length as a separate control that is used instead
> of loop_len with a bias != 0 and
From: Andrew Pinski
Combine disabled this optimization in r10-254-gddbb5da5199fb42 but it makes
sense to do this on the gimple level and then let expand decide which way is
better. So this adds the transformation on the gimple level (late like was
done for the multiply case).
OK? Bootstrapped
From: Andrew Pinski
The pattern here was not catching all comparisons and the multiply
was not commutative when it should have been. This patches fixes
that by using tcc_comparison and adding :c to the multiply.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
On Fri, Nov 19, 2021 at 3:53 PM Uros Bizjak via Gcc-patches
wrote:
>
> On Fri, Nov 19, 2021 at 8:50 AM Uros Bizjak wrote:
> >
> > On Fri, Nov 19, 2021 at 2:14 AM liuhongt wrote:
> > >
> > > >Why is the above declared as a special memory constraint? Also the
> > > Change to
On Wed, Nov 17, 2021 at 3:28 AM HAO CHEN GUI wrote:
>
> Hi,
>
> The patch optimized for vec_reve builtin on rs6000. For V2DI and V2DF, it
> is implemented by xxswapd on all targets. For V16QI, V8HI, V4SI and V4SF, it
> is implemented by quadword byte reverse plus halfword/word byte reverse
This second patch completes the work of the first 'array-copy' patch to
provide first-cut implementations of all P1997 features. It adds:
* Assignments to arrays from array values,a = b;
* Placeholder auto in array declarations, auto cp[] = a;
* Array as a return type from functions
This patch implements initializations of arrays from array values.
The first of two 'array-copy' patches, it adds the option -farray-copy
(flag_array_copy) to enable all features of P1997 (copy related or not),
documented as experimental extensions.
It deals with initialization of array
Also address "FIXME: this code is duplicated from reshape_init" in
cp_complete_array_type by always calling reshape_init on init-list.
PR c++/55227
gcc/cp/ChangeLog:
* decl.c (reshape_init_r): Only call has_designator_check when
first_initializer_p or for the inner
([PATCH 1/3] already submitted fix for PR c++/55227, is a dependency here.)
These patches implement C++ proposal P1997 "Relaxing restrictions on array"
that adds:
C array copy semantics:
* array-array initializations
* array-array assignments
* array return-by-value from functions
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
>> on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> As the discussion in PR102347,
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578552.html
One related patch [1] is ready to commit, whose test cases rely on
this patch if no changes are applied to them.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579658.html
BR,
Kewen
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580358.html
BR,
Kewen
>>> on 2021/9/28 下午4:16, Kewen.Lin via Gcc-patches wrote:
Hi,
This patch follows the discussions here[1][2], where Segher
pointed out the existing way to guard the extra
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572555.html
BR,
Kewen
>> on 2021/6/11 下午9:16, Kewen.Lin via Gcc-patches wrote:
>>> Hi Segher,
>>>
>>> Thanks for the review!
>>>
>>> on 2021/6/10 上午4:17, Segher Boessenkool wrote:
Hi!
on 2021/11/20 上午6:26, augustine.sterl...@gmail.com wrote:
> On Thu, Nov 11, 2021 at 3:25 AM Kewen Lin wrote:
>> gcc/ChangeLog:
>>
>> * config/xtensa/xtensa.md (movdi_internal, movdf_internal): Fix split
>> condition.
>
> I had been hoping Max would reply (as I'm just doing legacy
On Sun, 21 Nov 2021 19:59:35 +0100
Harald Anlauf wrote:
> Let's have a look at the tree-dump of the existing testcase:
>
> integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
> {
>integer(kind=4) res;
>
>{
> uint128_t D.4221;
>
> D.4221 = (uint128_t) *i;
>
Thanks for the review!
I updated the patch.
See notes below.
Le samedi 20 novembre 2021 à 13:50 -0500, David Malcolm a écrit :
> On Sat, 2021-11-20 at 11:27 -0500, Antoni Boucher wrote:
> > Hi.
> > Here's the updated patch.
> > Thanks for the review!
>
> Thanks for the updated patch...
>
> >
A recent thread on this mailing list made me remember that this proposal
is still open.
I've updated it just to add a missing std qualification.
François
On 08/06/21 5:21 pm, Jonathan Wakely wrote:
I haven't forgotten this one, I just need to double-check that we
don't create another problem
On Sat, 2021-11-20 at 17:34 -0500, Antoni Boucher wrote:
> Hi.
> Here's the updated patch.
> See comments below.
> Thanks for your reviews!
>
> Le jeudi 20 mai 2021 à 16:11 -0400, David Malcolm a écrit :
> > On Tue, 2021-05-18 at 20:43 -0400, Antoni Boucher via Gcc-patches
> > wrote:
> > > Hello.
On Sat, Nov 20, 2021 at 9:20 AM Jakub Jelinek wrote:
>
> Hi!
>
> As shown in the testcase below, if a function has multiple target attributes
> (rather than a single one with one or more arguments) or if a function
> gets one target attribute on one declaration and another one on another
>
Let's have a look at the tree-dump of the existing testcase:
integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
{
integer(kind=4) res;
{
uint128_t D.4221;
D.4221 = (uint128_t) *i;
res = __builtin_parityll ((unsigned long) D.4221 ^ (unsigned long)
(D.4221 >> 64));
On 11/21/2021 8:15 AM, Jan Hubicka via Gcc-patches wrote:
Hi,
this testcase needs -fno-ipa-modref becuase otherwise it hits the issue
that complete loop unrolling leaves somewhat mismatched profile.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/testsuite/ChangeLog:
2021-11-21 Jan
Hi,
on exchange2 benchamrk we miss some useful propagation because modref gives
up very early on analyzing accesses through pointers. For example in
int test (int *a)
{
int i;
for (i=0; a[i];i++);
return i+a[i];
}
We are not able to determine that a[i] accesses are relative to a.
This is
Hi,
this testcase needs -fno-ipa-modref becuase otherwise it hits the issue
that complete loop unrolling leaves somewhat mismatched profile.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/testsuite/ChangeLog:
2021-11-21 Jan Hubicka
PR ipa/103264
*
On Thu, 4 Nov 2021 18:25:14 -0600
Martin Sebor wrote:
> On 10/31/21 8:13 AM, Daniil Stas wrote:
> > On Sun, 10 Oct 2021 23:10:20 +
> > Daniil Stas wrote:
> >
> >> This option is enabled by default when -Wformat option is enabled.
> >> A user can specify -Wno-format-int-precision to
This option is enabled by default when -Wformat option is enabled. A
user can specify -Wno-format-int-precision to disable emitting
warnings when passing an argument of an incompatible integer type to
a 'd', 'i', 'o', 'u', 'x', or 'X' conversion specifier when it has
the same precision as the
From: Andrew Pinski
This PR was orignally for the missed optimization of a few isnegative which
had been solved a long time ago (sometime before 4.4.0). I noticed there was
one missed optimization on the gimple level. There is a match.pd pattern
for ~a < CST but we miss that there could be a
Le 19/11/2021 à 10:40, Jakub Jelinek via Fortran a écrit :
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hello,
you know probably better than me or any fortran maintainer whether it’s
good or bad.
So OK from the fortran side.
Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a
Le 15/11/2021 à 22:38, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds. It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics.
Regtested on
I tried to use the same approach I used for node based containers but
got ambiguity on erase calls. I think this simple version will do the work.
libstdc++: [_GLIBCXX_DEBUG] Enhance std::erase_if for vector/deque
libstdc++-v3/ChangeLog:
* include/std/deque (erase_if): Use
From: Sergei Trofimovich
gcc/fortran/
* gfortran.texi (BOZ literal constants): add X'ABC' to the list
of valid examples.
---
gcc/fortran/gfortran.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/gfortran.texi
From: Sergei Trofimovich
gcc/fortran/
* gfortran.texi (BOZ literal constants): fix invalid BOZ 'ABC'X
example to be X'ABC'.
---
gcc/fortran/gfortran.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/gfortran.texi
32 matches
Mail list logo
