- 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 ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
Bug ID: 97198
Summary: __is_constructible(int[], int) should return true
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #14 from Hongtao.liu ---
> Still I don't understand why compiler does not compare the cost of full loop
> body after combining to the cost before combining and does not come to
> conclusion that combining increased the cost.
As
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97183
--- Comment #3 from Jim Wilson ---
I installed Ubuntu 16.04 on an old laptop so I can directly reproduce the build
failure.
Checking for the zstd version looks like the easier patch.
Checking for specific macros and functions might be better,
Hi, Richard
> "Hu, Jiangping" writes:
> > Hi,
> >
> > I find there are many "ATTRIBUTE_UNUSED" macros in the function
> parameter lists,
> > but some of the parameters are used in the function bodies in fact. E.g.
> >
> > @@gcc/final.c
> > void
> > output_operand (rtx x, int code
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #7 from Rich Felker ---
Indeed, the direct clock_gettime syscall stuff is just unnecessary on any
modern system, certainly any time64 one. I read the patch briefly and I don't
see anywhere it would break anything, but it also
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97188
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Martin Sebor
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #6 from Jonathan Wakely ---
On second thoughts, we probably don't need to worry about
SYS_clock_gettime_time64. We only use SYS_clock_gettime syscalls on old glibc
systems where clock_gettime is in librt not libc, and those systems
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97182
--- Comment #5 from Jim Wilson ---
I see that a riscv64-linux libgomp.so has mutex calls and no obvious futex
calls. Though I find it a little curious that futex support isn't
auto-detected. There is already config/futex.m4 to detect futex
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
Snapshot gcc-8-20200924 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
I posted version 1 of the patches of the stuff needed to allow little endian
64-bit GCC on Linux to be configured to use long double.
As per the discussion in this thread, I did decide to keep things to two types
within the compiler. This means that an explicit __float128 or _Float128 will
use
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97190
Martin Sebor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97175
--- Comment #8 from Martin Sebor ---
*** Bug 97190 has been marked as a duplicate of this bug. ***
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97193
--- Comment #3 from Mario Klebsch ---
If it was a desired change, what were the reasons for this change?
This change breaks my makefiles. I am cross compiling for several different
targets possibly using a different version of gcc for each
incorrectly, it prints out:
count = 0
Tested with build g++ (GCC) 11.0.0 20200924 (experimental).
In order to compile and run:
g++ -std=c++17 -O3 -o bug-6 bug-6.cpp && ./bug-6
This builds for implicit '-m64' (x86_64) and produces invalid output.
To get valid output, compile wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97059
--- Comment #2 from Dimitri Gorokhovik ---
(In reply to Dimitri Gorokhovik from comment #1)
> I was able to reduce same code (attached file bug-6.cpp).
Please disregard the comment #1 -- posted to wrong bug.
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
, it prints out:
count = 0
Tested with build g++ (GCC) 11.0.0 20200924 (experimental).
In order to compile and run:
g++ -std=c++17 -O3 -o bug-6 bug-6.cpp && ./bug-6
This builds for implicit '-m64' (x86_64) and produces invalid output.
To get valid output, compile with either of the f
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94485
Dimitri Gorokhovik changed:
What|Removed |Added
Attachment #48194|0 |1
is obsolete|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97177
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97171
Nathan Sidwell changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97115
--- Comment #1 from David Malcolm ---
"Static Initialization Order Fiasco"
https://en.cppreference.com/w/cpp/language/siof
https://isocpp.org/wiki/faq/ctors#static-init-order
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97177
Nathan Sidwell changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot
gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c1fc9f6e10e646f01194c8f150affbc1cfbc404a
commit r11-3442-gc1fc9f6e10e646f01194c8f150affbc1cfbc404a
Author: Antony Polukhin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86883
vopl at bk dot ru changed:
What|Removed |Added
CC||vopl at bk dot ru
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032
--- Comment #7 from CVS Commits ---
The releases/gcc-8 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:97c34eb5f57bb1d37f3feddefefa5f553bcea9fc
commit r8-10533-g97c34eb5f57bb1d37f3feddefefa5f553bcea9fc
Author: H.J. Lu
Date: Mon
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97188
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412
Nathan Sidwell changed:
What|Removed |Added
Last reconfirmed||2020-09-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97175
--- Comment #7 from David Binderman ---
Interesting.
$ fgrep DECL_SOURCE_LOCATION `find trunk/gcc -name \*.c -print | fgrep -v
/testsuite/` | wc -l
1002
$ fgrep EXPR_LOCATION `find trunk/gcc -name \*.c -print | fgrep -v /testsuite/`
| wc -l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90380
Prasannanjaneyulu changed:
What|Removed |Added
CC||p.padavala@camlintechnologi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032
--- Comment #6 from CVS Commits ---
The releases/gcc-9 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:3bec35d813cc706b3334bd0b0edbd51869b0f725
commit r9-8937-g3bec35d813cc706b3334bd0b0edbd51869b0f725
Author: H.J. Lu
Date: Mon
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97175
--- Comment #6 from Martin Sebor ---
It definitely would be a step in the right direction. But I'm not sure how
feasible it is to turn any of these tests into compile-time. They often test
different bits in different structures. For example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97032
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f0baed1fb6cd6ed7c7a3dce1f555d3f72b1575a5
commit r10-8796-gf0baed1fb6cd6ed7c7a3dce1f555d3f72b1575a5
Author: H.J. Lu
Date: Mon
[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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #41 from CVS Commits ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:a8ec9cc2241f4e0c387e78f23bae0100c74de6a8
commit r8-10532-ga8ec9cc2241f4e0c387e78f23bae0100c74de6a8
Author: Kyrylo Tkachov
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #40 from CVS Commits ---
The releases/gcc-9 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:6f06be1769d45359940c60517f9d55bedd3cb1f4
commit r9-8936-g6f06be1769d45359940c60517f9d55bedd3cb1f4
Author: Kyrylo Tkachov
> 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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361
Prasannanjaneyulu changed:
What|Removed |Added
CC||p.padavala@camlintechnologi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197
Bug ID: 97197
Summary: With -O2, Incorrect -Werror=maybe-uninitialized
thrown, leads to 'target_mem_ref' and
'dump_expr' in message
Product: gcc
Version: 10.2.0
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.
>>
>>
1 - 100 of 239 matches
Mail list logo
