Commit r12-432, rewriting the dg-stuff, reverted the
adjustment for mmix-knuth-mmixware that I added in r11-2335.
(See those commits for context.)
Hopefully this variant will age better, just skipping it
with a trivial extra line less prone to pile-on. (Not much
is won by covering this generic ca
Looks like MMIX is the "correct target" too (cf. 2f6bdd51cfe15)
and from
https://gcc.gnu.org/pipermail/gcc-testresults/2021-July/710188.html
it seems powerpc-ibm-aix7.2.3.0 is too, but I've not found
other targets failing.
gcc/testsuite:
PR middle-end/101674
* gcc.dg/uninit-pred-9_
On Wed, Jul 28, 2021 at 05:16:32PM -0500, Segher Boessenkool wrote:
> On Fri, Jul 16, 2021 at 08:50:20AM -0500, Paul A. Clarke wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/sse4_1-round.h
> > @@ -0,0 +1,27 @@
> > +#include
> > +#include
> > +#include "sse4_1-check.h"
> > +
>
On 7/30/21 2:21 PM, Tom de Vries wrote:
On 7/30/21 6:17 PM, Martin Sebor wrote:
On 7/28/21 9:20 AM, Tom de Vries wrote:
Hi,
Improve nonnull attribute documentation in a number of ways:
Reorganize discussion of effects into:
- effects for calls to functions with nonnull-marked parameters, and
I guess the best way to describe these operands, at least for MMIX, is
"ballast". Some targets seem to drag along one or two of the incoming
pattern operands through the rtl passes and not dropping them until
assembly output. Let's stop doing that for MMIX. There really are
*two* unused paramete
* gcc.target/i386/pieces-memcpy-10.c: New test.
* gcc.target/i386/pieces-memcpy-11.c: Likewise.
* gcc.target/i386/pieces-memcpy-12.c: Likewise.
* gcc.target/i386/pieces-memcpy-13.c: Likewise.
* gcc.target/i386/pieces-memcpy-14.c: Likewise.
* gcc.targe
Expect no stack realignment since we no longer realign stack when
copying data.
* gcc.target/i386/incoming-11.c: Expect no stack realignment.
---
gcc/testsuite/gcc.target/i386/incoming-11.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/i
Also pass -mno-sse to vect8-ret.c to disable XMM load/store when running
GCC tests with "-march=x86-64 -m32".
* gcc.target/i386/vect8-ret.c: Also pass -mno-sse.
---
gcc/testsuite/gcc.target/i386/vect8-ret.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/
Also pass -mno-avx to sw-1.c for ia32 since copying data with YMM or ZMM
registers disables shrink-wrapping when the second argument is passed on
stack.
* gcc.target/i386/sw-1.c: Also pass -mno-avx for ia32.
---
gcc/testsuite/gcc.target/i386/sw-1.c | 1 +
1 file changed, 1 insertion(+)
d
We can use TImode/OImode/XImode integers for piecewise move and store.
1. Define MAX_MOVE_MAX to 64, which is the constant maximum number of
bytes that a single instruction can move quickly between memory and
registers or between two memory locations.
2. Define MOVE_MAX to MOVE_MAX_PIECES, which i
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/pr72839.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/pr72839.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr72839.c
b/gcc/
Also pass -mno-avx to pr72839.c to avoid copying data with YMM or ZMM
registers.
* gcc.target/i386/cold-attribute-1.c: Also pass -mno-avx.
---
gcc/testsuite/gcc.target/i386/cold-attribute-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386
Changes in the v6 patches:
1. No need to add TARGET_GEN_MEMSET_SCRATCH_RTX nor change the memset
expanders since they have been checked into master branch.
Changes in the v5 patches:
1. Add TARGET_GEN_MEMSET_SCRATCH_RTX to allow the backend to use a hard
scratch register to avoid stack realignme
Define TARGET_GEN_MEMSET_SCRATCH_RTX to ix86_gen_scratch_sse_rtx to
return a scratch SSE register for memset.
gcc/
PR middle-end/90773
* config/i386/i386.c (TARGET_GEN_MEMSET_SCRATCH_RTX): New.
gcc/testsuite/
PR middle-end/90773
* gcc.target/i386/pr90773-5.c: Upd
PR middle-end/90773
* gcc.target/i386/pr90773-20.c: New test.
* gcc.target/i386/pr90773-21.c: Likewise.
* gcc.target/i386/pr90773-22.c: Likewise.
* gcc.target/i386/pr90773-23.c: Likewise.
* gcc.target/i386/pr90773-26.c: Likewise.
---
gcc/testsuite/gc
To avoid stack realignment, use SCRATCH_SSE_REG to copy data from one
memory location to another.
gcc/
* config/i386/i386-expand.c (ix86_expand_vector_move): Call
ix86_gen_scratch_sse_rtx to get a scratch SSE register to copy
data from one memory location to another.
gcc/
Hi!
On Thu, Jul 29, 2021 at 05:11:49PM +, Patrick McGehearty wrote:
> The MAX and MIN values have only modest changes since the exponent
> field for IBM 128-bit floating point values is the same size as
> the exponent field for IBM 64-bit floating point values.
This is misleading / wrong / no
On 7/30/21 6:17 PM, Martin Sebor wrote:
> On 7/28/21 9:20 AM, Tom de Vries wrote:
>> Hi,
>>
>> Improve nonnull attribute documentation in a number of ways:
>>
>> Reorganize discussion of effects into:
>> - effects for calls to functions with nonnull-marked parameters, and
>> - effects for function
On Fri, Jan 29, 2021 at 10:46:30AM -0500, Lewis Hyatt wrote:
> On Tue, Jan 26, 2021 at 04:02:52PM -0500, David Malcolm wrote:
> > On Fri, 2020-12-18 at 18:03 -0500, Lewis Hyatt wrote:
> > > Hello-
> > >
> > > The attached patch addresses PR93067:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=
This patch adds a new target hook to detect if the CTF container can allow the
emission of CTF/BTF debug info at DWARF debug info early finish time. Some
backends, e.g., BPF when generating code for CO-RE usecase, may need to emit
the CTF/BTF debug info sections around the time when late DWARF debu
-mcore 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 li
Hello,
This patch series puts the framework in place for late BTF generation (in
dwarf2out_finish). This is needed for the landing of BPF CO-RE support in GCC.
BPF's Compile Once - Run Everywhere (CO-RE) feature is used to make a compiled
BPF program portable across kernel versions, all this wit
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.
In case of BPF CO-RE, the BPF backend adds information about CO-RE relocatio
On Fri, Jul 30, 2021 at 9:26 AM Jason Merrill via Gcc-patches
wrote:
>
> In discussion of jakub's patch for C++20 pointer-interconvertibility, it
> came up that we allow anonymous structs to have bases, but don't do anything
> usable with them. Let's reject it.
>
> The comment change is something
From: Andrew Pinski
Just like the old bug PR9651, unsigned_fix rtl should
also be handled as a trapping instruction.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR rtl-optimization/101683
* rtlanal.c (may_trap_p_1): Handle UNSIGNED_FIX.
-
When resolving issues with divide by 0 returning UNDEFINED, I discovered
that although we treat % 0 as undefined, the implementation of wi_fold
for modulus doesn't expect constants, and with the earlier changes to
wi_fold_in_parts, it can now get constants to calculate and combine. ie
[10,10]
This patch changes divide by 0 to produce an UNDEFINED range rather than
VARYING. This can help in propagating values by ignoring / 0 results
rather than bailing.
Bootstrapped on x86_64-pc-linux-gnu and powerpc64-unknown-linux-gnu with
no regressions. Pushed.
Andrew
>From ebbcdd7fae1f80
AS mentioned elsewhere, its const_basic_block not const basic_block.
bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
>From d242acc396d645267cd1ccbdb4d0d73cc9b1ef48 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 29 Jul 2021 09:15:45 -0400
Subject: [PATCH 1/3]
On Fri, Jul 30, 2021 at 8:24 PM Jeff Law wrote:
>
>
>
> On 7/30/2021 4:39 AM, Aldy Hernandez via Gcc-patches wrote:
> > It occurs to me that I should not have disabled early jump threading in
> > this test, as it may hide an actual defect. I have reverted my change
> > and XFAILed the test instea
On 7/29/2021 5:41 PM, Hans-Peter Nilsson wrote:
An old itch being scratched: the documentation lies; it's not "the
number of registers used as operands", unless the target makes a
special arrangement to that effect, and there's nothing in the guts of
gcc setting up or assuming those semantics.
On 7/30/2021 4:39 AM, Aldy Hernandez via Gcc-patches wrote:
It occurs to me that I should not have disabled early jump threading in
this test, as it may hide an actual defect. I have reverted my change
and XFAILed the test instead. I have also opened a PR101690 to keep track
of this problem.
On Fri, 2021-07-30 at 16:23 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote:
> > Xi Ruoyao writes:
> > > Ping again.
> > >
> > > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> > > > Commit message shamelessly copied from 1777beb6b129 by
On Fri, 2021-07-30 at 16:17 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote:
> > Xi Ruoyao writes:
> > > Ping again.
> >
> > Sorry that this has gone unreviewed for so long. I think in
> > practice
> > the MIPS port is essentially unmaintained
On Fri, Jul 30, 2021 at 8:40 AM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > +/* Callback routine for store_by_pieces. Read GET_MODE_BITSIZE (MODE)
> > + bytes from constant string DATA + OFFSET and return it as target
> > + constant. If PREV isn't nullptr, it has the
This adds a configure check for the GNU extension secure_getenv and then
uses it for looking up TMPDIR and similar variables.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
PR libstdc++/65018
* configure.ac: Check for secure_getenv.
* config.h.in: Regenerate.
On 7/30/21 11:23 AM, Jakub Jelinek wrote:
On Fri, Jul 30, 2021 at 11:00:26AM -0400, Jason Merrill wrote:
Patch attached.
LGTM (which would mean I'll need to replace that particular test union
with a different one which will have just a non-std-layout member of the
anon struct, see below), but
In discussion of jakub's patch for C++20 pointer-interconvertibility, it
came up that we allow anonymous structs to have bases, but don't do anything
usable with them. Let's reject it.
The comment change is something I noticed while looking for the right place
to diagnose this: finish_struct_anon
On 7/28/21 9:20 AM, Tom de Vries wrote:
Hi,
Improve nonnull attribute documentation in a number of ways:
Reorganize discussion of effects into:
- effects for calls to functions with nonnull-marked parameters, and
- effects for function definitions with nonnull-marked parameters.
This makes it c
On 7/30/2021 12:08 AM, Eugene Rozenfeld wrote:
This patch has the following changes:
Great thanks. Thanks for working on this. Looks all good to me (except I
guess the patches could be split up for commit)
-Andi
This patch adds a simple class for holding A/B fractions.
As the comments in the patch say, the class isn't designed
to have nice numerial properties at the extremes.
The motivating use case was some aarch64 costing work,
where being able to represent fractions was much easier
than using single in
On 7/30/2021 2:04 AM, Richard Sandiford via Gcc-patches wrote:
Xi Ruoyao writes:
Ping again.
Sorry that this has gone unreviewed for so long. I think in practice
the MIPS port is essentially unmaintained at this point -- it would
be great if someone would volunteer :-)
Yup.
It isn't re
"H.J. Lu via Gcc-patches" writes:
> +/* Callback routine for store_by_pieces. Read GET_MODE_BITSIZE (MODE)
> + bytes from constant string DATA + OFFSET and return it as target
> + constant. If PREV isn't nullptr, it has the RTL info from the
> + previous iteration. */
>
> +rtx
> +builti
On Fri, Jul 30, 2021 at 11:00:26AM -0400, Jason Merrill wrote:
> Patch attached.
LGTM (which would mean I'll need to replace that particular test union
with a different one which will have just a non-std-layout member of the
anon struct, see below), but I guess we want a testcase for this, e.g.
st
On 7/27/21 2:56 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575690.html
Are there any other suggestions or comments or is the latest revision
okay to commit?
OK.
On 7/20/21 12:34 PM, Martin Sebor wrote:
On 7/14/21 10:23 AM, Jason Merrill wrote:
On 7/14
On 7/30/21 6:44 AM, Jakub Jelinek wrote:
Hi!
During the OpenMP directives using C++ attribute syntax work, I've noticed
that cp_parser_statement when parsing various block declarations that do
not allow attribute-specifier-seq at the start rolls back the attributes
only if std_attrs is non-NULL
On 7/30/21 5:51 AM, Jakub Jelinek wrote:
On Thu, Jul 29, 2021 at 04:38:44PM -0400, Jason Merrill wrote:
We don't already reject an anonymous struct with bases? I think we should
do so, in fixup_anonymous_aggr. We might even require anonymous structs to
be standard-layout.
Not having base cla
Hi Richi,
on 2021/7/30 下午7:34, Richard Biener wrote:
> This adds a gather vectorization capability to the vectorizer
> without target support by decomposing the offset vector, doing
> sclar loads and then building a vector from the result. This
> is aimed mainly at cases where vectorizing the res
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Richard
> Biener
> Sent: Friday, July 30, 2021 12:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford
> Subject: [PATCH] Add emulated gather capability to the vectorizer
>
> This ad
On Fri, Jul 30, 2021 at 6:42 AM Jakub Jelinek wrote:
>
> On Fri, Jul 30, 2021 at 03:39:03PM +0200, Uros Bizjak via Gcc-patches wrote:
> > On Fri, Jul 30, 2021 at 3:04 PM H.J. Lu wrote:
> > >
> > > gcc/
> > >
> > > PR target/101685
> > > * config/i386/i386-options.c (ix86_option_ov
Richard Biener writes:
> This adds a gather vectorization capability to the vectorizer
> without target support by decomposing the offset vector, doing
> sclar loads and then building a vector from the result. This
> is aimed mainly at cases where vectorizing the rest of the loop
> offsets the co
On Fri, Jul 30, 2021 at 03:39:03PM +0200, Uros Bizjak via Gcc-patches wrote:
> On Fri, Jul 30, 2021 at 3:04 PM H.J. Lu wrote:
> >
> > gcc/
> >
> > PR target/101685
> > * config/i386/i386-options.c (ix86_option_override_internal):
> > Don't enable LZCNT/POPCNT if they have b
On Fri, Jul 30, 2021 at 3:04 PM H.J. Lu wrote:
>
> gcc/
>
> PR target/101685
> * config/i386/i386-options.c (ix86_option_override_internal):
> Don't enable LZCNT/POPCNT if they have been disabled explicitly.
>
> gcc/testsuite/
>
> PR target/101685
> * gcc.ta
On 7/30/21 9:25 AM, Richard Biener wrote:
> On Wed, 28 Jul 2021, Tom de Vries wrote:
>
>> Hi,
>>
>> Improve nonnull attribute documentation in a number of ways:
>>
>> Reorganize discussion of effects into:
>> - effects for calls to functions with nonnull-marked parameters, and
>> - effects for fun
On Fri, Jul 30, 2021 at 12:27:39PM +0200, Uros Bizjak wrote:
> Please put some space here, e.g.:
...
> Can you just name the relevant insn pattern and use
>
> emit_insn (gen_bsr_1)?
Here is the updated patch. I'll bootstrap/regtest it tonight.
2021-07-30 Jakub Jelinek
PR target/7810
gcc/
PR target/101685
* config/i386/i386-options.c (ix86_option_override_internal):
Don't enable LZCNT/POPCNT if they have been disabled explicitly.
gcc/testsuite/
PR target/101685
* gcc.target/i386/pr-101685.c: New test.
---
gcc/config/i386/i386-options.
On Fri, Jul 30, 2021 at 2:06 AM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
> > wrote:
> >>
> >> "H.J. Lu via Gcc-patches" writes:
> >> > On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
> >> > wrote:
> >> >>
> >> >> "H
On Fri, Jul 30, 2021 at 2:05 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Tue, Jul 27, 2021 at 8:31 AM H.J. Lu wrote:
> >>
> >> On Mon, Jul 26, 2021 at 4:19 PM H.J. Lu wrote:
> >> >
> >> > On Mon, Jul 26, 2021 at 3:56 PM H.J. Lu wrote:
> >> > >
> >> > > On Mon, Jul 26, 2021 at 2:53
1. Replace scalar_int_mode with fixed_size_mode in the by-pieces
infrastructure to allow non-integer mode.
2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size
to return QI vector mode for memset.
3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the
smallest integ
On Fri, 30 Jul 2021, Richard Biener wrote:
> > It isn't really appropriate for me to review MIPS stuff given that I work
> > for a company that has a competing architecture. I think Jeff expressed
> > similar concerns given his new role.
>
> I think that should be a non-issue unless it is an iss
Hi!
On 2021-07-30T12:05:56+0200, I wrote:
> On 2021-07-30T12:02:00+0200, Jakub Jelinek via Gcc-patches
> wrote:
>> On Fri, Jul 30, 2021 at 11:54:00AM +0200, Ulrich Drepper wrote:
>>> On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
>>>
>>> > I think for now it would be better to guard the
This adds a gather vectorization capability to the vectorizer
without target support by decomposing the offset vector, doing
sclar loads and then building a vector from the result. This
is aimed mainly at cases where vectorizing the rest of the loop
offsets the cost of vectorizing the gather.
Not
Hi,
This patch is to fix the typos in the move_sese_region_to_fn.
As mentioned here [1], I tried to debug the test case
gcc.dg/graphite/pr83359.c with trunk, but I found it didn't
go into the hunk guard with "if (moved_orig_loop_num)". So
I switched to commit 555758de90074 (also reproduced the IC
On 7/29/21 9:23 AM, Richard Biener wrote:
> On Wed, 28 Jul 2021, Bernd Edlinger wrote:
>
>> On 7/28/21 2:51 PM, Richard Biener wrote:
>>> On Mon, 26 Jul 2021, Bernd Edlinger wrote:
>>>
Ignored functions decls that are compiled at the start of
the assembly have bogus line numbers until
The front-end ensures that both sides have been casted to the same type
before being given to the lowering pass.
gcc/d/ChangeLog:
* expr.cc (binary_op): Remove dead code.
---
gcc/d/expr.cc | 8
1 file changed, 8 deletions(-)
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index 73e0
Makes it explicit that the default value is set to NULL.
gcc/d/ChangeLog:
* typeinfo.cc (TypeInfoVisitor::visit (TypeInfoClassDeclaration *)):
Always layout initializer for the m_RTInfo field.
---
gcc/d/typeinfo.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/d/typei
This expression is just discarded by add_stmt, so never reaches the
middle-end.
gcc/d/ChangeLog:
* expr.cc (ExprVisitor::visit (AssertExp *)): Don't generate
PREDICT_EXPR.
---
gcc/d/expr.cc | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/gcc/d/exp
The code block is done as an optimization to elide a call to the runtime
library helpers _d_arrayctor or _d_arrayassign.
gcc/d/ChangeLog:
* expr.cc (ExprVisitor::visit (AssignExp *)): Clarify comment
for generating static array assignment with literal.
---
gcc/d/expr.cc | 6 +++
Anonymous enums neither generate an initializer nor typeinfo symbol, so
it's safe to assert that all enum declarations passed to this function
always have an identifier.
gcc/d/ChangeLog:
* decl.cc (enum_initializer_decl): Only handle named enums.
---
gcc/d/decl.cc | 7 ++-
1 file cha
It is not expected to have a member function that can be non-public, but
this guards against any internal errors that might occur should that
ever change in the front-end.
gcc/d/ChangeLog:
* decl.cc (make_thunk): Set COMDAT and visibility of thunks only if
they are public.
---
gc
The self-hosted implementation of the D front-end changes the type of
`sinit' to a void pointer, which requires an explicit cast to `tree'.
gcc/d/ChangeLog:
* decl.cc (DeclVisitor::visit (StructDeclaration *)): Don't use sinit
for declaration directly.
(DeclVisitor::visit
The self-hosted implementation of the D front-end does not export
Identifier::generateId, so handle name generation inline instead.
gcc/d/ChangeLog:
* d-builtins.cc (build_frontend_type): Use Identifier::idPool to
generate anonymous field name.
---
gcc/d/d-builtins.cc | 10 ++
This helper introduced by the front-end is a better gate, and allows the
front-end to change rules for what gets a monitor in the future.
gcc/d/ChangeLog:
* types.cc (layout_aggregate_type): Call hasMonitor.
* typeinfo.cc (TypeInfoVisitor::layout_base): Likewise.
(layout_c
Covers cases where functions that handle the extracted strings ignore
the explicit length. This isn't something that's known to happen in the
current front-end, but the self-hosted front-end has been observed to do
this in its conversions between D and C-style strings.
gcc/d/ChangeLog:
*
This ensures there are no dangling references to AST members that have
been freed, either explcitly or by the garbage collector.
gcc/d/ChangeLog:
* d-builtins.cc (build_frontend_type): Restore builtin_converted_decls
length on conversion failure.
---
gcc/d/d-builtins.cc | 9 +
Both do the exact same operation, just on different AST nodes.
gcc/d/ChangeLog:
* d-codegen.cc (d_nested_class): Rename to ...
(get_outer_function): ... this. Handle all aggregate declarations.
(d_nested_struct): Remove.
(find_this_tree): Use get_outer_function.
Hi,
This small series of patches are for non-mechanical refactorings of the
D front-end either required to work with the self-hosted version, or
were made during the port to the self-hosted compiler.
Each individual change has been pulled out into its own patch, rather
than lumped together into o
Hi!
During the OpenMP directives using C++ attribute syntax work, I've noticed
that cp_parser_statement when parsing various block declarations that do
not allow attribute-specifier-seq at the start rolls back the attributes
only if std_attrs is non-NULL (i.e. some attributes have been parsed),
bu
It occurs to me that I should not have disabled early jump threading in
this test, as it may hide an actual defect. I have reverted my change
and XFAILed the test instead. I have also opened a PR101690 to keep track
of this problem.
I have pushed this patch, but could benefit from someone with k
On Wed, Jul 28, 2021 at 10:36 AM Jakub Jelinek wrote:
>
> Hi!
>
> This patch improves emitted code for the non-TARGET_LZCNT case.
> As __builtin_clz* is UB on 0 argument and for !TARGET_LZCNT
> CLZ_VALUE_DEFINED_AT_ZERO is 0, it is UB even at RTL time and so we
> can take advantage of that and ass
Hi!
On 2021-07-30T12:02:00+0200, Jakub Jelinek via Gcc-patches
wrote:
> On Fri, Jul 30, 2021 at 11:54:00AM +0200, Ulrich Drepper wrote:
>> On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
>>
>> > I think for now it would be better to guard the omp_display_env_*
>> > in fortran.c with #ifnd
On Mon, Jul 26, 2021 at 5:33 AM Hongtao Liu wrote:
>
> On Wed, Jul 14, 2021 at 8:27 PM H.J. Lu wrote:
> >
> > On Fri, Jun 25, 2021 at 5:39 AM H.J. Lu wrote:
> > >
> > > On Fri, Jun 25, 2021 at 12:50 AM Uros Bizjak wrote:
> > > >
> > > > On Fri, Jun 25, 2021 at 4:51 AM Hongtao Liu wrote:
> > >
On Fri, Jul 30, 2021 at 11:54:00AM +0200, Ulrich Drepper wrote:
> On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
>
> > I think for now it would be better to guard the omp_display_env_*
> > in fortran.c with #ifndef LIBGOMP_OFFLOADED_ONLY
> >
>
> OK, easy enough. This compiles for me.
Ok
On Fri, Jul 30, 2021 at 10:50 AM Jakub Jelinek wrote:
> I think for now it would be better to guard the omp_display_env_*
> in fortran.c with #ifndef LIBGOMP_OFFLOADED_ONLY
>
OK, easy enough. This compiles for me.
diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index 76285d4376b..26ec8ce30
On Thu, Jul 29, 2021 at 04:38:44PM -0400, Jason Merrill wrote:
> > +/* Helper function for pointer_interconvertible_base_of_p. Verify
> > + that BINFO_TYPE (BINFO) is pointer interconvertible with BASE. */
> > +
> > +static bool
> > +pointer_interconvertible_base_of_p_1 (tree binfo, tree base)
On 7/30/21 10:39 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On Mon, Jul 26, 2021 at 7:28 PM Richard Sandiford
wrote:
Aldy Hernandez writes:
On Mon, Jul 26, 2021 at 4:18 PM Richard Sandiford
wrote:
Aldy Hernandez writes:
This patch replaces the evrp_range_analyzer in the lo
On Mon, Jul 26, 2021 at 1:27 PM Roger Sayle wrote:
>
>
> The following patch to the x86_64 backend improves the code generated
> for a decrement followed by a conditional move. The primary change is
> to recognize that after subtracting one, checking the result is -1 (or
> equivalently that the o
On Fri, Jul 30, 2021 at 01:10:33AM -0400, Jason Merrill wrote:
> > It also shows that in the case (we're beyond the standard in this case
> > because anonymous structures are not in the standard) of union with
> > non-std-layout anonymous structure in it, in the case in the testcases like:
> > stru
"H.J. Lu via Gcc-patches" writes:
> On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
> wrote:
>>
>> "H.J. Lu via Gcc-patches" writes:
>> > On Mon, Jul 26, 2021 at 11:42 AM Richard Sandiford
>> > wrote:
>> >>
>> >> "H.J. Lu via Gcc-patches" writes:
>> >> > +to avoid stack realignment when expa
"H.J. Lu" writes:
> On Tue, Jul 27, 2021 at 8:31 AM H.J. Lu wrote:
>>
>> On Mon, Jul 26, 2021 at 4:19 PM H.J. Lu wrote:
>> >
>> > On Mon, Jul 26, 2021 at 3:56 PM H.J. Lu wrote:
>> > >
>> > > On Mon, Jul 26, 2021 at 2:53 PM Richard Sandiford
>> > > wrote:
>> > > >
>> > > > "H.J. Lu via Gcc-patc
On Thu, Jul 29, 2021 at 03:03:50PM -0400, Jason Merrill wrote:
> Let's not mention the obscure attribute-declaration grammar nonterminal,
> "attribute ignored" seems sufficient.
Ok, thanks. Here is what I've committed and I have also filed
PR101686 for the module related xfails.
2021-07-30 Jaku
On Fri, Jul 30, 2021 at 10:43:01AM +0200, Ulrich Drepper wrote:
> On Fri, Jul 30, 2021 at 9:50 AM Tobias Burnus
> wrote:
>
> > this patch breaks offloading. The reason is that most code
> > in env.c is enclosed in:
> >
>
> Indeed, normally I test that configuration but my setup currently has a f
Hi,
On Fri, Jul 30, 2021 at 9:50 AM Tobias Burnus
wrote:
> this patch breaks offloading. The reason is that most code
> in env.c is enclosed in:
>
Indeed, normally I test that configuration but my setup currently has a few
problems.
Although the env vars aren't parsed for those targets it seem
Aldy Hernandez writes:
> On Mon, Jul 26, 2021 at 7:28 PM Richard Sandiford
> wrote:
>>
>> Aldy Hernandez writes:
>> > On Mon, Jul 26, 2021 at 4:18 PM Richard Sandiford
>> > wrote:
>> >>
>> >> Aldy Hernandez writes:
>> >> > This patch replaces the evrp_range_analyzer in the loop versioning code
On Fri, Jul 30, 2021 at 10:06 AM Richard Sandiford via Gcc-patches
wrote:
>
> Xi Ruoyao writes:
> > Ping again.
>
> Sorry that this has gone unreviewed for so long. I think in practice
> the MIPS port is essentially unmaintained at this point -- it would
> be great if someone would volunteer :-)
On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Ping again.
> >
> > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> > > Commit message shamelessly copied from 1777beb6b129 by jakub:
> > >
> > > This function, because it is sometimes called even outside o
On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Ping again.
>
> Sorry that this has gone unreviewed for so long. I think in practice
> the MIPS port is essentially unmaintained at this point -- it would
> be great if someone would volunteer :-)
A company work
Xi Ruoyao writes:
> Ping again.
>
> On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
>> Commit message shamelessly copied from 1777beb6b129 by jakub:
>>
>> This function, because it is sometimes called even outside of function
>> bodies, uses create_tmp_var_raw rather than create_tmp_var. But
Xi Ruoyao writes:
> Ping again.
Sorry that this has gone unreviewed for so long. I think in practice
the MIPS port is essentially unmaintained at this point -- it would
be great if someone would volunteer :-)
It isn't really appropriate for me to review MIPS stuff given that I work
for a compan
On Fri, Jul 30, 2021 at 01:10:33AM -0400, Jason Merrill wrote:
> On 7/29/21 10:21 AM, Jakub Jelinek wrote:
> > On Thu, Jul 29, 2021 at 09:50:10AM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Now that I'm writing the above text and rereading the
> > > pointer-interconvertibility definition
On Fri, 2021-07-30 at 15:21 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 15:00 +0800, Kewen.Lin wrote:
> > Hi Ruoyao,
> >
> > on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote:
> > > Ping again.
> > >
> >
> > This ping-ed patch has been approved by Richard at
> >
> > http
1 - 100 of 108 matches
Mail list logo
