On Tue, 25 Oct 2011, Joseph S. Myers wrote:
On Tue, 25 Oct 2011, Richard Guenther wrote:
Joseph, does this look like a sensible use of the common
machinery? Do we want the init from COLLECT_GCC_OPTIONS
in opts-common.c instead?
Certainly there should be a single function to process
On Tue, Oct 25, 2011 at 9:30 PM, Xinliang David Li davi...@google.com wrote:
On Tue, Oct 25, 2011 at 1:02 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 24, 2011 at 6:27 PM, Xinliang David Li davi...@google.com
wrote:
Well, you seem to keep not reading what I write. I
On Tue, Oct 25, 2011 at 2:15 PM, Tom de Vries tom_devr...@mentor.com wrote:
Richard,
I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
pr50763-2.c looks like this before tail_merge_optimize:
...
std_canonical_va_list_type (union tree_node * typeD.1608)
{
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Michael Matz
Sent: Tuesday, October 11, 2011 10:45 PM
To: Kai Tietz
Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org; Richard
Henderson
Subject: Re: [patch
On Oct 21, 2011, Steve Ellcey s...@cup.hp.com wrote:
On Fri, 2011-10-21 at 21:25 +0200, Jakub Jelinek wrote:
My guess would be
http://gcc.gnu.org/viewcvs?root=gccview=revrev=180194
DEBUG_EXPR certainly shouldn't make it through into mem_loc_descriptor,
var-tracking is supposed to resolve
On Wed, Oct 26, 2011 at 07:15:20AM -0200, Alexandre Oliva wrote:
Ok to install?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/50826
* var-tracking.c (rtx_debug_expr_p): New.
(use_type): Don't use debug exprs to track non-VTA variables.
Yes,
2011/10/26 Jiangning Liu jiangning@arm.com:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Michael Matz
Sent: Tuesday, October 11, 2011 10:45 PM
To: Kai Tietz
Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
On Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 09/24/2011 01:42 PM, Richard Guenther wrote:
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the
Hi Richard,
On 25 Oct 2011, at 01:17, Richard Henderson wrote:
The Idea with this patch set is to re-arrange vector permutation
so that it can be used to implement other patterns automatically.
In particular, Altivec, SPU currently have (and Sparc VIS would need)
a large amount of boilerplate
Seems only in some cases we fault freeing an uninitialized obstack.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-10-26 Richard Guenther rguent...@suse.de
* lto-wrapper.c (run_gcc): Properly init/free obstack.
Index: gcc/lto-wrapper.c
Hi,
On Wed, 26 Oct 2011, Jiangning Liu wrote:
-
- if (LOGICAL_OP_NON_SHORT_CIRCUIT)
- {
- if (code != orig_code || lhs != orig_lhs || rhs !=
orig_rhs)
- return build2_loc (loc, code, truth_type, lhs, rhs);
- return NULL_TREE;
- }
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
Yes, this part introduced different behavior for this small case,
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
Well, as far as I understand C specification and sequence
Ian,
I committed this patch to mainline to try to fix these problems. Thanks
for testing. For this patch I bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.
with this patch, go and libgo results on Solaris 10 and 11/x86 are back
to normal, and Solaris 10 and 11/SPARC bootstraps
On Sun, Oct 16, 2011 at 02:51:01PM -0400, David Edelsohn wrote:
The patch is okay, although I am not thrilled about the need to change
the register allocation order.
Committed revision 180522. It turns out that shrink-wrapping isn't as
effective as it used to be with the 20110915 based sources
Hi,
On Tue, 25 Oct 2011, Andrew MacLeod wrote:
and new generic routines are provided as follows:
void __atomic_load (T* object, T* return_value, memory_order m)
void __atomic_store (T* object, T* new_value, memory_order m)
void __atomic_exchange (T* object, T* new_value, T* return_value,
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
Yes, this part introduced different behavior for this small case,
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
Well, as far as I
I describe the sample more closely here
extern int global = 0;
extern int *a = NULL;
void catchSigSegV( int sig )
{
a = global;
}
int foo (int j)
{
signal (SIGSEGV, catchSigSegV);
if (*a global) return 2;
return 0;
}
I admit that in most cases such a scenario is not common. This sample
On 10/26/11 14:27, Alan Modra wrote:
Committed revision 180522. It turns out that shrink-wrapping isn't as
effective as it used to be with the 20110915 based sources I was using
originally. povray Ray_In_Bound no longer gets the benefit of shrink
wrap, likely due to some cfg optimization.
On 10/26/2011 08:29 AM, Michael Matz wrote:
Hi,
On Tue, 25 Oct 2011, Andrew MacLeod wrote:
and new generic routines are provided as follows:
void __atomic_load (T* object, T* return_value, memory_order m)
void __atomic_store (T* object, T* new_value, memory_order m)
void __atomic_exchange
This completely rewrites LTO option merging. At compile (uselessly
now at WPA?) time we now stream a COLLECT_GCC_OPTIONS like string
as it comes from argv of the compiler binary. Those options are
read in by the LTO driver (lto-wrapper), merged into a single
set (very simple merge function
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
the case can be produced quite easily.
extern int global = 0;
if (*a global) ...
See? You had to
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
There's one problem left: with Solaris nawk, building libcalls.go fails
(from Solaris 8 to 11 inclusive):
nawk -f /vol/gcc/src/hg/trunk/local/libgo/go/syscall/mksyscall.awk ${files}
li
bcalls.go.tmp
nawk: syntax error at source line 47
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
the case can be produced quite easily.
extern int global = 0;
if
Thanks!
You're welcome. I have also installed the attached patch which makes minor
tweaks and fixes various issues in comments which have bugged me for years,
the most glaring one being:
Similar issue for (SUBREG:M1 (REG:M2 ...) ...) for a hard register R where
either M1 is not
On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
On 10/26/11 14:27, Alan Modra wrote:
Committed revision 180522. It turns out that shrink-wrapping isn't as
effective as it used to be with the 20110915 based sources I was using
originally. povray Ray_In_Bound no longer gets
On 25/10/11 15:16, Richard Earnshaw wrote:
The difficulty on R profile is that although BE-32 mode is obsolete,
there is a config bit that can be set to make the CPU byte-swap the
instruction stream to make it behave largely like it is running in BE-32
mode.
I think really we should be pushing
On 26/10/11 14:54, Andrew Stubbs wrote:
On 25/10/11 15:16, Richard Earnshaw wrote:
The difficulty on R profile is that although BE-32 mode is obsolete,
there is a config bit that can be set to make the CPU byte-swap the
instruction stream to make it behave largely like it is running in BE-32
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
well, if such a function is used as inline and we know for it that j has
value != 2, then we have here a big difference. For your first example,
we still have to do the memory access to *i, even if we are not
interested in result.
Actually we
Richard Henderson wrote:
Fix typos in the names of vec_extract vec_interleave tree codes.
Change vec_perm checking and expansion level.
Implement interleave via permutation.
spu: Remove vec_extract_even/odd and vec_interleave expanders.
rs6000: Remove some vec_extract_even/odd
Hi,
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in this case
is an ARROW_EXPR, thus its TREE_TYPE is NULL_TREE. I'm trying to fix
this be
On Wed, Oct 26, 2011 at 03:59:36PM +0200, Bernd Schmidt wrote:
On 10/26/11 15:54, Alan Modra wrote:
I guess the tradeoff between the classic shrink-wrap epilogue scheme
and my duplicate tail idea is whether duplicating tail blocks adds
more code than duplicating epilogues. From what I've
Ian,
Hmmm, I don't have a copy of nawk. Is it possible that it doesn't like
* == space*? You could try [ ]*.
the problem is another one: using /usr/xpg4/bin/awk, I find:
/usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function m
nawk(1) only documents match(s,ere) (i.e.
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
well, if such a function is used as inline and we know for it that j has
value != 2, then we have here a big difference. For your first example,
we still have to do the memory access to *i, even if we are not
On 10/26/2011 10:39 AM, Paolo Carlini wrote:
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in this case
is an ARROW_EXPR, thus its TREE_TYPE is
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
the problem is another one: using /usr/xpg4/bin/awk, I find:
/usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function m
nawk(1) only documents match(s,ere) (i.e. two args), and the gawk docs
state:
`match(STRING, REGEXP [,
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
So you would mean that memory dereferencing shouldn't be considered as
side-effect at all?
No. I haven't said this at all. Of course it's a side-effect, but we're
allowed to remove existing ones (under some circumstances). We're not
allowed to
On 10/26/2011 05:27 PM, Jason Merrill wrote:
On 10/26/2011 10:39 AM, Paolo Carlini wrote:
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in
On 10/26/2011 07:30 AM, Ulrich Weigand wrote:
This fails since for u == 4 and mode == V4SFmode it attempts to expand
a V4SFmode shift, which is unsupported.
Shouldn't this be using the mode of the selector rather than the mode
of the result in any case?
Yes, it should use the mode of the
Richard Henderson wrote:
On 10/26/2011 07:30 AM, Ulrich Weigand wrote:
This fails since for u == 4 and mode == V4SFmode it attempts to expand
a V4SFmode shift, which is unsupported.
Shouldn't this be using the mode of the selector rather than the mode
of the result in any case?
Yes,
I am hoping that too:) Yes, I will try to do it when I find some time.
David
On Wed, Oct 26, 2011 at 1:37 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Oct 25, 2011 at 9:30 PM, Xinliang David Li davi...@google.com wrote:
On Tue, Oct 25, 2011 at 1:02 AM, Richard Guenther
Hi,
we have an inconsistent mix: shall we do the below? Test in progress on
x86_64-linux.
Thanks,
Paolo.
//
2011-10-26 Paolo Carlini paolo.carl...@oracle.com
* typeck.c (cp_build_addr_expr_1): Use BASELINK_P.
* class.c (instantiate_type): Likewise.
Hello,
This patch series implements predication support for the selective scheduler.
It is implemented as a transformation similar to speculative execution, but
simpler in some aspects (e.g. does not require recovery code). On ia64,
combining speculation and conditional execution is supported.
On 10/26/2011 01:19 PM, Richard Henderson wrote:
!resolved to an instriction sequence. */
instruction
no no, its a mashup of restricted instruction.
ok, maybe not.
! gcc_assert (TREE_OPERAND (addr, 0) == fndecl);
! TREE_OPERAND (addr, 0) = builtin_decl_explicit(ext_call);
I do
(Note, this is a prerequisite for predication support but also is an
improvement on its own. This patch can be installed separately.)
This patch implements transformation replay mechanism (redo_transformations).
Currently, after choosing an expression to schedule and finding its original
On 10/26/2011 10:25 AM, Andrew MacLeod wrote:
hum. I suppose that wouldn't hurt. I don't think it should make any
difference since Im not modifying whats in the table, but I can give
it a shot. If it bootstraps, which I presume it will, I'll check it
in with the original decl replaced.
The
On 10/26/2011 12:41 PM, Paolo Carlini wrote:
we have an inconsistent mix: shall we do the below?
Sure, why not.
Jason
On 10/25/2011 06:45 PM, Andrew MacLeod wrote:
* builtins.c (expand_builtin_atomic_fetch_op): External calls for
'op_fetch' builtins need to instead call 'fetch_op' externals and issue
correction code.
(expand_builtin): Provide proper builtin name for external call and
On 10/25/2011 04:38 PM, Michael Meissner wrote:
On Tue, Oct 25, 2011 at 03:01:37PM -0700, Richard Henderson wrote:
Now that expand_binop handles lowering vec_extract_even to vec_perm,
we can remove the last two unnecessary vec_extract patterns from the
Altivec backend.
Ok?
Just to be
OK.
Jason
In my earlier patch to add support for --with-native-system-header-dir,
I messed up the case of a cross-compiler when not using --with-sysroot.
In that case the compiler was incorrectly searching /usr/include. This
patch restores the logic to what it used to be before my patch. As the
patch is
This patch contains the implementation of predication support.
The selective scheduler is adjusted to recognize COND_EXEC instructions. They
can be renamed like normal assignments. Selective scheduler itself will add
predicated variants of instructions in availability sets when computing them
On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
The attach patch reaps some code that is now dead
due to my recent changes for ishftc in check.c.
Regression tested on i686-*-freebsd.
2011-10-22 Steevn G. Kargl ka...@gcc.gnu.org
* simplify.c (gfc_simplify_ishftc): Reap
This RFC patch implements conversion of COND_EXEC instructions to control flow
for pre-RA selective scheduler. Something like this is needed to employ
predication support before reload.
Each COND_EXEC is converted separately to a new basic block with the
unconditional variant of the instruction,
Hi,
I've noticed that a test in g++.dg/tree-ssa/pr45605.C is Xfailed, even
though early FRE now does the devirtualization that it tests for.
True, the current scan happens over the SSA dump (which implies the
front-end was somehow supposed to do it?) but I think that given we do
perform the
Hi,
Honza requested that we do attempt to produce pass-through jump
functions even when the actual formal parameter that is being passed
on is addressable - provided that we can prove it has not changed
value, of course. The following patch does this, hopefully the
limitations of our
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused suffix parameter to
interpret_integer. So I've fixed that error. I also added a couple of
comments, and implemented the change to
On 26 Oct 2011, at 17:01, Richard Henderson wrote:
On 10/26/2011 07:30 AM, Ulrich Weigand wrote:
This fails since for u == 4 and mode == V4SFmode it attempts to
expand
a V4SFmode shift, which is unsupported.
Shouldn't this be using the mode of the selector rather than the mode
of the
Dear Steve,
Reaping implies that there is something about it that you want to keep
:-) Surely, weeding or herbicide spraying is better than reaping?
On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl
Hi,
one more / RFC, for the ICE on invalid part of these issues with '-'.
The below tries to catch the problem very early, in
cp_parser_postfix_dot_deref_expression and apparently works fine, passes
the testsuite, etc. Is it too early? Is the check tight enough?
Thanks,
Paolo.
Oct 26, 2011 03:39:09 PM, ja...@redhat.com wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused suffix parameter to
interpret_integer. So I've fixed that error. I also added a
Any questions on these patches? Are they ok for the trunk?
On 20 October 2011 12:37, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
And, finally, part with the tests.
On 20 October 2011 12:36, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
Back-end part of the patch is
On 10/26/2011 04:11 PM, 3dw...@verizon.net wrote:
Thank you Jason and Tom for your help in getting this together an putting up
with my slowness.
Thanks for all your work on this!
Jason
On 10/26/2011 04:04 PM, Paolo Carlini wrote:
The below tries to catch the problem very early, in
cp_parser_postfix_dot_deref_expression and apparently works fine, passes
the testsuite, etc. Is it too early? Is the check tight enough?
At a glance, it looks too early; it's valid to have
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct such kind of example myself... but my
patch does not regress on the testcase you wrote down. I
The compiler should issue the atomic access cannot be guaranteed error twice
on the attached testcase, but it only issues it for the stand-alone variable.
Fixed thusly, tested on i586-suse-linux, applied on the mainline.
2011-10-26 Eric Botcazou ebotca...@adacore.com
*
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct such kind of example myself... but my
patch does
The compiler aborts on a record type which contains a component of an unchecked
union type whose size is smaller than 64 bits and which is subject to a
representation clause that causes it not to start on a byte boundary.
We already have the machinery to handle this kind of composite component,
On Wed, Oct 26, 2011 at 09:55:09PM +0200, Paul Richard Thomas wrote:
Dear Steve,
Reaping implies that there is something about it that you want to keep
:-) Surely, weeding or herbicide spraying is better than reaping?
Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)
This is an internal error on the elaboration variable generated for an array of
discriminated record type whose discriminant is constraint by a dynamic upper
bound in -gnatct mode. In this mode, the compiler doesn't generate code and
gigi is invoked only to lay out types and back-annotate type
Steve,
Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)
And what, pray, does the Grim Reaper hold???
The patch is OK.
Thanks
Paul
On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve
The merge broke base/complete dtor transactional clones that we
originally implemented here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00590.html
First, ipa_tm_execute() was putting __comp_dtor's into tm_callees, which
wasn't happening pre-merge. Handling this __comp_dtor caused an ICE
The test gcc.dg/graphite/run-id-1.c requires more stack space than
Windows targets provide by default. This patch arranges for the
appropriate -Wl,--stack option (as in config/mh-mingw and
config/mh-cygwin) to be used by this test on those targets. Tested
with cross to i686-mingw32. OK to
gcc.dg/tls/thr-cse-1.c tests that there are not two calls to
__emutls_get_address in the output. Normally this just checks for
emutls_get_address.*emutls_get_address, but on some targets where the
compiler output declares the functions called in some way the testcase
has more specific tests.
gcc.target/i386/pad-4.c expects particular results from PIC code
generation - PIC in the sense of a GOT and a PLT, which is different
from the sense in which Windows code is always PIC. This patch
arranges for it to be skipped on Windows targets, similarly to other
tests such as
gcc.target/i386/pr37843-4.c tests for the form calls to a function
foo take in the output. On Windows targets this function has a
leading underscore and so the test fails. This patch allows for that
underscore in the test. Tested with cross to i686-mingw32. OK to
commit?
2011-10-26 Joseph
The background is that I was putting together some test cases for
gcc.target/sparc that make sure the most optimal setcc sequences
are being generated.
When v9, and thus conditional moves, are enabled we sometimes fall
back to conditional moves even when the addx/subx sequence is more
efficient.
On Oct 26, 2011, at 2:18 PM, Joseph S. Myers wrote:
gcc.target/i386/pr37843-4.c tests for the form calls to a function
foo take in the output. On Windows targets this function has a
leading underscore and so the test fails.
OK to commit?
Ok.
On Oct 26, 2011, at 2:18 PM, Joseph S. Myers wrote:
gcc.target/i386/pad-4.c expects particular results from PIC code
generation - PIC in the sense of a GOT and a PLT, which is different
from the sense in which Windows code is always PIC. This patch
arranges for it to be skipped on Windows
On 10/26/2011 10:35 PM, Paolo Carlini wrote:
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after -.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b-A::B::i;
I was also trying to construct
Hi!
This patch implements gather vectorization with -mavx2, if
dr_may_alias (which apparently doesn't use tbaa :(( ) can figure out
there is no overlap with stores in the loop (if any).
The testcases show what is possible to get vectorized.
I chose to add 4 extra (internal only) gather builtins
Hi,
patch looks fine for mingw 32-bit. With a small nit new test passes
for 64-bit mingw version, too. The cygwin-part looks like the mingw
one.
2011/10/26 Joseph S. Myers jos...@codesourcery.com:
gcc.dg/tls/thr-cse-1.c tests that there are not two calls to
__emutls_get_address in the
2011/10/26 Joseph S. Myers jos...@codesourcery.com:
The test gcc.dg/graphite/run-id-1.c requires more stack space than
Windows targets provide by default. This patch arranges for the
appropriate -Wl,--stack option (as in config/mh-mingw and
config/mh-cygwin) to be used by this test on those
On Oct 26, 2011, at 6:10 AM, Richard Guenther wrote:
This completely rewrites LTO option merging.
Any comments?
Wondering if It breaks darwin?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876
We have:
%{Zmultiply_defined*:-multiply_defined %*}
in LINK_SPEC.
and:
; Various linker
On Oct 26, 2011, at 2:17 PM, Joseph S. Myers wrote:
The test gcc.dg/graphite/run-id-1.c requires more stack space than
Windows targets provide by default. This patch arranges for the
appropriate -Wl,--stack option (as in config/mh-mingw and
config/mh-cygwin) to be used by this test on those
On 10/26/2011 06:27 PM, Jason Merrill wrote:
OK.
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea still
works, fwiw.
Thanks,
Paolo.
On Wed, 26 Oct 2011, Kai Tietz wrote:
Hi,
patch looks fine for mingw 32-bit. With a small nit new test passes
for 64-bit mingw version, too. The cygwin-part looks like the mingw
one.
I've committed my original patch as what I can test - you may wish to
commit followups after testing
... forgot the testcase, sorry.
Paolo.
//
// PR c++/50870
// { dg-options -std=gnu++0x }
template class V
struct impl
{
template class T static T create();
};
template class T, class U, class V, class
= decltype(implV::template createT()
-
On 10/24/2011 05:53 PM, Fabien Chêne wrote:
After looking into it a bit more, I now see things differently. The
target_decl is in fact put into the CLASSTYPE_METHOD_VEC at
instantiation time, via handle_using_decl, with the correct access.
Great.
The problem is that while parsing the
On 10/26/2011 06:20 PM, Paolo Carlini wrote:
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea still
works, fwiw.
- object_type =
On 10/27/2011 12:48 AM, Jason Merrill wrote:
On 10/26/2011 06:20 PM, Paolo Carlini wrote:
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea
.. maybe my message wasn't clear, sorry, I'm a bit tired (here it's
late): I meant to say that the non_reference tweak fixes the
non-template impl class case, but something more is needed for a
template impl (thus the new testcase). And, additionally, this issue is
a [4.6/4.7 Regression],
Hi,
I've been asked by Maxim Kuvyrkov to revive the following patch which
has not made it to 4.6. Currently, when type based devirtualization
detects a potential type change, it simply gives up on gathering any
information on the object in question. This patch adds an attempt to
actually detect
PR libstdc++/50862
* include/std/condition_variable (condition_variable_any::wait): Avoid
terminating if relocking user mutex throws during stack-unwinding.
* testsuite/30_threads/condition_variable_any/50862.cc: Add dg-require.
Fixes two more issues pointed out in
This makes sure the addx/subx sequence is used even when v9 conditional
moves are available.
It also shows the compiler that the setcc instructions emitting
-1, 0, or 1 all extend to DImode.
I left all the *x_{plus,minus}_foo and related patterns alone for
now, I'll get to those and add
Committed to trunk.
gcc/testsuite/
* gcc.target/sparc/fmaf-1.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180551
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog |2 +
gcc/testsuite/gcc.target/sparc/fmaf-1.c | 51
This patch fixes some of the problems we had with cgraph nodes for
merged functions. When merging a function that had a cgraph node emitted
for it, we were ICEing during cgraph allocation because the reader
was not checking whether the node already existed for that function.
Additionally, the
Some recent patch has exposed a reload bug. I'm seeing
libtool: compile: /home/amodra/build/gcc-curr/./gcc/xgcc
-B/home/amodra/build/gcc-curr/./gcc/ -B/home/amodra/gnu/powerpc-linux/bin/
-B/home/amodra/gnu/powerpc-linux/lib/ -isystem
/home/amodra/gnu/powerpc-linux/include -isystem
From: Alan Modra amo...@gmail.com
Date: Thu, 27 Oct 2011 13:29:56 +1030
Some recent patch has exposed a reload bug. I'm seeing
I think this might be a side effect or Eric's recent changes,
CC:'d.
More extensive testing showed that we have to force the usage of
v9 scc patterns when comparing DImode values with comparison codes
other than EQ and NE.
Soon we'll be able to add exceptions this this, because VIS3 has addxc
and addxccc instructions which test the 64-bit carry condition.
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
the problem is another one: using /usr/xpg4/bin/awk, I find:
/usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function m
nawk(1) only documents match(s,ere) (i.e. two args), and the gawk docs
state:
`match(STRING, REGEXP [,
1 - 100 of 101 matches
Mail list logo
