On Tue, Dec 31, 2013 at 10:39:58PM -0800, Mike Stump wrote:
> In testing for wide-int, we discovered that someone seems to have blown
> pch. The problem is that the optabs field is not a string. It's size is
> not determined by strlen. strlen are the semantics gty attaches to
> unsigned char * d
On Dec 31, 2013, at 12:26 PM, Jan-Benedict Glaw wrote:
> On Tue, 2013-12-31 15:24:52 +0800, Chung-Lin Tang
> wrote:
>> The nios2 port was just committed. Thanks to all that gave time and
>> effort to review this.
>
> Just a heads-up: I see a lot of warnings about BITS_PER_UNIT being
> redefined
In testing for wide-int, we discovered that someone seems to have blown pch.
The problem is that the optabs field is not a string. It's size is not
determined by strlen. strlen are the semantics gty attaches to unsigned char *
data. By defeating the type of optabs to being any other type, th
Hi!
I've noticed that all abi-avx512f.exp tests fail when the assembler doesn't
support avx512f. The problem is that the builtin has been optimized away
as unused and thus it passed even with assembler that doesn't support EVEX.
Fixed thusly, tested on x86_64-linux, committed to trunk as obvious
Hi!
In --enable-checking=rtl bootstrap most of SSE/AVX tests fail, because
*mov_internal is using REGNO on operands that are e.g. MEM or
CONST_INT etc. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, committed to trunk as obvious.
2014-01-01 Jakub Jelinek
* confi
On Tue, 2013-12-31 15:24:52 +0800, Chung-Lin Tang
wrote:
> The nios2 port was just committed. Thanks to all that gave time and
> effort to review this.
Just a heads-up: I see a lot of warnings about BITS_PER_UNIT being
redefined, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.ph
On 12/31/2013, 2:04 PM, Jakub Jelinek wrote:
Hi!
As written in the PR, I've been looking why is llvm 3.[34] so much faster
on Scimark2 SOR benchmark and the reason is that it's predictive commoning
or whatever it uses doesn't give up on the inner loop, while our predcom
unnecessarily gives up, b
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8?
>
> 2013-12-31 Jakub Jelinek
>
> PR rtl-optimization/59647
> * cse.c (cse_process_notes_1): Don't substitute negative VOIDmode
> new_rtx into UNSIGNED_FLOAT rtxes.
>
> * g++.dg/opt/pr59647.C: Ne
Hi!
This patch fixes a 4.8 ICE (on trunk the bug went latent by GIMPLE
optimization changes). The problem is we have a REG_EQUAL
(unsigned_float:DF (reg:SI ...)) and cse_process_notes_1 attempts
to replace the reg with CONST_INT that has the top most bit set.
As CONST_INTs are canonicalized by si
Hi!
As written in the PR, I've been looking why is llvm 3.[34] so much faster
on Scimark2 SOR benchmark and the reason is that it's predictive commoning
or whatever it uses doesn't give up on the inner loop, while our predcom
unnecessarily gives up, because there are reads that could alias the wri
Bingfeng Mei wrote:
Hi,
I created PR59544 and here is the patch. OK to commit?
Thanks,
Bingfeng
2013-12-18 Bingfeng Mei
PR tree-optimization/59544
* tree-vect-stmts.c (perm_mask_for_reverse): Move before
vectorizable_store. (vectorizable_store): Handle negative step.
Hello,
here is a simple patch for error recovery. We already check the arguments
earlier, but force_rvalue can replace them with errors.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2014-01-01 Marc Glisse
PR c++/59641
gcc/cp/
* call.c (build_conditional_expr_1): Check
Ping http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03822.html
On Sat, 30 Nov 2013, Marc Glisse wrote:
Hello,
we currently reject:
constexpr int s = 32;
typedef double VEC __attribute__ ((__vector_size__ (s)));
and similarly for other attributes, while we accept s+0 or (int)s, etc. The
code i
On Mon, 2 Dec 2013, Gerald Pfeifer wrote:
On Mon, 2 Dec 2013, Marc Glisse wrote:
Index: doc/extend.texi
===
+In C++, the ternary operator @code{?:} is available. @code{a?b:c}, where
+@code{b} and @code{c} are vectors of the same ty
Richard Biener writes:
> 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, b
Jan Hubicka wrote:
>> >I think so, after all don't we set noreturn attribute automatically
>> >even if it is missing when IPA can prove the function never returns?
>> >If we fold_stmt after that, the above testcase even without explicit
>> >noreturn attribute would need cfg cleanup.
>> >
>> >Perha
> >I think so, after all don't we set noreturn attribute automatically
> >even if it is missing when IPA can prove the function never returns?
> >If we fold_stmt after that, the above testcase even without explicit
> >noreturn attribute would need cfg cleanup.
> >
> >Perhaps gimple_fold_call should
On Tue, Dec 31, 2013 at 11:22 AM, Ilya Tocar wrote:
>> RA figured out that operation with general registers results in less
>> moves (you already have x1 in general reg). This is exaclty the reason
>> why I think unspecs are not needed. It is the job of the compiler to
>> choose most appropriate a
Jakub Jelinek wrote:
>On Tue, Dec 31, 2013 at 08:39:02AM +0100, Richard Biener wrote:
>> >That said, fold_stmt callers have to be prepared to handle say a
>normal
>> >call becoming noreturn call, consider say:
>> >
>> >struct A { virtual int foo (); };
>> >struct B : public A { int foo () __attrib
> RA figured out that operation with general registers results in less
> moves (you already have x1 in general reg). This is exaclty the reason
> why I think unspecs are not needed. It is the job of the compiler to
> choose most appropriate approach, and its behavior should be adjusted
> with appro
Hi all,
... and the reg-bashing continues: Here is a small patch to fix a
bind(c) problem. It essentially prevents 'resolve_global_procedure' to
be applied to bind(c) procedures.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2013-12-31 Janus Weil
PR fortran/59023
On Tue, Dec 31, 2013 at 08:39:02AM +0100, Richard Biener wrote:
> >That said, fold_stmt callers have to be prepared to handle say a normal
> >call becoming noreturn call, consider say:
> >
> >struct A { virtual int foo (); };
> >struct B : public A { int foo () __attribute__((noreturn)); };
> >int
Hi Volker,
apparently you added the wrong PR number to the patch. You probably
meant PR 59613. Would you mind fixing that in the ChangeLog?
Doh! Sorry - fixed.
Cheers
Nick
23 matches
Mail list logo
