On Wed, 23 Sep 2020, Tobias Burnus wrote:
> Actually working patch attached.
>
> As mentioned, just using TREE_PUBLIC in input_offload_tables
> works for functions but for variables this gets overridden.
>
> The externally_visible is set to avoid running into the
> promote_symbol code (? visibil
On 9/24/20 8:40 AM, Tom de Vries wrote:
Maybe we could require building libatomic for nvptx.
If one does not explicitly disable it, it builds,* which
I think is a good default. Additionally, libatomic is
only very rarely needed on x86-64 + nvptx and only
somewhat regularly on PowerPC + nvptx.
Looks like the last patch was not applied. Do I have to change something in
it?
On 9/23/20 5:02 PM, Martin Jambor wrote:
Hi,
On Wed, Sep 23 2020, Martin Liška wrote:
There's patch that does that.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
From ff5f78110684ed9aedde15d19e856b3acf649971 Mon Sep 17 00:00:00 2
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 DECL_IS_REPLACEABLE_OPERATOR_DELETE_P,
> >>> does not cause
On 9/24/20 9:03 AM, Richard Biener wrote:
Hmm, but offload_vars and offload_funcs do not need to be exported
since they get stored into tables with addresses pointing to them
(and that table is exported).
Granted but the x86-64 linker does not seem to be able to resolve
the symbol if the table
On Thu, 24 Sep 2020, Tobias Burnus wrote:
> On 9/24/20 9:03 AM, Richard Biener wrote:
>
> > Hmm, but offload_vars and offload_funcs do not need to be exported
> > since they get stored into tables with addresses pointing to them
> > (and that table is exported).
>
> Granted but the x86-64 linker
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.
If not: OK to commit and backport?
regards,
Mark
On 14/09/2020 09:03, Andre Vehr
Hi,
With the nvptx target, we run into:
...
FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(
The following aovids the ICE in the testcase by doing some additional
simplification of VEC_COND_EXPRs for VECTOR_BOOLEAN_TYPE_P which
we don't really expect, esp. when they are not classical vectors,
thus AVX512 or SVE masks.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-09-2
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&lvsr mode and change rs6000_expand_vector_set
param
This one is preparation work of fix lvsl&lvs
* 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 have been installed).
Is this about IEEE min or IEEE minimum? My understan
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 23 September 2020 19:34
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH] arm: Add a couple of extra stack-protector tests
>
> These tes
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 23 September 2020 19:20
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov ; Kees Cook
> Subject: [PATCH] arm: Fix canary address calculation for non-PIC
>
This patch backports the AArch64 support for Arm's Neoverse V1 CPU to
GCC 10.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
OK for GCC 10 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Add Neoverse V1.
* config/aarch64/aarch64-t
Kyrylo Tkachov writes:
> Hi Richard,
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: 23 September 2020 19:34
>> To: gcc-patches@gcc.gnu.org
>> Cc: ni...@redhat.com; Richard Earnshaw ;
>> Ramana Radhakrishnan ; Kyrylo
>> Tkachov
>> Subject: [PATCH] arm: Add a couple of extra s
This patch backports the AArch64 support for Arm's Neoverse V1 CPU to
GCC 9.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
OK for GCC 9 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Add Neoverse V1.
* config/aarch64/aarch64-tun
This patch backports the AArch64 support for Arm's Neoverse V1 CPU to
GCC 8.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
OK for GCC 8 branch?
Thanks,
Alex
---
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Add Neoverse V1.
* config/aarch64/aarch64-tun
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 implement IPA propagation since it needs bit more work which
I wi
On Fri, Sep 11, 2020 at 12:38 AM Pop, Sebastian via Gcc-patches
wrote:
>
> Hi,
>
> the attached patches are back-porting the flag -moutline-atomics to the
> gcc-7-arm vendor branch.
> The flag enables a very important performance optimization for N1-neoverse
> processors.
> The patches pass boot
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
> > > that lifetime management of the
Hi Alex,
> -Original Message-
> From: Alex Coplan
> Sent: 24 September 2020 10:01
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov
> Subject: [PATCH][GCC 8] aarch64: Add support for Neoverse V1 CPU
>
> This patch backports the AArch64 support f
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.
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
node-
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 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
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 aa47c98734
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 streamed
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 di
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 c
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 "-fident
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 conventi
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 I
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,
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 thi
> > + 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, base))
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 (bas
> >
> > 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 l
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 gcc/testsuite/gcc.dg/pr
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 documentatio
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 (?n)^_
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,
"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 build_mask_conversions
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] ]
O
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 .fun
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
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.
- clus
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: Do
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 whenever
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
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, o
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 local10
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&lvsr mode and change rs6000_
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 4-by
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 sharing
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 com
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 Gcc-pat
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, 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
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.
>>
>> Regtested
> 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: publ
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
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
[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
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: Rege
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:
* config/arm/arm-cpus.in
[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
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 N2
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 Arm'
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 in
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.
> > >
>
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 ppc-vxw
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
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 *allocate_value_ra
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 main
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 po
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 arm-vxw
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 Gcc-patches
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 in
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 Anton
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
https://gcc.gnu.org/
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:
> 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 inst
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 co
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 Powe
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
> separ
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.
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
>
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 DECL_IS_REPLACEABLE_OPERATOR_DEL
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, idx};
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 push
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 inclu
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.
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: 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
d
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 (!h
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 the
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, includ
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.
gcc/
1 - 100 of 126 matches
Mail list logo