Hello,
I’m Andrea, a freelance content writer for personal finance. I wanted to talk
to you about contributing an article to your site lemire.me
You’ve written about personal finance topics, and it tends to provoke a
positive response in your audience. I was thinking I could write another post,
For the testcase a symbol with a TLS reloc and an unary minus is being
generated. The backend didn't handle this correctly.
In s390_cannot_force_const_mem an unary minus on a symbolic constant
is rejected now since gas would not allow this.
legitimize_tls_address now makes the NEG rtx the outerm
The testcase failed because our backend refuses to generate vector
compare instructions for signaling operators with -fno-trapping-math
-fno-finite-math-only.
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
PR target/96456
* config/s390/s390.h
On Tue, Aug 11, 2020 at 01:30:36PM -0500, Segher Boessenkool wrote:
> Either always running or what this patch does will work. But please add
> comments what the test case wants to test,
That's already in the testcase.
/* Test local calls between pcrel and non-pcrel code.
The comment go
On Tue, Aug 11, 2020 at 08:01:50PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 11, 2020 at 12:23:07PM -0400, Michael Meissner wrote:
> > + /* See if we can use the ISA 3.1 min/max/compare instructions for IEEE
> > + 128-bit floating point. At present, don't worry about doing
> >
PING this issue.
-邮件原件-
发件人: qiaopeixin
发送时间: 2020年8月6日 21:01
收件人: 'gcc-patches@gcc.gnu.org'
抄送: 'richard.sandif...@arm.com'
主题: [PATCH] AArch64: Add if condition in aarch64_function_value [PR96479]
Hi,
The test case vector-subscript-2.c in the gcc testsuit will report an ICE in
the
On Tue, Aug 11, 2020 at 09:07:40PM -0500, Peter Bergner wrote:
> >> + static struct function *fn = NULL;
> >> +
> >> + /* We do not allow MMA types being used as return values. Only report
> >> + the invalid return value usage the first time we encounter it. */
> >> + if (for_return
> >> +
On 8/11/20 9:00 PM, Segher Boessenkool wrote:
> Not just params, but return values as well. "Error on MMA types in
> function prototype"?
Yes, it started out as a function param issue and then while working
on this, I decided I better look at what happens when they're used
as return values. I'll
Hi!
Not just params, but return values as well. "Error on MMA types in
function prototype"?
On Sun, Aug 09, 2020 at 10:03:35PM -0500, Peter Bergner wrote:
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -6444,8 +6444,23 @@ machine_mode
> rs6000_promote_funct
Hi!
On Tue, Aug 11, 2020 at 12:23:07PM -0400, Michael Meissner wrote:
> + /* See if we can use the ISA 3.1 min/max/compare instructions for IEEE
> + 128-bit floating point. At present, don't worry about doing conditional
> + moves with different types for the comparison and movement (unl
Hi!
On Tue, Aug 11, 2020 at 08:22:47AM -0500, Peter Bergner wrote:
> I was looking through some POWER10 test cases and noticed that we used
> -mcpu=power10 rather than the preferred -mdejagnu-cpu=power10.
It is not just *preferred*; things work incorrectly on many systems
without it. If all syst
P1975R0 tweaks the static_cast wording: it says that "An expression e can be
explicitly converted to a type T if [...] T is an aggregate type having a first
element x and there is an implicit conversion sequence from e to the type of
x." This already works for classes, e.g.:
struct Aggr { int x
On Tue, Aug 11, 2020 at 07:59:44AM +0100, Richard Sandiford wrote:
> >> I agree there's no obvious reason why splitting to a single insn
> >> should be rejected but a peephole2 to a single instruction should be OK.
> >> And reusing the existing, tried-and-tested code is the way to go.
> >
> > The o
2nd ping.
Any estimate on when a reviewer might get to this improvement
in the accuracy of Complex Divide?
I'm happy to supply more info on what testing I've done
and details about design decisions. I'd prefer to do that
sooner than later as who knows when corporate priority decisions
might prev
On Tue, 11 Aug 2020, Jason Merrill wrote:
> On 8/10/20 9:21 AM, Patrick Palka wrote:
> > On Fri, 7 Aug 2020, Jason Merrill wrote:
> >
> > > On 8/6/20 1:50 PM, Patrick Palka wrote:
> > > > This patch eliminates an exponential dependence in cxx_eval_vec_init on
> > > > the array dimension of a VEC_
The libgo update to the Go1.15rc1 release accidentally broke the
system call numbers used for 32-bit PPC. This patch fixes the
problem. This fixes GCC PR 96567. Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
2dda65380ae0b038884ed0e8b30c624486a516c2
diff --git
Segher, Will:
Patch 1, adds the sign extension instruction support and corresponding
builtins.
Carl Love
-
RS6000 Add 128-bit sign extension support
gcc/ChangeLog
2020-08-10 Carl Love
* config/rs6000/al
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 Power 10 system via the resolve function.
Segher, Will:
Patch 2, adds support for divide, modulo, shift, compare of 128-bit
integers. The support adds the instruction and builtin support.
Carl Love
---
rs6000, 128-bit multiply, divide, shift, compare
gcc/ChangeLog
2020
Segher, Will:
Patch 4 adds 128-bit integer shift instruction support.
Carl Love
-
Test 128-bit shifts for just the int128 type.
gcc/ChangeLog
2020-08-10 Carl Love
* config/rs6000/altivec.md (altivec_vslq, altiv
Segher, Will:
Path 3 adds support for converting to/from 128-bit integers and 128-bit
decimal floating point formats.
Carl Love
Add TI to TD (128-bit DFP) and TD to TI support
gcc/ChangeLog
2020-08-10 Carl
Segher:
The following is a five patch series for the 128-bit Binary Integer
Operations (RFC 2608).
The last patch does the 128-bit integer to 128-bit float to/from
conversions. The patch has been reviewed by Michael Meissner to make
sure the Floating point 128-mode handling is correct.
The patc
On 8/10/20 9:21 AM, Patrick Palka wrote:
On Fri, 7 Aug 2020, Jason Merrill wrote:
On 8/6/20 1:50 PM, Patrick Palka wrote:
This patch eliminates an exponential dependence in cxx_eval_vec_init on
the array dimension of a VEC_INIT_EXPR when the RANGE_EXPR optimization
applies. This is achieved b
Hello
On 06/08/2020 1:23 pm, Tom de Vries wrote:
> +static char AC[4];
> +static char init_qi[4] = { -30,-30,-50,-50 };
> +static char test_qi[4] = { -115,-115,25,25 };
> +
> +static void
> +do_qi (void)
> +{
> + if (__sync_val_compare_and_swap(AC+0, -30, -115) != -30)
> +abort ();
If 'char
On Tue, Aug 11, 2020 at 12:36:28PM -0500, Peter Bergner wrote:
> On 8/11/20 11:35 AM, Segher Boessenkool wrote:
> > Hi Alan,
> >
> > On Tue, Aug 11, 2020 at 06:38:53PM +0930, Alan Modra wrote:
> >> This fixes a fail when power10 isn't supported by binutils, and
> >> ensures the test isn't run with
Three new DRs. Pushed.
commit 0f4de13033aff42c43e1bbde9a3f7a5a31f33559
Author: Marek Polacek
Date: Tue Aug 11 14:17:15 2020 -0400
Update C++ DR table.
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index 5ee13d6d..7c0b9f3e 100644
--- a/htdocs/projec
Hi!
On Tue, Aug 11, 2020 at 12:22:06PM -0400, Michael Meissner wrote:
> (rs6000_emit_p9_fp_minmax,generate_fp_min_max): Rename.
Space after comma. "Rename." is never useful (and you should show what
is renamed to what). The patch does *not* do the same or similar to the
two names inside t
On 8/11/20 11:35 AM, Segher Boessenkool wrote:
> Hi Alan,
>
> On Tue, Aug 11, 2020 at 06:38:53PM +0930, Alan Modra wrote:
>> This fixes a fail when power10 isn't supported by binutils, and
>> ensures the test isn't run without power10 hardware or simulation on
>> the off chance that power10 insns
Hi, Alexandre,
CC’ing Richard for his comments on this.
> On Aug 10, 2020, at 9:39 PM, Alexandre Oliva wrote:
>> I think that moving how to zeroing the registers part to each target
>> will be a better solution since each target has
>> Better idea on how to use the most efficient insns to do th
Christophe Lyon writes:
> On Mon, 10 Aug 2020 at 17:27, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
>> > wrote:
>> >>
>> >> The stack_protect_test patterns were leaving the canary value in the
>> >> temporary register, meaning tha
Christophe Lyon via Gcc-patches writes:
> This patch fixes an incorrect parameter passing for $gcc_opts, which
> produces a DejaGnu error: (DejaGnu) proc "gcc_opts" does not exist.
Huh, wonder how that went unnoticed for so long…
> 2020-08-11 Christophe Lyon
>
> gcc/testsuite/
>
Hi Alan,
On Tue, Aug 11, 2020 at 06:38:53PM +0930, Alan Modra wrote:
> This fixes a fail when power10 isn't supported by binutils, and
> ensures the test isn't run without power10 hardware or simulation on
> the off chance that power10 insns are emitted in the future for this
> testcase.
The test
Hi,
Add some missing require-effect-targets directives (alloca, indirect_jumps,
label_values and nonlocal_goto).
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Add missing require-effective-target directives in gcc.dg
gcc/testsuite/ChangeLog:
* gcc.dg/Warray-bounds-46
PowerPC: Add power10 IEEE 128-bit min/max/cmove.
This patch adds support for the new ISA 3.1 (power10) xscmp{eq,gt,ge}qp,
xsmincqp, and xsmaxcqp instructions for IEEE 128-bit conditional move, minimum,
and maximum.
gcc/
2020-08-07 Michael Meissner
* config/rs6000/rs6000.c (rs6000_emit
PowerPC: Rename min/max/cmove functions.
This patch renames some of the functions in rs6000.c that are used to generate
floating point scalar minimum, maximum, and conditional move sequences to use a
more generic name then _p9.
gcc/
2020-08-07 Michael Meissner
* config/rs6000/rs6000.c
These two patches are a reworking of similar patches that I submitted in July.
The change in these patches are to rename the functions that generate the
minimum, maximum, and compare IEEE 128-bit to produce a mask to use better
names, and to rework the comments. In addition, I have changed the tar
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element. That's correct for
the latter but wrong for the former, causing false positives when
the element size is greater than one.
In addition, the warning doesn't even attempt to handle arr
On 11/08/20 16:38 +0100, Jonathan Wakely wrote:
Make the experimental Networking TS code work without std::mutex and
std::condition_variable.
libstdc++-v3/ChangeLog:
PR libstdc++/89760
* include/experimental/executor [!_GLIBCXX_HAS_GTHREADS]:
(execution_context::mutex_ty
These two tests fail on AIX because defines struct thread
in the global namespace (despite it not being a reserved name). That
means the using-declaration that adds it to the global namespace causes
a redeclaration error.
libstdc++-v3/ChangeLog:
* testsuite/30_threads/thread/cons/84535.c
libstdc++-v3/ChangeLog:
* include/experimental/executor (system_context::a__tag): Make
default constructor explicit.
Tested powerpc64le-linux. Committed to trunk.
commit 2a6918e4fa57edbe0dc326d5f142350b1dd4afd7
Author: Jonathan Wakely
Date: Tue Aug 11 16:16:21 2020
libstd
On Thu, 7 May 2020, Patrick Palka wrote:
> On Mon, 2 Mar 2020, Patrick Palka wrote:
>
> > On Mon, 24 Feb 2020, Patrick Palka wrote:
> >
> > > On Mon, 24 Feb 2020, Patrick Palka wrote:
> > >
> > > > This implements signed and unsigned integer-class types, whose width is
> > > > one bit
> > > >
Make the experimental Networking TS code work without std::mutex and
std::condition_variable.
libstdc++-v3/ChangeLog:
PR libstdc++/89760
* include/experimental/executor [!_GLIBCXX_HAS_GTHREADS]:
(execution_context::mutex_type): Define dummy mutex type.
(system_cont
libstdc++-v3/ChangeLog:
* include/experimental/executor (system_context::_M_run()):
Fix predicate.
* testsuite/experimental/net/system_context/1.cc: New test.
Tested powerpc64le-linux and powerpc-aix, with both --enable-threads
and --disable threads. Committed to trunk.
libstdc++-v3/ChangeLog:
* include/std/stop_token: Check _GLIBCXX_HAS_GTHREADS using
#ifdef instead of #if.
(stop_token::_S_yield()): Check _GLIBCXX_HAS_GTHREADS before
using __gthread_yield.
Tested powerpc64le-linux and powerpc-aix, with both --enable-threads
and
The only function in namespace std::this_thread that actually depends on
thread support being present is this_thread::get_id(). The other
functions (yield, sleep_for and sleep_until) can be defined for targets
without gthreads.
A small change is needed in std::this_thread::sleep_for which currentl
On 8/11/20 5:36 AM, Martin Liška wrote:
Hello.
All right, I did it in 3 steps:
1) - new exact argument is added (no default value) - I tested the on
x86_64-linux-gnu
and I build all cross targets.
2) set default value of exact = false
3) change places which calculate its own growth to use the
Hello-
Attached is the patch I mentioned in another discussion here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551442.html
This adds a new option -fdiagnostics-plain-output that currently means the
same thing as:
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-
On Tue, Aug 11, 2020 at 10:50:28AM +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As the testcase shows, we would ICE if the type of the first argument of
> various atomic builtins was pointer to (non-void) incomplete type, we would
> assume that TYPE_SIZE_UNIT must be non-NULL. This patch
I was looking through some POWER10 test cases and noticed that we used
-mcpu=power10 rather than the preferred -mdejagnu-cpu=power10. I went
looking for more tests that were not converted over and came up with the
following patch. Ok for trunk?
Peter
gcc/testsuite/
* g++.dg/ext/spe1.C
This patch fixes an incorrect parameter passing for $gcc_opts, which
produces a DejaGnu error: (DejaGnu) proc "gcc_opts" does not exist.
2020-08-11 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/multilib.exp: Fix parameter passing for gcc_opts.
diff --git a/gcc/testsuite/gcc.
On Mon, 10 Aug 2020 at 17:27, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Wed, 5 Aug 2020 at 16:33, Richard Sandiford
> > wrote:
> >>
> >> The stack_protect_test patterns were leaving the canary value in the
> >> temporary register, meaning that it was often still in registers on
-- Forwarded message -
From: Aldy Hernandez
Date: Thu, Aug 6, 2020, 16:54
Subject: [PATCH] Rewrite get_size_range for irange API.
To:
Cc: , Aldy Hernandez
[Martin, does this sound reasonable to you?]
The following patch converts get_size_range to the irange API, thus
removing
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 13:34
Subject: [PATCH] Adjust tree-ssa-strlen.c for irange API.
To:
Cc: , , Aldy Hernandez
This patch adapts the strlen pass to use the irange API.
I wasn't able to remove the one annoying use of VR_ANTI_RANGE
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 14:03
Subject: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and
value_range_equiv.
To:
Cc: , Aldy Hernandez
I've abstracted out the parts of the code that had nothing to do with
value_range_equiv
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 13:55
Subject: [PATCH 1/2] Add statement context to get_value_range.
To:
Cc: , Aldy Hernandez
This is in line with the statement context that we have for get_value()
in the substitute_and_fold_engine class.
---
-- Forwarded message -
From: Aldy Hernandez
Date: Tue, Aug 4, 2020, 13:39
Subject: [PATCH] Adjust tree-ssa-dom.c for irange API.
To:
Cc: , Aldy Hernandez
This patch removes all uses of VR_ANTI_RANGE in DOM. It required
minor surgery in the switch handling code.
In doing so, I
>From 292532ea9e3d42ca164b9951674c1eccc86a1f11 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 10 Aug 2020 12:01:59 +0200
Subject: [PATCH 2/3] vec: default exect = false in grow functions.
gcc/ChangeLog:
* vec.h (vec_safe_grow): Change default of exact to false.
(vec_safe_grow_cleared
>From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 10 Aug 2020 12:09:19 +0200
Subject: [PATCH 3/3] vec: use inexact growth where possible.
gcc/ChangeLog:
* cfgrtl.c (rtl_create_basic_block): Use default value for
growth vector function.
* g
Hello.
All right, I did it in 3 steps:
1) - new exact argument is added (no default value) - I tested the on
x86_64-linux-gnu
and I build all cross targets.
2) set default value of exact = false
3) change places which calculate its own growth to use the default argument
I would like to install
On August 11, 2020 11:00:14 AM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>At GIMPLE e.g. for __builtin_memmove we optimize away (to just the
>return
>value) noop copies where src == dest, but at the RTL we don't, and as
>the
>testcase shows, in some cases such copies can appear only at the RTL
>leve
On August 11, 2020 10:46:47 AM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>My changes to get_narrower to support COMPOUND_EXPRs apparently
>used a wrong type for the COMPOUND_EXPRs, while e.g. the rhs
>type was unsigned short, the COMPOUND_EXPR got int type as that was the
>original type of op. The
On Tue, Aug 11, 2020 at 9:34 AM Roger Sayle wrote:
>
>
> The recent fix for mul_widen_cost revealed an interesting
> quirk of ira/reload register allocation on x86_64. As shown in
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551648.html
> for gcc.target/i386/pr71321.c we generate the f
Hi,
this patch avoids both PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION to be
attached to one edge. We have logic that prevents same predictor to apply to
one edge twice, but since we split LOOP_GUARD to two more specialized cases,
this no longer fires.
Double prediction happens in exchange
On Tue, Aug 11, 2020 at 11:36 AM Hongtao Liu wrote:
>
> On Tue, Aug 11, 2020 at 4:38 PM Uros Bizjak wrote:
> >
> > On Tue, Aug 11, 2020 at 5:30 AM Hongtao Liu wrote:
> > >
> > > Hi:
> > > The issue is described in the bugzilla.
> > > Bootstrap is ok, regression test for i386/x86-64 backend i
On 8/11/20 11:04 AM, Jan Hubicka wrote:
Looks good to me. Perhaps it would be more systematic to add them to
the remaining propagators as well - bugs tends to pop up from time to
time related to those.
Works for me.
@Martin: Can you please add them?
Thanks,
Martin
Hi:
The issue is described in the bugzilla.
Bootstrap is ok, regression test for i386/x86-64 backend is ok.
Ok for trunk?
ChangeLog
gcc/
PR target/96551
* config/i386/sse.md (vec_unpacku_float_hi_v16si): For vector
compare to integer mask, don't use gen_rtx_LT , use
On Tue, Aug 11, 2020 at 4:38 PM Uros Bizjak wrote:
>
> On Tue, Aug 11, 2020 at 5:30 AM Hongtao Liu wrote:
> >
> > Hi:
> > The issue is described in the bugzilla.
> > Bootstrap is ok, regression test for i386/x86-64 backend is ok.
> > Ok for trunk?
> >
> > ChangeLog
> > gcc/
> > PR t
On 11/08/20 10:11 +0100, Jonathan Wakely wrote:
On 27/12/19 11:57 +0100, François Dumont wrote:
Here is the patch to extend DR 526 to forward_list and list
remove_if and unique.
As the adopted pattern is simpler I also applied it to the remove methods.
   PR libstdc++/91620
   * incl
On 27/12/19 11:57 +0100, François Dumont wrote:
Here is the patch to extend DR 526 to forward_list and list remove_if
and unique.
As the adopted pattern is simpler I also applied it to the remove methods.
   PR libstdc++/91620
   * include/bits/forward_list.tcc (forward_list<>::remove
This fixes a fail when power10 isn't supported by binutils, and
ensures the test isn't run without power10 hardware or simulation on
the off chance that power10 insns are emitted in the future for this
testcase. Bootstrapped etc. OK?
PR target/96525
* testsuite/gcc.target/powerpc
> Hey.
>
> I'm debugging PR96482 and it would be handy for me to have a debug counter
> for the problematic transformation.
>
> Ready for master?
Looks good to me. Perhaps it would be more systematic to add them to
the remaining propagators as well - bugs tends to pop up from time to
time relat
Hi!
At GIMPLE e.g. for __builtin_memmove we optimize away (to just the return
value) noop copies where src == dest, but at the RTL we don't, and as the
testcase shows, in some cases such copies can appear only at the RTL level
e.g. from trying to copy an aggregate by value argument to the same loc
Hi!
As the testcase shows, we would ICE if the type of the first argument of
various atomic builtins was pointer to (non-void) incomplete type, we would
assume that TYPE_SIZE_UNIT must be non-NULL. This patch diagnoses it
instead. And also changes the TREE_CODE != INTEGER_CST check to
!tree_fits
Hi!
My changes to get_narrower to support COMPOUND_EXPRs apparently
used a wrong type for the COMPOUND_EXPRs, while e.g. the rhs
type was unsigned short, the COMPOUND_EXPR got int type as that was the
original type of op. The type of COMPOUND_EXPR should be always the type
of the rhs.
Fixed thus
On Tue, Aug 11, 2020 at 5:30 AM Hongtao Liu wrote:
>
> Hi:
> The issue is described in the bugzilla.
> Bootstrap is ok, regression test for i386/x86-64 backend is ok.
> Ok for trunk?
>
> ChangeLog
> gcc/
> PR target/96350
> * config/i386/i386.c (ix86_legitimate_constant_p): R
The recent fix for mul_widen_cost revealed an interesting
quirk of ira/reload register allocation on x86_64. As shown in
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551648.html
for gcc.target/i386/pr71321.c we generate the following code that
performs unnecessary register shuffling.
Hey.
I'm debugging PR96482 and it would be handy for me to have a debug counter
for the problematic transformation.
Ready for master?
Thanks,
Martin
gcc/ChangeLog:
* dbgcnt.def (DEBUG_COUNTER): Add ipa_cp_bits.
* ipa-cp.c (ipcp_store_bits_results): Use it when we store known
Segher Boessenkool writes:
> On Mon, Aug 10, 2020 at 05:16:15PM +0100, Richard Sandiford wrote:
>> Senthil Kumar via Gcc-patches writes:
>> > The wiki suggests using post-reload splitters, so that's the
>> > direction I took, but I ran into an issue where split_insn
>> > bails out early if
78 matches
Mail list logo
