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
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
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 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
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
> Ok without the comment (this is obvious)
And with an appropriate name for the variable, typically "prec".
--
Eric Botcazou
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
>
> 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
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
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
>> 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 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
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
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
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
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
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
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 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
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
+
+
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
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
> 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
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
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/
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
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 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
29 matches
Mail list logo
