On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>>> Sorry, I don't understand. I never said it was invalid. I said
>>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represen
Hi,
We have
(define_insn "*movsf_internal"
[(set (match_operand:SF 0 "nonimmediate_operand"
"=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
(match_operand:SF 1 "general_operand"
"Yf*fm,Yf*f,G ,rmF,rF,C,v,m,v,Yj,r ,*y ,m ,*y,*Yn,r"))]
alternative 13
On 10 December 2013 21:51, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
Sorry, I don't understand. I never said it was invalid. I said
(subreg:SF (re
Pre-remark:
I had hoped that something like the following patch would work. However,
it will lead to a bunch of run-time segfaults in the test suite - but
the original dump seems to be fine and I also fail to spot the problem
when looking at the patch. Thus, instead of posting a working patch,
On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod wrote:
> On 10 December 2013 21:51, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understa
Hi Jeff,
On Thu, 2013-12-05 21:14:23 -0700, Jeff Law wrote:
> On 12/05/13 21:10, Jan-Benedict Glaw wrote:
> > On Thu, 2013-12-05 20:49:06 -0700, Jeff Law wrote:
> > > I'd just change this one to be correct for the GNU style. If
> > > you wanted to follow-up with another patch to fix these
> > >
The patch does the same for libgfortran as Uros did for
libgcc/libatomic, cf.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00878.html
"This is also how glibc generates exceptions."
Build and tested on x86-64-gnu-linux.
OK ?
Tobias
2013-12-10 Tobias Burnus
* config/fpu-387.h (sigill_hdlr,
On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
> This is the new version patch computing the difference in tree affine then
> comparing against integer_zero_node.
> Bootstrap and test on current upstream. I will commit it if there is no
> other objection.
This breaks bootstrap on x86_
> The patch does indeed fix unsigned-extend-1.c on arm and bootstraps
> succesfully on arm-none-linux-gnueabihf.
Thanks for the testing.
> Thanks for fixing this, that test failure has been spoiling my test runs for
> quite a while now :)
You're welcome. Now applied on mainline and 4.8 branch,
On Tue, Dec 10, 2013 at 11:23 PM, H.J. Lu wrote:
> Hi,
>
> We have
>
> (define_insn "*movsf_internal"
> [(set (match_operand:SF 0 "nonimmediate_operand"
> "=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
> (match_operand:SF 1 "general_operand"
> "Yf*fm,Yf*
On Tue, Dec 10, 2013 at 7:30 AM, Jeff Law wrote:
>
>
> Ping!
I'd prefer going with the first patch to merge_if_blocks (with a big
"???" or FIXME), to contain this problem to where it occurs.
Otherwise, before you know it, there are other places in the compiler
that assume it's OK to merge blocks t
On Tue, Dec 10, 2013 at 3:19 PM, Uros Bizjak wrote:
> On Tue, Dec 10, 2013 at 11:23 PM, H.J. Lu wrote:
>> Hi,
>>
>> We have
>>
>> (define_insn "*movsf_internal"
>> [(set (match_operand:SF 0 "nonimmediate_operand"
>> "=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
>>
Hello!
> PR gcc/59422
>
> This patch extends the supported targets for function multi versiong to also
> include Haswell, Silvermont, and the most recent AMD models. It also
> prioritizes AVX2 versions over AMD specific pre-AVX2 versions.
Please add a ChangeLog entry and attach the complete patch
Il 09/12/2013 12:08, Gerald Pfeifer ha scritto:
> On Mon, 9 Dec 2013, FX wrote:
>> > Look at this as a diagnostics bug: our current diagnostics for this
>> > pretty common situation sucks. It comes late in the compilation, and
>> > the message itself isn’t helpful.
> Totally seconded.
>
> Paolo,
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test on current upstream. I will commit it if t
On Tue, Dec 10, 2013 at 2:33 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod
> wrote:
>> On 10 December 2013 21:51, H.J. Lu wrote:
>>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson
wrote:
> On 12/10/2013
On 12/10/13 16:22, Steven Bosscher wrote:
On Tue, Dec 10, 2013 at 7:30 AM, Jeff Law wrote:
Ping!
I'd prefer going with the first patch to merge_if_blocks (with a big
"???" or FIXME), to contain this problem to where it occurs.
Otherwise, before you know it, there are other places in the comp
On Wed, Dec 11, 2013 at 4:31 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 6:46 PM, bin.cheng wrote:
>>
>>>
>> Hi,
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test on current upstream. I will commit it if th
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> This is the new version patch computing the difference in tree affine then
>> comparing against integer_zero_node.
>> Bootstrap and test on current upstream. I will commit it if t
So for this source, compiled for x86_64 with -O3:
typedef unsigned long int uint64_t;
typedef long int int64_t;
int summation_helper_1(int64_t* products, uint64_t count)
{
int s = 0;
uint64_t i;
for(i=0; i0) ? 1 : -1;
products[i] *= val;
if
On 12/10/13 23:35, Bin.Cheng wrote:
I know little about GC, so when ggc_collect may be called (between two
passes)? If so, I have to call free_affine_expand_cache just after the
calling to tree_to_affine_combination_expand in SCEV because it's an
analyzer and as you pointed out, the analyzing re
Tobias Burnus wrote:
A rather simple fix for an ICE on invalid bug (low-priority 4.8/4.9
regression).
Bootstrapped and regtested without new failure on x86-64-gnu-linux.
OK for the trunk and 4.8?
Tobias
On Wed, Dec 11, 2013 at 12:42 AM, Tobias Burnus wrote:
> The patch does the same for libgfortran as Uros did for libgcc/libatomic,
> cf. http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00878.html
>
> "This is also how glibc generates exceptions."
>
> Build and tested on x86-64-gnu-linux.
> OK ?
Ok,
101 - 123 of 123 matches
Mail list logo
