At one time I know I had the max_size == size test in
valid_ao_ref_for_dse. But it got lost at some point. This is what
caused the Ada failure.
Technically it'd be OK for the potentially dead store to have a variable
size as long as the later stores covered the entire range of the
potenti
In file included from ../../../libgo/runtime/runtime.h:113:0,
from ../../../libgo/runtime/go-libmain.c:15:
./runtime.inc:650:8: error: redefinition of 'struct siginfo'
struct siginfo {
^~~
In file included from /usr/include/signal.h:79:0,
from ../../..
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-7.1-b20170101.sv.po',
On Fri, Jan 13, 2017 at 9:26 AM, Ville Voutilainen
wrote:
> Update patch with splices for __carry added. Hopefully this resolves
> the remaining concerns that we had.
On rereading the patch today, the size calculation for merge() appears
to be backwards. [__first2, __last2) consists of the nodes
On 15 January 2017 at 18:42, Tim Song wrote:
> On rereading the patch today, the size calculation for merge() appears
> to be backwards. [__first2, __last2) consists of the nodes not
> transferred into *this, so the new size of __x should be __dist while
> this->size() should be incremented by (__
On 15 January 2017 at 19:01, Ville Voutilainen
wrote:
> On 15 January 2017 at 18:42, Tim Song wrote:
>> On rereading the patch today, the size calculation for merge() appears
>> to be backwards. [__first2, __last2) consists of the nodes not
>> transferred into *this, so the new size of __x should
On 15 January 2017 at 19:07, Ville Voutilainen
wrote:
> On 15 January 2017 at 19:01, Ville Voutilainen
> wrote:
>> On 15 January 2017 at 18:42, Tim Song wrote:
>>> On rereading the patch today, the size calculation for merge() appears
>>> to be backwards. [__first2, __last2) consists of the node
On 15 January 2017 at 19:22, Ville Voutilainen
wrote:
> Hmm, and yeah, your test uses a different throw-after number, so I
> should change the tests to do the same. :)
In other words, like in the attached patch.
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc
b/libstdc
Andreas Schwab writes:
> In file included from ../../../libgo/runtime/runtime.h:113:0,
> from ../../../libgo/runtime/go-libmain.c:15:
> ./runtime.inc:650:8: error: redefinition of 'struct siginfo'
> struct siginfo {
> ^~~
> In file included from /usr/include/signal.h
Hello!
Attached patch removes now unneeded call to recog in
ix86_legitimate_combined_insn.
Thanks Alan for his guidance!
2017-01-15 Uros Bizjak
* config/i386/i386.c (ix86_legitimate_combined_insn): Do not
call recog here. Assert that INSN_CODE (insn) is non-negative.
Bootstrapped a
On Sat, Jan 14, 2017 at 09:16:11PM -0700, Jeff Law wrote:
> > The force_operand on complex count expression in doloop_modify can invoke
> > various expander routines that are assuming there is rtl unsharing after
> > them (which is the case for expansion). When later optimizations invoke
> > the e
On Sun, Jan 15, 2017 at 10:08 AM, Rainer Orth
wrote:
> Andreas Schwab writes:
>
> Same on Solaris. However, before I even get there, I hit
>
> make[4]: *** No rule to make target 'golang_org/x/net/lif/lif.lo', needed by
> 'libgo.la'. Stop.
>
> Fixed like this:
Thanks. Committed.
Ian
On Sun, Jan 15, 2017 at 3:12 AM, Andreas Schwab wrote:
> In file included from ../../../libgo/runtime/runtime.h:113:0,
> from ../../../libgo/runtime/go-libmain.c:15:
> ./runtime.inc:650:8: error: redefinition of 'struct siginfo'
> struct siginfo {
> ^~~
> In file incl
On 01/13/2017 05:59 AM, Rainer Orth wrote:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -26391,6 +26391,13 @@ be as many clauses as you need. This ma
@end table
+The switch matching text @code{S} in a %@{@code{S}@},
+%@{@code{S}
On 01/13/2017 05:19 AM, Torsten Duwe wrote:
Changes since v4: hopefully addressed all of Sandra's requests
and suggestions concerning the documentation snippets, thanks
for the feedback. If it still isn't clear, feel free to rephrase
-- I'm a programmer, not a technical writer.
Thanks, this ma
On Sat, Jan 14, 2017 at 09:19:52AM -0600, Segher Boessenkool wrote:
> On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> > > Have you checked if/what this changes for some bigger code?
> >
> > Well, the bootstrap was all langs (minus ada due to not having ada
> > installed) and ppc32 mu
expand function on __builtin_mul_overflow is missing gen a truncdisi2
after muldi3 since it's just call gen_lowpart and it's not consider
TRULY_NOOP_TRUNCATION == false,
This patch has been run gcc testsuite for mips64, x86-64 and
riscv64/riscv32, fix mips64 and riscv64 for
builtin-arith-overflow-
On Sun, 15 Jan 2017, Jakub Jelinek wrote:
> On Sat, Jan 14, 2017 at 09:16:11PM -0700, Jeff Law wrote:
> > > The force_operand on complex count expression in doloop_modify can invoke
> > > various expander routines that are assuming there is rtl unsharing after
> > > them (which is the case for exp
On Mon, Jan 16, 2017 at 02:42:08PM +0800, Kito Cheng wrote:
> 2017-01-16 Kito Cheng
> Kuan-Lin Chen
>
> PR target/PR79079
> * gcc/internal-fn.c (expand_mul_overflow): Use convert_modes instead
> of
> gen_lowpart.
No gcc/ prefix in gcc/ChangeLog.
> @@ -1505
On Mon, Jan 16, 2017 at 08:23:32AM +0100, Richard Biener wrote:
> > I think it is not as bad. I think the problem is only when you
> > force_operand 1) after expansion 2) with complicated expression.
> > I think if you force_operand just with something that appears in some insn,
> > it is very unl
20 matches
Mail list logo
