On Mon, May 02, 2016 at 02:16:25PM -0400, Nathan Sidwell wrote:
> While working on some more loop partitioning improvements, I noticed some
> unnecessary checking. By construction an openacc loop must have at least
> one head/tail marker, so we should assert that earlier when lowering the
> loop (
2016-05-02 Uros Bizjak
* config/i386/predicates.md (register_ssemem_operand): New predicate.
* config/i386/i386.md (*cmpi): Merge from
*cmpi_mixed and
*cmpi_i387. Disable unsupported
alternatives using "enabled" attribute. Use register_ssemem_operand
as operand 1 predi
On May 2, 2016 6:29:55 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Most of the builtins don't pass arguments in char/short types,
>except for some sync/atomic builtins, some sanitizer builtins and
>TM builtins.
>On targets where targetm.calls.promote_prototypes returns true (e.g.
>always
>on x86_64
On Mon, Apr 25, 2016 at 11:47 AM, Bernd Schmidt wrote:
Here is a patch to correct the -fabi-version docs on the GCC 5 branch.
>>> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00480.html
ping^3
I put an explanation of the patch history for gcc-5 in the PR
https://gcc.gnu.org/bugzilla/sh
On Sat, Apr 30, 2016 at 2:28 PM, Patrick Palka wrote:
> `On Fri, Apr 29, 2016 at 3:15 PM, Jeff Law wrote:
>> On 04/19/2016 11:50 AM, Patrick Palka wrote:
>>
>>> 1. This patch introduces a "regression" in gcc.dg/tree-ssa/ssa-thread-11.c
>>> in that we no longer perform FSM threading during vrp2 bu
2016-04-26 10:41 GMT-03:00 Andres Tiraboschi
:
> Hi, thanks for answering,
>
> 2016-04-25 16:21 GMT-03:00 Jason Merrill :
>> Let's create a constexpr.h rather than expose constexpr internals to all of
>> the front end. Really, I'd prefer to avoid exposing them at all. Why does
>> what you want to
On 04/22/2016 12:21 PM, Bernd Schmidt wrote:
> (Apologies if you get this twice, the mailing list didn't like the
> html attachment in the first attempt).
>
> We frequently get malformatted patches, and it's been brought to my
> attention that some people don't even make the effort to read the GNU
On 05/02/2016 02:40 PM, Carlos O'Donell wrote:
However, in the end, I think that yet-another-document is not the
solution we want. What we actually need is a program that just formats
your source according to the GNU Coding Style and that way you can always
tell your users "Run indent" and be do
On Mon, May 2, 2016 at 6:36 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch adds pattern recognition (see attached testcase on what it e.g.
> can handle) of the i?86/x86_64 lock; bt[src] operations.
> It is too late to do this during or after RTL expansion, so it is done late
> during gimple, by rec
On Mon, May 02, 2016 at 12:54:43PM +0200, Bernd Schmidt wrote:
> On 04/30/2016 06:00 PM, Segher Boessenkool wrote:
> >On Fri, Apr 29, 2016 at 04:51:27PM -0400, Michael Meissner wrote:
> >>2016-04-29 Michael Meissner
> >>
> >>* config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
>
Since x86 psABIs require the function incoming stack must align at 16
bytes, child process stack passed to clone should be aligned at 16
bytes.
Tested on Linux/x86-64. OK for trunk?
H.J.
PR testsuite/70520
* c-c++-common/asan/clone-test-1.c (main): Align child process
st
Hi Michael,
Thanks for letting us know.
Right now, the Fortran front-end uses the following real modes:
- those corresponding to {float,double,long_double}_type_node
- TFmode (if libquadmath support is enabled)
and then uses the corresponding complex modes.
So, I guess the question in your c
On Mon, 2016-05-02 at 16:13 +0200, Bernd Schmidt wrote:
> On 05/02/2016 03:43 PM, Bernd Edlinger wrote:
> > Yes, you are right. Only the original use-case seems to be
> > sh-superh-elf specific. But there are also spec strings
> > that are always available. I think adding -DFOO to
> > "cpp_uniqu
On Mon, May 02, 2016 at 11:01:02PM +0200, Uros Bizjak wrote:
> > +(define_expand "atomic_bit_test_and_set"
> > + [(match_operand:SWI248 0 "register_operand")
> > + (match_operand:SWI248 1 "memory_operand")
> > + (match_operand:SWI248 2 "nonmemory_operand")
> > + (match_operand:SI 3 "const_in
On Mon, May 02, 2016 at 02:11:49PM -0700, H.J. Lu wrote:
> Since x86 psABIs require the function incoming stack must align at 16
> bytes, child process stack passed to clone should be aligned at 16
> bytes.
>
> Tested on Linux/x86-64. OK for trunk?
>
>
> H.J.
> PR testsuite/70520
>
On Mon, May 02, 2016 at 11:24:25PM +0200, FX wrote:
> Hi Michael,
>
> Thanks for letting us know.
>
> Right now, the Fortran front-end uses the following real modes:
> - those corresponding to {float,double,long_double}_type_node
> - TFmode (if libquadmath support is enabled)
> and then uses
On Tue, 26 Apr 2016, Jeff Law wrote:
> > So offhand I think you need an RTL instruction splitter to express this,
> > and then avoid fetching 64 bits worth of data from memory -- for the sake
> > of matching the indexed addressing mode -- where you only need 32 bits.
> > At the hardware instructio
The bootstrap and make check succeeded without problems.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
On 05/02/2016 11:10 PM, Michael Meissner wrote:
So I would like to commit the following changes (assuming they bootstrap and
have no regressions) instead. Are these patches ok for the trunk, and
eventually the gcc 6.2 branch if they don't break other back ends?
Ok for the non-rs6000 changes.
On 02.05.2016 23:28, Oleg Endo wrote:
> On Mon, 2016-05-02 at 16:13 +0200, Bernd Schmidt wrote:
>> On 05/02/2016 03:43 PM, Bernd Edlinger wrote:
>>> Yes, you are right. Only the original use-case seems to be
>>> sh-superh-elf specific. But there are also spec strings
>>> that are always available
Oleg Endo wrote:
> On Mon, 2016-05-02 at 16:13 +0200, Bernd Schmidt wrote:
>> On 05/02/2016 03:43 PM, Bernd Edlinger wrote:
>> > Yes, you are right. Only the original use-case seems to be
>> > sh-superh-elf specific. But there are also spec strings
>> > that are always available. I think adding
Bernd Edlinger wrote:
> No, I actually fixed it, thanks. That test was done without my patch:
>
> > LAST_UPDATED: Sun May 1 13:46:11 UTC 2016 (revision 235692)
>
> svn log -r235762
>
> r235762 | edlinger | 2016-05-02 16:
This patch
1. changes the need_assert_for bitmap into an sbitmap since its size is
known to be at most num_ssa_names
2. changes a use of FOR_EACH_IMM_USE_STMT to a use of
FOR_EACH_IMM_USE_FAST since the uses are only being read, not modified
Does this look OK to commit after bootstrap and regtest
On Mon, May 2, 2016 at 3:20 PM, Bernd Schmidt wrote:
> On 05/02/2016 01:57 PM, Uros Bizjak wrote:
>
>> With the referred testcase, the compare-debug failure trips on (debug_insn
>> 101)
>
>
> Ok, INDEX_REG_CLASS is NO_REGS on alpha, and apparently the contents of the
> MEM isn't a valid address.
>
This patch introduced
/home/marek/src/gcc/gcc/c-family/c-common.h:1270:58: warning: comma at end of
enumerator list [-Wpedantic]
C_ORT_OMP_DECLARE_SIMD = C_ORT_OMP | C_ORT_DECLARE_SIMD,
^
I'm fixing that with
2016-05-03 Marek Polacek
This removes the duplication. I also removed the case (A&B)&(A&C) which is
handled by reassoc. And I need 2 NOP checks, for the case where @0 is a
constant (that couldn't happen before my patch because canonicalization
would put the constant as second operand).
Bootstrap+regtest on powerpc64le
Hi,
The attached patch cleans up the SH div and mul patterns a bit. Almost
no changes in CSiBE, except for a few minor improvements.
Tested on sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r235803.
Chee
101 - 127 of 127 matches
Mail list logo
