Hi!
As mentioned in the PR, this hunk is guarded with !wi::neg_p (r1val | r1mask,
sgn)
which means if sgn is UNSIGNED, it is always true, but r1val | r1mask in
widest_int is still sign-extended. That means wi::clz (arg) returns 0,
wi::get_precision (arg) returns some very large number
(WIDE_INT_
On 2021/8/30 17:19, Richard Biener wrote:
bitmap_set_bit (work_set, loop->header->index);
+ unsigned bb_index;
- for (i = 0; i < loop->num_nodes; i++)
- {
- edge_iterator ei;
- bb = bbs[i];
+ unsigned array_size = last_basic_block_for_fn (cfun) + 1;
Hi!
The removal of remove_zero_width_bitfields function and its call from
C++ FE layout_class_type (which I've done in the P0466R5
layout-compatible helper intrinsics patch, so that the FE can actually
determine what is and isn't layout-compatible according to the spec)
unfortunately changed the A
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, this hunk is guarded with !wi::neg_p (r1val | r1mask,
> sgn)
> which means if sgn is UNSIGNED, it is always true, but r1val | r1mask in
> widest_int is still sign-extended. That means wi::clz (arg) returns 0,
> wi::get_
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> Hi!
>
> The removal of remove_zero_width_bitfields function and its call from
> C++ FE layout_class_type (which I've done in the P0466R5
> layout-compatible helper intrinsics patch, so that the FE can actually
> determine what is and isn't layout-compat
On Tue, 31 Aug 2021, Richard Biener wrote:
> On Tue, 31 Aug 2021, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The removal of remove_zero_width_bitfields function and its call from
> > C++ FE layout_class_type (which I've done in the P0466R5
> > layout-compatible helper intrinsics patch, so that the F
Hi!
This is an incremental patch to
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578447.html
for x86_64 ABI.
For zero-width bitfields current GCC classify_argument does:
if (DECL_BIT_FIELD (field))
{
for (i = (int_bit_position (f
On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> Just to clarify - in the C++ FE these fields are meaningful for
> layout purposes but they are only supposed to influence layout
> but not ABI (but why does the C++ FE say that?) and thus the
> 'DECL_FIELD_ABI_IGNORED' is a good term
The description of behaviour is incorrect, the virtual base gets
assigned before entering the bodies of A::operator= and B::operator=,
not after.
The example is also ill-formed (passing a string literal to char*) and
undefined (missing return from Base::operator=).
Signed-off-by: Jonathan Wakely
It looks like my questions about this patch never got an answer, and
it never got applied.
Could somebody say whether TLS is enabled for native *-*-mingw*
builds? If it is, then we definitely need to add GCC_CHECK_TLS to the
cross-compiler config too.
For a linux-hosted x86_64-w64-mingw32 cross c
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote:
> > Just to clarify - in the C++ FE these fields are meaningful for
> > layout purposes but they are only supposed to influence layout
> > but not ABI (but why does the C++ FE say that?) and
When doing whole-function SLP we have to make sure the recorded
base alignments we compute as the maximum alignment seen for a
base anywhere in the function is actually valid at the point
we want to make use of it.
To make this work we now record the stmt the alignment was derived
from in addition
The following avoids applying TER to possibly trapping expressions,
preventing a trapping FP multiplication to be moved across a call
that should not be executed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-08-31 Richard Biener
PR middle-end/102129
* tree
YunQiang Su writes:
> Currently, the enums from define_c_enum and define_enum can only
> has values one by one from 0.
>
> In fact we can support the behaviour just like C, aka like
> (define_enum "mips_isa" [mips1=1 mips2 mips32=32 mips32r2]),
> then we can get
> enum mips_isa {
> MIPS_IS
Richard Biener writes:
> On Mon, Aug 30, 2021 at 12:59 PM Thomas Schwinge
> wrote:
>>
>> Hi!
>>
>> Ping. For easy reference I've again attached Richard Sandiford's
>> "libgcc: Add missing runtime exception notices".
>>
>> On 2021-07-12T17:34:09+0100, Richard Sandiford via Gcc-patches
>> wrote:
This patch fixes an ICE during error-recovery regression in the C front-end.
The symptom is that the middle-end's sanity checking assertions fail during
gimplification when being asked to increment an array, which is non-sense.
The issue is that the C-front end has detected the type mismatch and
r
On Mon, Aug 30, 2021 at 8:25 PM Richard Biener via Gcc-patches
wrote:
>
> On Fri, Aug 27, 2021 at 8:53 AM liuhongt wrote:
> >
> > When gimple simplifcation try to combine op and vec_cond_expr to cond_op,
> > it doesn't check if mask type matches. It causes an ICE when expand cond_op
> > with mi
This fixes a typo in the condition guarding the cleanup of the
visited flag of costed scalar stmts.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-08-31 Richard Biener
PR tree-optimization/102142
* tree-vect-slp.c (vect_bb_vectorization_profitable_p): Fix
Currently, the enums from define_c_enum and define_enum can only
has values one by one from 0.
In fact we can support the behaviour just like C, aka like
(define_enum "mips_isa" [(mips1 1) mips2 (mips32 32) mips32r2]),
then we can get
enum mips_isa {
MIPS_ISA_MIPS1 = 1,
MIPS_ISA_MIPS2
On Tue, Aug 31, 2021 at 8:48 AM Hongtao Liu wrote:
>
> On Tue, Aug 31, 2021 at 2:30 PM Hongtao Liu wrote:
> >
> > On Tue, Aug 31, 2021 at 2:11 PM Richard Biener
> > wrote:
> > >
> > > On Fri, Aug 27, 2021 at 6:50 AM Hongtao Liu wrote:
> > > >
> > > > On Thu, Aug 26, 2021 at 7:09 PM Richard Bien
This reverts commit 7218c2ec365ce95f5a1012a6eb425b0a36aec6bf.
PR middle-end/102133
---
gcc/expmed.c | 103 +--
1 file changed, 25 insertions(+), 78 deletions(-)
diff --git a/gcc/expmed.c b/gcc/expmed.c
index f083d6e86d0..3143f38e057 100644
---
Hi:
There's 2 patches, the first patch revert my r12-3218 which caused ICE
in PR102133, the second one remove all float-int special cases in
validate_subreg as suggested in [1].
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
PS: I am building SPEC2017 and eembc to see
gcc/ChangeLog:
* emit-rtl.c (validate_subreg): Get rid of all float-int
special cases.
---
gcc/emit-rtl.c | 40
1 file changed, 40 deletions(-)
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index ff3b4449b37..77ea8948ee8 100644
--- a/gcc/em
Currently, the enums from define_c_enum and define_enum can only
has values one by one from 0.
In fact we can support the behaviour just like C, aka like
(define_enum "mips_isa" [(mips1 1) mips2 (mips32 32) mips32r2]),
then we can get
enum mips_isa {
MIPS_ISA_MIPS1 = 1,
MIPS_ISA_MIPS2
YunQiang Su 于2021年8月31日周二 下午7:09写道：
>
> Currently, the enums from define_c_enum and define_enum can only
> has values one by one from 0.
>
> In fact we can support the behaviour just like C, aka like
> (define_enum "mips_isa" [(mips1 1) mips2 (mips32 32) mips32r2]),
> then we can get
> enum mi
On Tue, 31 Aug 2021, Xionghu Luo wrote:
>
>
> On 2021/8/30 17:19, Richard Biener wrote:
> bitmap_set_bit (work_set, loop->header->index);
> + unsigned bb_index;
> - for (i = 0; i < loop->num_nodes; i++)
> -{
> - edge_iterator ei;
>
On Tue, Aug 31, 2021 at 11:26 AM Richard Biener via Gcc-patches
wrote:
>
> When doing whole-function SLP we have to make sure the recorded
> base alignments we compute as the maximum alignment seen for a
> base anywhere in the function is actually valid at the point
> we want to make use of it.
>
On Tue, Aug 31, 2021 at 12:18 PM Hongtao Liu wrote:
>
> On Mon, Aug 30, 2021 at 8:25 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Fri, Aug 27, 2021 at 8:53 AM liuhongt wrote:
> > >
> > > When gimple simplifcation try to combine op and vec_cond_expr to
> > > cond_op,
> > > it doesn't
On Tue, Aug 31, 2021 at 1:17 PM liuhongt wrote:
>
> gcc/ChangeLog:
OK.
Thanks,
Richard.
> * emit-rtl.c (validate_subreg): Get rid of all float-int
> special cases.
> ---
> gcc/emit-rtl.c | 40
> 1 file changed, 40 deletions(-)
>
> diff -
Hi!
The following testcase is miscompiled on aarch64-linux at -O3 since the
introduction of WIDEN_MINUS_EXPR.
The problem is if the inner type (half_type) is unsigned and the result
type in which the subtraction is performed (type) has precision more than
twice as larger as the inner type's precis
Hi!
I'm getting:
FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1 loops" 7
FAIL: gcc.dg/vect/pr101145_1.c scan-tree-dump-times vect "vectorized 1 loops" 2
FAIL: gcc.dg/vect/pr101145_2.c scan-tree-dump-times vect "vectorized 1 loops" 2
FAIL: gcc.dg/vect/pr101145_3.c scan-tree-du
On 29/08/2021 09:46, Roger Sayle wrote:
SUBREG_PROMOTED_VAR_P is a mechanism for tracking that a partial subreg
is correctly zero-extended or sign-extended in the parent register. For
example, the RTL (subreg/s/v:QI (reg/v:SI 23 [ x ]) 0) indicates that the
byte x is zero extended in reg:SI 23
David: PING
Le jeudi 29 juillet 2021 à 08:59 -0400, Antoni Boucher a écrit :
> David: PING
>
> Le lundi 19 juillet 2021 à 12:10 -0400, Antoni Boucher a écrit :
> > I'm sending the patch once again for review/approval.
> >
> > I fixed the doc to use the new function names.
> >
> > Le vendredi 18
On 2021-08-31 20:12, Jakub Jelinek wrote:
Hi!
I'm getting:
FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1
loops" 7
FAIL: gcc.dg/vect/pr101145_1.c scan-tree-dump-times vect "vectorized 1
loops" 2
FAIL: gcc.dg/vect/pr101145_2.c scan-tree-dump-times vect "vectorized 1
loops
On Tue, Aug 31, 2021 at 8:22 AM Roger Sayle wrote:
>
>
> Time to hopefully earn some goodwill from the team; this patch fixes
> a P1 wrong-code-on-valid regression in ivopts. Many thanks to Andrew
> Pinski for help with the analysis.
>
> Consider the code fragment below:
>
> int i;
>
On Tue, 31 Aug 2021, Jakub Jelinek wrote:
> Hi!
>
> I'm getting:
> FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1 loops" 7
> FAIL: gcc.dg/vect/pr101145_1.c scan-tree-dump-times vect "vectorized 1 loops"
> 2
> FAIL: gcc.dg/vect/pr101145_2.c scan-tree-dump-times vect "vectori
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc: Undefine some more names used
by Solaris system headers.
Tested x86_64-linux and sparc-solaris2.11. Committed to trunk.
commit 69b09c5599b201ac039db564c303f7b20d87e0df
Author: Jonathan Wakely
Hi Christophe,
I'm testing the attached patch, but without an aarch64, it'll take a while to
figure
out the toolchain to reproduce the failure. Neither of the platforms I tested
were
affected, but I can see it's unsafe to reuse the subreg_promoted_reg idiom from
just a few lines earlier. Any h
On Thu, Aug 12, 2021 at 8:24 PM Ian Lance Taylor via Gcc-patches
wrote:
>
> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
> release. As usual with these version updates, the patch itself is too
> large to attach to this e-mail message. I've attached the changes to
> files
Hi All,
Consider the following case
#include
uint64_t
test4 (uint8x16_t input)
{
uint8x16_t bool_input = vshrq_n_u8(input, 7);
poly64x2_t mask = vdupq_n_p64(0x0102040810204080UL);
poly64_t prodL = vmull_p64((poly64_t)vgetq_lane_p64((poly64x2_t)bool_input,
0),
Hi All,
As the vectorizer has improved over time in capabilities it has started
over-vectorizing. This has causes regressions in the order of 1-7x on libraries
that Arm produces.
The vector costs actually do make a lot of sense and I don't think that they are
wrong. I think that the costs for t
Hi All,
This patch gets CSE to re-use constants already inside a vector rather than
re-materializing the constant again.
Basically consider the following case:
#include
#include
uint64_t
test (uint64_t a, uint64x2_t b, uint64x2_t* rt)
{
uint64_t arr[2] = { 0x0942430810234076UL, 0x0942430810
Hi All,
This patch adds extended costing to cost the creation of constants and the
manipulation of constants. The default values provided are based on
architectural expectations and each cost models can be individually tweaked as
needed.
The changes in this patch covers:
* Construction of PARAL
Hi All,
The following example
void f10(double * restrict z, double * restrict w, double * restrict x,
double * restrict y, int n)
{
for (int i = 0; i < n; i++) {
z[i] = (w[i] > 0) ? x[i] + w[i] : y[i] - w[i];
}
}
generates currently:
ld1dz1.d, p1/z, [x1, x5,
Hi All,
The following example
void f5(float * restrict z0, float * restrict z1, float *restrict x,
float * restrict y, float c, int n)
{
for (int i = 0; i < n; i++) {
float a = x[i];
float b = y[i];
if (a > b) {
z0[i] = a + b;
if (a > c)
Hi All,
The following example:
void f11(double * restrict z, double * restrict w, double * restrict x,
double * restrict y, int n)
{
for (int i = 0; i < n; i++) {
z[i] = (w[i] > 0) ? w[i] : y[i];
}
}
Generates currently:
ptrue p2.b, all
ld1dz0.d, p
Hi All,
The following loop does a conditional reduction using an add:
#include
int32_t f (int32_t *restrict array, int len, int min)
{
int32_t iSum = 0;
for (int i=0; i= min)
iSum += array[i];
}
return iSum;
}
for this we currently generate:
mov z1.b, #0
mo
On Tue, 31 Aug 2021, guojiufu wrote:
> On 2021-08-30 20:02, Richard Biener wrote:
> > On Mon, 30 Aug 2021, guojiufu wrote:
> >
> >> On 2021-08-30 14:15, Jiufu Guo wrote:
> >> > Hi,
> >> >
> >> > In patch r12-3136, niter->control, niter->bound and niter->cmp are
> >> > derived from number_of_itera
These bugs are considered duplicate cases of PR51851 which has been suspended
since 2012, an issue known as "core1001/1322". Considering this background,
it deserves a long comment to explain.
Many people believed the root cause of this family of bugs is related with
the nature of how and when
Dropping stabs from cris, m32r, mn103/am33, xtensa & m32c. No
particular rhyme or reason to those ports.
Committed to the trunk,
Jeff
commit d158c3f77738e1d44aa117c1674e9ec8dee38661
Author: Jeff Law
Date: Tue Aug 31 09:48:02 2021 -0400
More stabs removal.
gcc/
On 8/30/21 12:54 PM, Tobias Burnus wrote:
> Document Roger's patch
> https://gcc.gnu.org/g:3c496e92d795a8fe5c527e3c5b5a6606669ae50d
>
> OK? Suggestions?
>
LGTM.
Thanks,
- Tom
To best handle BTF/CO-RE in GCC, a distinct BTF_WITH_CORE_DEBUG debug format is
being added. This helps the compiler detect whether BTF with CO-RE relocations
needs to be emitted.
gcc/ChangeLog:
* flag-types.h (enum debug_info_type): Add new enum
DINFO_TYPE_BTF_WITH_CORE.
[Changes from V2]
- Instead of target hook, the patch set now adds a new debug format
BTF_WITH_CORE_DEBUG.
- Renamed the BPF option from -mcore to -mco-re.
- Adapted the commit logs a bit.
[End of Changes from V2]
Hello,
This patch series puts the framework in place for late BTF generation (in
d
-mco-re in the BPF backend enables code generation for the CO-RE usecase. LTO is
disabled for CO-RE compilations.
gcc/ChangeLog:
* config/bpf/bpf.c (bpf_option_override): For BPF backend, disable LTO
support when compiling for CO-RE.
* config/bpf/bpf.opt: Add new command l
DWARF generation is split between early and late phases when LTO is in effect.
This poses challenges for CTF/BTF generation especially if late debug info
generation is desirable, as turns out to be the case for BPF CO-RE.
The approach taken here in this patch is:
1. LTO is disabled for BPF CO-RE
Hi Jakub!
We never finished this dicussion here -- but I ran into this again, last
week:
On 2019-05-29T18:59:46+0200, I wrote:
> On Mon, 27 May 2019 18:49:20 +0200, Jakub Jelinek wrote:
>> On Sun, May 26, 2019 at 07:43:04PM +0200, Thomas Schwinge wrote:
>> > On Tue, 18 Oct 2005 03:01:40 -0400, J
在 2021-08-31 17:02, Jonathan Wakely 写道:
> It looks like my questions about this patch never got an answer, and
> it never got applied.
>
> Could somebody say whether TLS is enabled for native *-*-mingw*
> builds? If it is, then we definitely need to add GCC_CHECK_TLS to the
> cross-compiler config
On Tue, Aug 31, 2021 at 04:28:19PM +0200, Thomas Schwinge wrote:
> >From fb29fe81b4c8e880b32d68351385d8a42c97934b Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Wed, 29 May 2019 18:59:46 +0200
> Subject: [PATCH] [OMP] Standardize on 'omp_privatize_by_reference'
>
> ... instead of 'omp_i
Tamar Christina writes:
> Hi All,
>
> As the vectorizer has improved over time in capabilities it has started
> over-vectorizing. This has causes regressions in the order of 1-7x on
> libraries
> that Arm produces.
>
> The vector costs actually do make a lot of sense and I don't think that they
Ping patch.
| Date: Wed, 25 Aug 2021 15:46:43 -0400
| Subject: [PATCH] Generate XXSPLTIDP on power10.
| Message-ID:
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Recent improvements to Ranger have optimized away some of the code in
mips/data-sym-multi-pool.c which in turn causes the test to fail as it's
looking for specific bits in the assembly output. The easiest fix here
which preserves the intent of the test is to disable VRP as done by this
patch.
Tamar Christina writes:
> @@ -13936,8 +13937,65 @@ cost_plus:
>mode, MULT, 1, speed);
>return true;
> }
> + break;
> +case PARALLEL:
> + /* Fall through */
Which code paths lead to getting a PARALLEL here?
> +case CONST_VECTOR:
>
On 8/31/2021 7:24 AM, Roger Sayle wrote:
Hi Christophe,
I'm testing the attached patch, but without an aarch64, it'll take a while to
figure
out the toolchain to reproduce the failure. Neither of the platforms I tested
were
affected, but I can see it's unsafe to reuse the subreg_promoted_re
---
libffi/testsuite/lib/libffi.exp | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
index 4f4dd48d2c6..d8bf6269a36 100644
--- a/libffi/testsuite/lib/libffi.exp
+++ b/libffi/testsuite/lib
Add scripts for syncing with libffi upstream:
1. Clone libffi repo.
2. Checkout the specific commit.
3. Remove the unused files.
4. Add new files if needed.
* HOWTO_MERGE: New file.
* autogen.sh: Likewise.
* merge.sh: Likewise.
---
libffi/HOWTO_MERGE | 13
li
1. Integrate with GCC.
2. Support multilib.
* Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir.
(ACLOCAL_AMFLAGS): Set to -I .. -I ../config.
(SUBDIRS): Don't add doc.
(TEXINFO_TEX): New.
(MAKEINFOFLAGS): Likewise.
(info_TEXINFOS): Likewise.
GCC maintained a copy of libffi snapshot from 2009 and cherry-picked fixes
from upstream over the last 10+ years. In the meantime, libffi upstream
has been changed significantly with new features, bug fixes and new target
support. Here is a set of patches to sync with libffi 3.4.2 release and
ma
Merged commit: f9ea41683444ebe11cfa45b05223899764df28fb
---
libffi/.gitattributes | 4 +
libffi/ChangeLog.libffi | 7743 +-
libffi/LICENSE| 2 +-
libffi/LICENSE-BUILDTOOLS | 353 +
libf
Tamar Christina writes:
> Hi All,
>
> The following example
>
> void f10(double * restrict z, double * restrict w, double * restrict x,
>double * restrict y, int n)
> {
> for (int i = 0; i < n; i++) {
> z[i] = (w[i] > 0) ? x[i] + w[i] : y[i] - w[i];
> }
> }
>
> generates cu
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, August 31, 2021 4:14 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and oper
On 8/30/21 9:26 PM, Patrick Palka wrote:
During overload resolution, when the arity of a function template
clearly disagrees with the arity of the call, no specialization of the
function template could yield a viable candidate. The deduction routine
type_unification_real already notices this sit
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, August 31, 2021 4:14 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH 2/2]AArch64: Add better costin
The compiler tries to limit error cascades in limit_bad_template_recursion
by avoiding triggering a new instantiation from one that has caused errors.
We were exempting constexpr functions from this because they can be needed
for constant evaluation, but as more and more functions get marked
conste
Hi hj,
libffi-3.4.2's new static trampoline feature is known to break some
downstream packages with some specific use (or misuse?) of libffi,
unexpected by the libffi developers. For example
https://gitlab.gnome.org/GNOME/gjs/-/issues/428.
I've not use gccgo recently, so I don't know if it might
My apologies for the inconvenience. My recent patch to preserve
SUBREG_PROMOTED_VAR_P on (extend:HI (subreg/s:QI (reg:SI))), and other
places in the middle-end, has broken the build on several targets.
The change to convert_modes inadvertently used the same
subreg_promoted_mode idiom for retrievi
Solaris 11 does not have "http" in /etc/services, which causes this test
to fail. Try some other services until we find one that works.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Try other service if "http
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/experimental/internet (__make_resolver_error_code):
Handle EAI_SYSTEM errors.
(basic_resolver_results): Use __make_resolver_error_code. Use
Glibc NI_MAXHOST and NI_MAXSERV values for buffer sizes.
T
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, August 31, 2021 5:07 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and op
This adds a missing return statement to the non-futex wait-until
operation.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/102074
* include/bits/atomic_timed_wait.h (__timed_waiter_pool)
[!_GLIBCXX_HAVE_PLATFORM_TIMED_WAIT]: Add missing return.
Test
These destructors are noexcept anyway. I removed the redundant noexcept
from the error_category destructor's declaration in r0-123475, but
didn't remove it from the defaulted definition in system_error.cc. That
causes warnings if the library is built with Clang.
This removes the redundant noexcept
On 26/08/21 12:46 +0100, Jonathan Wakely wrote:
PR libstdc++/100285
* configure.ac: Check for O_NONBLOCK.
This check was broken, oops. Fixed like so.
Tested x86_64-linux. Committed to trunk.
commit 1cacdef0d1a3f587691735d1822d584b68eba593
Author: Jonathan Wakely
Date: Tue
A typo in maybe_warn_alloc_args_overflow() has it compare the address
of an array for equality to null when it actually means to compare
the value of the array's element. This is apparently caught by
Converity (and Jason who pointed it out to me -- thanks again).
In r12-3268 I've pushed the chang
Hi!
Given this:
On 2016-11-10T18:44:52+0800, Chung-Lin Tang wrote:
> --- tree.c(revision 241809)
> +++ tree.c(working copy)
> @@ -327,7 +327,7 @@ unsigned const char omp_clause_num_ops[] =
> - 1, /* OMP_CLAUSE_TILE */
> + 3, /* OMP_CLAUSE_TILE */
... for this:
> --- tree.h(rev
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/98421
* include/std/span (span(Iter, size_type), span(Iter, Iter)):
Add valid range checks.
* testsuite/23_containers/span/cons_1_assert_neg.cc: New test.
* testsuite/23_containers/span/co
On Tue, Aug 31, 2021 at 9:32 AM Xi Ruoyao wrote:
>
> Hi hj,
>
> libffi-3.4.2's new static trampoline feature is known to break some
> downstream packages with some specific use (or misuse?) of libffi,
> unexpected by the libffi developers. For example
> https://gitlab.gnome.org/GNOME/gjs/-/issues
I intend to commit the fix to the error message using the patch below
within the next 24h unless there are objections or better suggestions.
The unchanged part of the error message is already covered by
gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 and does
not need to be adapted.
Thanks,
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, August 31, 2021 5:07 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH 2/2]AArch64: Add better costin
Hi!
On 2006-01-25T12:41:14-0500, Diego Novillo wrote:
> This patch replaces all the OMP_CLAUSE_* tree codes with a single
> OMP_CLAUSE tree with sub-codes.
So, originally all OMP clauses were represented by their own tree codes,
which all had to be enumerated/handled individually. But, with all
PING!
> Gesendet: Dienstag, 24. August 2021 um 22:36 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in
> trans_caf_is_present, at fortran/trans-intrinsic.c:8469
>
> Dear Fortranners,
>
> here's a pretty obvious one: w
On Mon, 30 Aug 2021, Patrick Palka wrote:
> In the context of overload resolution we have the notion of a "bad"
> argument conversion, which is a conversion that "would be a permitted
> with a bending of the language standards", and we handle such bad
> conversions specially. In particular, we ra
On Tue, 31 Aug 2021, Roger Sayle wrote:
> This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
> and "make -k check" with no new failures. Ok for mainline?
OK, with a space added before '(' in the call to seen_error.
--
Joseph S. Myers
jos...@codesourcery.com
A copy-paste error, a couple of missed checks to guard undefined accesses,
and we don't need to use type_uses_auto to extract the auto node we just
built.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* coroutines.cc (flatten_await_stmt): Fix copyo.
* decl.c (r
Hi Roger,
> I'm testing the attached patch, but without an aarch64, it'll take a while
> to figure
> out the toolchain to reproduce the failure. Neither of the platforms I
> tested were
> affected, but I can see it's unsafe to reuse the subreg_promoted_reg idiom
> from
> just a few lines earlier
Hi!
On Thu, Aug 26, 2021 at 05:28:42PM -0400, Michael Meissner wrote:
> On Thu, Aug 26, 2021 at 02:17:57PM -0500, will schmidt wrote:
> > On Wed, 2021-08-25 at 15:46 -0400, Michael Meissner wrote:
> > > Generate XXSPLTIDP on power10.
> > >
> > > I have added a temporary switch (-mxxspltidp) to co
From: Andrew Pinski
The problem here is the aarch64_expand_setmem code did not check
STRICT_ALIGNMENT if it is creating an overlapping store.
This patch adds that check and the testcase works.
gcc/ChangeLog:
PR target/101934
* config/aarch64/aarch64.c (aarch64_expand_setmem):
Hi!
Please do two separate patches. The first that adds the instruction
(with a bit pattern, i.e. integer, input), and perhaps a second pattern
that has an fp as input and uses it if the constant is valid for the
insn (survives being converted to SP and back to DP (or the other way
around), and i
On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote:
> Create a new hook to let target could override the multi-lib result,
> the motivation is RISC-V might have very complicated multi-lib re-use
> rule*, which is hard to maintain and use current multi-lib scripts,
> we even hit the "argument list t
From: Andrew Pinski
This adds MIPS Linux support to gcc.misc-tests/linkage.exp. Basically
copying what was done for MIPS IRIX and changing the options to be correct.
OK?
gcc/testsuite/ChangeLog:
PR testsuite/51748
* gcc.misc-tests/linkage.exp: Add mips*-linux-* support.
---
g
On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote:
> Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for
> riscv*-*-elf*,
> according following rules:
>
I find the other_cond support a bit confusing. Is this for -mcmodel
perhaps? Why not just say that if so?
match_score:
weigth -> we
On Tue, Aug 31, 2021 at 5:22 PM Jim Wilson wrote:
> On Wed, Jul 21, 2021 at 2:28 AM Kito Cheng wrote:
>
>> Use TARGET_COMPUTE_MULTILIB to search the multi-lib reuse for
>> riscv*-*-elf*,
>> according following rules:
>>
>
> I find the other_cond support a bit confusing. Is this for -mcmodel
> p
1 - 100 of 109 matches
Mail list logo
