ping
As trunk is in stage 4, is there some accepted custom to re-run all the third
party
generators, to avoid different versions of generated code across the final
release?
Thanks!
/haubi/
On 01/04/2015 08:20 PM, Michael Haubenwallner wrote:
> (CC'ing build machinery maintainers, maybe I shoul
On Wed, Jan 21, 2015 at 9:00 PM, Marc Glisse wrote:
> Hello,
>
> (sorry for the broken thread, for some reason I haven't received any email
> from gcc since about 10am, I'll investigate later)
>
> +/* x & ~(x & y) -> x & ~y */
> +(simplify
> + (bit_and:c @0 (bit_not (bit_and:c@2 @0 @1)))
> + (if (
> This is a follow-up to a change [1] in glibc. It fixes the issue [2]
> when jal can not reach a target in different region.
>
> It has been tested with DejaGnu for mips32/o32, mips64/n32 and
> mips64/n64.
>
> Let me know what you think.
So to confirm, the issue is non-pic crt calling an init r
Add h8300-*-linux target for h8300 linux kernel and userland.
h8300-*-elf is some difference of standard elf.
h8300-*-linux is compatible of standard elf rules.
Thanks.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9d3fa57..acbbbe1 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1190,6
As said in the other thread - this makes sure we don't perform inlining
that might end up generating invalid code. It also preserves
user-provided optimize attributes more properly.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-22 Richard Biener
Hi,
As -freport-bug dumps also the error output into the file as /* ... */
comment, there is a problem if that text includes /* or */ character
sequences.
This patch fixes this by not wrapping error output with /* ... */, but
comment out each line with C++ style comments instead.
Tested on P
On Thu, Jan 22, 2015 at 12:25:20PM +0400, Maxim Ostapenko wrote:
> gcc/ChangeLog:
>
> 2015-01-22 Max Ostapenko
>
> PR driver/64690
> * gcc.c (insert_comments): New function.
> (try_generate_repro): Call it.
> (append_text): Removed.
>
> diff --git a/gcc/gcc.c b/gcc/gcc
Hi Richard,
I thought one of my current issue would be solved by this patch, but it
is not : I have some inlining failures with the attribute target on ARM.
(e.g inline-3.c) where obvious early inline fails with because we fail
into the last can_inline_edge_p case:
opt_for_fn (callee->decl,
Ping
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of Tony Liu
Sent: Thursday, January 15, 2015 8:10 PM
To: gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan; Richard Earnshaw
Subject: [PATCH, ARM, testsuite] Improve scd42-1.c for UA
On Thu, 22 Jan 2015, Christian Bruel wrote:
> Hi Richard,
>
> I thought one of my current issue would be solved by this patch, but it is not
> : I have some inlining failures with the attribute target on ARM. (e.g
> inline-3.c) where obvious early inline fails with because we fail into the
> last
On 21 January 2015 at 22:58, Jan Hubicka wrote:
> Hi,
> these two rather noticeable features are not mentioned.
>
> Honza
>
> Index: changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> retrieving revision 1.6
Hi Honza,
On 21/01/15 21:58, Jan Hubicka wrote:
Hi,
these two rather noticeable features are not mentioned.
Honza
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.69
diff -u -r1.
From: Trevor Saunders
Hi,
fold calls symtab_node::get_create () which can change this field from NULL to
point to a new object. It doesn't seem to really matter when the object gets
created and I don't think it changes any properties of the tree object. So I
think it makes sense to do here wha
On Thu, Jan 22, 2015 at 06:02:06AM -0500, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders
>
> Hi,
>
> fold calls symtab_node::get_create () which can change this field from NULL to
> point to a new object. It doesn't seem to really matter when the object gets
> created and I don't thin
On 21/01/15 15:07, Christophe Lyon wrote:
On 19 January 2015 at 17:54, Marcus Shawcroft
wrote:
On 19 January 2015 at 15:43, Christophe Lyon wrote:
On 19 January 2015 at 14:29, Marcus Shawcroft
wrote:
On 16 January 2015 at 17:52, Christophe Lyon wrote:
OK provided, as per the previous cou
Hi,
I've committed the following bugfix which fixes an obvious typo in the
atomic code attribute. Due to this the load and or instructions was
not used.
Committed to 4.9 branch and mainline.
Bye,
-Andreas-
2015-01-22 Andreas Krebbel
* config/s390/s390.md (atomic code attribute): F
On 01/22/2015 02:46 AM, Mike Stump wrote:
> On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
>> On 1/6/15 04:07, Jeff Law wrote:
>>>
* toplev.c (init_local_tick): Process the failure when read
fails for random_seed.
>>> This is fine for the trunk. Please install.
>
>> I am not fam
On Wed, Jan 21, 2015 at 10:07:14AM +0100, Rainer Orth wrote:
> Ok for mainline once that has been done?
>
> Thanks.
> Rainer
>
>
> 2015-01-20 Rainer Orth
>
> * gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit.
Ok.
Though wonder if for the TARGET_LIBC_PROVIDES_SSP case LI
On 11/24/2014 04:24 PM, Jakub Jelinek wrote:
> On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
>> On 11/24/14 15:41, Jakub Jelinek wrote:
>>> On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
>>
>> [...]
>>
+else
+ pp_wide_int(&pretty_name,
+
On 10/08/2014 10:52 PM, Richard Henderson wrote:
> On 10/08/2014 03:47 AM, Chen Gang wrote:
>> It passes "make -k check" under Darwin x86_64.
>>
>> 2014-10-07 Chen Gang
>>
>> * unwind-dw2-fde.h (last_fde): Use "(const fde *)" instead of
>> "(char *)" to avoid qualifier warning by 'xgcc
ping. Segher do you any comments from your side.
regards,
Venkat.
On 14 January 2015 at 16:57, Venkataramanan Kumar
wrote:
> Hi all,
>
> When trying to debug GCC combiner pass with the test case in PR63949
> ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 I came across this
> code.
>
> T
ping.
Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
regards,
Venkat.
On 20 January 2015 at 18:51, Venkataramanan Kumar
wrote:
> Hi all,
>
> This patch changes make file and configure under libsanitizer, to
> separate out X86_64 specific file "tsan_rtl_amd64.S" from
On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
> ping.
>
> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
Well, without a change from upstream to guard the HACKY_CALL and actual tsan
port to non-x86_64 this patch doesn't solve anything.
On Thu, Jan 22 2015, Richard Biener wrote:
> On Wed, Jan 21, 2015 at 9:00 PM, Marc Glisse wrote:
>> Hello,
>>
>> (sorry for the broken thread, for some reason I haven't received any email
>> from gcc since about 10am, I'll investigate later)
>>
>> +/* x & ~(x & y) -> x & ~y */
>> +(simplify
>> +
On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek wrote:
> On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
>> ping.
>>
>> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
>
> Well, without a change from upstream to guard the HACKY_CALL and actual tsan
>
Hi Jakub,
Thank you for the reply.
Yes there is no functional change. I got some comments in PR63850
about pushing a patch since is GCC only change.
Ok I will wait for LLVM merge of TSAN which needs this patch.
regards,
Venkat.
On 22 January 2015 at 19:33, Jakub Jelinek wrote:
> On Thu,
On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote:
> On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek wrote:
> > On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
> >> ping.
> >>
> >> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
> >
> > W
On 22 January 2015 at 12:19, Tejas Belagod wrote:
> On 21/01/15 15:07, Christophe Lyon wrote:
>>
>> On 19 January 2015 at 17:54, Marcus Shawcroft
>> wrote:
>>>
>>> On 19 January 2015 at 15:43, Christophe Lyon
>>> wrote:
On 19 January 2015 at 14:29, Marcus Shawcroft
wrote:
>
>
Hi,
const_binop is now invoked on MEM_EXPR, which doesn't make much sense given
the assertion at the end:
/* Make sure type and arg0 have the same saturating flag. */
gcc_checking_assert (TYPE_SATURATING (type)
== TYPE_SATURATING (TREE_TYPE (arg1)));
Tested on x86_64
Hello!
Attached patch fixes PR 64688. Operand constraints were wrong for
reg-to-vec targets.
The patch also fixes PR 64477.
2015-22-01 Uros Bizjak
PR target/64688
PR target/64477
* config/i386/sse.md (vec_set_0): Use (Yi/r/C) constraints
for alternative 3.
te
As discussed in the PR, this patch partially reverts Tom's change
in r136209. (The is_if argument to _cpp_parse_expr is kept for the
sake of diagnostics.)
The change made sense at that time, but now we have DR#412 resolved.
This DR deals with the case where we have an #elif conditional that
doesn
This is a case when _init () function has to jump to __do_global_ctors_aux,
but __do_global_ctors_aux is too far away, so the target address is
shortened to fit in jal, and __do_global_ctors_aux is not reached.
Regards,
Petar
-Original Message-
From: Matthew Fortune [mailto:matthew.fort..
On 22/01/15 14:28, Christophe Lyon wrote:
On 22 January 2015 at 12:19, Tejas Belagod wrote:
On 21/01/15 15:07, Christophe Lyon wrote:
On 19 January 2015 at 17:54, Marcus Shawcroft
wrote:
On 19 January 2015 at 15:43, Christophe Lyon
wrote:
On 19 January 2015 at 14:29, Marcus Shawcroft
w
Ping!
2015-01-18 11:46 GMT+01:00 Janus Weil :
> Hi all,
>
> the attached patch is close to trivial and fixes a memory-leak
> regression that appeared after the implementation of finalization.
>
> My suspicion it that it's simply a copy'n'paste error, where the wrong
> attribute was copied from v
ping
now that C11 mode is the default, can we avoid the warning?
On 10/17/2014 12:14 PM, Matthias Klose wrote:
> Building libssp in C11 mode shows a warning for 64bit configurations,
>
> ../../../src/libssp/gets-chk.c:62:12: warning: return makes pointer from
> integer
> without a cast [-Wint-c
On Thu, Jan 22, 2015 at 3:36 PM, Eric Botcazou wrote:
> Hi,
>
> const_binop is now invoked on MEM_EXPR, which doesn't make much sense given
> the assertion at the end:
>
> /* Make sure type and arg0 have the same saturating flag. */
> gcc_checking_assert (TYPE_SATURATING (type)
>
The following fixes PR64728 - with the change to aggressively
propagate uninitialized abnormal SSA names we have to avoid
coalescing that with anything (we'll just expand it to whatever
the rest of the args was coalesced with).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
On 01/22/2015 12:56 AM, Andrew Pinski wrote:
> On Wed, Jan 21, 2015 at 8:51 AM, Jakub Jelinek wrote:
>> On Wed, Jan 21, 2015 at 08:41:46AM -0800, pins...@gmail.com wrote:
On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
__objc_get_forward_imp and get_imp were exported in libobjc
On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote:
> ping. Segher do you any comments from your side.
I agree combine should not transform shifts into multiplication (except
in addresses, where it is canonical). I haven't looked at the actual
patch in detail though, it will hav
LGTM.
Thanks, I should mention that this test fails on aarch64_be, because
of pending Alan's patches.
A few big-endian fixes were checked in last night. Do you mean this?
r219957 | rsandifo | 2015-01-21 17:53:04 + (Wed, 21 Jan 2015) | 6 lines
gcc/
2015-01-25 Alan Hayward
On 01/22/15 06:32, Chen Gang S wrote:
2014-10-07 Chen Gang
>>
>>* unwind-dw2-fde.h (last_fde): Use "(const fde *)" instead of
>>"(char *)" to avoid qualifier warning by 'xgcc' compiling.
Patch applied on your behalf.
Thanks,
Jeff
On 01/22/15 06:15, Chen Gang S wrote:
On 11/24/2014 04:24 PM, Jakub Jelinek wrote:
On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote:
On 11/24/14 15:41, Jakub Jelinek wrote:
On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote:
[...]
+ else
+ pp_wide_
On 01/22/15 05:37, Jakub Jelinek wrote:
On Wed, Jan 21, 2015 at 10:07:14AM +0100, Rainer Orth wrote:
Ok for mainline once that has been done?
Thanks.
Rainer
2015-01-20 Rainer Orth
* gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit.
Ok.
Though wonder if for the TA
Dear Janus,
As it happens I loaded this patch up last night to see if I could plug
the last leak in my patch for PR63205, which is making heavy use of
the default finalizers. It seemed to do the job. As you said in the PR
it appears to be a typo and really is obvious. I can canfirm that it
bootstr
On 01/22/15 04:55, Chen Gang S wrote:
On 01/22/2015 02:46 AM, Mike Stump wrote:
On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
On 1/6/15 04:07, Jeff Law wrote:
* toplev.c (init_local_tick): Process the failure when read
fails for random_seed.
This is fine for the trunk. Please in
On 01/22/15 01:38, Yoshinori Sato wrote:
Add h8300-*-linux target for h8300 linux kernel and userland.
h8300-*-elf is some difference of standard elf.
h8300-*-linux is compatible of standard elf rules.
It seems to me that you should have linux.h just define things that are
specific to the linux
This patch by Chris Manghane fixes the Go frontend to avoid an
infinite loop when reporting an initialization loop. This is Go issue
7558. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 4a641c29091f go/gogo.cc
--- a/go/gogo.ccWed Jan 21
On 01/19/15 06:07, Maxim Kuvyrkov wrote:
The underlying problem is that the order in which elements of
ready_list are compared matters to the final result. This is because
rank_for_schedule sorting heuristic establishes a partial order on
the set of instructions, and it can happen that with 3 i
Much of the jit testsuite currently segfaults on i686, after
two in-process iterations. In odd-numbered iterations,
gcc_jit_context_compile generates correct code, but on
even-numbered iterations, the generated code trashes the
%ebx register, leading to SIGSEGV back at the call site when
setting u
On 01/22/15 08:45, Matthias Klose wrote:
ping
now that C11 mode is the default, can we avoid the warning?
Ick.
Part of me wants to say drop the gets intercepting and just issue some
kind of error for C11 mode.
Part of me wants to ignore the issue and accept the warning.
Part of me wants to
On 01/21/15 15:32, Wei Mi wrote:
Hi,
The patch is to address the bug here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
It is to call get_addr for VALUE before forming a mem_addr expr with
the VALUE and an offset. This is to avoid the problem that get_addr
can only handle VALUE but cannot
On 01/19/15 11:30, Martin Liška wrote:
On 01/19/2015 03:48 PM, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 03:44:20PM +0100, Martin Liška wrote:
There's a bunch of another places that emit false positives. With
following patch,
I am able to run profiledbootstrap on x86_64-linux-pc and
ppc64-li
Thanks for the review. Comments addressed and patch committed. The
problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait
another day to commit it to gcc-4_9 if it is ok.
Thanks,
Wei.
On Thu, Jan 22, 2015 at 9:39 AM, Jeff Law wrote:
> On 01/21/15 15:32, Wei Mi wrote:
>>
>> Hi,
>>
On 01/22/15 11:00, Wei Mi wrote:
Thanks for the review. Comments addressed and patch committed. The
problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait
another day to commit it to gcc-4_9 if it is ok.
Yes, if the patch from Uros was backported to 4.9, then this patch
should get
On 01/22/2015 09:34 AM, David Malcolm wrote:
> gcc/ChangeLog:
> PR 64722
> * emit-rtl.c (init_emit_regs): Set pic_offset_table_rtx to
> NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM, since the
> latter may be affected by the former (e.g. on i686).
Ok.
r~
Thanks, Christophe - that's helpful, I'm getting a few tests working now.
Ramana/Richard, any thoughts on which way you'd like to add the float16 tests,
with preprocessor directives (I believe the relevant is #if __ARM_FP & 2) or in
separate files=Dejagnu testcases?
Thanks, Alan
Christophe L
On Thu, Jan 22, 2015 at 3:41 PM, Uros Bizjak wrote:
> Attached patch fixes PR 64688. Operand constraints were wrong for
> reg-to-vec targets.
>
> The patch also fixes PR 64477.
Whoops, I have regtested wrong compiler. The patch introduced some
AVX2 regressions. Following patch is also needed, ot
On 01/21/2015 11:52 PM, Richard Biener wrote:
> On January 21, 2015 10:23:56 PM CET, Richard Henderson
> wrote:
>> On 12/29/2014 06:04 AM, Thomas Preud'homme wrote:
>>> Since 16bit byteswap can be done via an 8 bit rotation (and it is the
>> canonical form),
>>> the check for an optab only serves
>
> As said in the other thread - this makes sure we don't perform inlining
> that might end up generating invalid code. It also preserves
> user-provided optimize attributes more properly.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2015-01-22
On Thu, Jan 22, 2015 at 7:04 PM, Jeff Law wrote:
>> Thanks for the review. Comments addressed and patch committed. The
>> problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait
>> another day to commit it to gcc-4_9 if it is ok.
>
> Yes, if the patch from Uros was backported to 4.9
On Jan 22, 2015, at 8:11 PM, Jeff Law wrote:
> On 01/19/15 06:07, Maxim Kuvyrkov wrote:
>>
>> The underlying problem is that the order in which elements of
>> ready_list are compared matters to the final result. This is because
>> rank_for_schedule sorting heuristic establishes a partial order
On 01/23/2015 12:41 AM, Jeff Law wrote:
> On 01/22/15 04:55, Chen Gang S wrote:
>> On 01/22/2015 02:46 AM, Mike Stump wrote:
>>> On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
On 1/6/15 04:07, Jeff Law wrote:
>
>> * toplev.c (init_local_tick): Process the failure when read
>>
Hi,
this patch fixes problem noticed by HJ about matinenance of the heap.
I doubt it really fixed the underlying correctness issue of the PR mentioned.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- Cha
On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
No problem.
After finish the assignment working flow, I guess, I may have the write
access, then can finish these kinds of trivial patches by myself (will
not always bother other members any
On 01/22/15 12:01, Maxim Kuvyrkov wrote:
This happens when all 3 instructions have (1) same priority, and (2)
only two of the three instructions are comparable on a "selective"
heuristic. "Selective" means that a heuristic only applies to a
subset of instructions, e.g., comparing speculative in
"parallel/kernel loop" is handled by the function being patched (an
assert ensures that no other directives end here). The first part of the
function handles the parallel and kernel part, the loop itself should be
handled by the called function. However, it currently passes the
"kernel/parallel
On Thu, Jan 22, 2015 at 7:37 PM, Uros Bizjak wrote:
>> Attached patch fixes PR 64688. Operand constraints were wrong for
>> reg-to-vec targets.
>>
>> The patch also fixes PR 64477.
>
> Whoops, I have regtested wrong compiler. The patch introduced some
> AVX2 regressions. Following patch is also n
Hi!
As has been noted several times in the past, and most recently e.g. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511#c13
generating backtrace from internal_error call in driver's execute is
undesirable, there is nothing wrong in the driver, the problem is that
the compiler crashed. This
On Thu, Jan 22, 2015 at 12:34:37PM -0500, David Malcolm wrote:
> Much of the jit testsuite currently segfaults on i686, after
> two in-process iterations. In odd-numbered iterations,
> gcc_jit_context_compile generates correct code, but on
> even-numbered iterations, the generated code trashes the
Hi!
The latest testcase from the PR ICEs on running out of stack during GC
collection, because we have a long chain of dw_loc_descr_nodes.
Am not adding the testcase to the testsuite because it looks too costly.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-22 Jak
Hi!
While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
some targets like i?86/x86_64 choose to populate it again during machine
reorg and some target don't free it at the end of machine reorg.
This patch updates cleanup_barrier pass, so that it adjusts basic block
boundaries and BL
On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote:
> On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek wrote:
> > On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
> >> ping.
> >>
> >> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
> >
> > W
On Thu, Jan 22, 2015 at 09:35:45AM -0700, Jeff Law wrote:
> >Though wonder if for the TARGET_LIBC_PROVIDES_SSP case LINK_SSP_SPEC
> >shouldn't be
> >#define LINK_SSP_SPEC
> >"{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:}"
> >and
> >gcc/config/freebsd.h:
On 01/23/2015 03:53 AM, Jeff Law wrote:
> On 01/22/15 12:42, Chen Gang S wrote:
>>
>>
>> Thank you very much for your help applying the 3 patches. :-)
> No problem.
>
>>
>> After finish the assignment working flow, I guess, I may have the write
>> access, then can finish these kinds of trivial pat
On 21 January 2015 at 23:18, Eric Botcazou wrote:
>> Thanks. I had wrongly made eliminate_constant_term() static, reverted
>> that change and it builds on
>> all targets in config-list.mk.
>> Committed as r219655 (hopefully nothing breaks!).
>
> Any particular reason why store_bit_field, extract_b
On 22 January 2015 at 17:17, Tejas Belagod wrote:
>
>>>
>>> LGTM.
>>>
>> Thanks, I should mention that this test fails on aarch64_be, because
>> of pending Alan's patches.
>
>
> A few big-endian fixes were checked in last night. Do you mean this?
>
> r219957 | rsandifo | 2015-01-21 17:53:04 +
Just knocking out another m68k issue since I've got my little aranym
setup running.
This BZ is a quality of code regression relative to very old versions of
GCC for two code sequences.
First, setting a bitfield to all ones. Right now we're doing this via
moveq/bfins. It's a 6 byte sequen
On Wed, Jan 21, 2015 at 05:44:03PM -0500, David Malcolm wrote:
> Don't install signal handlers in toplev.c if we're called from libgccjit,
> only install them if we're called from main.c, thus avoiding
> touching process-wide state from a shared library (see the PR for
> details of how this is curr
On 22 January 2015 at 16:22, Tejas Belagod wrote:
> On 22/01/15 14:28, Christophe Lyon wrote:
>>
>> On 22 January 2015 at 12:19, Tejas Belagod wrote:
>>>
>>> On 21/01/15 15:07, Christophe Lyon wrote:
On 19 January 2015 at 17:54, Marcus Shawcroft
wrote:
>
>
> On 19
On 01/22/2015 12:08 PM, Tobias Burnus wrote:
> "parallel/kernel loop" is handled by the function being patched (an
> assert ensures that no other directives end here). The first part of the
> function handles the parallel and kernel part, the loop itself should be
> handled by the called function.
Hi,
The attached patch is a temporary workaround for PR 29366. We've been
having support for various atomics on SH for a while, but libstdc++'s
configury makes it impossible to use when doing a cross build (PR
53579). Even if that worked, if I'm not mistaken,
config/cpu/sh/atomicity.h overrides
On Thu, 2015-01-22 at 01:51 +0100, Oleg Endo wrote:
> On Tue, 2015-01-20 at 20:05 +0900, Kaz Kojima wrote:
> > Oleg Endo wrote:
> > > The updated treg_set_expr patch is attached, which should fix the GBR
> > > issues. Tests here OK.
> > > Kaz, could you please try again?
> >
> > New tests that F
OK for trunk.
OK for 4.9 branch if it's OK with the release manager.
Do you need someone to apply it for you?
> Thanks, moved them to expmed.h.
> Boostrapped on x86_64-unknown-linux-gnu with languages: all, testing
> in progress.
> Build on all targets in config-list.mk in progress.
> Assuming it goes fine, OK to commit ?
You can install it under the obvious rule once successfully tested.
--
Eric Botcaz
On Fri, Sep 26, 2014 at 1:04 AM, Maxim Ostapenko
wrote:
> Thank you all for your help!
>
> Done in r215633.
>
> -Maxim
>
> On 09/25/2014 11:05 PM, Jeff Law wrote:
>>
>> On 09/23/14 01:14, Maxim Ostapenko wrote:
>>>
>>>
>>>
>>> 2014-09-04 Jakub Jelinek
>>> Max Ostapenko
>>>
>>> * commo
On Thu, 22 Jan 2015, Yoshinori Sato wrote:
> +h8300-*-linux*)
> + tmake_file="${tmake_file} h8300/t-h8300 h8300/t-linux"
> + tm_file="h8300/linux.h dbxelf.h elfos.h linux.h"
Toplevel linux.h should always be used together with gnu-user.h and
glibc-stdint.h.
> +#define __h8300_linux__
T
On Thu, 22 Jan 2015, Marek Polacek wrote:
> As discussed in the PR, this patch partially reverts Tom's change
> in r136209. (The is_if argument to _cpp_parse_expr is kept for the
> sake of diagnostics.)
>
> The change made sense at that time, but now we have DR#412 resolved.
> This DR deals with
In the past I had some issues on various linux platforms to build some multilib
configurations, all not building libbacktrace and libsanitizer, seen on powerpc,
ix86 and x86_64. All fail like
Running configure in multilib subdir x32
pwd: /«PKGBUILDDIR»/build/i586-linux-gnu
configure: creating cac
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Friday, January 23, 2015 2:43 AM
> On 01/21/2015 11:52 PM, Richard Biener wrote:
> >
> > I was asking for the generic expander to consider bswapHI. Rotates are
> > certainly more likely to get combined with sth else.
>
> Maybe. Alternate
Per Richi's request, I've committed this patch to gotools to add
trivial man pages for the go and gofmt commands. The cgo command is
internal and does not require a man page. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2015-01-22 Ian Lance Taylor
PR go/64595
* go.
On Thu, Jan 22, 2015 at 3:44 PM, Matthias Klose wrote:
>
> However for the libbacktrace and the libsanitizer builds, the
> AM_ENABLE_MULTILIB
> macro is included way too late. Scan the generated configure file for
> "cross_compiling" and see that the above snippet is added after the failing
> ch
The ARM run-time ABI says that long long division by zero should return
the result of calling __aeabi_ldiv0 with an argument that is either zero
if the numerator is zero, the largest value of the type if the numerator
is positive, or the smallest value of the type if the numerator is
negative.
On Thu, Jan 22, 2015 at 12:35 PM, Jakub Jelinek wrote:
>
> 2015-01-22 Jakub Jelinek
>
> * diagnostic-core.h (internal_error_no_backtrace): New prototype.
> * diagnostic.def (DK_ICE_NOBT): New kind.
> * diagnostic.c (diagnostic_action_after_output): Handle DK_ICE_NOBT
>
Thank you Segher, I will send an updated patch for stage 1.
regards,
Venkat.
On 22 January 2015 at 21:46, Segher Boessenkool
wrote:
> On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote:
>> ping. Segher do you any comments from your side.
>
> I agree combine should not transfor
Adding myself to write after approval.
- Braden Obrzut
2015-01-23 Braden Obrzut
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 220026)
+++ MAINTAINERS (working copy)
@@ -50
Hi,
On Thu, 22 Jan 2015 17:56:19, DJ Delorie wrote:
>
>
> OK for trunk.
>
> OK for 4.9 branch if it's OK with the release manager.
>
> Do you need someone to apply it for you?
No, I have write-after-approval access.
I just did not post this patch earlier, because I do not have an
environment to
Cesar Philippidis wrote:
It looks OK to me. In fact, I have an identical patch in our internal
branch and I don't know why it didn't make its way upstream or at
least into gomp-4_0-branch. Maybe it got lost after stage 1 closed.
I have now committed it as Rev. 220028.
Tobias
> I just did not post this patch earlier, because I do not have an
> environment to test the generated code on a m32c device.
You wouldn't want to wait for the results on a real device. Use the
simulator that's included with gdb for testing.
Ian Lance Taylor writes:
> On Thu, Jan 22, 2015 at 12:35 PM, Jakub Jelinek wrote:
>>
>> 2015-01-22 Jakub Jelinek
>>
>> * diagnostic-core.h (internal_error_no_backtrace): New prototype.
>> * diagnostic.def (DK_ICE_NOBT): New kind.
>> * diagnostic.c (diagnostic_action_af
At Thu, 22 Jan 2015 09:52:09 -0700,
Jeff Law wrote:
>
> On 01/22/15 01:38, Yoshinori Sato wrote:
> > Add h8300-*-linux target for h8300 linux kernel and userland.
> >
> > h8300-*-elf is some difference of standard elf.
> > h8300-*-linux is compatible of standard elf rules.
> It seems to me that y
1 - 100 of 101 matches
Mail list logo
