- According the conclusion in RISC-V C API document, we decide to deprecat
the __riscv_cmodel_pic marco
- __riscv_cmodel_pic is deprecated and will removed in next GCC
release.
[1] https://github.com/riscv/riscv-c-api-doc/pull/11
---
gcc/config/riscv/riscv-c.c| 7 ---
On September 25, 2020 5:50:40 AM GMT+02:00, xionghu luo
wrote:
>Hi,
>
>On 2020/9/24 21:27, Richard Biener wrote:
>> On Thu, Sep 24, 2020 at 10:21 AM xionghu luo
>wrote:
>>
>> I'll just comment that
>>
>> xxperm 34,34,33
>> xxinsertw 34,0,12
>> xxperm 34,34,32
>>
>>
Hi,
On 2020/9/24 21:27, Richard Biener wrote:
> On Thu, Sep 24, 2020 at 10:21 AM xionghu luo wrote:
>
> I'll just comment that
>
> xxperm 34,34,33
> xxinsertw 34,0,12
> xxperm 34,34,32
>
> doesn't look like a variable-position insert instruction but
> this is a
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
On Linux/x86_64,
c33f474239308d81bf96cfdb2520d25488ad8724 is the first bad commit
commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka
Date: Thu Sep 24 15:09:17 2020 +0200
Add access through parameter derference tracking to modref
caused
FAIL: gcc.dg/ipa/ipa-pta-13.c
On Linux/x86_64,
2e66e53b1efb98f5cf6b0a123990c1ca999affd7 is the first bad commit
commit 2e66e53b1efb98f5cf6b0a123990c1ca999affd7
Author: Nathan Sidwell
Date: Thu Sep 24 06:17:00 2020 -0700
c++: local-decls are never member fns [PR97186]
caused
FAIL: g++.dg/template/local-fn4.C
On Linux/x86_64,
c33f474239308d81bf96cfdb2520d25488ad8724 is the first bad commit
commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka
Date: Thu Sep 24 15:09:17 2020 +0200
Add access through parameter derference tracking to modref
caused
FAIL:
On Sep 24, 2020, at 2:38 AM, Tom de Vries wrote:
>
> Fix this by adding an effective target ident_directive, and requiring
> it in both test-cases.
> OK for trunk?
Ok.
On Thu, Sep 24, 2020 at 11:04:38AM -0500, will schmidt wrote:
> [PATCH 2/2, rs6000] VSX load/store rightmost element operations
>
> Hi,
> This adds support for the VSX load/store rightmost element operations.
> This includes the instructions lxvrbx, lxvrhx, lxvrwx, lxvrdx,
> stxvrbx, stxvrhx,
On Linux/x86_64,
c33f474239308d81bf96cfdb2520d25488ad8724 is the first bad commit
commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka
Date: Thu Sep 24 15:09:17 2020 +0200
Add access through parameter derference tracking to modref
caused
FAIL: gcc.dg/ipa/ipa-pta-13.c
On Linux/x86_64,
c33f474239308d81bf96cfdb2520d25488ad8724 is the first bad commit
commit c33f474239308d81bf96cfdb2520d25488ad8724
Author: Jan Hubicka
Date: Thu Sep 24 15:09:17 2020 +0200
Add access through parameter derference tracking to modref
caused
FAIL:
The machinery recently added to support -Warray-parameter and
-Wvla-parameter also results in enhanced detection of null
pointer arguments to VLA function parameters. This enhancement
wasn't tested as comprehensively as it should have been and
so has some bugs. The attached patch fixes one that
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then we copy the big S in every iteration.
Using "const auto " would
On Linux/x86_64,
2e66e53b1efb98f5cf6b0a123990c1ca999affd7 is the first bad commit
commit 2e66e53b1efb98f5cf6b0a123990c1ca999affd7
Author: Nathan Sidwell
Date: Thu Sep 24 06:17:00 2020 -0700
c++: local-decls are never member fns [PR97186]
caused
FAIL: g++.dg/template/local-fn4.C
On Wed, Sep 23, 2020 at 05:12:45PM -0500, Paul A. Clarke wrote:
> Copied from gcc.target/i386.
Okay for trunk then. Thanks!
(I peeked, it is just fine ;-) )
Segher
Hi!
On Wed, Sep 23, 2020 at 05:12:44PM -0500, Paul A. Clarke wrote:
> +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> +_mm_insert_epi8 (__m128i const __A, int const __D, int const __N)
> +{
> + __v16qi result = (__v16qi)__A;
> +
> + result [(__N
Hi!
On Thu, Sep 24, 2020 at 10:59:09AM -0500, will schmidt wrote:
> This is a sub-set of the 128-bit sign extension support patch series
> that I believe will be fully implemented in a subsequent patch from Carl.
> This is a necessary pre-requisite for the vector-load/store rightmost
> element
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but provides mechanisms
for backwards compatibility between
On Thu, Sep 24, 2020 at 10:24:52AM +0200, Florian Weimer wrote:
> * Michael Meissner via Gcc-patches:
>
> > These patches are my latest versions of the patches to add IEEE 128-bit min,
> > max, and conditional move to GCC. They correspond to the earlier patches #3
> > and #4 (patches #1 and #2
PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.
This patch changes the __ibm128 emulator to use __builtin_pack_ieee128
instead of __builtin_pack_longdouble if long double is IEEE 128-bit, and
we need to use the __ibm128 type.
libgcc/
2020-09-23 Michael Meissner
*
>From e4114c9c13067b356f9ab5c5bb4c6a928771aef8 Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Wed, 23 Sep 2020 17:12:56 -0400
Subject: [PATCH 8/9] PowerPC: Change tests to use __float128 instead of
__ieee128.
Two of the tests used the __ieee128 keyword instead of __float128. This
patch
PowerPC: Update IEEE 128-bit built-in functions to work if long double is IEEE
128-bit.
This patch adds long double variants of the power10 __float128 built-in
functions. This is needed because __float128 uses TFmode in this case
instead of KFmode.
gcc/
2020-09-23 Michael Meissner
PowerPC: If long double is IEEE 128-bit, map q built-ins to *l instead of *f128.
If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support. This patch maps the functions
to the long double version if long double is IEEE 128-bit.
PowerPC: Update tests to run if long double is IEEE 128-bit.
gcc/testsuite/
2020-09-23 Michael Meissner
* c-c++-common/dfp/convert-bfp-11.c: If long double is IEEE
128-bit, skip the test.
* gcc.dg/nextafter-2.c: On PowerPC, if long double is IEEE
128-bit,
PowerPC: Add IEEE 128-bit <-> Decimal conversions.
This patch adds the basic support for converting between IEEE 128-bit floating
point and Decimal types.
libgcc/
2020-09-23 Michael Meissner
* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
[PATCH, rs6000] correct an erroneous blip in the BU_P10_MISC define
Hi,
We have extraneous BTM entry (RS6000_BTM_POWERPC64) in the define for
our P10 MISC 2 builtin definition. This does not exist for the '0',
'1' or '3' definitions. It appears to me that this was erroneously
copied from
Hi, Richard,
As you suggested, I added a default implementation of the target hook
“zero_cal_used_regs (HARD_REG_SET)” as following in my latest patch
/* The default hook for TARGET_ZERO_CALL_USED_REGS. */
void
default_zero_call_used_regs (HARD_REG_SET need_zeroed_hardregs)
{
gcc_assert
PowerPC: Update IEEE <-> IBM 128-bit floating point conversions.
This patch changes the code for doing conversions between IEEE 128-bit floating
point and IBM 128-bit extended double floating point. It moves the conversion
functions to a separate file. It uses explicit __ibm128 instead of long
PowerPC: Update __float128 and __ibm128 error messages.
This patch attempts to make the error messages for intermixing IEEE 128-bit
floating point with IBM 128-bit extended double types to be clearer if the long
double type uses the IEEE 128-bit format.
gcc/
2020-09-23 Michael Meissner
PowerPC: Map long double built-in functions if IEEE 128-bit long double.
This patch goes through the built-in functions and changes the name that is
used to the name used for __float128 and _Float128 support in glibc if the
PowerPC long double type is IEEE 128-bit instead of IBM extended double.
This series of 9 patches is an attempt to gather together all of the patches
that are needed to be able to configure and build a little endian 64-bit
PowerPC Linux GCC compiler where the defualt long double format uses the IEEE
128-bit representation.
I have created an IBM vendor branch that
In cleaning up local decl handling, here's an initial patch that takes
advantage of C++'s default args for the is_friend parm of pushdecl,
duplicate_decls and push_template_decl_real and the scope & tpl_header
parms of xref_tag. Then many of the calls simply not mention these.
I also rename
Hi!
On Thu, Sep 24, 2020 at 04:55:21PM +0200, Richard Biener wrote:
> Btw, on x86_64 the following produces sth reasonable:
>
> #define N 32
> typedef int T;
> typedef T V __attribute__((vector_size(N)));
> V setg (V v, int idx, T val)
> {
> V valv = (V){idx, idx, idx, idx, idx, idx, idx,
On 9/24/20 3:43 AM, Richard Biener wrote:
On Wed, 23 Sep 2020, Jason Merrill wrote:
On 9/23/20 2:42 PM, Richard Biener wrote:
On September 23, 2020 7:53:18 PM GMT+02:00, Jason Merrill
wrote:
On 9/23/20 4:14 AM, Richard Biener wrote:
C++ operator delete, when
Hi!
On Thu, Sep 24, 2020 at 03:27:48PM +0200, Richard Biener wrote:
> On Thu, Sep 24, 2020 at 10:21 AM xionghu luo wrote:
> I'll just comment that
>
> xxperm 34,34,33
> xxinsertw 34,0,12
> xxperm 34,34,32
>
> doesn't look like a variable-position insert instruction but
This libgo patch by Clément Chigot removes __go_ptrace on AIX. AIX
ptrace syscalls doesn't have the same semantic than the glibc one.
The syscall package is already handling it correctly so disable the
new __go_ptrace C function for AIX. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.
On Mon, 2020-09-21 at 16:57 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 5 adds the 128-bit integer to/from 128-floating point
> conversions. This patch has to invoke the routines to use the 128-
> bit
> hardware instructions if on Power 10 or use software routines if
> running on a pre
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 4 adds the vector 128-bit integer shift instruction support for
> the V1TI type.
>
> The following changes were made from the previous version.
>
> Renamed VSX_TI to VEC_TI, put def in vector.md. Didn't get it
>
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Add support for converting to/from 128-bit integers and 128-bit
> decimal floating point formats.
A more wordy blurb here clarifying what the patch does would be useful.
i.e. this adds support for dcffixqq and dctfixqq
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Segher, Will:
>
> Patch 1, adds the 128-bit sign extension instruction support and
> corresponding builtin support.
>
> No changes from the previous version.
>
> The patch has been tested on
>
> powerpc64le-unknown-linux-gnu (Power 9 LE)
On Mon, 2020-09-21 at 16:56 -0700, Carl Love wrote:
> Will, Segher:
>
> Add support for divide, modulo, shift, compare of 128-bit
> integers instructions and builtin support.
>
> The following are the changes from the previous version of the patch.
>
> The TARGET_TI_VECTOR_OPS was removed per
Hi Mark,
I haven't yet committed this.
I am unfamiliar with Andre, I've checked MAINTAINERS and I find Andre in
the "Write after approval" section.
Is Andre's approval sufficient? If so MAINTAINERS needs to be updated.
The official list of people who can review is at
On 20/08/20 18:31 +0300, Antony Polukhin via Libstdc++ wrote:
ср, 19 авг. 2020 г. в 14:29, Jonathan Wakely :
<...>
Do we also want to check
(std::__is_complete_or_unbounded(__type_identity<_ArgTypes>{}) && ...)
for invoke_result and the is_invocable traits?
Done.
Changelog:
2020-08-20
On Wed, Sep 23, 2020 at 04:51:01PM +0200, Mark Wielaard wrote:
> This adds a get_DW_UT_name function to dwarfnames using dwarf2.def
> for use in binutils readelf to show the unit types in a DWARF5 header.
>
> Also remove DW_CIE_VERSION which was already removed in binutils/gdb
> and is not used
On Thu, Sep 24, 2020 at 9:48 AM H.J. Lu wrote:
>
> On Wed, Sep 16, 2020 at 4:47 AM Jakub Jelinek wrote:
> >
> > On Wed, Sep 16, 2020 at 12:34:50PM +0100, Richard Sandiford wrote:
> > > Jakub Jelinek via Gcc-patches writes:
> > > > On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via
This fixlet makes sure -mcpu=xscale selects the correct VX_CPU.
Fixes a number of tests for arm-vxworks.
Committing to mainline shortly.
Olivier
2020-09-24 Olivier Hainque
* config/arm/vxworks.h (TARGET_OS_CPP_BUILTINS): Fix
the VX_CPU selection for -mcpu=xscale on
Arrange to inhibit the effects of CPLUSPLUS_CPP_SPEC in gnu-user.h,
which #defines _GNU_SOURCE, which is invalid for VxWorks (possibly
not providing ::mkstemp, for example).
This has been used in gcc-9 based production compilers for several targets
for a year, passed a build & test sequence for
To handle ports where we might arrange to use different
sets of fixed headers for different multilibs.
This has been used in gcc-9 based production compilers for several targets
for a year, passed a build & test sequence for powerpc-vxworks7 with gcc-10
and a sanity check build with a recent
On 9/24/20 12:46 AM, Aldy Hernandez wrote:
On 9/24/20 1:53 AM, Martin Sebor wrote:
Finally, unless both a type and function with the same name exist
in the same scope there is no reason to mention the class-id when
referencing a class name. I.e., this
value_range_equiv
The special vxworks rules for the compilation of libgcc had
-I.../gcc/include and not .../gcc/include-fixed, causing build
failure of our arm-vxworks7r2 port because of indirect dependencies
on limits.h.
The omission was just an oversight and this change just adds the
missing -I,
This fixes the
This is a minor adjustment to the vxworks specific macro name
used to guard the header file contents, to make it closer to the
original one and easier to search for.
We have been using this in gcc-9 based compilers for a while now,
I was able to build and test a gcc-10 based toolchain for
On Wed, Sep 16, 2020 at 4:47 AM Jakub Jelinek wrote:
>
> On Wed, Sep 16, 2020 at 12:34:50PM +0100, Richard Sandiford wrote:
> > Jakub Jelinek via Gcc-patches writes:
> > > On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote:
> > >> Something like this for GCC 8 and 9.
> > >
>
libstdc++-v3/ChangeLog:
* doc/xml/manual/configure.xml: Correct name of option.
* doc/html/*: Regenerate.
Committed to trunk.
commit 61f7995398a719f2ff91d07e8f8ed6d4413db697
Author: Jonathan Wakely
Date: Thu Sep 24 17:33:16 2020
libstdc++: Fix misnamed configure option
Hi Alex,
> -Original Message-
> From: Alex Coplan
> Sent: 24 September 2020 17:01
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH 2/2] arm: Add support for Neoverse N2 CPU
>
> This adds support for
Hi Alex,
> -Original Message-
> From: Alex Coplan
> Sent: 24 September 2020 17:00
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov
> Subject: [PATCH 1/2] aarch64: Add support for Neoverse N2 CPU
>
> This patch adds support for Arm's Neoverse
[PATCH 2/2, rs6000] VSX load/store rightmost element operations
Hi,
This adds support for the VSX load/store rightmost element operations.
This includes the instructions lxvrbx, lxvrhx, lxvrwx, lxvrdx,
stxvrbx, stxvrhx, stxvrwx, stxvrdx; And the builtins
vec_xl_sext() /* vector load sign extend
This adds support for Arm's Neoverse N2 CPU to the AArch32 backend.
Neoverse N2 builds AArch32 at EL0 and therefore needs support in AArch32
GCC.
Testing:
* Bootstrapped and regtested on arm-none-linux-gnueabihf.
OK for master?
Thanks,
Alex
---
gcc/ChangeLog:
*
This patch adds support for Arm's Neoverse N2 CPU to the AArch64
backend.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
OK for trunk?
Thanks,
Alex
---
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Add Neoverse N2.
* config/aarch64/aarch64-tune.md:
[PATCH, rs6000] int128 sign extention instructions (partial prereq)
Hi
This is a sub-set of the 128-bit sign extension support patch series
that I believe will be fully implemented in a subsequent patch from Carl.
This is a necessary pre-requisite for the vector-load/store rightmost
element
Hi all,
I'd like to backport support for the __jcvt intrinsic to the active branches as
it's an Armv8.3-a intrinsic that should have been supported there.
This is a squashed commit of the initial supported and a couple of follow-up
fixes from Andrea.
This is the GCC 8 version.
Bootstrapped and
Hi all,
I'd like to backport support for the __jcvt intrinsic to the active branches as
it's an Armv8.3-a intrinsic that should have been supported there.
This is a squashed commit of the initial supported and a couple of follow-up
fixes from Andrea.
This is the GCC 9 version.
Bootstrapped and
> I see it handy to debug cgraph_edge and I've dumped it manually many times.
> Maybe it's time to come up with the function? Example output:
>
> (gdb) p e->debug()
> ag/9 -> h/3 (1 (adjusted),0.25 per call)
>
> ag/9 (ag) @0x7773eca8
> Type: function definition analyzed
> Visibility:
Hi Richard,
thanks for reviewing
Richard Sandiford writes:
> Andrea Corallo writes:
>> Hi all,
>>
>> having a look for force_reg returned rtx later on modified I've found
>> this other case in `aarch64_general_expand_builtin` while expanding
>> pointer authentication builtins.
>>
>>
On Thu, 24 Sep 2020, Jonathan Wakely wrote:
> On 24/09/20 11:11 +0200, Richard Biener wrote:
> >On Wed, 26 Aug 2020, Richard Biener wrote:
> >
> >> On Thu, 6 Aug 2020, Richard Biener wrote:
> >>
> >> > On Thu, 6 Aug 2020, Richard Biener wrote:
> >> >
> >> > > This adds a move CTOR to auto_vec and
Thanks Richard for your recommendations.
I am still discussing with Kyrill about a good name for the branch.
Once we agree on a name we will commit the patches to that branch.
Sebastian
On 9/24/20, 4:10 AM, "Richard Biener" wrote:
On Fri, Sep 11, 2020 at 12:38 AM Pop, Sebastian via
On 24/09/20 09:04 -0400, Patrick Palka via Libstdc++ wrote:
The class template semiregular-box defined in [range.semi.wrap] is
used by a number of views to accomodate non-semiregular subobjects
while ensuring that the overall view remains semiregular. It provides
a stand-in default constructor,
On Thu, Sep 24, 2020 at 3:27 PM Richard Biener
wrote:
>
> On Thu, Sep 24, 2020 at 10:21 AM xionghu luo wrote:
> >
> > Hi Segher,
> >
> > The attached two patches are updated and split from
> > "[PATCH v2 2/2] rs6000: Expand vec_insert in expander instead of gimple
> > [PR79251]"
> > as your
I see it handy to debug cgraph_edge and I've dumped it manually many times.
Maybe it's time to come up with the function? Example output:
(gdb) p e->debug()
ag/9 -> h/3 (1 (adjusted),0.25 per call)
ag/9 (ag) @0x7773eca8
Type: function definition analyzed
Visibility: public
next
Fixes the conversion from UTF-8 to UTF-16 to properly return partial
instead ok.
Fixes the conversion from UTF-16 to UTF-8 to properly return partial
instead ok.
Fixes the conversion from UTF-8 to UCS-2 to properly return partial
instead error.
Fixes the conversion from UTF-8 to UCS-2 to treat
On Thu, Sep 24, 2020 at 10:21 AM xionghu luo wrote:
>
> Hi Segher,
>
> The attached two patches are updated and split from
> "[PATCH v2 2/2] rs6000: Expand vec_insert in expander instead of gimple
> [PR79251]"
> as your comments.
>
>
> [PATCH v3 2/3] rs6000: Fix lvsl mode and change
This fixes an ICE in noexcept instantiation. It was presuming
functions always have template_info, but that changed with my
DECL_LOCAL_DECL_P changes. Fortunately DECL_LOCAL_DECL_P fns are
never member fns, so we don't need to go fishing out a this pointer.
Also I realized I'd misnamed
Ping?
On Mon, 7 Sep 2020 at 18:13, Christophe Lyon wrote:
>
> Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
> branches over IT blocks on Cortex-M. As a result, instead of
> generating two nested IT blocks in thumb2-cond-cmp-[1234].c, we
> generate either a single IT block,
On 24/09/20 11:11 +0200, Richard Biener wrote:
On Wed, 26 Aug 2020, Richard Biener wrote:
On Thu, 6 Aug 2020, Richard Biener wrote:
> On Thu, 6 Aug 2020, Richard Biener wrote:
>
> > This adds a move CTOR to auto_vec and makes use of a
> > auto_vec return value for get_loop_exit_edges denoting
The class template semiregular-box defined in [range.semi.wrap] is
used by a number of views to accomodate non-semiregular subobjects
while ensuring that the overall view remains semiregular. It provides
a stand-in default constructor, copy assignment operator and move
assignment operator
On Thu, 24 Sep 2020, Tom de Vries wrote:
> On 9/24/20 1:42 PM, Richard Biener wrote:
> > On Wed, 23 Sep 2020, Tom de Vries wrote:
> >
> >> On 9/23/20 9:28 AM, Richard Biener wrote:
> >>> On Tue, 22 Sep 2020, Tom de Vries wrote:
> >>>
> [ was: Re: [Patch] [middle-end & nvptx] gcc/tracer.c:
On Wed, Sep 2, 2020 at 1:53 PM Martin Liška wrote:
>
> On 9/1/20 4:50 PM, David Malcolm wrote:
> > Hope this is constructive
> > Dave
>
> Thank you David. All of them very very useful!
>
> There's updated version of the patch.
I noticed several functions without a function-level comment.
-
xionghu luo writes:
> @@ -2658,6 +2659,43 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall
> *stmt, convert_optab optab)
>
> #define expand_vec_cond_mask_optab_fn expand_vect_cond_mask_optab_fn
>
> +/* Expand VEC_SET internal functions. */
> +
> +static void
> +expand_vec_set_optab_fn
Hi,
With nvptx, we run into:
...
FAIL: gcc.dg/tls/thr-cse-1.c scan-assembler-not \
emutls_get_address.*emutls_get_address.*
...
because the nvptx assembly looks like:
...
call (%value_in), __emutls_get_address, (%out_arg1);
...
// BEGIN GLOBAL FUNCTION DECL: __emutls_get_address
.extern
On 9/24/20 1:42 PM, Richard Biener wrote:
> On Wed, 23 Sep 2020, Tom de Vries wrote:
>
>> On 9/23/20 9:28 AM, Richard Biener wrote:
>>> On Tue, 22 Sep 2020, Tom de Vries wrote:
>>>
[ was: Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB
with SIMT LANE [PR95654] ]
Hi,
"duanbo (C)" writes:
> Sorry for the late reply.
My time to apologise for the late reply.
> Thanks for your suggestions. I have modified accordingly.
> Attached please find the v1 patch.
Thanks, the logic to choose which precision we pick looks good.
But I think the
On Wed, 23 Sep 2020, Tom de Vries wrote:
> On 9/23/20 9:28 AM, Richard Biener wrote:
> > On Tue, 22 Sep 2020, Tom de Vries wrote:
> >
> >> [ was: Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB
> >> with SIMT LANE [PR95654] ]
> >>
> >> On 9/16/20 8:20 PM, Alexander Monakov wrote:
>
Hi,
When running test-case gcc.dg/independent-cloneids-1.c for nvptx, we get:
...
FAIL: scan-assembler-times (?n)^_*bar[.$_]constprop[.$_]0: 1
FAIL: scan-assembler-times (?n)^_*bar[.$_]constprop[.$_]1: 1
FAIL: scan-assembler-times (?n)^_*bar[.$_]constprop[.$_]2: 1
FAIL: scan-assembler-times
On Thu, Sep 24, 2020 at 1:26 PM Jan Hubicka wrote:
>
> > >
> > > I will do (but need to think bit of a redundancy between comment in
> > > ipa-modref and ipa-modref-tree)
> >
> > One place is enough - just add a pointer to the other place.
> Here is updated patch I am testing. I adds
This adds another testcase for the PR97085 fix.
Pused.
2020-09-24 Richard Biener
PR tree-optimization/97085
* gcc.dg/pr97192.c: New testcase.
---
gcc/testsuite/gcc.dg/pr97192.c | 16
1 file changed, 16 insertions(+)
create mode 100644
> >
> > I will do (but need to think bit of a redundancy between comment in
> > ipa-modref and ipa-modref-tree)
>
> One place is enough - just add a pointer to the other place.
Here is updated patch I am testing. I adds documentation into
ipa-modref-tree.h that is perhaps more natural place and
On Thu, Sep 24, 2020 at 12:54 PM Jan Hubicka wrote:
>
> > > + else if (TREE_CODE (op) == SSA_NAME
> > > + && POINTER_TYPE_P (TREE_TYPE (op)))
> > > +{
> > > + if (DECL_P (base) && !ptr_deref_may_alias_decl_p (op, base))
> > > + return false;
> > > + if (TREE_CODE
> > + else if (TREE_CODE (op) == SSA_NAME
> > + && POINTER_TYPE_P (TREE_TYPE (op)))
> > +{
> > + if (DECL_P (base) && !ptr_deref_may_alias_decl_p (op, base))
> > + return false;
> > + if (TREE_CODE (base) == SSA_NAME
> > + && !ptr_derefs_may_alias_p (op,
Hi,
with nvptx we run into:
...
FAIL: gcc.dg/pr87314-1.c scan-assembler hellooo
...
The required string is part of the assembly, just in a different format than
expected:
...
.const .align 1 .u8 $LC0[12] =
{ 104, 101, 108, 108, 111, 111, 111, 111, 98, 121, 101, 0 };
...
Fix
On Thu, Sep 24, 2020 at 11:06 AM Jan Hubicka wrote:
>
> Hi,
> this patch re-adds tracking of accesses which was unfinished in David's patch.
> At the moment I only implemented tracking of the fact that access is based on
> derefernece of the parameter (so we track THIS pointers).
> Patch does not
Hi all,
I'd like to backport this fix from Tamar to the GCC 8 branch to avoid having
incorrectly-named intrinsics.
Tested on aarch64-none-elf.
Committing to the branch.
This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from u32 to f16
to be more consistent with the naming
Hi all,
I'd like to backport this patch to the GCC 8 branch that implements intrinsics
that were (erroneously) missed out
of the initial implementation in GCC 8.
Bootstrapped and tested on aarch64-none-linux-gnu on the branch.
This patch adds the missing neon intrinsics for all 128 bit vector
Hi,
On nvptx we run into:
...
FAIL: c-c++-common/ident-1b.c -Wc++-compat scan-assembler GCC:
FAIL: c-c++-common/ident-2b.c -Wc++-compat scan-assembler GCC:
...
Using a scan-assembler directive adds -fno-indent to the compile options.
The test c-c++-common/ident-1b.c adds dg-options
This fixes spurious complaints about PIC mode not supported
on "gcc --help=...", on VxWorks without -mrtp. The spurious message
is emitted by vxworks_override_options, called with flag_pic == -1
when we're running for --help.
The change simply adjusts the check testing for "we're generating pic
On Thu, Sep 24, 2020 at 11:50 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Sep 24, 2020 at 11:41:00AM +0200, Tobias Burnus wrote:
> > Following Jakub's suggestion, I also added
> > __attribute__((used))
> > to the tree belonging to both tables in omp-offload.c's omp_finish
> > but that
On Thu, Sep 24, 2020 at 11:41 AM Tobias Burnus wrote:
>
> On 9/24/20 10:03 AM, Richard Biener wrote:
>
> >> The symbols are added to offload_vars + offload_funcs.
> >> In lto-cgraph.c's output_offload_tables there is the last chance
> >> to remove now unused nodes ? as once the tables are
Andrea Corallo writes:
> Kyrylo Tkachov writes:
[...]
>>
>> Can you please also backport it to the appropriate branches as well after
>> some time on trunk.
>> Thanks,
>> Kyrill
>
> Ciao Kyrill,
>
> Sure happy to do that. For now into trunk as 2c62952f816.
Backported into gcc-10 as
On Thu, Sep 24, 2020 at 11:41:00AM +0200, Tobias Burnus wrote:
> Following Jakub's suggestion, I also added
> __attribute__((used))
> to the tree belonging to both tables in omp-offload.c's omp_finish
> but that did not help, either.
That is really DECL_PRESERVED_P, the attribute is turned into
Hello,
After
https://gcc.gnu.org/pipermail/gcc-patches/2020-January/537843.html
and
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg01398.html
Re-proposing this patch after re-testing with a recent
mainline on on aarch64-linux (bootstrap and regression test
with --enable-languages=all),
On 9/24/20 10:03 AM, Richard Biener wrote:
The symbols are added to offload_vars + offload_funcs.
In lto-cgraph.c's output_offload_tables there is the last chance
to remove now unused nodes ? as once the tables are streamed
for device usage, they cannot be changed. Hence, there one
has
On 24/09/20 10:15 +0300, Antony Polukhin via Libstdc++ wrote:
Looks like the last patch was not applied. Do I have to change something in
it?
No, it just hasn't been reviewed yet.
1 - 100 of 127 matches
Mail list logo
