On Wed, Sep 1, 2021 at 7:09 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 30/08/2021 14:01, Sebastian Huber wrote:
> > Do not declare abort in "libgcc/unwind-arm-common.inc" since it is
> already
> > provided by "tsystem.h". It fixes the following build error:
> >
> > In fi
Hi!
Power ISA 2.07 (Power8) introduces transactional memory feature
but ISA3.1 (Power10) removes it. It exposes one troublesome
issue as PR102059 shows. Users define some function with
target pragma cpu=power10 then it calls one function with
attribute always_inline which inherits command line o
On Mon, Aug 30, 2021 at 8:27 AM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, Aug 25, 2021 at 12:14:09PM +0200, Marcel Vollweiler wrote:
> > Add support for device-modifiers for 'omp target device'.
> >
> > 'device_num' and 'ancestor' are now parsed on target device con
This adds the testcase from the PR.
Pushed.
2021-09-01 Richard Biener
PR tree-optimization/102149
* gcc.dg/torture/pr102149.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr102149.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuit
Hi!
bswap_view_convert is used twice in spots where gsi_insert_before is the
right thing, but in the last one it wants to insert preparation stmts
for the VIEW_CONVERT_EXPR emitted with gsi_insert_after, where at the
gsi we still need to insert bswap_stmt and maybe mask_stmt whose lhs
the preparat
From: wangpc
---
gcc/cp/pt.c| 8 +++-
.../aarch64/sve/static-var-in-template.C | 18 ++
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644
gcc/testsuite/g++.target/aarch64/sve/static-var-in-template.C
diff --git a
apinski--- via Gcc-patches writes:
> 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
> * con
apinski--- via Gcc-patches writes:
> 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-te
On Wed, Sep 01, 2021 at 09:06:31AM +0200, Christophe Lyon wrote:
> > > * gfortran.dg/gomp/target-device-ancestor-4.f90: New test.
> >
>
> The last new test fails on aarch64:
> /gcc/testsuite/gfortran.dg/gomp/target-device-ancestor-4.f90:7:15: Error:
> Sorry, 'reverse_offload' clause at (1)
This patch improves coloring of graph dumps, as can be seen here:
https://splichal.eu/tmp/example.svg
Ready to be installed once it finishes tests?
Thanks,
Martin
gcc/ChangeLog:
* graph.c (draw_cfg_node_succ_edges): Do not color fallthru
edges and rather use colors for TRUE an
Richard Sandiford via Gcc-patches
于2021年9月1日周三 下午4:55写道：
>
> apinski--- via Gcc-patches writes:
> > 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?
> >
>
On Tue, Aug 31, 2021 at 08:51:16PM +0200, Thomas Schwinge wrote:
> gcc/
> * tree.c (walk_tree_1) : Simplify.
:
And you don't mention the omp_clause_num_ops and build_omp_clause comment
changes in the ChangeLog.
Otherwise LGTM, thanks.
Jakub
On Wed, 1 Sept 2021 at 02:44, Jonathan Yong <10wa...@gmail.com> wrote:
>
> On 8/31/21 9:02 AM, Jonathan Wakely wrote:
> > 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
This fixes the CFG walk order of fill_always_executed_in to use
RPO oder rather than the dominator based order computed by
get_loop_body_in_dom_order. That fixes correctness issues with
unordered dominator children.
The RPO order computed by rev_post_order_and_mark_dfs_back_seme in
its for-iterat
Richard Biener writes:
> 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
Hi All,
This is a respin of an older patch which never got upstream reviewed by a
maintainer. It's been updated to fit the current GCC codegen.
This patch adds a pattern to support the (F)ADDP (scalar) instruction.
Before the patch, the C code
typedef float v4sf __attribute__((vector_size (16)
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 {
> MIP
On Wed, 1 Sep 2021, Jakub Jelinek wrote:
> Hi!
>
> bswap_view_convert is used twice in spots where gsi_insert_before is the
> right thing, but in the last one it wants to insert preparation stmts
> for the VIEW_CONVERT_EXPR emitted with gsi_insert_after, where at the
> gsi we still need to insert
On Wed, 1 Sep 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > 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
> >>
Jakub Jelinek writes:
> 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
Richard Biener writes:
> On Wed, 1 Sep 2021, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > 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 m
Hi,
As discussed with Jason at WG21 in Prague - last year, this amends the
way in which the coroutine frame copies of variables are represented in
the front end lowering. Instead of an explicit pointer->field we now
apply a DECL_VALUE_EXPR to each instead (where that value is the
pointer->field).
Hi,
Variables that need to persist over suspension expressions
must be preserved by being copied into the coroutine frame.
The initial implementations do this manually in the transform
code. However, that has various disadvantages - including
that the debug connections are lost between the origi
This is primarily code factoring, but we take this opportunity
to rename some of the implementation variables (which we intend
to expose to debugging) so that they are in the implementation
namespace.
Signed-off-by: Iain Sandoe
gcc/cp/ChangeLog:
* coroutines.cc (coro_build_artificial_
Some of the state that is associated with the implementation
is of interest to a user debugging a coroutine. In particular
items such as the suspend point, promise object, and current
suspend point.
These variables live in the coroutine frame, but we can inject
proxies for them into the outermo
Some of the compiler-generated entries are of interest to a
user debugging - keep variables in the implementation namespace
but avoid using periods as separators (which is not compatible
with visible symbols for some assemblers).
Partial improvement to debugging (PR 99215).
Signed-off-by: Iain
This is an efficiency measure and repeats the pattern used for
other identifiers used in the coroutine implementation.
In support of debugging, the user might well need to look at some
of the variables that the implementation manipulates in lowering
the coroutines. The defines the identifiers f
The user might well wish to inspect some of the state that represents
the implementation of the coroutine machine.
In particular:
The promise object.
The function pointers for the resumer and destroyer.
The current resume index (suspend point).
The handle that represent this coroutine 's
This makes us avoid PREing calls that could trap across other
calls that might not return. The PR88087 testcase has exactly
such case so I've refactored the testcase to contain a valid PRE.
I've also adjusted PRE to not consider pure calls possibly
not returning in line with what we do elsewhere.
This adds top level proxy variables for the coroutine frame
copies of the original function args. These are then available
in the debugger to refer to the frame copies. We rewrite the
function body to use the copies, since the original parms will
no longer be in scope when the coroutine is runn
When we have a suspend method that returns a coroutine handle
we transfer (hopefully symmetrically, i.e. with a tailcall) to
that new coroutine instead of returning to our resumer.
This adds the variable to the outer block for the actor function
which means that '_Coro_actor_continue' is visible
On Wed, Sep 1, 2021 at 8:28 AM Hongtao Liu wrote:
>
> On Tue, Aug 31, 2021 at 7:56 PM Richard Biener
> wrote:
> >
> > 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
On Wed, Sep 1, 2021 at 11:10 AM Martin Liška wrote:
>
> This patch improves coloring of graph dumps, as can be seen here:
> https://splichal.eu/tmp/example.svg
>
> Ready to be installed once it finishes tests?
OK
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * graph.c (draw_cfg_node_succ_edg
Richard Biener writes:
> On Wed, Sep 1, 2021 at 8:28 AM Hongtao Liu wrote:
>>
>> On Tue, Aug 31, 2021 at 7:56 PM Richard Biener
>> wrote:
>> >
>> > 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:
>>
Hi,
This patch updates the comment for DRUNTIME_OS_SOURCES to reflect new
conditionals that have been added since it was introduced.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* m4/druntime/os.m4
Hi,
The D run-time library does not depend on zlib, so only include it in
the library when Phobos is being built as well.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain.
---
libphobos/ChangeLog:
* src/Makefile.am: Don't add z
Hi,
Minor cleanup, this is statement not an expression, we do not
need to use finish_expr_stmt here.
tested on x86_64, powerpc64-linux, x86_64-darwin,
pushed to master as trivial/obvious, thanks
Iain
Signed-off-by: Iain Sandoe
gcc/cp/ChangeLog:
* coroutines.cc (await_statement_walker)
Hi,
Minor code-gen correction.
tested on x86_64, powerpc64 - linux, x86_64-darwin,
pushed to master as trivial/obvious, thanks
Iain
Signed-off-by: Iain Sandoe
gcc/cp/ChangeLog:
* coroutines.cc (build_actor_fn): Add begin/finish clauses
to the initial test in the actor function
On Wed, Sep 1, 2021 at 2:52 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Sep 1, 2021 at 8:28 AM Hongtao Liu wrote:
> >>
> >> On Tue, Aug 31, 2021 at 7:56 PM Richard Biener
> >> wrote:
> >> >
> >> > On Tue, Aug 31, 2021 at 12:18 PM Hongtao Liu wrote:
> >> > >
> >> > > On M
On Tue, Aug 31, 2021 at 4:50 PM Richard Sandiford via Gcc-patches
wrote:
>
> 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 p
Hi,
The patch was approved here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562757.html
and here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560604.html
subject to a documentation nit.
I ran out of time before stage3 ended .. and just got around to this now.
re-tested o
Hi
When a method returns a type that the platform ABI says should be
returned in memory, and that is done by a hidden 'sret' parameter,
the message send calls must be adjusted to inform the runtime that
the sret parameter is present. As reported in the PR, this is not
working for non-aggregate ty
Since this post I’ve tested this on more platforms (including cfarm machines
with dejagnu-1.5.1 and tcl 8.5).
If there’s concern about applying it everywhere, I could make a second version
of fixed_host_execute and have that called conditionally on Darwin.
The Jit testsuite is unusable without t
On 9/1/2021 1:00 AM, Christophe Lyon via Gcc-patches wrote:
On Wed, Sep 1, 2021 at 7:09 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
On 30/08/2021 14:01, Sebastian Huber wrote:
Do not declare abort in "libgcc/unwind-arm-common.inc" since it is
already
provided by "tsyst
Although this patch looks quite large, the changes are fairly minimal.
Most of it is duplicating the large function that does the overload
resolution using the automatically generated data structures instead of
the old hand-generated ones. This doesn't make the patch terribly easy to
review, unfor
Hi!
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572231.html
V3 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573020.html
V4 patch series here:
http
I over-restricted use of __builtin_mffsl, since I was unaware that it
automatically uses mffs when mffsl is not available. Paul Clarke pointed
this out in discussion of his SSE 4.1 compatibility patches.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (__builtin_mffsl): Mov
Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
__builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
I had been using to automate gimple folding of MMA builtins. Previously,
every MMA function that could be folded had an associated internal function
tha
This is another patch that looks bigger than it really is. Because we
have a new namespace for the builtins, allowing us to have both the old
and new builtin infrastructure supported at once, we need versions of
these functions that use the new builtin namespace. Otherwise the code is
unchanged.
This patch just duplicates a couple of functions and adjusts them to use the
new builtin names. There's no logical change otherwise.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000.c (rs6000-builtins.h): New include.
(rs6000_new_builtin_vectorized_function): New function.
This patch and the subsequent five patches form the meat of the improvements
for this patch series. We develop a replacement for rs6000_expand_builtin
and its supporting functions, which are inefficient and difficult to
maintain. This patch implements rs6000_expand_new_builtin, and creates
stubs
Implement rs6000_invalid_new_builtin, which issues the appropriate error
message when a builtin is used when it is not enabled. Also implement
rs6000_expand_ldst_mask, which just factors out the code that handles
ALTIVEC_BUILTIN_MASK_FOR_LOAD in the old rs6000_expand_builtin. Finally,
ensure the
Implement the replacement for cpu_expand_builtin. There are no logic
changes here, just changes to use the new built-in function names and
clean up some formatting.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (new_cpu_expand_builtin):
Implement.
---
gcc/config/
Consolidate into elemrev_icode some logic that is scattered throughout
the old altivec_expand_builtin. Also replace functions for handling
special load and store built-ins:
= ldv_expand_builtin replaces altivec_expand_lv_builtin
= lxvrse_expand_builtin and lxvrze_expand_builtin replace
altivec_e
Replace mma_expand_builtin. There are no significant logic changes,
just adjustments to use the new infrastructure and clean up formatting.
2021-09-01 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (new_mma_expand_builtin):
Implement.
---
gcc/config/rs6000/rs6000-call.c | 10
Provide replacements for htm_spr_num and htm_expand_builtin. No logic
changes are intended here, as usual. Much code was factored out into
rs6000_expand_new_builtin, so the new version of htm_expand_builtin is
a little tidier.
Also implement the support for the "endian" and "32bit" attributes,
w
Create a new version of this function that uses the new infrastructure,
and particularly checks for supported builtins the new way.
2021-08-31 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_new_builtin_decl): New
function.
(rs6000_builtin_decl): Call it.
---
g
There are a few leftover places where we use the old rs6000_builtins_decl
array, but we need to use rs6000_builtins_decl_x instead when the new
builtins infrastructure is in play.
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/rs6000.c (rs6000_builtin_reciprocal): Use
rs6000_buil
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/rs6000-call.c (rs6000_debug_type): New function.
(def_builtin): Change debug formatting for easier parsing and
include more information.
(rs6000_init_builtins): Add dump of autogenerated builtins.
(altivec_init
2021-07-28 Bill Schmidt
gcc/
* config/rs6000/altivec.h: Delete a number of #defines that are
now superfluous. Alphabetize. Include rs6000-vecdefines.h.
Include some synonyms.
---
gcc/config/rs6000/altivec.h | 519 +++-
1 file changed, 3
2021-03-05 Bill Schmidt
gcc/
* config/rs6000/rs6000-gen-builtins.c (write_init_file):
Initialize new_builtins_are_live to 1.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
2021-07-19 Bill Schmidt
gcc/testsuite/
* gcc.target/powerpc/bfp/scalar-extract-exp-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-extract-sig-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-insert-exp-2.c: Adjust.
* gcc.target/powerpc/bfp/scalar-insert-exp-5.c: Adjust
2021-08-19 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def (VEC_INIT_V16QI): Use
escape-newline support.
(VEC_INIT_V4SI): Likewise.
(VEC_INIT_V8HI): Likewise.
(PACK_V1TI): Likewise.
(DIVDEU): Likewise.
(VFIRSTMISMATCHOREOSINDEX_V1
On 8/24/21 12:55 AM, Richard Biener wrote:
On Mon, Aug 23, 2021 at 11:18 PM Indu Bhagat via Gcc-patches
wrote:
Hello,
What is the expected DWARF for extern variable in the following cases? I
am seeing that the DWARF generated is different with gcc8.4.1 vs gcc-trunk.
Testcase 2
--
ex
On 8/31/2021 8:08 PM, Martin Sebor via Gcc-patches wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return &a == 0;
}
G
On 8/30/2021 1:29 PM, Iain Sandoe wrote:
Hi,
Darwin provides an implementation of sbrk, which is detected by the
libiberty configuration process.
However, (like most of the BSD-derivatives) sbrk/brk are deprecated on
Darwin which leads to build-time warnings. It seems that the configure
pro
> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
> wrote:
>
> Generally OK. There's some C++ front-end bits that Jason ought to take a
> quick looksie at. Second, how does this interact with targets that allow
> objects at address 0? We have a few targets like that and that makes
On 9/1/2021 12:57 PM, Koning, Paul wrote:
On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
wrote:
Generally OK. There's some C++ front-end bits that Jason ought to take a quick
looksie at. Second, how does this interact with targets that allow objects at
address 0? We have a fe
Fixed by my c++/99701 patch.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101592
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wlogical-op-3.C: New test.
---
gcc/testsuite/g++.dg/warn/Wlogical-op-3.C | 12
1 file changed, 12 insertions(+)
create mode 100644 gcc/
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
return &a == 0;
}
GCC issues -Wadd
On 8/30/21 3:11 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
together with your
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
incr
> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>
>>> On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
>>> wrote:
>>>
>>> Generally OK. There's some C++ front-end bits that Jason ought to take a
>>> quick looksie a
Hi Paul,
> On 1 Sep 2021, at 20:28, Koning, Paul via Gcc-patches
> wrote:
>
>> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
>> wrote:
>> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>>
On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
wrote:
Generally OK. The
Hi!
On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
wrote:
> On 6/22/21 5:28 PM, David Malcolm wrote:
>> On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
>>> On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduces the suppress_warning(),
wa
On Wed, Sep 1, 2021 at 2:46 AM YunQiang Su wrote:
>
> Richard Sandiford via Gcc-patches
> 于2021年9月1日周三 下午4:55写道：
> >
> > apinski--- via Gcc-patches writes:
> > > From: Andrew Pinski
> > >
> > > This adds MIPS Linux support to gcc.misc-tests/linkage.exp. Basically
> > > copying what was done fo
On Sep 01 2021, Iain Sandoe via Gcc-patches wrote:
> I wonder what things like m68k do that have vector tables at 0 …
Vector 0 is the reset stack pointer, if that isn't ROM you have a
problem. On the Atari, the MCU redirects physical addresses 0-7 to the
system ROM. Then there is the VBR on m68
On Tue, Aug 31, 2021 at 05:52:48PM -0500, Segher Boessenkool wrote:
> 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 XXSPLT
On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
> On 8/30/21 3:11 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping the following patches
> >
> > libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
>
On Tue, Aug 31, 2021 at 06:41:30PM -0500, Segher Boessenkool wrote:
> 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
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
int f (void)
{
int a[2][2];
> On Sep 1, 2021, at 3:35 PM, Iain Sandoe wrote:
>
>
> [EXTERNAL EMAIL]
>
> Hi Paul,
>
>> ...
>> If so, then I would think that ignoring it for this patch as well is
>> reasonable. If in a given target a pointer that C thinks of as NULL is in
>> fact a valid object pointer, then all sor
On trunk, PR101592 was fixed by r12-2537, but that change shouldn't be
backported to GCC 11. In the PR Jakub suggested this fix, so here it
is, after the usual testing.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 11?
PR c++/101592
gcc/ChangeLog:
* fold-const.c (make_r
On Wed, Sep 01, 2021 at 05:18:09PM -0400, Marek Polacek wrote:
> On trunk, PR101592 was fixed by r12-2537, but that change shouldn't be
> backported to GCC 11. In the PR Jakub suggested this fix, so here it
> is, after the usual testing.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 1
On Tue, Aug 31, 2021 at 4:22 AM YunQiang Su wrote:
>
> 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
On 8/31/21 5:15 AM, Richard Biener wrote:
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 wh
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared object
for equality to null, similar to:
On 9/1/21 4:11 PM, Jakub Jelinek wrote:
On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote:
On 8/30/21 3:11 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-J
On Wed, Sep 01, 2021 at 05:32:07PM -0400, Jason Merrill wrote:
> On 8/31/21 5:15 AM, Richard Biener wrote:
> > 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
On 9/1/21 3:39 PM, Jason Merrill wrote:
On 9/1/21 4:33 PM, Martin Sebor wrote:
On 9/1/21 1:21 PM, Jason Merrill wrote:
On 8/31/21 10:08 PM, Martin Sebor wrote:
A Coverity run recently uncovered a latent bug in GCC that GCC should
be able to detect itself: comparing the address of a declared ob
As noted in the PR, we can get an ICE after the introduction of code to
reduce a vector comparison to a scalar. The problem is we left the
operand cache in an inconsistent state because we called the new
function too late. This is trivially fixed by making the transformation
before we call upd
On 8/31/2021 7:29 AM, Tamar Christina wrote:
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)
{
uin
On Mon, Aug 30, 2021 at 6:49 AM Jakub Jelinek wrote:
>
> On Sun, Aug 29, 2021 at 12:11:23PM -0700, H.J. Lu wrote:
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -1840,6 +1840,54 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /*
> > Argument info to initialize */
> >
TYPE_MODE of record and union depends on whether vector_mode_supported_p
returns true or not. x86-64 backend uses TYPE_MODE to decide how to pass
a parameter and return a value in a function. 64-bit integer vectors
were supported only by MMX and 64-bit float vector was supported only by
3DNOW. G
On 9/1/21 1:35 PM, Thomas Schwinge wrote:
Hi!
On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches
wrote:
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduc
On 8/30/21 4:46 AM, Thomas Schwinge wrote:
Hi!
Ping -- we still need to plug the memory leak; see patch attached, and/or
long discussion here:
Thanks for answering my questions. I have no concerns with going
forward with the patch as is. Just a suggestion/request: unless
this patch fixes all
Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is
as large as a pointer), due to making calculations relative to a NULL
pointer. This patch avoids the problem by extracting out and
simplifying __BPTR_ALIGN for the usual case. I've continued to use
ptrdiff_t here, where it mig
Hi:
Details discussed in PR.
Bootstrapped and regtested on x86-64_linux-gnu{-m32,}.
Pushed to master and GCC-11.
gcc/ChangeLog:
PR target/102166
* config/i386/amxbf16intrin.h : Remove macro check for __AMX_BF16__.
* config/i386/amxint8intrin.h : Remove macro check fo
On 2021/9/1 17:58, Richard Biener wrote:
This fixes the CFG walk order of fill_always_executed_in to use
RPO oder rather than the dominator based order computed by
get_loop_body_in_dom_order. That fixes correctness issues with
unordered dominator children.
The RPO order computed by rev_post_
Added missging PREFERRED_DEBUGGING_TYPE.
gcc/ChangeLog
* config/rx/linux.h (PREFERRED_DEBUGGING_TYPE):
Added missing define.
---
gcc/config/rx/linux.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/rx/linux.h b/gcc/config/rx/linux.h
index 9ee484af886..e9b51197a23
I'm going to check in the first 3 patches which are already approved.
Update hf soft-fp from glibc.
[i386] Enable _Float16 type for TARGET_SSE2 and above.
[i386] libgcc: Enable hfmode soft-sf/df/xf/tf extensions and
truncations.
On Mon, Aug 2, 2021 at 2:31 PM liuhongt wrote:
>
> Update
1 - 100 of 102 matches
Mail list logo
