On Thu, Nov 12, 2020 at 3:04 AM Hongtao Liu wrote:
> > > gcc/ChangeLog:
> > >
> > > PR target/97194
> > > * config/i386/i386-expand.c (ix86_expand_vector_set_var): New function.
> > > * config/i386/i386-protos.h (ix86_expand_vector_set_var): New Decl.
> > > * config/i386/predicates.md (vec_setm_o
On Thu, Nov 12, 2020 at 4:21 PM Uros Bizjak wrote:
>
> On Thu, Nov 12, 2020 at 3:04 AM Hongtao Liu wrote:
>
> > > > gcc/ChangeLog:
> > > >
> > > > PR target/97194
> > > > * config/i386/i386-expand.c (ix86_expand_vector_set_var): New function.
> > > > * config/i386/i386-protos.h (ix86_expand_vecto
On Thu, Nov 12, 2020 at 5:12 PM Hongtao Liu wrote:
>
> On Thu, Nov 12, 2020 at 4:21 PM Uros Bizjak wrote:
> >
> > On Thu, Nov 12, 2020 at 3:04 AM Hongtao Liu wrote:
> >
> > > > > gcc/ChangeLog:
> > > > >
> > > > > PR target/97194
> > > > > * config/i386/i386-expand.c (ix86_expand_vector_set_var)
On Thu, Nov 12, 2020 at 5:15 PM Hongtao Liu wrote:
>
> On Thu, Nov 12, 2020 at 5:12 PM Hongtao Liu wrote:
> >
> > On Thu, Nov 12, 2020 at 4:21 PM Uros Bizjak wrote:
> > >
> > > On Thu, Nov 12, 2020 at 3:04 AM Hongtao Liu wrote:
> > >
> > > > > > gcc/ChangeLog:
> > > > > >
> > > > > > PR target/
Hi,
with ipa-icf we often run into problem that operand_equal_p does not
match ADDR_EXPR that take address of fields from two different instances
of same class (at ideantical offsets). Similar problem can also happen
for record types with LTO if they did not get tree merged.
This patch makes fold-
On Thu, Nov 12, 2020 at 10:36:28AM +0100, Jan Hubicka wrote:
> * fold-const.c (operand_compare::operand_equal_p): When comparing
> addresses
> look info field offsets for COMPONENT_REFs.
> (operand_compare::hash_operand): Likewise.
> diff --git a/gcc/fold-const.c b/gcc/fold-const
> > + if (!operand_equal_p (DECL_FIELD_OFFSET (field0),
> > + DECL_FIELD_OFFSET (field1),
> > + flags & ~OEP_ADDRESS_OF)
> > + || !operand_equal_p (DECL_FIELD_BIT_OFFSET (field0),
> > +
On Thu, Nov 12, 2020 at 10:49:40AM +0100, Jan Hubicka wrote:
> > > + if (!operand_equal_p (DECL_FIELD_OFFSET (field0),
> > > + DECL_FIELD_OFFSET (field1),
> > > + flags & ~OEP_ADDRESS_OF)
> > > + || !operand_equ
This fixes the postorder compute for the case of multiple
expression leaders for a value.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-11-12 Richard Biener
PR tree-optimization/97806
* tree-ssa-pre.c (pre_expr_DFS): New overload for visiting
values
Hi,
the two following patches implement a new handling of the loops in
OpenACC "kernels" regions which is based on Graphite and which is meant
to replace the current handling based on the "parloops" pass. This
extends the class of OpenACC codes using "kernels" regions that can be
analysed by GCC
This patch enables the use of Graphite for the analysis of OpenACC
"auto" loops. The goal is to decide if a loop may be parallelized
(i.e. converted to an "independent" loop) or not. Graphite and the
functionality on which it relies (scalar evolution, data references) are
extended to interpret t
This patch changes the "kernels" conversion to route loops in OpenACC
"kernels" regions through Graphite. This is done by converting the loops
in "kernels" regions which are not yet known to be "independent" to
"auto" loops as in the current (OG10) "parloops" based "kernels"
handling. Afterwards,
libgomp build fails because of the false -Wformat error, even though:
1. Correct C99 inttypes.h macros are used.
2. __mingw_* C99 wrappers are used.
3. The printf attribute is used, but it was aliased to ms_printf
The attached patch makes mingw-w64 printf attribute equivalent to other
platforms
> On Thu, Nov 12, 2020 at 10:49:40AM +0100, Jan Hubicka wrote:
> > > > + if (!operand_equal_p (DECL_FIELD_OFFSET (field0),
> > > > + DECL_FIELD_OFFSET (field1),
> > > > + flags & ~OEP_ADDRESS_OF)
> > > > +
On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > that two COMPONENT_REFs access the same memory, then just comparing
> > DECL_BIT_FIELD_REPRESENTATIVE is not sufficient, you could have:
> > struct S { int c; i
> On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > > that two COMPONENT_REFs access the same memory, then just comparing
> > > DECL_BIT_FIELD_REPRESENTATIVE is not sufficient, you could have:
> > > struct S
On Thu, Nov 12, 2020 at 11:39:07AM +0100, Jan Hubicka wrote:
> > On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > > > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > > > that two COMPONENT_REFs access the same memory, then just comparing
> > > > DECL_BIT_FI
> On Thu, Nov 12, 2020 at 11:39:07AM +0100, Jan Hubicka wrote:
> > > On Thu, Nov 12, 2020 at 11:29:21AM +0100, Jan Hubicka wrote:
> > > > > If OEP_ADDRESS is used also on non-addressable stuff, just to compare
> > > > > that two COMPONENT_REFs access the same memory, then just comparing
> > > > > D
> > How is that different from:
> > struct S { long long d; int e; };
> > struct T { long long d; long long e; };
> > s->e vs. t->e ?
> > One thing is comparison of the address (as it is comparing
> > DECL_FIELD_BIT_OFFSET too, it is essentially bit-address), and another thing
> > (unlrelated to OE
For code like
!$acc kernels
... a lot of loops and other code
!$acc end kernels
gfortran generates
#pragma ..._kernels
{
... lot of code
}
As the PR shows, the location associated with the #pragma
is not the 'acc kernels' line but the one near the 'acc end kernel'
line.
Th
The following make sure to only iterate PRE insertion when
necessary - which is when AVAIL_OUT of a predecessor of a
block we already visited changed (that's backedge destinations).
To not regress this also makes sure to locally iterate insertion
since even topological sort of expressions isn't en
Hi,.
this patch converts the variables that hold time benefits and
frequencies in IPA-CP from plain integers to sreals, avoiding the need
to cap them to avoid overflows and also fixing a potential underflows.
Size costs corresponding to individual constants are left as ints so
that they do not ta
Hi Tobias!
On 2020-11-12T12:45:24+0100, Tobias Burnus wrote:
> For code like
> !$acc kernels
> ... a lot of loops and other code
> !$acc end kernels
>
> gfortran generates
>#pragma ..._kernels
> {
>... lot of code
> }
>
> As the PR shows, the location associated wit
The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representa
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/vector.md ("vec_vfees"): New insn pattern.
---
gcc/config/s390/vector.md | 26 ++
1 file changed, 26 insertions(+)
diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/vx-builtins.md ("*vfees"): Fix output
template.
---
gcc/config/s390/vx-builtins.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/vx-builtins.md b/gcc/config/s
Hi,
here is updated patch that replaces 'C' by '1'...'9' so we still have
place to specify size.
As discussed on IRC, this seems better alternative.
Bootstrapped/regtested x86_64-linux, OK?
Honza
gcc/ChangeLog:
2020-11-12 Jan Hubicka
* attr-fnspec.h: Update topleve comment.
> Hi,.
>
> this patch converts the variables that hold time benefits and
> frequencies in IPA-CP from plain integers to sreals, avoiding the need
> to cap them to avoid overflows and also fixing a potential underflows.
>
> Size costs corresponding to individual constants are left as ints so
> tha
On 12.11.20 13:25, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
>
> gcc/ChangeLog:
>
> * config/s390/vx-builtins.md ("*vfees"): Fix output
> template.
> ---
> gcc/config/s390/vx-builtins.md | 2 +-
> 1 file changed, 1 insertion(+), 1 del
On 12.11.20 13:21, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
>
> gcc/ChangeLog:
>
> * config/s390/vector.md ("vec_vfees"): New insn pattern.
> ---
> gcc/config/s390/vector.md | 26 ++
> 1 file changed, 26 insertions(+)
On Thu, 12 Nov 2020, Jan Hubicka wrote:
> Hi,
> with ipa-icf we often run into problem that operand_equal_p does not
> match ADDR_EXPR that take address of fields from two different instances
> of same class (at ideantical offsets). Similar problem can also happen
> for record types with LTO if t
> > * fold-const.c (operand_compare::operand_equal_p): When comparing
> > addresses
> > look info field offsets for COMPONENT_REFs.
> > (operand_compare::hash_operand): Likewise.
> > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > index c47557daeba..a4e8cccb1b7 100644
> > --- a/gc
On Thu, 12 Nov 2020, Jan Hubicka wrote:
> Hi,
> here is updated patch that replaces 'C' by '1'...'9' so we still have
> place to specify size.
> As discussed on IRC, this seems better alternative.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
Richard.
> Honza
>
> gcc/ChangeLog:
>
> 2020-1
Hi,
this is updated patch I am re-testing and plan to commit if it suceeds.
* fold-const.c (operand_compare::operand_equal_p): Compare
offsets of fields in component_refs when comparing addresses.
(operand_compare::hash_operand): Likewise.
diff --git a/gcc/fold-const.c b/gc
On Thu, Nov 12, 2020 at 10:23 AM Hongtao Liu wrote:
>
> On Thu, Nov 12, 2020 at 5:15 PM Hongtao Liu wrote:
> >
> > On Thu, Nov 12, 2020 at 5:12 PM Hongtao Liu wrote:
> > >
> > > On Thu, Nov 12, 2020 at 4:21 PM Uros Bizjak wrote:
> > > >
> > > > On Thu, Nov 12, 2020 at 3:04 AM Hongtao Liu wrote
On Thu, 12 Nov 2020, Jan Hubicka wrote:
> Hi,
> this is updated patch I am re-testing and plan to commit if it suceeds.
>
> * fold-const.c (operand_compare::operand_equal_p): Compare
> offsets of fields in component_refs when comparing addresses.
> (operand_compare::hash_operand
On 3/9/20 2:55 AM, Nicholas Guriev wrote:
> gcc/c-family/ChangeLog:
>
> PR pch/86674
> * c-pch.c (c_common_valid_pch): Use cpp_warning with CPP_W_INVALID_PCH
> reason to fix -Werror=invalid-pch and -Wno-error=invalid-pch switches.
> ---
> gcc/c-family/ChangeLog | 6 ++
> g
This fixes a bug in bitmap_list_view which could end up with
a NULL head->current which makes followup searches fail. Oops.
It also further optimizes the PRE DFS walk by removing useless
stuff and special-casing bitmaps with just one element for
EXECUTE_IF_AND_IN_BITMAP which makes a quite big di
Here's a small tweak to __numeric_traits that I decided to do after
the previous patch.
Tested on powerpc64le-linux. Committed to trunk.
commit d21776ef90361e66401cd99c8ff0d98b46d3b0d6
Author: Jonathan Wakely
Date: Thu Nov 12 13:31:02 2020
libstdc++: Simplify __numeric_traits definition
On Wed, Nov 11, 2020 at 06:22:53PM -0600, Segher Boessenkool wrote:
> I'm running an all-arch comparison with this patch, just to see what it
> does, but [...]
Results: C0 is trunk, C1 with patch:
C0C1
alpha 6422312 99.971%
arc 3783838 100.000%
在 2020/11/12 18:18, Jonathan Yong 写道:
> libgomp build fails because of the false -Wformat error, even though:
> 1. Correct C99 inttypes.h macros are used.
> 2. __mingw_* C99 wrappers are used.
> 3. The printf attribute is used, but it was aliased to ms_printf
>
> The attached patch makes mingw-w64
Will push pending aarch64 tests.
gcc/ChangeLog:
* tree-vrp.c (identify_jump_threads): Refactor to..
(vrp_jump_threader::vrp_jump_threader): ...here
(vrp_jump_threader::~vrp_jump_threader): ...and here.
(vrp_jump_threader::after_dom_children): Rename vr_values to
vr_values is being shared among the propagator and the folder and
passed around. I've pulled it out from the propagator so it can be
passed around to each, instead of being publicly accessible from the
propagator.
Will push pending aarch64 tests.
gcc/ChangeLog:
* tree-vrp.c (class vrp_p
Will push pending aarch64 tests.
gcc/ChangeLog:
* tree-vrp.c (class vrp_prop): Move entire class...
(class vrp_folder): ...before here.
---
gcc/tree-vrp.c | 200 -
1 file changed, 100 insertions(+), 100 deletions(-)
diff --git a/gc
Will push pending aarch64 tests.
gcc/ChangeLog:
* tree-vrp.c (class vrp_folder): Make visit_stmt, visit_phi,
and m_vr_values private.
(vrp_folder::vrp_evaluate_conditional): Remove.
(vrp_folder::vrp_simplify_stmt_using_ranges): Remove.
(vrp_folder::fold_pre
Earlier in this cycle there was some work by Giuliano Belinassi and
myself to refactor tree-vrp.c. A lot of functions and globals were
moved into independent classes, but the haphazard layout remained.
Assertion methods were indispersed with the propagation code, and with
the jump threading code,
> On Thu, 12 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > this is updated patch I am re-testing and plan to commit if it suceeds.
> >
> > * fold-const.c (operand_compare::operand_equal_p): Compare
> > offsets of fields in component_refs when comparing addresses.
> > (operand_compare::ha
On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote:
> The following patch extends the generation of exception handling
> information, so that it is possible to catch exceptions thrown from
> volatile asm statements, when -fnon-call-exceptions is enabled. Parts
> of the gcc code already sugg
On Thu, Nov 12, 2020 at 02:18:13PM +0100, Andreas Krebbel wrote:
> On 12.11.20 13:21, Stefan Schulze Frielinghaus wrote:
> > Bootstrapped and regtested on IBM Z. Ok for master?
> >
> > gcc/ChangeLog:
> >
> > * config/s390/vector.md ("vec_vfees"): New insn pattern.
> > ---
> > gcc/config/s39
On 11/11/20 10:03 PM, Marek Polacek wrote:
I'd like to have the option of marking functions with
__attribute__ ((__warn_unused_result__)), so this patch adds a macro.
And use it for maybe_wrap_with_location, it's always a bug if the
return value is not used, which happened to me and got me confus
On 4/7/20 2:45 PM, Pat Haugen via Gcc-patches wrote:
> The Power processor has the ability to fuse certain pairs of dependent
> instructions to improve their performance if they appear back-to-back in
> the instruction stream. In looking at the current support for
> instruction fusion in GCC I sa
As pointed out in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558816.html
this instruction pattern will be removed anyway. Thus we can ignore
this patch.
On Thu, Nov 12, 2020 at 01:25:35PM +0100, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
On 4/23/20 9:48 AM, will schmidt wrote:
> On Wed, 2020-04-22 at 12:26 -0600, Jeff Law wrote:
>> On Fri, 2020-04-10 at 16:40 -0500, will schmidt via Gcc-patches
>> wrote:
>>> [RFC][PR target/9] Compile time hog w/impossible asm constraint
>>> lra loop
>>>
>>> Hi,
>>> RFC for a bandaid/p
On 11/3/20 4:17 PM, Nathan Sidwell wrote:
this is the module mapper client and server pieces. It features a
default resolver that can read a text file, or generate default mappings
from module name to cmi name.
Richard rightly suggested on IRC that the sample server for the module
mapper sho
在 2020/11/12 23:12, Liu Hao 写道:
>
> My humble opinion is that people should have gotten used to the `ll`
> specifier so I propose a
> different patch that enables it unconditionally. As Jonathan Yong pointed
> out, GCC is impossible to
The previous patch missed a `double_name` field. A revised
On Fri, 2020-10-23 at 21:45 +0200, Jan Hubicka wrote:
> Hi,
> this patch moves thunk_info out of cgraph_node into a symbol summary.
> I also moved it to separate hearder file since cgraph.h became really
> too
> fat. I plan to contiue with similar breakup in order to cleanup
> interfaces
> and red
On 11/11/20 17:31 +, Jonathan Wakely wrote:
On 11/11/20 16:13 +, Jonathan Wakely wrote:
This makes it possible to use std::thread in single-threaded builds.
All member functions are available, but attempting to create a new
thread will throw an exception.
The main benefit for most targe
Hi,
cgraph_node::materialize_clone segfaulted when I tried compiling Tramp3D
with -fdump-ipa-all because there was no clone_info - IPA-CP created a
clone only for an aggregate constant, adding a note to its
transformation summary but not creating any tree_map nor
param_adjustements.
Fixed with th
> On Fri, 2020-10-23 at 21:45 +0200, Jan Hubicka wrote:
> > Hi,
> > this patch moves thunk_info out of cgraph_node into a symbol summary.
> > I also moved it to separate hearder file since cgraph.h became really
> > too
> > fat. I plan to contiue with similar breakup in order to cleanup
> > interf
> Hi,
>
> cgraph_node::materialize_clone segfaulted when I tried compiling Tramp3D
> with -fdump-ipa-all because there was no clone_info - IPA-CP created a
> clone only for an aggregate constant, adding a note to its
> transformation summary but not creating any tree_map nor
> param_adjustements.
On 04/11/20 10:55 -0800, Thomas Rodgers wrote:
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -603,13 +603,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
#if __cplusplus > 201703L
+ template
+ _GLIBCXX_ALWAYS_INLINE void
+ _M_wait(_
On 11/11/20 19:08 +0100, Jakub Jelinek via Libstdc++ wrote:
On Wed, Nov 11, 2020 at 05:24:42PM +, Jonathan Wakely wrote:
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -684,7 +684,14 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
static inline __gthread_t
__gthread_self (v
Hi,
this is updated patch. It fixes the comparsion of bitfield where I now
check that they bitsizes and bitoffsets match (and OEP_ADDRESSOF is not
used for bitfield references).
I also noticed problem with dependence clique in ao_refs_may_alias that
I copied here. Instead of base rbase should be
On Thu, Nov 12, 2020 at 2:59 PM Richard Biener
wrote:
> > > > > > > > gcc/ChangeLog:
> > > > > > > >
> > > > > > > > PR target/97194
> > > > > > > > * config/i386/i386-expand.c (ix86_expand_vector_set_var): New
> > > > > > > > function.
> > > > > > > > * config/i386/i386-protos.h (ix86_expand_vec
Hi,
On Fri, Aug 7, 2020 at 6:18 AM Richard Sandiford wrote:
>
> https://gcc.gnu.org/g:5380912a17ea09a8996720fb62b1a70c16c8f9f2
>
> commit r9-8794-g5380912a17ea09a8996720fb62b1a70c16c8f9f2
> Author: Richard Sandiford
> Date: Fri Aug 7 12:17:37 2020 +0100
could you please also apply this change
On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak wrote:
> > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use
> > > > GET_MODE_INNER
> > > > for value_mode. ".md expanders" shall support for integer constants
> > > > index mode, but
> > > > I guess they shouldn't be expanded
The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (according to find_template_parameters).
This assumption unfortunately doesn't always hold for TARGET_EXPRs,
because cp_tree_equal i
On Thu, Nov 12, 2020 at 09:15:11AM -0700, Jeff Law wrote:
> > void foo (void)
> > {
> > register float __attribute__ ((mode(SD))) r31 __asm__ ("r31");
> > register float __attribute__ ((mode(SD))) fr1 __asm__ ("fr1");
> >
> > __asm__ ("#" : "=d" (fr1));
> > r31 = fr1;
> > __asm__ ("#" : :
On Thu, Nov 12, 2020 at 7:26 PM Uros Bizjak wrote:
>
> On Thu, Nov 12, 2020 at 6:51 PM Uros Bizjak wrote:
>
> > > > > Yes, removed 'code' and value_mode by checking VECTOR_MODE_P and use
> > > > > GET_MODE_INNER
> > > > > for value_mode. ".md expanders" shall support for integer constants
> >
Hi,
could the SLS Mitigation patches be back-ported to the gcc-8 branch?
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=dc586a74922 aarch64:
Introduce SLS mitigation for RET and BR instructions
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=20da13e395b aarch64:
New Straight Line Speculation
On Thu, Nov 12, 2020 at 01:27:23PM -0500, Patrick Palka wrote:
> The atom_cache in normalize_atom relies on the assumption that two
> equivalent (templated) trees (in the sense of cp_tree_equal) must use
> the same template parameters (according to find_template_parameters).
>
> This assumption un
I'd expect these patches to include updates to the gcc.dg/format/ms_*.c
tests to reflect the changed semantics (or new tests there if some of the
changes don't result in any failures in the existing tests).
--
Joseph S. Myers
jos...@codesourcery.com
Final bits for libstdc/71579
std::common_type assertions attempt to give a proper 'required from
here' hint for user code, do not bring many changes to the
implementation and check all the template parameters for completeness.
In some cases the type could be checked for completeness more than
once
Hi!
On 2020-11-12T12:45:24+0100, Tobias Burnus wrote:
> For code like
> !$acc kernels
> ... a lot of loops and other code
> !$acc end kernels
>
> gfortran generates
>#pragma ..._kernels
> {
>... lot of code
> }
>
> As the PR shows, the location associated with the #
On Wed, 11 Nov 2020, Hongtao Liu via Gcc-patches wrote:
> + New ISA extension support for Intel AVX-VNNI was added to GCC.
More for the future (i.e., no need to change that now): I suggest
to skip "to GCC" in cases like this, since this is our context to
begin with.
Gerald
Hi,
On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> Two of the tests used the __ieee128 keyword instead of __float128. This
> patch changes those cases to use the official keyword.
What is "official" about that?
Why make this change at all? __ieee128 should work as well! D
Per our discussion on the list (plus a grammer improvement in a
section above).
One question: why are the ISA extension lists not alphabetically
sorted? Wouldn't that be beneficial for users? Easier to find
something and also easier to compare?
Gerald
---
htdocs/gcc-11/changes.html | 13 +
On Fri, 6 Nov 2020, Liu, Hongtao wrote:
> I realize you're talking about the patch for gcc-wwwdocs.
> No, I didn't send out a patch, sorry for that, will do it in further commit.
Thanks - saw that. Jeff just beat me to it. :-)
Gerald
Hi all,
This patch adds widening add and widening subtract patterns to
tree-vect-patterns.
All 3 patches together bootstrapped and regression tested on aarch64.
gcc/ChangeLog:
2020-11-12 Joel Hutton
* expr.c (expand_expr_real_2): add widen_add,widen_subtract cases
* optabs-
Hi all,
This patch adds backend patterns for vec_widen_add, vec_widen_sub on aarch64.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
* config/aarch64/aarch64-simd.md: New patterns
vec_widen_saddl_lo/hi_
F
Hi all,
This patch adds support in the aarch64 backend for the vec_widen_shift
vect-pattern and makes a minor mid-end fix to support it.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
* config/aarch64/aar
On Thu, 12 Nov 2020, Iain Sandoe wrote:
> OK for the c-family parts?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
The following patch implements asm goto with outputs. Kernel
developers several times expressed wish to have this feature. Asm
goto with outputs was implemented in LLVM recently. This new feature
was presented on 2020 linux plumbers conference
(https://linuxplumbersconf.org/event/7/contributio
Hi,
On Wed, Nov 11 2020, Richard Biener wrote:
> On Mon, 9 Nov 2020, Martin Jambor wrote:
>
>> this patch modifies the loop invariant pass so that is can operate
>> only on a single requested loop and its sub-loops and ignore the rest
>> of the function, much like it currently ignores basic blocks
Hi!
For now, task/taskloop constructs aren't handled and C/C++ array reductions
and reductions with task or inscan modifiers need further work.
Instead of calling omp_alloc/omp_free (where the former doesn't have
alignment argument and omp_aligned_alloc is 5.1 only feature), this calls
GOMP_alloc/
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up by:
if ((gimple_code (s) == GIMPLE_ASSIGN) || (gimple_code (s) ==
GIMPLE_COND))
return range_op_handler (gimple_expr_code (s),
On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via Gcc-patches
wrote:
>So I spent some time tracking down a ranger issue, and in the end, it
>boiled down to the range-op handler not being picked up properly.
>
>The handler is picked up by:
>
> if ((gimple_code (s) == GIMPLE_ASSIGN)
On 11/12/20 3:53 PM, Richard Biener wrote:
On November 12, 2020 9:43:52 PM GMT+01:00, Andrew MacLeod via Gcc-patches
wrote:
So I spent some time tracking down a ranger issue, and in the end, it
boiled down to the range-op handler not being picked up properly.
The handler is picked up by:
C2x adds the __has_c_attribute preprocessor operator, similar to C++
__has_cpp_attribute.
GCC implements __has_cpp_attribute as exactly equivalent to
__has_attribute. (The documentation says they differ regarding the
values returned for standard attributes, but that's actually only a
matter of th
Hi,
The PR notes that our inability to parse these keywords in GNU Objective-C
is one of the contributing factors to being unable to use some important
system
headers (at least, on Darwin platforms).
tested on x86_64-darwin and x86_64-linux-gnu,
OK for the C-family changes?
thanks
Iain
— com
On Thu, Oct 29, 2020 at 10:05:38PM +, Joseph Myers wrote:
> On Thu, 29 Oct 2020, Segher Boessenkool wrote:
>
> > > Doing these conversions accurately is nontrivial. Converting via strings
> > > is the simple approach (i.e. the one that moves the complexity somewhere
> > > else). There are
On Thu, Nov 12, 2020 at 01:26:32PM -0600, Segher Boessenkool wrote:
> Hi,
>
> On Thu, Oct 22, 2020 at 06:12:31PM -0400, Michael Meissner wrote:
> > Two of the tests used the __ieee128 keyword instead of __float128. This
> > patch changes those cases to use the official keyword.
>
> What is "offi
On Tue, Nov 10, 2020 at 7:33 PM Nelson Chu wrote:
> gcc/
> * configure: Regenerated.
> * configure.ac: If ifunc was supported in the binutils for
> linux toolchain, then set enable_gnu_indirect_function to yes.
>
Looks good. I committed and pushed it.
I see some
On Mon, Nov 9, 2020 at 11:15 PM Monk Chiang wrote:
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 172c7ca7c98..3bd1993c4c9 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -342,9 +342,13 @@ extern const char *riscv_default_mtune (int argc,
On 11/12/20 1:27 PM, Patrick Palka wrote:
The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (according to find_template_parameters).
This assumption unfortunately doesn't always ho
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 8948a5715b00fe36d20c03b6c4c4397b74cc6282.
gcc/jit/ChangeLog:
* libgccjit.h: Fix typo in comment.
---
gcc/jit/libgccjit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/jit/libgccjit
This patch fixes a bug in recording::string::make_debug_string in which
'\t' and '\n' were "escaped" by simply prepending a '\', thus emitting
'\' then '\n', rather than '\' then 'n'. It also removes a hack that
determined if a string is to be escaped by checking for a leading '"',
by instead addi
This patch adds various entrypoints to libgccjit for directly embedding
asm statements into a compile, analogous to inline asm in the C frontend:
gcc_jit_block_add_extended_asm
gcc_jit_block_end_with_extended_asm_goto
gcc_jit_extended_asm_as_object
gcc_jit_extended_asm_set_volatile_flag
g
In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
indicate that the section must be preserved by the linker.
Add SECTION_RETAIN to indicate a section should be retained by the linker
and set SECTION_RETAIN on section for the preserved symbol if assembler
supports SHF_GNU_RETAIN
On 10/11/2020 6:01 pm, Jakub Jelinek wrote:
One thing is that max-active-levels-var in 5.0 is per-device,
but in 5.1 per-data environment. The question is if we should implement
the problematic 5.0 way or the 5.1 one. E.g.:
#include
#include
int
main ()
{
#pragma omp parallel
{
om
1 - 100 of 131 matches
Mail list logo
