On 2021-05-12, Rainer Orth wrote:
Hi Fangrui,
Hi Rainer,
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
Solaris/x86 ld doesn't support this, so HAVE_LD_PIE_COPYRELOC needs to
stay.
Implement FP vector compares for V2SFmode for TARGET_MMX_WITH_SSE.
2021-05-12 Uroš Bizjak
gcc/
PR target/98218
* config/i386/i386-expand.c (ix86_expand_sse_movcc): Handle V2SF mode.
* config/i386/mmx.md (MMXMODE124): New mode iterator.
(V2FI): Ditto.
(mmxintvecmode): New mo
Hi Fangrui,
> This was introduced in 2014-12 to use local binding for external symbols
> for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
> nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
> should retire now.
Solaris/x86 ld doesn't support this, so HAVE_L
Nothing in gcc or binutils or gdb or anything anywhere uses these.
config/
* acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
---
config/acinclude.m4 | 102
1 file changed, 102 deletions(-)
diff --git a/config/acinclude.m4 b/config/a
This was introduced in 2014-12 to use local binding for external symbols
for -fPIE. Now that we have H.J. Lu's GOTPCRELX for years which mostly
nullify the benefit of HAVE_LD_PIE_COPYRELOC, HAVE_LD_PIE_COPYRELOC
should retire now.
One design goal of -fPIE was to avoid copy relocations.
HAVE_LD_PIE
This patch implements [dcl.attr.grammar]/5: "If an attribute-specifier-seq
appertains to a friend declaration ([class.friend]), that declaration shall
be a definition."
This restriction only applies to C++11-style attributes. There are
various forms of friend declarations, we have friend template
default_zero_call_used_regs currently requires all potentially zeroed
registers to offer a move opcode that accepts zero as an operand.
This is not the case e.g. for ARM's r12/ip in Thumb mode, and it was
not the case of FP registers on AArch64 as of GCC 10.
This patch introduces a fallback str
C2X adds #elifdef and #elifndef preprocessor directives; these have
also been proposed for C++. Implement these directives in libcpp
accordingly.
In this implementation, #elifdef and #elifndef are treated as
non-directives for any language version other than c2x and gnu2x (if
the feature is accep
* 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
When expanding a constant constructor, don't call expand_constructor if
it is more efficient to load the data from the memory via move by pieces.
gcc/
PR middle-end/90773
* expr.c (expand_expr_real_1): Don't call expand_constructor if
it is more efficient to load the data
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-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
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
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/testsuite/gcc.target/i386/pr90773-20.c | 13 +
gcc
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/
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset. Define SCRATCH_SSE_REG as a scratch register for
ix86_gen_memset_value.
gcc/
PR middle-end/90773
* builtins.c (builtin_mems
1. Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target instructions to duplicate QImode value to TImode/OImode/XImode
value for memmset.
2. x86: Avoid stack realignment when copying data
3. x86: Remov MAX_BITSIZE_MODE_ANY_INT. Only x86 backend defines it.
4. x86: Use TImode/
We can use TImode/OImode/XImode integers for piecewise move and store.
When vector register is used for piecewise move and store, we don't
increase stack_alignment_needed since vector register spill isn't
required for piecewise move and store. Since stack_realign_needed is
set to true by checking
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): Use
SCRATCH_SSE_REG to copy data from one memory location to
another.
gcc/testsuite/
* gcc.target/i386/eh
It is only defined for i386 and everyone uses the default:
#define MAX_BITSIZE_MODE_ANY_INT (64*BITS_PER_UNIT)
Whatever problems we had before, they have been fixed now.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): Removed.
---
gcc/config/i386/i386-modes.def | 15 +++---
On Tue, May 11, 2021 at 10:57:56AM -0500, Bill Schmidt wrote:
> Hi! I'd like to ping this series. This is a big change, so I'd like to
> get it committed fairly early in stage 1. I know you have a lot stacked
> up, though.
I haven't received most of this series (only the last three patches).
The sfield / firstprivate lookup used the wrong var decl
for the lookup – hence it failed.
I used an extra long diff to make it easier to follow why
'c' and not 'detach_clause' has the proper clause for the
decl to be used as key.
Testsuite run ongoing.
OK for mainline, when it passes?
Tobias
-
Hi!
On Fri, May 07, 2021 at 10:40:21AM +0800, Kewen.Lin wrote:
> .../gcc.target/powerpc/vec-perm-ctor-run.c| 124 +
> .../gcc.target/powerpc/vec-perm-ctor.c| 9 +
> .../gcc.target/powerpc/vec-perm-ctor.h| 163 ++
The new testcases are fine (as far
Ping 2:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
On 5/3/21 3:50 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
On 4/27/21 9:52 AM, Martin Sebor wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:
On 2/12/21 1:55 AM, Richard Biener wrote:
On Fri, Feb 12, 2021 at 1:35 AM Martin Sebor via Gcc-patches
wrote:
While trawling through old bugs I came across one from 2005: PR 21433
- The COMPONENT_REF case of expand_expr_real_1 is probably wrong.
The report looks correct in that argument 0 in
On 11/05/21 21:27 +0300, Antony Polukhin via Libstdc++ wrote:
This patch provides compile time diagnostics for common misuse of
[locale.convenience] functions with std::string as a character type.
2021-05-11 Antony Polukhin
PR libstdc++/89728
* include/bits/locale_facets.h (ctype) Add stat
The attached change teaches the uninitialized pass about
__builtin_stack_restore and __builtin___asan_mark to avoid two
classes of -Wuninitialized false negatives.
Richard, you already approved the __builtin_stack_restore change
in the bug but I figured I'd submit a patch with both changes for
ap
The libcpp function cpp_avoid_paste is used to insert whitespace in
preprocessed output where needed to avoid two consecutive
preprocessing tokens, that logically (e.g. when stringized) do not
have whitespace between them, from being incorrectly lexed as one when
the preprocessed input is reread by
This patch provides compile time diagnostics for common misuse of
[locale.convenience] functions with std::string as a character type.
2021-05-11 Antony Polukhin
PR libstdc++/89728
* include/bits/locale_facets.h (ctype) Add static assert.
* testsuite/22_locale/ctype/is/string/89728_neg.cc
It's about more porting to Python3.
Ready for master?
Thanks,
Martin
gcc/ada/ChangeLog:
* doc/share/conf.py: Do not use binary mode.
Do not use u' literals as Python3 uses unicode by default.
---
gcc/ada/doc/share/conf.py | 28 ++--
1 file changed, 14 in
On Tue, May 11, 2021 at 06:07:19PM +0100, Jonathan Wakely via Gcc-patches wrote:
> > I'm not sure if the abort call is necessary since the link step already
> > fails with a multiple definition error (without the fix) even if the
> > function is defined with an empty body. But since Jakub included
On 11/05/21 13:04 -0400, Patrick Palka wrote:
On Tue, 11 May 2021, Jonathan Wakely wrote:
On 11/05/21 11:16 -0400, Patrick Palka via Libstdc++ wrote:
> On Tue, 11 May 2021, Patrick Palka wrote:
>
> > floating_to_chars.cc includes the Ryu sources into an anonymous
> > namespace as a convenient w
On Tue, 11 May 2021, Jonathan Wakely wrote:
> On 11/05/21 11:16 -0400, Patrick Palka via Libstdc++ wrote:
> > On Tue, 11 May 2021, Patrick Palka wrote:
> >
> > > floating_to_chars.cc includes the Ryu sources into an anonymous
> > > namespace as a convenient way to give all its symbols internal li
On 11/05/21 11:16 -0400, Patrick Palka via Libstdc++ wrote:
On Tue, 11 May 2021, Patrick Palka wrote:
floating_to_chars.cc includes the Ryu sources into an anonymous
namespace as a convenient way to give all its symbols internal linkage.
But an entity declared extern "C" always has external lin
The header synopsis test fails to define NOTHROW for C++98.
The shared_ptr test should be skipped for C++98.
The debug mode one should work for C++98 too, it just needs to avoid
C++11 syntax that isn't valid in C++98.
libstdc++-v3/ChangeLog:
* testsuite/20_util/headers/memory/synopsis.c
The changes in 75c6a925dab5b7af9ab47c10906cb0e140261cc2 were slightly
incorrect, because the converting constructor should be noexcept, and
the POCMA and is_always_equal traits should still be present in C++20.
This fixes it, and slightly refactors the preprocessor conditions and
order of members.
Hi! I'd like to ping this specific patch from the series, which is the
only one remaining that affects common code. I confess that I don't
know whom to ask for a review for gengtype; I didn't get any good ideas
from MAINTAINERS. If you know of a good reviewer candidate, please CC them.
In a
Hi! I'd like to ping this series. This is a big change, so I'd like to
get it committed fairly early in stage 1. I know you have a lot stacked
up, though.
Thanks!
Bill
On 4/27/21 10:32 AM, Bill Schmidt wrote:
The design of the target-specific built-in function support in the
Power back end
Hi! I'd like to ping this series. It has slightly higher priority from
my perspective, since I'd like this to be backported in time for GCC 11.2.
Thanks!
Bill
On 4/25/21 8:50 PM, Bill Schmidt via Gcc-patches wrote:
Add POWER10 support for hashst[p] and hashchk[p] operations. When
the -mrop-
On Tue, May 11, 2021 at 05:30:19PM +0200, Tobias Burnus wrote:
> On 11.05.21 17:20, Jakub Jelinek via Gcc-patches wrote:
> > One extra thing, sorry, forgot to mention, for the translators it might be
> > better to use "too many %qs modifiers", "always" (or, "close").
> > That way they can translate
On 11.05.21 17:20, Jakub Jelinek via Gcc-patches wrote:
One extra thing, sorry, forgot to mention, for the translators it might be
better to use "too many %qs modifiers", "always" (or, "close").
That way they can translate it just once instead of twice.
That won't work for
c_parser_error (pars
On Tue, May 11, 2021 at 04:27:55PM +0200, Marcel Vollweiler wrote:
> > The usual wording would be
> > "too many % modifiers"
> >
>
> Changed for 'always' and 'close' for C and C++.
One extra thing, sorry, forgot to mention, for the translators it might be
better to use "too many %qs modifiers",
On Tue, 11 May 2021, Patrick Palka wrote:
> floating_to_chars.cc includes the Ryu sources into an anonymous
> namespace as a convenient way to give all its symbols internal linkage.
> But an entity declared extern "C" always has external linkage, even
> from within an anonymous namespace, so this
Hi Chung-Lin!
On 2021-05-11T19:28:04+0800, Chung-Lin Tang wrote:
> This patch largely implements three pieces of functionality:
>
> (1) Per discussion and clarification on the omp-lang mailing list,
> standards conforming behavior for mapping array sections should *NOT* also
> map the base-point
On Tue, May 11, 2021 at 04:36:47PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> The type of the output operands *p and *q of the extended asm statement
> of function foo is unsigned long whereas the type of the corresponding
> input operands is int. This results, e.g. on IBM Z, in
[Changes from V1]
- included checks in
- config/darwin.c
- config/i386/cygming.h
- config/i386/darwin.h
- config/mips/mips.c
- config/rs6000/rs6000.c
[End of changes from V1]
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on wri
[Changes from V1]
- Use debug_set_names API and remove asserts around the diagnostics
- Reword diagnostic and adjust testsuite
[End of changes from V1]
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
gcc/c-fami
[Changes from V1]
- (Addressed Richard's comments)
- For patch 1/2 [opts: change write_symbols to support bitmasks], use
debug_set_names more uniformly. Reworded the diagnostics in c-family/c-opts.c
and c-family/c-pch.c as there can be multiple debug formats. Updated the
testsuite files a
The type of the output operands *p and *q of the extended asm statement
of function foo is unsigned long whereas the type of the corresponding
input operands is int. This results, e.g. on IBM Z, in the case that
the immediates 2 and 3 are written into registers in SI mode and read in
DI mode resul
Am 10.05.2021 um 20:34 schrieb Jakub Jelinek:
On Mon, May 10, 2021 at 04:11:39PM +0200, Marcel Vollweiler wrote:
@@ -15660,37 +15665,54 @@ c_parser_omp_clause_map (c_parser *parser, tree list)
if (!parens.require_open (parser))
return list;
- if (c_parser_next_token_is (parser, CPP_
C2X adds digit separators, as in C++. Enable them accordingly in
libcpp and c-lex.c. Some basic tests are added that digit separators
behave as expected for C2X and are properly disabled for C11; further
test coverage is included in the existing g++.dg/cpp1y/digit-sep*.C
tests.
Bootstrapped with
On 5/10/21 6:11 AM, Richard Biener wrote:
On Thu, May 6, 2021 at 2:31 AM Indu Bhagat via Gcc-patches
wrote:
To support multiple debug formats, we need to move away from explicit
enumeration of each individual combination of debug formats.
debug_set_names with its static buffer seems unused?
floating_to_chars.cc includes the Ryu sources into an anonymous
namespace as a convenient way to give all its symbols internal linkage.
But an entity declared extern "C" always has external linkage, even
from within an anonymous namespace, so this trick doesn't work in the
presence of extern "C", a
My recent change to reject calling rvalue() with an argument of class type
crashes on this testcase, where we use rvalue() on what we expect to be an
argument of integer or vector type. Fixed by checking first.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/1005
This removes stale users of maybe_fold_reference where IL constraints
make it never do anything.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-05-11 Richard Biener
* gimple-fold.c (gimple_fold_call): Do not call
maybe_fold_reference on call arguments or the
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Japanese team of translators. The file is available at:
https://translationproject.org/latest/gcc/ja.po
(This file, 'gcc-11.1.0.ja.po', has j
Ping.
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
> On Apr 26, 2021, at 2:00 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> This adds some test cases to make sure that the combine patterns for p10
> fusion are working.
>
> OK for trunk?
>
> gcc/tests
Ping.
In answer to Will’s question — some of these are not immediately used but will
be in other pending patches.
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
> On Apr 26, 2021, at 1:04 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> This adds new valu
Ping.
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
> On Apr 26, 2021, at 3:21 PM, acsaw...@linux.ibm.com wrote:
>
> From: Aaron Sawdey
>
> Two more sets of combine patterns for p10 fusion. These require
> the "Add insn types for fusion pairs" patch I posted earlier
On Tue, May 11, 2021 at 3:39 PM Jakub Jelinek wrote:
>
> On Tue, May 11, 2021 at 03:33:58PM +0200, Martin Liška wrote:
> > On 5/11/21 9:49 AM, Richard Biener wrote:
> > > I wonder if we can instead upstream the build-id use and conditionalize
> > > the checksum stuff on some configury? Some peopl
On Tue, May 11, 2021 at 03:33:58PM +0200, Martin Liška wrote:
> On 5/11/21 9:49 AM, Richard Biener wrote:
> > I wonder if we can instead upstream the build-id use and conditionalize
> > the checksum stuff on some configury? Some people do seem worried
> > about "weakening" the checksum.
>
> I lik
On 5/11/21 9:49 AM, Richard Biener wrote:
I wonder if we can instead upstream the build-id use and conditionalize
the checksum stuff on some configury? Some people do seem worried
about "weakening" the checksum.
I like the build-id approach. Can we please upstream it?
If it's not feasible the
On Fri, 7 May 2021, Kewen.Lin wrote:
> Hi,
>
> This patch is to teach forwprop to optimize some cases where the
> permutated operands of vector permutation are from two same type
> CTOR and CTOR or one CTOR and one VECTOR CST. It aggressively
> takes VIEW_CONVERT_EXPR as trivial copies and tran
On Tue, 11 May 2021 19:28:04 +0800
Chung-Lin Tang wrote:
> This patch largely implements three pieces of functionality:
>
> (1) Per discussion and clarification on the omp-lang mailing list,
> standards conforming behavior for mapping array sections should *NOT*
> also map the base-pointer, i.e
Hi Robin,
On 5/5/21 5:18 PM, Robin Dapp wrote:
...
> diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
> index c80d582a300..7c730432d80 100644
> --- a/gcc/config/s390/vector.md
> +++ b/gcc/config/s390/vector.md
> @@ -36,6 +36,7 @@
> (define_mode_iterator V_HW2 [V16QI V8HI V4SI V
On Mon, May 10, 2021 at 8:52 PM Martin Jambor wrote:
>
> Hi,
>
> On Mon, May 10 2021, Richard Biener wrote:
> > I've tried to have a look at this patch but it does a lot of IPA specific
> > refactoring(?), so the actual DCE bits are hard to find. Is it possible
> > to split the patch up or is it
Hi,
On Tue, May 11 2021, Richard Biener wrote:
> This fixes unintended clobbering of SSA_NAME_DEF_STMT of the
> cloned/inlined from SSA name during IPA parameter manipulation
> of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT
> of the lhs to the stmt being modified but when
> ipa_
On Tue, May 11, 2021 at 12:50 PM Kewen.Lin wrote:
>
> Hi Richi,
>
> > OTOH we already pass scalar_stmt to individual add_stmt_cost,
> > so not sure whether the context really matters. That said,
> > the density test looks "interesting" ... the intent was that finish_cost
> > might
This patch largely implements three pieces of functionality:
(1) Per discussion and clarification on the omp-lang mailing list,
standards conforming behavior for mapping array sections should *NOT* also map
the base-pointer,
i.e for this code:
struct S { int *ptr; ... };
struct S s;
#p
This fixes unintended clobbering of SSA_NAME_DEF_STMT of the
cloned/inlined from SSA name during IPA parameter manipulation
of call stmt LHSs. gimple_call_set_lhs adjusts SSA_NAME_DEF_STMT
of the lhs to the stmt being modified but when
ipa_param_body_adjustments::modify_call_stmt is called the
clo
This patch removes the duplication between the mul_laneq3
and the older mul-lane patterns. The older patterns were previously
divided into two based on whether the indexed operand had the same mode
as the other operands or whether it had the opposite length from the
other operands (64-bit vs. 128-
On 06/05/2021 09:27, Alex Coplan via Gcc-patches wrote:
Hi all,
The PR shows us attaching REG_CFA_ADJUST_CFA notes to stack pointer
adjustments emitted in cmse_nonsecure_call_inline_register_clear (when
-march=armv8.1-m.main). However, the stack pointer is not guaranteed to
be the CFA reg. If
Jakub Jelinek writes:
> On Tue, Jan 19, 2021 at 04:10:33PM +, Richard Sandiford via Gcc-patches
> wrote:
>> Ah, ok, thanks for the extra context.
>>
>> So AIUI the problem when recording xmm2<-di isn't just:
>>
>> [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
>>
>> but also that:
This adjusts maybe_fold_reference to adhere to its desired behavior
of performing constant folding and thus explicitely avoid returning
unfolded reference trees.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-05-11 Richard Biener
* gimple-fold.c (maybe_fold_referenc
Hi Richi,
> OTOH we already pass scalar_stmt to individual add_stmt_cost,
> so not sure whether the context really matters. That said,
> the density test looks "interesting" ... the intent was that finish_cost
> might look at gathered data from add_stmt, not that it looks at
>
When folding a constant initializer looking through aliases to
incompatible types can lead to us trying to fold a constant
to an aggregate type which can't work. Simply avoid trying
to constant fold non-register typed symbols.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk
Alex Coplan writes:
> Hi Richard,
>
> On 21/04/2021 13:05, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > Hi Richard,
>> >
>> > On 15/04/2021 18:45, Richard Sandiford wrote:
>> >> Looks good in general, but like you say, it's GCC 12 material.
>> >
>> > Thanks for the review. The attached pa
It seems useful, I've backported to GCC 9/10/11.
Without this patch:
$ riscv64-unknown-elf-gcc -march=rv32imafd ~/hello.c -march=rv64gc
/scratch1/kitoc/riscv-gnu-workspace/rv64gc/install/bin/../lib/gcc/riscv64-unknown-elf/11.1.0/../../../../riscv64-unknown-elf/bin/ld:
unrecognised
emulation mode:
This work-in-progress patch tries to get
GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like
GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups
to be processed by build_struct_group/build_struct_comp_map. I think
that's important to integrate with how groups of mappings
This patch reworks indirect struct handling in gimplify.c (i.e. for struct
components mapped with "mystruct->a[0:n]", "mystruct->b", etc.), for
both OpenACC and OpenMP. The key observation leading to these changes
was that component mappings of references-to-structures is already
implemented and w
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, and with OpenMP making use of that mapping type too
now alongside OpenACC, there are cases where it was making it through
to omp-low.c. This patch rewrites such mappings to GOMP_MAP_ATTACH or
GOMP_MAP_DETACH un
With the "rework indirect struct handling" patch later in this series,
some parts of this earlier patch (by Chung-Lin) become unnecessary.
This patch reverts those bits.
An XFAIL has been added for a test that fails for the time being with
this reversion, until the later patch in the series fixes
With the "rework indirect struct handling" patch later in this series,
some parts of this earlier patch (by Chung-Lin) become unnecessary.
This patch reverts those bits.
2021-05-11 Julian Brown
gcc/
* gimplify.c (gimplify_scan_omp_clauses): Don't strip nops in indir_p
case. Don
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
https://gcc.gnu.org/pipermail/gcc-patch
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional benchm
Hi,
This patch series reworks how indirect struct (or class or derived-type)
component mappings are lowered for OpenMP and OpenACC. The series is
currently based on the og10 branch, but I'm planning to rebase it to
trunk and repost soon.
Currently on og10, there are some conflicts with Chung-Lin
Hello.
I'm going to push a commit that removes non-strict mode. It's useless right now.
Martin
contrib/ChangeLog:
* gcc-changelog/git_check_commit.py: Remove --non-strict-mode.
* gcc-changelog/git_commit.py: Remove strict mode.
* gcc-changelog/git_email.py: Likewise.
On Tue, 11 May 2021, Jakub Jelinek wrote:
> On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
> > We can probably do it in 2 steps, first something like
> >
> > (for cmp (eq ne)
> > (simplify
> > (cmp (bit_and:c @0 @1) @0)
> > (cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@
On Tue, 11 May 2021, Jakub Jelinek via Gcc-patches wrote:
On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
We can probably do it in 2 steps, first something like
(for cmp (eq ne)
(simplify
(cmp (bit_and:c @0 @1) @0)
(cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); })
On Tue, May 11, 2021 at 9:10 AM Kewen.Lin wrote:
>
> Hi Richi,
>
> on 2021/5/10 下午9:55, Richard Biener wrote:
> > On Sat, May 8, 2021 at 10:05 AM Kewen.Lin wrote:
> >>
> >> Hi Richi,
> >>
> >> Thanks for the comments!
> >>
> >> on 2021/5/7 下午5:43, Richard Biener wrote:
> >>> On Fri, May 7, 2021 a
On Tue, May 11, 2021 at 8:46 AM Martin Liška wrote:
>
> On 4/23/21 1:37 PM, Martin Liška wrote:
> > On 4/23/21 12:59 PM, Richard Biener wrote:
> >> True, the question is on how much detail we have to pay attention to.
> >
> > Agree with that.
> >
> >> For us of course the build-id solution works f
On 5/4/21 5:08 PM, Robin Dapp wrote:
> Hi,
>
> instead of selecting bits 62 to (wraparound) 59 from r2 and inserting
> them into r3, we select bits 60 to 62 from r3 and insert them into r2
> nowadays. Adjust the test accordingly.
>
> Is this OK?
>
> Regards
> Robin
>
> gcc/testsuite/Change
On Thu, May 06, 2021 at 09:42:41PM +0200, Marc Glisse wrote:
> We can probably do it in 2 steps, first something like
>
> (for cmp (eq ne)
> (simplify
> (cmp (bit_and:c @0 @1) @0)
> (cmp (@0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); })))
>
> to get rid of the double use, and then sim
Hi!
When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
return, doesn't create any tasks and more importantly, doesn't create
a taskgroup and doesn't register task reductions. But, the code emitted
in the callers assumes task reductions have been registered and performs
the
Hi Segher,
on 2021/5/11 上午4:12, Segher Boessenkool wrote:
> Hi!
>
> On Sat, May 08, 2021 at 04:12:18PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -5234,6 +5234,8 @@ typedef struct _rs6000_cost_data
>>/* For each vectorized loop, this
Hi Richard,
on 2021/5/10 下午10:08, Richard Sandiford wrote:
> "Kewen.Lin via Gcc-patches" writes:
>> on 2021/5/7 下午5:43, Richard Biener wrote:
>>> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
>>> wrote:
Hi,
When I was investigating density_test heuristics, I notice
Hi Richi,
on 2021/5/10 下午9:55, Richard Biener wrote:
> On Sat, May 8, 2021 at 10:05 AM Kewen.Lin wrote:
>>
>> Hi Richi,
>>
>> Thanks for the comments!
>>
>> on 2021/5/7 下午5:43, Richard Biener wrote:
>>> On Fri, May 7, 2021 at 5:30 AM Kewen.Lin via Gcc-patches
>>> wrote:
Hi,
W
97 matches
Mail list logo
