Hello Uroš, Jakub,
On 22 Dec 11:47, Uros Bizjak wrote:
> The x86 part is OK for mainline. You will also need approval from the
> middle-end reviewer for tree-* parts.
Thanks, I'am testing (in agreed volume, bootstrap passed so far) patch
in the bottom.
If no more inputs - I'll check it in to main
Hello Uroš,
On 18 Dec 18:16, Uros Bizjak wrote:
> +/* Walk through insns sequence or pattern and erase rounding mentions.
> + Main transformation is performed in ix86_erase_embedded_rounding_1. */
> +static rtx
> +ix86_erase_embedded_rounding (rtx pat)
>
> All calls to this function are made wi
Hello,
On 19 Nov 15:36, Uros Bizjak wrote:
> Please also add new command options to g++.dg/other/sse-2.C and
> g++.dg/other/sse-3.C
Done (to i386-[23].C).
> > --mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd @gol
> > +-mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd -msha -mno-sha @gol
>
> No n
Adding gcc-patches.
On Mon, Dec 30, 2013 at 5:06 PM, Kirill Yukhin wrote:
> Hello,
> It seems that we forgot about kmovw instruction in AVX512 patch series.
>
> Patch in the bottom, is it ok for trunk?
>
> gcc/
>
> * config/i386/avx512fintrin.h (_mm512_kmov): New.
> * config/i386/
On Mon, Dec 30, 2013 at 2:07 PM, Kirill Yukhin wrote:
> Adding gcc-patches.
>
> On Mon, Dec 30, 2013 at 5:06 PM, Kirill Yukhin
> wrote:
>> Hello,
>> It seems that we forgot about kmovw instruction in AVX512 patch series.
>>
>> Patch in the bottom, is it ok for trunk?
>>
>> gcc/
>>
>> * c
> You don't need an unspec (or corresponding __builtin), generic movhi
> pattern should be able to generate correct insn.
>
> Uros.
Hi,
Generic movhi genrates simple mov.
Actually the whole purpose of this intrinsic is to let complier know,
that this variable should pe placed on mask register an
Hi Guys,
I have tracked down a bug reported against the MSP430 (PR
target/59613) which turns out to be a generic problem. The function
get_mode_bounds() in stor-layout.c computes the minimum and maximum
values for a given mode, but it uses the bitsize of the mode not the
precision. Thi
On Mon, Dec 30, 2013 at 4:11 PM, Ilya Tocar wrote:
>> You don't need an unspec (or corresponding __builtin), generic movhi
>> pattern should be able to generate correct insn.
>
> Generic movhi genrates simple mov.
> Actually the whole purpose of this intrinsic is to let complier know,
> that this
On 12/30/2013, 2:27 AM, Yangfei (Felix) wrote:
Add one entry to ChangeLog:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 206236)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-12-30 Felix Yang
+
+
Hi Guys,
I am applying the patch below to the MSP430 backend to enable the use
of %A, %B, %C and %D in asm statements as selectors of 16-bit parts of
a 64-bit value. This is at the request of TI, for compatibility with
their compiler.
Cheers
Nick
gcc/ChangeLog
2013-12-30 Nick Clifton
Hi!
This patch fixes masked gather load vectorization if the narrowing (or
widening) gather needs to be used (one where either the index is 32-bit and
loaded type 64-bit or index is 64-bit and loaded type 32-bit).
Bootstrapped/regtested on x86_64-linux and i686-linux, Kyrill has also
kindly teste
Hi!
Setting gimple_call_set_fndecl of a random method call to
__bultin_unreachable can't work properly, the method call probably
passes in arguments that __builtin_unreachable doesn't expect, and if
the method call has LHS, we'll ICE, because __builtin_unreachable doesn't
have a LHS. Fixed by not
Jakub Jelinek wrote:
>Hi!
>
>Setting gimple_call_set_fndecl of a random method call to
>__bultin_unreachable can't work properly, the method call probably
>passes in arguments that __builtin_unreachable doesn't expect, and if
>the method call has LHS, we'll ICE, because __builtin_unreachable
>does
Jakub Jelinek wrote:
>Hi!
>
>This patch fixes masked gather load vectorization if the narrowing (or
>widening) gather needs to be used (one where either the index is 32-bit
>and
>loaded type 64-bit or index is 64-bit and loaded type 32-bit).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux
Nick Clifton wrote:
>Hi Guys,
>
> I have tracked down a bug reported against the MSP430 (PR
> target/59613) which turns out to be a generic problem. The function
> get_mode_bounds() in stor-layout.c computes the minimum and maximum
> values for a given mode, but it uses the bitsize of the mod
On Mon, Dec 30, 2013 at 05:56:04PM +0100, Richard Biener wrote:
> Jakub Jelinek wrote:
> >Setting gimple_call_set_fndecl of a random method call to
> >__bultin_unreachable can't work properly, the method call probably
> >passes in arguments that __builtin_unreachable doesn't expect, and if
> >the
Hi all,
since the number of regressions unfortunately keeps on rising since
quite some time, I think it would be a suitable new-year's resolution
for the whole gfortran team to try and get the number of those buggers
closer to zero again ;)
I even volunteer to make a start with the one mentioned
On Mon, Dec 30, 2013 at 06:03:30PM +0100, Janus Weil wrote:
>
> I even volunteer to make a start with the one mentioned in the subject
> line. The fix is actually easy once you know where to look (which was
> simplified a lot by Dominique's efforts to identify the blameworthy
> commit).
>
> The r
>> The rather straightforward one-line patch was regtested on
>> x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
>>
>
> OK.
Thanks, Steve. Committed as r206249.
Cheers,
Janus
On Dec 30, 2013, at 8:24 AM, Nick Clifton wrote:
> I am applying the patch below to the MSP430 backend to enable the use
> of %A, %B, %C and %D in asm statements as selectors of 16-bit parts of
> a 64-bit value. This is at the request of TI, for compatibility with
> their compiler.
Seems lik
Jakub Jelinek wrote:
>On Mon, Dec 30, 2013 at 05:56:04PM +0100, Richard Biener wrote:
>> Jakub Jelinek wrote:
>> >Setting gimple_call_set_fndecl of a random method call to
>> >__bultin_unreachable can't work properly, the method call probably
>> >passes in arguments that __builtin_unreachable doe
>
> Yes. Also affecting other statements isn't allowed.
>
> >One would need to also unlink vdefs and release the vdef SSA_NAME, and
> >not
> >sure if fold_stmt_inplace callers would be even prepared for the stmt
> >to
> >become noreturn, and no longer throwing, etc.
>
> That I think they have t
Hi,
this is C version
static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
main()
{
return p(1);
}
Here we get in CCP:
Folding statement: return _4;
Not folded
Folding statement: _4 = p.0_2 (1);
Folded into: _4 = __builtin_unreachable (1);
Removing dead stmt p.0_2 = __builtin_unreacha
> Ok without the comment (this is obvious)
And with an appropriate name for the variable, typically "prec".
--
Eric Botcazou
On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
> this is C version
> static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
> main()
> {
> return p(1);
> }
Well, that testcase is invalid, as you are calling the function (builtin)
through incompatible function pointer, so al
> On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
> > this is C version
> > static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
> > main()
> > {
> > return p(1);
> > }
>
> Well, that testcase is invalid, as you are calling the function (builtin)
> through incompatible fun
Yes, I see. Thanks for taking this patch.
Cheers,
Fei.
>
> On 12/30/2013, 2:27 AM, Yangfei (Felix) wrote:
> > Add one entry to ChangeLog:
> >
> > Index: gcc/ChangeLog
> >
>
> ===
> > --- gcc/ChangeLog (revision 206236)
> >
On 2013/12/28 02:29 PM, Chung-Lin Tang wrote:
> On 13/12/23 12:54 AM, Chung-Lin Tang wrote:
>>> Other than these two, I think this can go in.
Bernd
>> Attached is the updated patch for the compiler.
>>
>> Since Bernd is a Global Reviewer, am I clear for committing the port
>> now? (including t
Jakub Jelinek wrote:
>On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
>> this is C version
>> static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
>> main()
>> {
>> return p(1);
>> }
>
>Well, that testcase is invalid, as you are calling the function
>(builtin)
>through inc
29 matches
Mail list logo
