Simple peephole rules which combines multiple ld/st instructions into
64-bit load/store instructions. It only works for architectures which
are having double load/store option on.
gcc/
Claudiu Zissulescu
* config/arc/arc-protos.h (gen_operands_ldd_std): Add.
*
Hi Andrew,
Please find a number of patches that are adding more features to arc backend
(BI/BIH instructions, peephole rules, enter/leave instructions) or fixes
exising issues (store hazards, tls implementation, library calls).
Please let me know if you have any question,
Claudiu
Claudiu
Replace all custom "library" calls with compiler known patterns.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.md (mulsi3): Remove call to mulsi_600_lib.
(mulsi3_600_lib): Remove pattern.
(umulsi3_highpart_600_lib_le): Likewise.
(umulsi3_highpart): Remove
On Fri, Oct 05, 2018 at 06:49:58PM +0200, Uros Bizjak wrote:
> This constraint is used in move patterns which do not depend on TARGET_SSE.
>
> Also, rename "vector_move_operand" to "nonimm_or_0_operand".
>
> 2018-10-05 Uros Bizjak
>
> * config/i386/constraints.md ("C"): Do not depend on
Handle store cacheline hazard for A700 cpus by inserting two NOP_S
between ST ST LD or their logical equivalent (like ST ST NOP_S NOP_S
J_L.D LD)
gcc/
2016-08-01 Claudiu Zissulescu
* config/arc/arc-arch.h (ARC_TUNE_ARC7XX): New tune value.
* config/arc/arc.c (arc_active_insn):
Use BI/BIH instruction to implement casesi pattern. Only ARC V2.
gcc/
2018-03-21 Claudiu Zissulescu
* config/arc/arc.c (arc_override_options): Remove
TARGET_COMPACT_CASESI.
* config/arc/arc.h (ASM_OUTPUT_ADDR_DIFF_ELT): Update.
(CASE_VECTOR_MODE): Likewise.
Cleanup TLS implementation and add a number of tests.
gcc/
2018-07-25 Claudiu Zissulescu
* config/arc/arc.c (arc_get_tp): Remove function.
(arc_emit_call_tls_get_addr): Likewise.
(arc_call_tls_get_addr): New function.
(arc_legitimize_tls_address): Make use of
Reimplement how prologue and epilogue is emitted to accomodate
enter/leave instructions, as well as improving the size of the
existing techinques.
The following modifications are added:
- millicode thunk calls can be now selected regardless of the
optimization level. However they are enabled
Hi!
typeid of an expression that is a bitfield right now returns various weird
results, depending on what exact type ignoring precision we choose for the
bitfield. Haven't found exact wording in the standard that would back this
out though. clang++ agrees with the patched g++ though.
On Wed, Oct 10, 2018 at 11:09 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase shows that we incorrectly handle __builtin_ia32_rdpmc
> as a const function, so we e.g. CSE it. The problem is that all bdesc_args
> functions are registered using def_builtin_const. The patch fixes this by
On Wed, Oct 10, 2018 at 10:48 AM Jakub Jelinek wrote:
>
> On Fri, Oct 05, 2018 at 06:49:58PM +0200, Uros Bizjak wrote:
> > This constraint is used in move patterns which do not depend on TARGET_SSE.
> >
> > Also, rename "vector_move_operand" to "nonimm_or_0_operand".
> >
> > 2018-10-05 Uros
On Fri, Oct 05, 2018 at 01:48:24PM +0100, Richard Sandiford wrote:
> We've traditionally allowed vectors of enums (not sure if that's
> deliberate) but vector_types_compatible_elements_p checked for
> INTEGER_TYPE rather than INTEGRAL_TYPE_P.
>
> Tested on aarch64-linux-gnu. OK to install?
>
>
Hi!
The following testcase shows that we incorrectly handle __builtin_ia32_rdpmc
as a const function, so we e.g. CSE it. The problem is that all bdesc_args
functions are registered using def_builtin_const. The patch fixes this by
moving it to the bdesc_special_args category, which is registered
On Tue, Oct 9, 2018 at 6:23 PM Aldy Hernandez wrote:
>
> I'm assuming the silence on the RFC means nobody is viscerally opposed
> to it, so here goes the actual implementation ;-).
>
> FWI: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00157.html
>
> My aim is no change to the current
On 10/9/18 10:34 PM, Martin Jambor wrote:
> On Tue, Oct 09 2018, Martin Liška wrote:
>> Hi.
>>
>> Utilizing rtags' --find-dead-functions I'm suggesting a removal of part
>> of the functions reported with the script. I built all cross compilers
>> defined in contrib/config-list.mk and I fixed VMS
Existing splitter is not able to split const_vector 0 as
general_operand predicate matches only scalar zeros.
2018-10-10 Uros Bizjak
PR target/87573
* config/i386/mmx.md (const_vector 0 -> mem splitter): New splitter.
testsuite/ChangeLog:
2018-10-10 Uros Bizjak
PR
On 10/4/18 3:37 PM, Hrishikesh Kulkarni wrote:
> Hi,
>
> Please find the patch for LTO dump tool attached herewith.
>
> Regards,
>
> Hrishikesh
>
Hello.
Thank you for working on that as GSoC student and I hope we can get the patch
into GCC 9.1 release. However I have first bunch of comments
Ping.
On Wed, Oct 03, 2018 at 07:11:37PM -0400, Marek Polacek wrote:
> On Wed, Oct 03, 2018 at 10:24:52AM -0400, Jason Merrill wrote:
> > On Tue, Oct 2, 2018 at 5:25 PM Marek Polacek wrote:
> > >
> > > On Mon, Oct 01, 2018 at 07:47:10PM -0400, Jason Merrill wrote:
> > > > On Mon, Oct 1, 2018 at
> Looking at the .rodata.str1.4 section, I see
>
> $ objdump -s -j .rodata.str1.8 allocatable_function_5.exe
>
> allocatable_function_5.exe: file format elf32-sparc-sol2
>
> Contents of section .rodata.str1.8:
> 10ba8 6d666f6f 2063616c 6c696e67 2000 mfoo calling ...
> 10bb8 666f6f00
Hi Eric,
>> Which version exactly (pkg list entire) of Solaris 11 are you running?
>> I'm using gas 2.31 and /bin/ld on Solaris 11.4 resp. 11.5 Beta, where
>> Bernd's patch in PR bootstrap/87551 fixed the remaining regressions.
>
> Solaris 11.3 with Gas 2.30.
I could now reproduce the
On Wed, 10 Oct 2018 at 14:35, Martin Jambor wrote:
>
> Hi,
>
> On Wed, Oct 10 2018, Christophe Lyon wrote:
> > On 10/10/2018 13:17, Martin Jambor wrote:
> >> Hi,
> >>
> >> On Wed, Sep 26 2018, Joseph Myers wrote:
> >>> On Wed, 26 Sep 2018, Martin Jambor wrote:
> >>>
> I see, I guess the
On Tue, Oct 9, 2018 at 1:19 PM David Malcolm wrote:
> + if (!DECL_P (decl)
> + && decl == error_mark_node)
You don't need to check DECL_P here.
Jason
On 10/06/2018 04:13 PM, David Edelsohn wrote:
On Fri, Oct 5, 2018 at 5:47 PM Martin Sebor wrote:
David,
Attached is a patch to conditionalize the memchr-1.c test
to pass even with 2-byte wchar_t's. It also adds a compile
only test to verify memchr with -fnarrow-wchar. I verified
the
Hi,
On Wed, Oct 10 2018, Christophe Lyon wrote:
> On 10/10/2018 13:17, Martin Jambor wrote:
>> Hi,
>>
>> On Wed, Sep 26 2018, Joseph Myers wrote:
>>> On Wed, 26 Sep 2018, Martin Jambor wrote:
>>>
I see, I guess the easiest is to skip the test on targets that do not
really have long
Hi Eric,
>> This isn't necessary on Solaris 11.4, and Solaris 11.3/x86 isn't
>> affected as well. I'm still determining what the best course of action
>> is: disable string merging support before Solaris 11.4 or enable the
>> workaround above instead.
>
> Out of curiosity, why isn't it necessary
Hi,
Some additional testcases to exercise the vec_mergee and
vec_mergeo intrinsics.
Tested across assorted power linux platforms. OK for trunk?
Thanks
-Will
[testsuite]
2018-10-10 Will Schmidt
* gcc.target/powerpc/fold-vec-mergeeo-floatdouble.c: New.
*
Hi,
Add testcase coverage for the vec_sel builtins.
Tested across assorted Linux platforms.
OK for trunk?
Thanks,
-Will
[testsuite]
2018-10-10 Will Schmidt
* gcc.target/powerpc/fold-vec-select-char.c: New.
* gcc.target/powerpc/fold-vec-select-double.c: New.
Hi!
On Wed, Oct 10, 2018 at 10:14:21AM -0500, Will Schmidt wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-select-double.c
> @@ -0,0 +1,22 @@
> +/* Verify that overloaded built-ins for vec_sel with
> + double inputs for VSX produce the right code. */
> +
> +/* { dg-do
Hi!
On Wed, Oct 10, 2018 at 10:14:31AM -0500, Will Schmidt wrote:
> Add some testcases for verification of vec_insert() codegen.
> The char,float,int,short tests are broken out into -p8 and -p9
> variants due to codegen variations between the platforms.
>
> Tested across assorted power linux
On Wed, 2018-10-10 at 12:33 -0500, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Oct 10, 2018 at 10:14:31AM -0500, Will Schmidt wrote:
> > Add some testcases for verification of vec_insert() codegen.
> > The char,float,int,short tests are broken out into -p8 and -p9
> > variants due to codegen
On 10/10/18 6:35 AM, Martin Jambor wrote:
> Hi,
>
> On Wed, Oct 10 2018, Christophe Lyon wrote:
>> On 10/10/2018 13:17, Martin Jambor wrote:
>>> Hi,
>>>
>>> On Wed, Sep 26 2018, Joseph Myers wrote:
On Wed, 26 Sep 2018, Martin Jambor wrote:
> I see, I guess the easiest is to skip the
In this testcase, the call to f() can never be a constant expression, but
that's not a problem because it is never reached. We handle a similar scenario
for IF_STMT, so we can just do the same. The RANGE_FOR_STMT case seems to
never be reached in the whole testsuite, so I didn't change that.
Hi!
On Wed, Oct 10, 2018 at 10:14:01AM -0500, Will Schmidt wrote:
> 2018-10-09 Will Schmidt
>
> * config/rs6000/rs6000.c: (fold_mergeeo_helper): New helper function.
* config/rs6000/rs6000.c (fold_mergeeo_helper): New helper function.
(i.e. no colon there)
>gimple *g =
On 10/10/2018 13:17, Martin Jambor wrote:
Hi,
On Wed, Sep 26 2018, Joseph Myers wrote:
On Wed, 26 Sep 2018, Martin Jambor wrote:
I see, I guess the easiest is to skip the test on targets that do not
really have long double, although if someone thinks that is too
restrictive, I can also split
On Wed, Oct 03, 2018 at 06:05:43PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 03, 2018 at 11:56:15AM -0400, Jason Merrill wrote:
> > --- a/gcc/c-family/c-lex.c
> > +++ b/gcc/c-family/c-lex.c
> > @@ -356,6 +356,8 @@ c_common_has_attribute (cpp_reader *pfile)
> >|| is_attribute_p
Hi,
Testcase coverage for the vec_extract builtins.
Due to codegen differences between (p7,p8,p9) targets, these
have been split into bits and pieces as seen.
Tested across assorted power linux platforms. OK for trunk?
Thanks,
-Will
[testsuite]
2018-10-09 Will Schmidt
*
Hi,
Add some testcases for verification of vec_insert() codegen.
The char,float,int,short tests are broken out into -p8 and -p9
variants due to codegen variations between the platforms.
Tested across assorted power linux platforms. OK for trunk?
Thanks
-Will
[testsuite]
2018-10-10
Hi,
Add support for early gimple folding of the vec_mergee() and vec_mergeo()
intrinsics.
Testcases posted separately.
Tested across assorted power linux platforms.
OK for trunk?
Thanks,
-Will
[gcc]
2018-10-09 Will Schmidt
* config/rs6000/rs6000.c: (fold_mergeeo_helper): New
Hi Will,
On Wed, Oct 10, 2018 at 10:13:48AM -0500, Will Schmidt wrote:
> Some additional testcases to exercise the vec_mergee and
> vec_mergeo intrinsics.
>
> Tested across assorted power linux platforms. OK for trunk?
Sure, that looks fine, okay for trunk. Thanks! One little thing:
> +/* {
Hi,
as my last message
(https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00280.html) did not
garner much attention, I'm posting it in proper patch form this time.
The problem I'm trying to solve is that an insn's priority seems
unchanged if the priority of insns that depend on it is changed (and the
On 10/9/18 6:45 AM, Bernd Edlinger wrote:
> On 10/03/18 18:31, Jeff Law wrote:
>>> - && (len = int_size_in_bytes (TREE_TYPE (decl))) > 0
>>> - && TREE_STRING_LENGTH (decl) >= len)
>>> + && (len = int_size_in_bytes (TREE_TYPE (decl))) >= 0
>>> + && TREE_STRING_LENGTH (decl) ==
On 10/5/18 6:09 AM, Giuliano Augusto Faulin Belinassi wrote:
> Thank you for the review. I will address all these issues :-).
>
>> Imagine a pause here while I lookup isolation of radicals It's been
>> a long time... OK. Sure. I see what you're doing here...
>
> Sorry, but I really did
The C++17 standard requires the default implementation for
allocator_traits::max_size to return SIZE_MAX / sizeof(value_type).
That causes GCC to warn because the value could be larger than can
sensibly be passed to malloc. This patch changes the new_allocator and
malloc_allocator max_size()
Hi,
On Wed, Oct 10 2018, Martin Liška wrote:
> On 10/9/18 10:34 PM, Martin Jambor wrote:
>> On Tue, Oct 09 2018, Martin Liška wrote:
>>> * ipa-cp.c (ipcp_vr_lattice::meet_with): Likewise.
>>
>> Interesting, I believe that a class representing a lattice should have a
>> meet function with its
Hi!
This patch adds testcases to cover the case when C/C++ array task reductions
are used with VLAs, either whole VLAs or array sections from them.
Tested on x86_64-linux, committed to gomp-5_0-branch.
2018-10-10 Jakub Jelinek
* omp-low.c (lower_rec_input_clauses): Handle VLAs
Hi,
On Wed, Sep 26 2018, Joseph Myers wrote:
> On Wed, 26 Sep 2018, Martin Jambor wrote:
>
>> I see, I guess the easiest is to skip the test on targets that do not
>> really have long double, although if someone thinks that is too
>> restrictive, I can also split the test again and move long
On Mon, Oct 08, 2018 at 03:36:18PM +0200, Andreas Schwab wrote:
> This still doesn't fix the tests.
Sure, one needs to add the constexpr virtual calls for ia64 as I said in the
mail.
Jakub
Hi.
I'm sending updated version of the patch. I made a research and it looks that
actually any significant consumer of GCOV does not use intermediate format:
https://github.com/gcovr/gcovr/issues/282
https://github.com/linux-test-project/lcov/issues/43
https://github.com/mozilla/grcov/issues/55
On 10/4/18 9:54 AM, Robin Dapp wrote:
> Hi,
>
> I'm working on some insn latency changes in the s390 backend and noticed
> a regression in the SPEC2006 bzip2 test case that was due to some insns
> being scheduled differently.
>
> The sequence in short form before my change is
>
> ;; | insn
On 10/8/18 8:22 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01528.html
>
> I will go ahead and commit this as obvious this week if there
> are no objections.
Go ahead.
Jeff
On Wed, Oct 10, 2018 at 01:24:52PM -0500, Will Schmidt wrote:
> > For all the scan-assembler tests, did you verify these are exactly the
> > instructions we want generated?
>
> "want" may be a bit strong, but I do verified that is what we get now.
The difference is if the testcases start failing
On 10/2/18 10:37 AM, Martin Sebor wrote:
> [2/4] - Relax strlen range optimization to avoid making assumptions
> about types
>
> This main part of this patch is to relax the strlen range
> optimization to avoid relying on array types. Instead, the function
> either removes the upper
Hello,
The aarch64 "platform register" r18 is currently
unconditionally used as a scratch register by gcc.
Working on a VxWorks port for this arch (that we
plan to contribute soon), we discovered that VxWorks
has an internal use of this register so it needs
to be considered "fixed" for this
Same patch as for std::list iterators. I only additionally move doc on
those operators.
I also avoid redefining some typedef that are already defined in
_Fwd_list_base<>.
* include/bits/forward_list.h
(_Fwd_list_iterator<>::operator==): Replace member function with inline
friend.
On Wed, Oct 10, 2018 at 11:58 AM Marek Polacek wrote:
>
> In this testcase, the call to f() can never be a constant expression, but
> that's not a problem because it is never reached. We handle a similar
> scenario
> for IF_STMT, so we can just do the same. The RANGE_FOR_STMT case seems to
>
On Wed, Oct 10, 2018 at 03:48:34PM -0400, Jason Merrill wrote:
> On Wed, Oct 10, 2018 at 11:58 AM Marek Polacek wrote:
> >
> > In this testcase, the call to f() can never be a constant expression, but
> > that's not a problem because it is never reached. We handle a similar
> > scenario
> > for
On 10/2/18 10:37 AM, Martin Sebor wrote:
> [1/4] - Introduce struct strlen_data_t into gimple-fold
>
> This patch introduces a new data structure to reduce the number
> of arguments and overloads of the get_range_strlen API. One of
> the goals of this change is to make the API safer to use for
>
Ping...
On 08/26/18 21:40, Bernd Edlinger wrote:
> Ping...
>
> This is just plain wrong, independent
> of any STRING_CST semantic issues.
>
> The original patch (retested on current trunk) is
> here: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00370.html
>
>
> On 08/05/18 18:59, Bernd
On Tue, 2018-10-09 at 18:38 -0400, Jason Merrill wrote:
> On Tue, Oct 9, 2018 at 1:19 PM David Malcolm
> wrote:
> > + /* Emulation of a "move" constructor, but really a copy
> > + constructor. */
> > +
> > + name_hint (const name_hint )
> > + : m_suggestion (other.m_suggestion),
> > +
Hi!
On Wed, Oct 10, 2018 at 10:14:42AM -0500, Will Schmidt wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
> @@ -0,0 +1,60 @@
> +/* Verify that overloaded built-ins for vec_extract() with char
> + inputs produce the right code with a power7 (BE)
On 10/5/18 4:56 PM, Martin Sebor wrote:
> While working on tests for an enhancement in the area of
> attributes I noticed that the handler for attribute assume_aligned
> (among others) does only a superficial job of detecting meaningless
> specifications such as using the attribute on a function
> LGTM otherwise, but I'll leave the AArch64 maintainers to do the
> main review.
>
> Thanks,
> Richard
Here is an updated version that addresses the issues you raised. The
only thing I did not try to do is to
change aarch64_use_simple_return_insn_p, so shrink wrapping of SIMD
functions will
On 10/10/18 10:03 AM, Robin Dapp wrote:
> Hi,
>
> as my last message
> (https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00280.html) did not
> garner much attention, I'm posting it in proper patch form this time.
> The problem I'm trying to solve is that an insn's priority seems
> unchanged if the
On 10/2/18 10:37 AM, Martin Sebor wrote:
> [4/4] - Replace uses of old get_range_strlen with the new one.
>
> This change switches the remaining get_range_strlen() callers
> to use the new overload of the function that takes a strlen_data_t
> argument. There are no functional changes here.
>
>
OK, thanks.
On Wed, Oct 10, 2018 at 10:02 AM Jakub Jelinek wrote:
>
> On Wed, Oct 03, 2018 at 06:05:43PM +0200, Jakub Jelinek wrote:
> > On Wed, Oct 03, 2018 at 11:56:15AM -0400, Jason Merrill wrote:
> > > --- a/gcc/c-family/c-lex.c
> > > +++ b/gcc/c-family/c-lex.c
> > > @@ -356,6 +356,8 @@
It turns out that, even if cgraph_node::expand_thunk happily overrides the
DECL_IGNORED_P setting on the thunk from the front-end, this is necessary when
the thunk is initially a back-end thunk and then turned into a GIMPLE thunk,
e.g. because of inlining, to play nice with early debug info
On 10/2/18 10:37 AM, Martin Sebor wrote:
> [3/4] - Change sprintf to use new get_range_strlen overload
>
> This change makes use of the new get_range_strlen() overload
> in gimple-ssa-sprintf.c. This necessitated a few changes to
> the API but also enabled the removal of the flexarray member
>
On 9/15/18 2:43 AM, Bernd Edlinger wrote:
> Hi,
>
> this is an update on my strlen range patch (V7). Again re-based and
> retested to current trunk.
>
> I am aware that Martin wants to re-factor the interface of get_range_strlen
> and have no objections against, but I'd suggest that to be a
This seems to have caused errors in the testsuite. I guess that the
problem is that the testcases are invalid :-(
>From David Edelsohn:
Error: Substring reference of nonscalar not permitted at (1)
arrayio_11.f90
arrayio_12.f90
associate_23.f90
data_char_1.f90
deferred_character_2.f90
On 10/10/2018 04:58 AM, Alexandre Oliva wrote:
> On Oct 10, 2018, JonY <10wa...@gmail.com> wrote:
>
>> On 10/10/2018 03:24 AM, Alexandre Oliva wrote:
>>> On Oct 9, 2018, JonY <10wa...@gmail.com> wrote:
>
>>> Now, if you wish it to affect Cygwin as well, I could implement that,
>>> and drop
OK.
On Wed, Oct 10, 2018 at 5:17 AM Jakub Jelinek wrote:
>
> Hi!
>
> typeid of an expression that is a bitfield right now returns various weird
> results, depending on what exact type ignoring precision we choose for the
> bitfield. Haven't found exact wording in the standard that would back
On 10/8/18 9:52 AM, Jeff Law wrote:
> My tester is showing a variety of problems as well. hppa, sh4, aarch64,
> aarch64_be, alpha arm* and s390x bootstraps are all failing at various
> points. Others may trickle in over time, but clearly something went
> wrong recently. I'm going to start
While writing tests for fixes and enhancements for attribute
handling I keep finding myself coming up with the same boiler-
plate code to verify whether an attribute has or has not been
successfully applied. It's often error-prone because it
depends on the subtle and unique effects each
On 10/10/2018 03:18 PM, Jeff Law wrote:
On 10/2/18 10:37 AM, Martin Sebor wrote:
[2/4] - Relax strlen range optimization to avoid making assumptions
about types
This main part of this patch is to relax the strlen range
optimization to avoid relying on array types. Instead, the
On Wed, Oct 10, 2018 at 7:37 PM JonY <10wa...@gmail.com> wrote:
>
> On 10/10/2018 04:58 AM, Alexandre Oliva wrote:
> > On Oct 10, 2018, JonY <10wa...@gmail.com> wrote:
> >
> >> On 10/10/2018 03:24 AM, Alexandre Oliva wrote:
> >>> On Oct 9, 2018, JonY <10wa...@gmail.com> wrote:
> >
> >>> Now, if
75 matches
Mail list logo
