On Fri, May 13, 2016 at 07:25:43PM -0400, Michael Meissner wrote:
> This patch adds support for the 32-bit word splat instructions, the byte
> immediate splat instructions, and the vector sign extend instructions to GCC
> 7.0.
>
> In addition to the various splat instructions, since I was modifyin
This patch adds support for the 32-bit word splat instructions, the byte
immediate splat instructions, and the vector sign extend instructions to GCC
7.0.
In addition to the various splat instructions, since I was modifying the vector
moves, I took the opportunity to reorganize the vector move ins
If the compiled program does a shift by a negative amount, combine will
happily work with that, but it shouldn't then do an undefined operation
in GCC itself. This patch fixes the first case mentioned in the bug
report (I haven't been able to reproduce the second case, on trunk at
least).
Bootstr
The resolution of C11 DR#423, apart from doing things with the types
of expressions cast to qualified types which are only in standard
terms observable with _Generic and which agree with how GCC has
implemented _Generic all along, also specifies that qualifiers are
discarded from function return ty
On Wed, May 11, 2016 at 04:05:46PM -0600, Kelvin Nilsen wrote:
> I have bootstrapped and tested this patch against the trunk and against
> the gcc-6-branch on both powerpc64le-unknown-linux-gnu and
> powerpc64-unknown-linux-gnu with no regressions. Is this ok for trunk
> and for backporting to GCC
On 05/11/2016 09:59 AM, Ilya Verbin wrote:
On Wed, May 11, 2016 at 10:47:49 +0100, Ramana Radhakrishnan wrote:
I've looked at the generated code in more details, and for armv6 this generates
mcr p15, 0, r0, c7, c10, 5
which is not what __cilkrts_fence uses currently (CP15DSB vs CP15DMB)
This patch by Chris Manghane implements the escape analysis discovery
phase in the Go frontend. Escape analysis is still not turned on.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Fri, 13 May 2016, Bernd Schmidt wrote:
> Thanks. So, this would seem to suggest that BITS_PER_UNIT in memcmp/memcpy
> expansion is more accurate than a plain 8, although pedantically we might want
> to use CHAR_TYPE_SIZE? Should I adjust my patch to use the latter or leave
> these parts as-is?
On Fri, 2016-05-06 at 12:40 -0400, David Malcolm wrote:
> Mark most virtual functions in gcc/jit as being FINAL OVERRIDE.
> gcc::jit::recording::lvalue::access_as_rvalue is the sole OVERRIDE
> that isn't a FINAL.
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
>
> I can self-approve
On May 13, 2016, at 11:50 AM, Jakub Sejdak wrote:
>
> OK I understand. So am I right, that in such a case there is no way to
> introduce new OS targets to branch 4.9 and 5?
No. You just hand edit in the bits you need for your port, and seek approval
for that.
In general, all new work goes int
On Fri, May 13, 2016 at 12:58 PM, Richard Biener
wrote:
> On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
> wrote:
>>The cse_sincos pass tries to optimize sequences such as
>>
>> sin (x);
>> cos (x);
>>
>>into a single call to sincos, or cexpi, when available. However, the
>>nvptx targ
On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
wrote:
>The cse_sincos pass tries to optimize sequences such as
>
> sin (x);
> cos (x);
>
>into a single call to sincos, or cexpi, when available. However, the
>nvptx target has sin and cos instructions, albeit with some loss of
>precision
On May 13, 2016 7:22:37 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Since a recent change, TYPE_ALIAS_SET of types can change during
>folding.
>This patch arranges for it not to be checksummed.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux (normal
>bootstrap)
>and built (nonbootstrap) +
The cse_sincos pass tries to optimize sequences such as
sin (x);
cos (x);
into a single call to sincos, or cexpi, when available. However, the
nvptx target has sin and cos instructions, albeit with some loss of
precision (so it's only enabled with -ffast-math). This patch teaches
cse_sincos p
On 02/16/2016 07:49 PM, Jason Merrill wrote:
Clearly the DR 141 change is requiring much larger adjustments in the
rest of the compiler than I'm comfortable making at this point in the
GCC 6 schedule, so I'm backing out my earlier changes for 10200 and
69753 and replacing them with a more modest
Hello,
maybe this would fit better in VRP, but it is easier (and not completely
useless) to put it in match.pd.
Since the transformation is restricted to GIMPLE, I think I don't need to
check that @0 is SSA_NAME. I didn't test if @0 has pointer type before
calling get_range_info because we a
OK I understand. So am I right, that in such a case there is no way to
introduce new OS targets to branch 4.9 and 5?
What about 6 branch and trunk?
On the other hand: this is my first patch and I'm not quite familiar
with the procedure of applying patches to upstream. Who should upload
my patch, w
Hello,
when VRP does some transforms, it may create new SSA_NAMEs, but doesn't
give them range information. This can prevent cascading transformations in
a single VRP pass. With this patch, I assign range information to the
variable introduced by one transformation, and in another transformati
On Fri, 13 May 2016, Jakub Sejdak wrote:
> Is it OK for trunk, gcc-4.9, gcc-5 and gcc-6 branches?
It's not appropriate to update these scripts from upstream on release
branches. For example, config.guess changed a while back to output
x86_64-pc-linux-gnu in place of x86_64-unknown-linux-gnu, a
On May 13, 2016 11:50:33 AM GMT+02:00, Richard Biener
wrote:
>On Fri, May 13, 2016 at 11:03 AM, Ilya Enkovich
> wrote:
>> Hi,
>>
>> This patch improves cse_cfg_altered computation by taking into
>account
>> cleanup_cfg returned values. This resolves another case of
>invalidated
>> dominance info
Also remove unneeded XOP handling.
2016-05-13 Uros Bizjak
* gcc.dg/vect/tree-vect.h (check_vect): Handle AVX2,
remove XOP handling.
Tested on x86_64-linux-gnu AVX target and committed to mainline SVN.
Patch will be backported to other release branches.
Uros.
Index: gcc.dg/vect/tree-
On Fri, May 13, 2016 at 7:11 PM, Jakub Jelinek wrote:
> Hi!
>
> I found a couple of spots where we can use the HOST_WIDE_INT_C macro.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-05-13 Jakub Jelinek
>
> * config/i386/i386.c (ix86_compute_frame_layout
On Fri, May 13, 2016 at 7:20 PM, H.J. Lu wrote:
> On Fri, May 13, 2016 at 9:51 AM, Uros Bizjak wrote:
>> On Fri, May 13, 2016 at 9:07 AM, Uros Bizjak wrote:
>>> On Fri, May 13, 2016 at 1:20 AM, H.J. Lu wrote:
>>>
>> testsuite/gcc.target/i386/pr61599-{1,2}.c testcases expose a failure
>>
Hi!
Since a recent change, TYPE_ALIAS_SET of types can change during folding.
This patch arranges for it not to be checksummed.
Bootstrapped/regtested on x86_64-linux and i686-linux (normal bootstrap)
and built (nonbootstrap) + regtested the
--enable-checking=yes,extra,fold,rtl version (previousl
On Fri, May 13, 2016 at 9:51 AM, Uros Bizjak wrote:
> On Fri, May 13, 2016 at 9:07 AM, Uros Bizjak wrote:
>> On Fri, May 13, 2016 at 1:20 AM, H.J. Lu wrote:
>>
> testsuite/gcc.target/i386/pr61599-{1,2}.c testcases expose a failure
> with -mcmodel -fpic, where:
>
> /tmp/ccfpoxHY.o
Hi!
These insns are either AVX512VL or AVX512VL & BW, this patch allows using
XMM16+ where possible.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek
* config/i386/sse.md (pbroadcast_evex_isa): New mode attr.
(avx2_pbroadcast): Add
Hi!
vpalignr is AVX512BW & VL, so we shouldn't enable it just for VL.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek
* config/i386/sse.md (_palignr): Use
constraint x instead of v in second alternative, add avx512bw
alter
Hi!
vpshufb is AVX512BW & AVX512VL insn, so we shouldn't allow it for
AVX512VL only.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek
* config/i386/sse.md (_pshufb3): Use
constraint x instead of v in second alternative, add avx512b
Hi!
vpmulhrsw is AVX512BW & AVX512VL insn, so we shouldn't enable it just
when AVX512VL is on.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-05-13 Jakub Jelinek
* config/i386/sse.md (*_pmulhrsw3): Use
constraint x instead of v in seco
Hi!
This is either AVX2 or for EVEX AVX512BW (& AVX512VL) instruction,
thus the patch adds it as a separate alternative guarded with avx512bw
isa attribute.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek
* config/i386/sse.md (avx2_pmaddu
Hi!
I found a couple of spots where we can use the HOST_WIDE_INT_C macro.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek
* config/i386/i386.c (ix86_compute_frame_layout, ix86_expand_prologue,
ix86_expand_split_stack_prologue): Us
On 16-05-12 11:16:57, Bernd Schmidt wrote:
> On 05/12/2016 02:36 AM, Dhole wrote:
> >+ error_at (input_location, "environment variable SOURCE_DATE_EPOCH
> >must "
> >+"expand to a non-negative integer less than or equal to %wd",
> >+MAX_SOURCE_DATE_EPOCH);
>
> >+/* Th
On Fri, May 13, 2016 at 6:51 PM, Uros Bizjak wrote:
> On Fri, May 13, 2016 at 9:07 AM, Uros Bizjak wrote:
>> On Fri, May 13, 2016 at 1:20 AM, H.J. Lu wrote:
>>
> testsuite/gcc.target/i386/pr61599-{1,2}.c testcases expose a failure
> with -mcmodel -fpic, where:
>
> /tmp/ccfpoxHY.o
On May 13, 2016 6:02:27 PM GMT+02:00, Bin Cheng wrote:
>Hi,
>As PR69848 reported, GCC vectorizer now generates comparison outside of
>VEC_COND_EXPR for COND_REDUCTION case, as below:
>
> _20 = vect__1.6_8 != { 0, 0, 0, 0 };
> vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0, 0, 0 }, vect_c_2.7_13>;
>
On Fri, May 13, 2016 at 9:07 AM, Uros Bizjak wrote:
> On Fri, May 13, 2016 at 1:20 AM, H.J. Lu wrote:
>
testsuite/gcc.target/i386/pr61599-{1,2}.c testcases expose a failure
with -mcmodel -fpic, where:
/tmp/ccfpoxHY.o: In function `bar':
pr61599-2.c:(.text+0xe): relocation
Hello,
On Fri, 13 May 2016, Nathan Sidwell wrote:
> I've committed this cleanup to use TARGET_MANGLE_DECL_ASSEMBLER_NAME rather
> than the ad-hoc solution the ptx backend currently has. I didn't address it
> during the earlier set of cleanups as I felt there were more important things
> to addre
On May 13, 2016, at 6:53 AM, Jiong Wang wrote:
>
> This patch skip g++.dg/lto/pr69589_0.C on typical arm & aarch64
> bare-metal targets as they don't support "-rdynamic".
>
> OK for trunk?
Ok.
Hi,
As PR69848 reported, GCC vectorizer now generates comparison outside of
VEC_COND_EXPR for COND_REDUCTION case, as below:
_20 = vect__1.6_8 != { 0, 0, 0, 0 };
vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0, 0, 0 }, vect_c_2.7_13>;
_21 = VEC_COND_EXPR <_20, ivtmp_17, _19>;
This results in in
I've committed this cleanup to use TARGET_MANGLE_DECL_ASSEMBLER_NAME rather than
the ad-hoc solution the ptx backend currently has. I didn't address it during
the earlier set of cleanups as I felt there were more important things to
address then.
I did discover an issue in langhooks, where t
On Wed, May 11, 2016 at 03:23:50PM +0200, Christophe Lyon wrote:
> Hi,
>
> A few months ago, we decided it was time to remove neon-testgen.ml
> and its generated tests. I did it, just to realize too late that
> some intrinsics were not covered anymore, so I reverted the removal.
>
> This patch se
Hi Matthew,
Many thanks for reviewing this patch. Upon closer validation of the patch I
have
found this this approach will not work in all cases so unfortunately I am going
to
have to abandon it. I will be shortly posting a new patch to fix this issue in
the middle-end.
Regards,
Andrew
>
Hi,
On Fri, May 13, 2016 at 01:01:50PM +0200, Eric Botcazou wrote:
> > Hmm, the patch looks obvious if it was the intent to allow constant
> > pool replacements
> > _not_ only when the whole constant pool entry may go away. But I
> > think the intent was
> > to not do this otherwise it will gener
On Wed, May 11, 2016 at 03:24:00PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (result):
> Add poly64x1_t and poly64x2_t cases if supported.
> * gcc.target/aarch64/advsimd-intrinsics/compute-ref-data.h
>
On Wed, May 11, 2016 at 03:24:01PM +0200, Christophe Lyon wrote:
> 2016-05-04 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vreinterpret.c: Add fp16
> tests.
> * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p128.c: Likewise.
> * gcc.target/aarch64/ad
Hi,
This trivial patch adds INCOMING_FRAME_SP_OFFSET to
current_function_static_stack_size, thus fixing the 2 (or 3, for
3 byte PC devices) byte difference between reported and actual
values when using -fstack-usage.
The patch came about because of this discussion
(https://gcc.gnu.org
On Thu, May 12, 2016 at 10:54 AM, H.J. Lu wrote:
>>> Here is a patch to add
>>> -mgeneral-regs-only option to x86 backend. We can update
>>> spec for interrupt handle to recommend compiling interrupt handler
>>> with -mgeneral-regs-only option and add a note for compiler
>>> implementers.
>>>
>>
On Wed, May 11, 2016 at 03:23:59PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vrnd.c: New.
> * gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vrndX.inc: New.
> * gcc/testsuite/gcc.target/aarch64/adv
On Wed, May 11, 2016 at 03:23:58PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vstX_lane.c: Add fp16 tests.
OK.
Thanks,
James
Hi,
A small patch to correct the latency for M5100.
Ok to commit?
Regards,
Robert
2016-05-13 Matthew Fortune
* config/mips/m5100.md (m51_int_load): Update the latency to 2.
---
gcc/config/mips/m5100.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/
Hi,
The below enables LSA/DLSA instructions for -mmsa.
Ok to commit?
Regards,
Robert
* config/mips/mips.h (ISA_HAS_LSA): Enable for -mmsa.
(ISA_HAS_DLSA): Ditto.
---
gcc/config/mips/mips.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/mips
On Fri, May 13, 2016 at 04:41:33PM +0200, Christophe Lyon wrote:
> On 13 May 2016 at 16:37, James Greenhalgh wrote:
> > On Wed, May 11, 2016 at 03:23:56PM +0200, Christophe Lyon wrote:
> >> 2016-05-02 Christophe Lyon
> >>
> >> * gcc.target/aarch64/advsimd-intrinsics/vtst.c: Add tests
> >>
Self-explanatory. Tested x86_64-linux, committed to trunk.
PR libstdc++/71073
* include/debug/bitset: Add #pragma GCC system_header.
* include/debug/deque: Likewise.
* include/debug/list: Likewise.
* include/debug/map: Likewise.
* include/debug/set:
On Fri, May 13, 2016 at 7:17 AM, H.J. Lu wrote:
> On Fri, May 13, 2016 at 5:51 AM, Martin Liška wrote:
>> On 05/13/2016 02:46 PM, Richard Biener wrote:
>>> Use them for HOST_WIDE_INT printing, for [u]int64_t use the PRI stuff.
>>>
>>> Richard.
>>
>> Thanks you both, installed as r236208.
>>
>
> I
On 13 May 2016 at 16:37, James Greenhalgh wrote:
> On Wed, May 11, 2016 at 03:23:56PM +0200, Christophe Lyon wrote:
>> 2016-05-02 Christophe Lyon
>>
>> * gcc.target/aarch64/advsimd-intrinsics/vtst.c: Add tests
>> for vtst_p8 and vtstq_p8.
>
> And vtst_p16 and vtstq_p16 too please.
>
On Wed, May 11, 2016 at 03:23:57PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vget_lane.c: Add fp16 tests.
OK.
Thanks,
James
On Wed, May 11, 2016 at 03:23:56PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vtst.c: Add tests
> for vtst_p8 and vtstq_p8.
And vtst_p16 and vtstq_p16 too please.
vtst_s64
vtstq_s64
vtst_u64
vtstq_u64 are also missing (AA
On 13 May 2016 at 16:08, James Greenhalgh wrote:
> On Wed, May 11, 2016 at 03:23:54PM +0200, Christophe Lyon wrote:
>> 2016-05-02 Christophe Lyon
>>
>> * gcc.target/aarch64/advsimd-intrinsics/vsli_n.c: Add check for
>> vsliq_n_u64.
>>
>
> And vsliq_n_s64 ?
>
Damn! You are right, I missed
On Fri, May 13, 2016 at 5:51 AM, Martin Liška wrote:
> On 05/13/2016 02:46 PM, Richard Biener wrote:
>> Use them for HOST_WIDE_INT printing, for [u]int64_t use the PRI stuff.
>>
>> Richard.
>
> Thanks you both, installed as r236208.
>
It isn't fixed:
/export/gnu/import/git/sources/gcc/gcc/tree-s
On Wed, May 11, 2016 at 03:23:55PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vreinterpret.c: Add
> missing tests for vreinterpretq_p{8,16}.
OK.
Thanks,
James
On Wed, May 11, 2016 at 03:23:53PM +0200, Christophe Lyon wrote:
> It is useful to have more detailed information in the logs when checking
> validation results: instead of repeating the intrinsic name, we now print
> its return type too.
>
> 2016-05-02 Christophe Lyon
>
> * gcc.target/a
On Fri, 13 May 2016, Bernd Schmidt wrote:
> On 05/13/2016 03:07 PM, Richard Biener wrote:
> > On Fri, May 13, 2016 at 3:05 PM, Bernd Schmidt wrote:
> > > Huh? Can you elaborate?
> >
> > When you have a builtin taking a size in bytes then a byte is 8 bits,
> > not BITS_PER_UNIT bits.
>
> That ma
On Wed, May 11, 2016 at 03:23:54PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vsli_n.c: Add check for
> vsliq_n_u64.
>
And vsliq_n_s64 ?
OK with that change.
Thanks,
James
> Change-Id: I90bb2b225ffd7bfd54a0827a0264ac20271f5
For thumb mode, this is causing wrong size calculation and may affect
some rtl pass, for example bb-order where copy_bb_p needs accurate insn
length info.
This have eventually part of the reason for
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00639.html where bb-order
failed to do the bb copy.
On Wed, May 04, 2016 at 11:55:42AM +0200, Christophe Lyon wrote:
> On 4 May 2016 at 10:43, Kyrill Tkachov wrote:
> >
> > Hi Christophe,
> >
> >
> > On 02/05/16 12:50, Christophe Lyon wrote:
> >>
> >> Hi,
> >>
> >> I've noticed a "regression" of AArch64's noplt_3.c in the gcc-6-branch
> >> because
On 05/13/2016 03:53 PM, Joseph Myers wrote:
* In C: a byte is the minimal addressable unit; an N-byte object is made
up of N "unsigned char" objects, with successive addresses in terms of
incrementing an "unsigned char *" pointer. A byte is at least 8 bits.
* In GCC, at the level of GNU C APIs
On Wed, May 11, 2016 at 03:23:52PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vmul.c: Remove useless #ifdef.
> * gcc.target/aarch64/advsimd-intrinsics/vshl.c: Likewise.
> * gcc.target/aarch64/advsimd-intrinsics/vtst.c
This patch skip g++.dg/lto/pr69589_0.C on typical arm & aarch64
bare-metal targets as they don't support "-rdynamic".
spu-unknown-elf is known to be failing also, but I'd leave it to
those who are more familar with all relevant spu targets.
dg-skip-if is used instead of dg-xfail-if because the l
On Wed, May 11, 2016 at 03:23:51PM +0200, Christophe Lyon wrote:
> 2016-05-02 Christophe Lyon
>
> * gcc.target/aarch64/advsimd-intrinsics/vreinterpret.c: Fix typo in
> comment.
This one would have been OK to commit as obvious.
OK for trunk.
Thanks,
James
avr-gcc crashes for following test as it couldn't recognize the
instruction pattern.
struct st {
unsigned char uc1;
unsigned int *ui1;
};
unsigned int ui1;
struct st foo () {
struct st ret;
ret.uc1 = 6;
ret.ui1 = &ui1;
return ret;
}
$ avr-gcc -mmcu=atmega328p -O1 test.c
(-- snip --)
On Thu, Apr 28, 2016 at 03:11:59PM +0100, Matthew Wahab wrote:
> Hello,
>
> Yvan Roux pointed out that the patch at
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01713.html was never
> committed.
>
> From the original submission:
>
> The LEGITIMIZE_RELOAD_ADDRESS macro is only needed for rel
On Thu, Apr 28, 2016 at 10:20 AM, Matthew Wahab
wrote:
> Hello,
>
> The ARM target supports the half-precision floating point type __fp16
> but does not allow its use as a function return or parameter type. This
> patch removes that restriction and defines the ACLE macro
> __ARM_FP16_ARGS to indic
On Fri, 13 May 2016, Mikhail Maltsev wrote:
I don't know if we might want some :c / single_use restrictions, maybe on the
outer convert and the rshift/rotate.
I don't think :c can be used here.
Oups, typo for :s.
As for :s, I added it, as you suggested.
:s will be ignored when there is n
On 05/13/2016 03:22 PM, Kyrill Tkachov wrote:
/* We only want to handle integral modes. This catches VOIDmode,
CCmode, and the floating-point modes. An exception is that we
@@ -11649,7 +11649,8 @@ simplify_comparison (enum rtx_code code,
/* Try to simplify the compare to
On 13/05/16 14:01, Bernd Schmidt wrote:
On 05/13/2016 02:21 PM, Kyrill Tkachov wrote:
Hi all,
In this PR we may end up shifting a negative value left in
simplify_comparison.
The statement is:
const_op <<= INTVAL (XEXP (op0, 1));
This patch guards the block of that statement by const_op >= 0.
On 05/13/2016 03:07 PM, Richard Biener wrote:
On Fri, May 13, 2016 at 3:05 PM, Bernd Schmidt wrote:
Huh? Can you elaborate?
When you have a builtin taking a size in bytes then a byte is 8 bits,
not BITS_PER_UNIT bits.
That makes no sense to me. I think the definition of a byte depends on
t
On Fri, May 13, 2016 at 3:05 PM, Bernd Schmidt wrote:
> On 05/13/2016 12:20 PM, Richard Biener wrote:
>>
>> I'm not much of a fan of C++-ification (in this case it makes review
>> harder) but well ...
>
>
> I felt it was a pretty natural way to structure the code to avoid
> duplicating the same lo
On 05/13/2016 12:20 PM, Richard Biener wrote:
I'm not much of a fan of C++-ification (in this case it makes review
harder) but well ...
I felt it was a pretty natural way to structure the code to avoid
duplicating the same logic across more functions, and we might as well
use the language for
Hello.
I've tried to apply the same patch for the current trunk and tried to separate
reported errors to a different categories by a simple script ([1]).
There are number (complete report: [2]):
SECTION: gfortran
error types: 3534, total errors: 113282
error types: 90.15%, total errors: 27.
On 05/13/2016 02:21 PM, Kyrill Tkachov wrote:
Hi all,
In this PR we may end up shifting a negative value left in
simplify_comparison.
The statement is:
const_op <<= INTVAL (XEXP (op0, 1));
This patch guards the block of that statement by const_op >= 0.
I _think_ that's a correct thing to do for
The atomic_compare_exchange_$n builtins have an exciting calling convention
where the 4th ('weak') parm is dropped in a real call. This caused
gcc.dg/atomic-noinline.c to fail on PTX as the prototype didn't match the use.
Fixed thusly when emitting the ptx prototyp. Also fixed is the subseq
On 05/13/2016 02:46 PM, Richard Biener wrote:
> Use them for HOST_WIDE_INT printing, for [u]int64_t use the PRI stuff.
>
> Richard.
Thanks you both, installed as r236208.
Martin
On Fri, May 13, 2016 at 2:43 PM, Kyrill Tkachov
wrote:
> Hi Martin,
>
>
> On 13/05/16 13:39, Martin Liška wrote:
>>
>> On 05/13/2016 02:11 PM, H.J. Lu wrote:
>>>
>>> On Fri, May 13, 2016 at 3:44 AM, Martin Liška wrote:
On 05/13/2016 11:43 AM, Bin.Cheng wrote:
>
> On Thu, May 12,
Hi Martin,
On 13/05/16 13:39, Martin Liška wrote:
On 05/13/2016 02:11 PM, H.J. Lu wrote:
On Fri, May 13, 2016 at 3:44 AM, Martin Liška wrote:
On 05/13/2016 11:43 AM, Bin.Cheng wrote:
On Thu, May 12, 2016 at 5:41 PM, Martin Liška wrote:
On 05/12/2016 03:51 PM, Bin.Cheng wrote:
On Thu, May
On 05/13/2016 02:11 PM, H.J. Lu wrote:
> On Fri, May 13, 2016 at 3:44 AM, Martin Liška wrote:
>> On 05/13/2016 11:43 AM, Bin.Cheng wrote:
>>> On Thu, May 12, 2016 at 5:41 PM, Martin Liška wrote:
On 05/12/2016 03:51 PM, Bin.Cheng wrote:
> On Thu, May 12, 2016 at 1:13 PM, Martin Liška wro
ARC support has been added to libgloss in this patch to newlib repository:
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=acdfcb0a0af54715bc37ed1c767bfe901b679357
2016-05-13 Anton Kolesov
* configure.ac: Add ARC support to libgloss.
* configure: Regenerate
---
conf
Committing as obvious.
Thanks,
Kyrill
2016-05-12 Kyrylo Tkachov
* tree-ssa-loop-ivanon.c (try_unroll_loop_completely): Typo fix in
comment.
diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c
index 9d92276dbbbfe3a768b9e8b0c90ee60e05c885fb..e8f67953231f54ce2517a55e1
On 05/05/2016 08:03 AM, Shiva Chen wrote:
- /* We do not handle setting only part of the register. */
- if (DF_REF_FLAGS (adef) & DF_REF_READ_WRITE)
-return GRD_INVALID;
-
This isn't right, at least not without other changes. This prevents
using references where the register is set as
Hi all,
The name of the parameter is max-completely-peel-times.
Applying to trunk as obvious.
Thanks,
Kyrill
2016-05-13 Kyrylo Tkachov
* tree-ssa-loop-ivcanon.c (try_unroll_loop_completely):
Change --param max-completely-peeled-times to
--param max-completely-peel-times in dump
The recent subreg-CSE allows a part of PR42587 to be fixed with
minimal surgery to the bswap pass - namely adding support for
BIT_FIELD_REF.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2016-05-13 Richard Biener
PR tree-optimization/42587
*
Hi all,
In this PR we may end up shifting a negative value left in simplify_comparison.
The statement is:
const_op <<= INTVAL (XEXP (op0, 1));
This patch guards the block of that statement by const_op >= 0.
I _think_ that's a correct thing to do for that trasnformation:
"If we have (compare (xsh
On Fri, May 13, 2016 at 3:44 AM, Martin Liška wrote:
> On 05/13/2016 11:43 AM, Bin.Cheng wrote:
>> On Thu, May 12, 2016 at 5:41 PM, Martin Liška wrote:
>>> On 05/12/2016 03:51 PM, Bin.Cheng wrote:
On Thu, May 12, 2016 at 1:13 PM, Martin Liška wrote:
> On 05/10/2016 03:16 PM, Bin.Cheng w
On Fri, 13 May 2016, Tejas Belagod wrote:
> > It's not a change between the two versions of ACLE. It's a change
> > relative to the early (pre-ACLE) __fp16 specification (or, at least, a
> > clarification thereto in email on 12 Aug 2008) that was used as a basis
> > for the original implementatio
On 05/11/2016 10:52 AM, Marc Glisse wrote:
> +/* ~((~X) >> Y) -> X >> Y (for arithmetic shift). */
> +(simplify
> + (bit_not (convert? (rshift (bit_not @0) @1)))
> + (if (!TYPE_UNSIGNED (TREE_TYPE (@0))
> + && TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@0)))
> + (convert (rshift
On Fri, May 13, 2016 at 1:01 PM, Eric Botcazou wrote:
>> Hmm, the patch looks obvious if it was the intent to allow constant
>> pool replacements
>> _not_ only when the whole constant pool entry may go away. But I
>> think the intent was
>> to not do this otherwise it will generate worse code by
On Fri, May 13, 2016 at 02:46:36PM +0300, Kirill Yukhin wrote:
> NP. Below is the patch which fixes both issues.
> It also revealed, that for "*and" pattern 32 byte long
> internal buffer is not enough.
> I've extended bunch of such buffers to 128 bytes.
>
> Probably we might want to re-factor all
Hello,
On 12 May 20:42, Jakub Jelinek wrote:
> On Thu, May 12, 2016 at 05:20:02PM +0300, Kirill Yukhin wrote:
> > > 2016-05-04 Jakub Jelinek
> > >
> > > * config/i386/sse.md (sse_shufps_, sse_storehps, sse_loadhps,
> > > sse_storelps, sse_movss, avx2_vec_dup, avx2_vec_dupv8sf_1,
> > > sse
On 05/13/2016 01:03 PM, Jakub Jelinek wrote:
> On Fri, May 13, 2016 at 12:26:57PM +0200, Martin Liška wrote:
>> On 05/12/2016 02:44 PM, Jakub Jelinek wrote:
>>> I think it isn't obvious that one needs to put halt_on_error=0 or
>>> halt_on_error=1 into those options and what to do if you need multip
Hi!
This patch adds parsing of new OpenMP 4.5 constructs (though, collapse(n)
is still not handled), but we don't do anything about those during resolve
and later.
Committed to gomp-4_5-branch.
2016-05-13 Jakub Jelinek
* parse.c (decode_omp_directive): Use gfc_match_omp_end_critical
Hi Christophe,
On 12/05/16 20:57, Christophe Lyon wrote:
On 12 May 2016 at 11:48, Ramana Radhakrishnan wrote:
On Thu, May 5, 2016 at 12:50 PM, Kyrill Tkachov
wrote:
Hi all,
In this PR we deal with some fallout from the conversion to unified
assembly.
We now end up emitting instructions like
On Fri, May 13, 2016 at 12:26:57PM +0200, Martin Liška wrote:
> On 05/12/2016 02:44 PM, Jakub Jelinek wrote:
> > I think it isn't obvious that one needs to put halt_on_error=0 or
> > halt_on_error=1 into those options and what to do if you need multiple
> > options in there.
>
> What about changin
1 - 100 of 119 matches
Mail list logo