OK.
Jason
On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
> On Wed, 15 Feb 2012, Christian Bruel wrote:
>
>> Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
>> looks safe from my testing, because the loc is inserted using
>> 'protected_set_expr_location', whereas no loc for a constant c
On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
wrote:
> Paolo Bonzini writes:
>
>> This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
>> gcc_AC_INITFINI_ARRAY.
>
> Here's an updated patch that does so. During testing, I found one
> additional complication, though. With the Sun
Hi Patrick,
On 16 Feb 2012, at 02:17, Patrick Marlier wrote:
Index: libgcc/config/darwin-crt-tm.c
===
--- libgcc/config/darwin-crt-tm.c (revision 184293)
+++ libgcc/config/darwin-crt-tm.c (working copy)
@@ -103,8 +103,6
On Thu, 16 Feb 2012, Jakub Jelinek wrote:
> Hi!
>
> On this testcase we ICE, because slpeel_tree_peel_loop_to_edge is first
> called with a loop that has a virtual PHI and no virtual PHI in the loop
> exit bb and this function doesn't update the vop properly after inserting
> second loop and addi
>
>
> On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
>> On Wed, 15 Feb 2012, Christian Bruel wrote:
>>
>>> Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
>>> looks safe from my testing, because the loc is inserted using
>>> 'protected_set_expr_location', whereas no loc for a
Hi,
Due recent regression test-runs for x86_64-w64-mingw32, I noticed that
some tests actual were failing
due internal-compiler error for code-paths using split_double
functions on PCREL symbols.
The cause for this is that this unspec didn't allowed
constant-interger displacements. This patch fix
The hunk about config/i386/predicates.md (x86_64_immediate_operand) I
recet here,
actual it would lead to none-PIC code.
So updated patch:
2012-02-16 Kai Tietz
* config/i386/i386.c (legitimate_pic_address_disp_p): Allow
interger-constant displacement for UNSPEC_PCREL.
Tested
On Thu, Feb 16, 2012 at 12:49 PM, Christian Bruel
wrote:
>
>>
>>
>> On 02/15/2012 06:03 PM, Joseph S. Myers wrote:
>>> On Wed, 15 Feb 2012, Christian Bruel wrote:
>>>
Removal of this NOP_EXPR if !CAN_HAVE_LOCATION_P fixes the problem.
looks safe from my testing, because the loc is insert
neghi2's "r,0" alternative reads
com %B0
neg %A0
sbc %B0,__zero_reg__
inc %B0
The INC commutates with the NEG+SBC and can be moved 2 instructions up:
com %B0
inc %B0
neg %A0
sbc %B0,__zero_reg__
COM+INC can be fused to NEG:
neg %B0
neg %A0
sbc %B0,__zero_reg__
with the additional benefit that
First, if there isn't a bug in Bugzilla for this problem please file one
so it's properly tracked if it takes a while to work out how to solve it.
As I understand it from your testcases, it's a matter of certain code that
is not valid ISO C but you would like to be accepted unless -pedantic, by
Greetings,
Given the recent discussion on getting 4.6 cleaned up, I thought I'd
check back on this one. Thanks!
Bill
On Fri, 2012-02-10 at 14:58 -0600, William J. Schmidt wrote:
> This patch backports the two recent trunk fixes for powerpc64
> vectorization degradations. The fixes are largely
On Thu, Feb 16, 2012 at 8:18 AM, Quentin Neill
wrote:
> On Tue, Feb 14, 2012 at 9:01 PM, Mike Stump wrote:
>> On Feb 14, 2012, at 8:39 AM, Quentin Neill wrote:
>>> Thanks for the fix. This seemed familiar, and upon review it looks
>>> like I never committed this fix:
>>> http://gcc.gnu.org/ml/gc
On 02/16/2012 01:56 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, if SET_SRC MEM (with REG_EQUIV note) isn't a MEM
that can be used in general operations, but requires some specialized
instruction to load it, decreasing its mem_cost results sometimes in
worse code, the MEM is loaded with
On 11/02/12 01:11, Richard Henderson wrote:
On 02/08/2012 08:28 AM, Andrew Stubbs wrote:
Unfortunately, these don't work in Thumb mode (no IT block), and I'd have to
add arith-shift variants, I think, for ARM mode to work.
H ... I'll try again.
Does it work to simply use branches initial
Hello guys,
Here is a patch which adds support of first part of Intel TSX extensions.
Could you please have a look?
ChangeLog entry:
2012-02-16 Kirill Yukhin
* common/config/i386/i386-common.c (OPTION_MASK_ISA_RTM_SET):
New.
(OPTION_MASK_ISA_RTM_UNSET): Ditto.
(
Here is link to the description of TSX:
http://software.intel.com/en-us/blogs/2012/02/07/transactional-synchronization-in-haswell/
K
On Thu, Feb 16, 2012 at 8:06 PM, Kirill Yukhin wrote:
> Hello guys,
> Here is a patch which adds support of first part of Intel TSX extensions.
>
> Could you pleas
Hi Mike, Hi Steve,
* config/rx/rx.h: Remove SMALL_REGISTER_CLASSES.
I wasn't sure if these are obvious, because I already removed the
definition from rx.h before, see ChangeLog-2010. Maybe someone put it
back intentionally.
Nick did it (intentionally) with:
Sorry about that - sanfu
Hi,
On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
> +(define_insn "xbegin_1"
> + [(set (match_operand:SI 0 "register_operand" "=a")
> +(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN))
> + (set (match_operand:BLK 1 "" "")
> +(unspec_volatile:BLK [(match_dup 1)] UNSPECV_XBEGIN))]
> +
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
> On 02/16/2012 11:06 AM, Kirill Yukhin wrote:
> > +(define_insn "xbegin_1"
> > + [(set (match_operand:SI 0 "register_operand" "=a")
> > +(unspec_volatile:SI [(match_dup 0)] UNSPECV_XBEGIN))
> > + (set (match_operand:BLK 1 "" "
On 02/16/2012 02:14 PM, Joseph S. Myers wrote:
> First, if there isn't a bug in Bugzilla for this problem please file one
> so it's properly tracked if it takes a while to work out how to solve it.
OK, tracked with PR52283
> As I understand it from your testcases, it's a matter of certain code
On Feb 15, 2012, at 10:32 PM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux,
> committed to trunk as obvious:
>
> 2012-02-16 Jakub Jelinek
>
> PR translation/52264
> * cgraphunit.c (verify_cgraph_node): Fix a typo.
>
> --- gcc/cgraphunit.c.jj 2
On Feb 16, 2012, at 8:59 AM, Mike Stump wrote:
>> -error ("Alias has non-alias refernece");
>> +error ("Alias has non-alias reference");
>
> Unless Alias means something very specific, the english word should be lower
> case. Since this is the middle end, it should not refer to a
On Thu, Feb 16, 2012 at 11:26:53AM -0500, Patrick Marlier wrote:
> Here you cannot specify your fallback instruction address. Since those
> primitives provide high performance speculative code, I would prefer to
> move my fallback code far away from the speculative code path to improve
> the cod
On Thu, Feb 16, 2012 at 1:32 AM, Richard Guenther
wrote:
> On Wed, Feb 15, 2012 at 6:09 PM, Rainer Orth
> wrote:
>> Paolo Bonzini writes:
>>
>>> This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
>>> gcc_AC_INITFINI_ARRAY.
>>
>> Here's an updated patch that does so. During t
These look fine. I'll defer to others on whether it should wait to Phase 1.
I had tried to make divmod work but never figured out the reason why it did
not. Thanks for answering that question.
As for the subregs that Richard commented on -- I will gladly admit that this
target isn't all clean
On 02/16/2012 11:47 AM, Jakub Jelinek wrote:
if you want to use different fallback code from the transaction code.
So the above is right and needed, though perhaps we might want
a combine pattern or peephole to turn the
movl $-1, %eax
xbegin .+6
cmpl %eax, $-1
jne 1f
sequence into
movl $-1, %eax
On 02/15/12 12:07, Jakub Jelinek wrote:
On Wed, Feb 15, 2012 at 11:59:15AM -0600, Aldy Hernandez wrote:
Hmmm, isn't %K for trees? We're talking gimple, and FUNCTION_DECLs,
which don't have a TREE_BLOCK, here.
Gimple stmts have gimple_block, I guess you'd need to create some tree
and set its T
On 02/16/2012 04:23 AM, Kai Tietz wrote:
> 2012-02-16 Kai Tietz
>
> * config/i386/i386.c (legitimate_pic_address_disp_p): Allow
> interger-constant displacement for UNSPEC_PCREL.
Ok.
r~
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> The patch allowed the bootstrap to complete successfully, but since
>> libgo.so now has undefined references to log2 and trunc, all Go
>> execution still fail.
>
> I went ahead and removed the uses of the libc log2 and trunc functions,
> on the
Hello,
I just created a new branch (and announced it on the gcc mailing
list). This patch updates the web page docs to briefly describe the
new branch.
-- Caroline Tice
cmt...@google.com
? my-patch.txt
? htdocs/svn.html.~1.168.~
Index: htdocs/svn.html
On 16/02/12 14:04 , Caroline Tice wrote:
Hello,
I just created a new branch (and announced it on the gcc mailing
list). This patch updates the web page docs to briefly describe the
new branch.
The patch looks fine. When you have a more complete description for the
project, could you add a l
On 02/16/12 12:04, Jakub Jelinek wrote:
On Thu, Feb 16, 2012 at 11:46:33AM -0600, Aldy Hernandez wrote:
#GOOD
houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O0 -quiet -w
In function 'asmfunc',
inlined from 'f' at a.c:13:10:
a.c:7:3: error: asm not allowed in 'transaction_safe' function
#BAD
ho
On Thu, Feb 16, 2012 at 11:46:33AM -0600, Aldy Hernandez wrote:
> #GOOD
> houston:/build/t2/gcc$ ./cc1 a.c -fgnu-tm -O0 -quiet -w
> In function 'asmfunc',
> inlined from 'f' at a.c:13:10:
> a.c:7:3: error: asm not allowed in 'transaction_safe' function
>
> #BAD
> houston:/build/t2/gcc$ ./cc1 a
Hi Jon,
> On 15 February 2012 17:44, Rainer Orth wrote:
>>
>> Ok for mainline?
>
> Yes, although I would prefer the config option to be
> --enable-libstdcxx-gthreads or --enable-libstdcxx-threads, since I
I'll go for the latter since the use of gthreads is just an
implementation detail.
> prefer
Lambda closure object initialization uses VEC_INIT_EXPR to express array
copy, which confused dump_expr. But there's no reason to print out the
details of that initialization at all; we should just say "closure
object" and be done with it.
Of course, this is another instance of problems with
Rainer Orth writes:
> FAIL: time
>
> No hint why.
>
> FAIL: net/http
>
> Again, no hint what's wrong.
Sometimes it helps to run
make GOTESTFLAGS=--keep time/check
and then run
LD_LIBRARY_PATH=.libs gotestN/a.out
That will sometimes print something useful. It seems that some times
"H.J. Lu" writes:
> GNU assembler understands:
>
> .section.init_array*
>
> If Solaris assembler doesn't, I don't know how it will work
> with .init_array with priority.
That's not the issue: merging .init_array* sections is handled all right
by gld irrespective of sh_type; there's nothi
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> FAIL: time
>>
>> No hint why.
>>
>
>> FAIL: net/http
>>
>> Again, no hint what's wrong.
>
> Sometimes it helps to run
> make GOTESTFLAGS=--keep time/check
> and then run
> LD_LIBRARY_PATH=.libs gotestN/a.out
I know, and that would
I found there are too many rejecting pseudo splits because I excluded
most common case of choosing register class for split pseudo.
The following patch fixes this.
Committed as rev. 184315.
2012-02-16 Vladimir Makarov
* lra-constraints.c (choose_split_class): Check allocno_class too.
Richard Guenther writes:
> I'm not sure about the varasm.c change - it's definitely not a no-op
> (callback will be not set, and the flags will be different). Certainly
As I've demonstrated in my response to H.J., the effect with gas is none.
> the current code is inconsistent wrt the priority
Andrew MacLeod writes:
> On 02/09/2012 09:38 AM, Uros Bizjak wrote:
>> On Thu, Feb 9, 2012 at 3:12 PM, Aldy Hernandez wrote:
>>
>> It was me, and the sole reason was that timeout didn't worked and the
>> log filled the file system. After timeout functionality was fixed, the
>> timeout was forced
On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote:
> Even with the 20-second timeout, I was seeing lots of failures on slower
> machines, like sparc, alpha, or mips. I've had good success with the
> following patch which uses the default dejagnu timeout instead of some
> arbitrary value. It even ta
Hi!
We should IMHO ignore the clobber stmts when deciding if we can tail
call optimize or tail recurse.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-02-16 Jakub Jelinek
PR tree-optimization/52285
* tree-tailcall.c (find_tail_calls): Ignore gimple_
Hi,
templatestruct A
{
int foo;
struct B : A { using A::foo; }; // (1)
struct C : A { using A::foo; }; // (2)
};
There are two problems in this PR. Firstly, for (1) it seems to work,
but in reality the lookup for foo is not performed. Hence, I have
modified dfs_lookup_base so that (1
On 02/16/2012 01:47 PM, Fabien Chêne wrote:
+ tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo));
BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here?
For (2), the lookup was failing because the flag
BINFO_DEPENDENT_BASE_P was set. It think it should not be set for t
On 02/16/2012 04:32 PM, Mike Stump wrote:
On Feb 16, 2012, at 12:47 PM, Rainer Orth wrote:
Even with the 20-second timeout, I was seeing lots of failures on slower
machines, like sparc, alpha, or mips. I've had good success with the
following patch which uses the default dejagnu timeout instead
This patch to the Go compiler lowers constant string comparisons at
compile time rather than runtime. Not doing this led to a compiler
crash on code like
var V = "a" > "b"
because the compiler thinks that expressions involving only constants do
not require any runtime initialization, but string
On 02/16/2012 11:54 AM, Richard Henderson wrote:
> I'll work on a proper fix to the unwinder; we can then decide
> whether and when to apply it...
Something like this. Not the best of solutions, but we've run out
of bits in the exception structure, and thus we can't use this
solution universally
With this patch, I'm getting:
gcc/cp/pph-in.c: In function 'tree_node* pph_in_tree(pph_stream*)':
gcc/cp/pph-in.c:1694:70: error: 'decl_declared_inline' may be used
uninitialized in this function
[-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1644:8: note:
'decl_declared_inline' was declared here
gc
On 02/16/2012 01:45 PM, Jakub Jelinek wrote:
> 2012-02-16 Jakub Jelinek
>
> PR tree-optimization/52285
> * tree-tailcall.c (find_tail_calls): Ignore gimple_clobber_p stmts
> when deciding if a call is a tail call or tail recursion.
Ok.
r~
2012/2/16 Jason Merrill :
> On 02/16/2012 01:47 PM, Fabien Chêne wrote:
>>
>> + tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo));
>
>
> BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here?
>
>
>> For (2), the lookup was failing because the flag
>> BINFO_DEPENDENT_BASE_P
This patch to the Go frontend avoids crashing the compiler when an
erroneous program causes it to attempt to build a type descriptor for an
unnamed integer type, or other types that should never be unnamed.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
On 02/16/2012 02:12 PM, Richard Henderson wrote:
[...]
index 1c19f8b..59d4560 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals;
with arguments ARGS. */
#define PMODE_INSN(NAME, ARGS) \
(Pmode =
David Daney writes:
> On 02/16/2012 02:12 PM, Richard Henderson wrote:
> [...]
Thanks for the patch.
>> index 1c19f8b..59d4560 100644
>> --- a/gcc/config/mips/mips.h
>> +++ b/gcc/config/mips/mips.h
>> @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals;
>> with argum
On 2/16/12, Diego Novillo wrote:
> With this patch, I'm getting:
>
> gcc/cp/pph-in.c: In function 'tree_node* pph_in_tree(pph_stream*)':
> gcc/cp/pph-in.c:1694:70: error: 'decl_declared_inline' may be used
> uninitialized in this function
> [-Werror=maybe-uninitialized]gcc/cp/pph-in.c:1644:8: note
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 German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.7-b20120128.de.po', h
On Thu, 16 Feb 2012, Richard Henderson wrote:
> On 02/16/2012 11:54 AM, Richard Henderson wrote:
> > I'll work on a proper fix to the unwinder; we can then decide
> > whether and when to apply it...
>
> Something like this. Not the best of solutions, but we've run out
> of bits in the exception
On 16 February 2012 19:10, Rainer Orth wrote:
>>> Btw., the ChangeLog lies at one point: I didn't include the
>>> configure.html update since I lack the required tools. I'd appreciate
>>> it if some of the libstdc++ maintainers could handle this for me after
>>> checking.
>>
>> Sure, I can do that
OK.
Jason
Hi Diego & Ollie,
Could you guys take a look?
-Doug
On Mon, Feb 13, 2012 at 6:41 PM, Doug Kwan wrote:
> Hi,
>
> This patch adds support for powerpc*-grtev2-linux-gnu. The changes
> include:
>
> 1. Relocating the dynamic linker using a run-time root prefix.
> 2. Using different library sett
On Feb 15, 2012, Richard Sandiford wrote:
> I'm fine with putting it in and seeing what breaks. But I'd really
> prefer if we knew in theory. :-)
Ok, I dove into the problem without a testcase, and I managed to trigger
it on other platforms after tweaking get_addr a bit so as use loc lists
form
62 matches
Mail list logo
