On Wed, Mar 28, 2012 at 1:07 AM, Vladimir Makarov vmaka...@redhat.com wrote:
The following patch implements general spilling one class pseudos
into another class hard registers *instead of memory* in LRA.
Can't find the patch itself
- Joey
On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson r...@redhat.com wrote:
On 03/27/12 09:37, Uros Bizjak wrote:
Now, in this particular case, there might be another option to
avoid this hassle completely: I understand that this UNSPEC is
simply a magic marker to make the address use the
On Tue, 27 Mar 2012, Eric Botcazou wrote:
Changelog:
* expmed.c (store_bit_field_1): Fix wordnum value for big endian targets
The author line was missing so I put:
2012-03-27 Aurelien Buhrig aurelien.buhrig@gmail.com
PR middle-end/51893
* expmed.c
On Tue, 27 Mar 2012, Eric Botcazou wrote:
Bootstrapped/regtested on x86_64-suse-linux, applied on mainline. Should
it be applied to the release branches as well?
2012-03-26 Eric Botcazou ebotca...@adacore.com
PR rtl-optimization/52629
* reload1.c (count_pseudo):
On Sat, Mar 24, 2012 at 16:13, Thomas Koenig tkoe...@netcologne.de wrote:
Hello world,
this patch uses division by known sizes (which can usually be replaced
by a simple shift because intrinsics have sizes of power of two) instead
of division by the size extracted from the array descriptor
On 03/27/2012 05:42 PM, Andreas Schwab wrote:
Sebastian Hubersebastian.hu...@embedded-brains.de writes:
What is the purpose of the ctrbegin.o and crtend.o?
The same as crtbeginS.o and crtendS.o, except for non-shared linking.
Ok, so if I add additional files here:
What's the impact of this bug? If it is a wrong-code or ice-on-valid
bug then it's ok for the 4.7 branch.
Neither, it's an out-of-bounds memory access in reload1.c with apparently no
visible effects as it has been introduced with IRA (4.4 series).
--
Eric Botcazou
Vladimir Makarov vmaka...@redhat.com writes:
The following patch implements general spilling one class pseudos
into another class hard registers *instead of memory* in LRA.
Nice.
Just double checking: would it automatically disable itself with
-mno-sse2 for code that does not support the
On Tue, Mar 27, 2012 at 3:17 PM, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
And the patch is now attached
This does not look like it would compile on any other target.
Richard.
Ramana
On Wed, Mar 28, 2012 at 11:57 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Mar 27, 2012 at 3:17 PM, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
And the patch is now attached
This does not look like it would compile on any other target.
Looks like the
On Tue, Mar 27, 2012 at 7:48 PM, H.J. Lu hongjiu...@intel.com wrote:
OPTION_MASK_ISA_64BIT 32bit x86-64 code or 64bit x86-64 code
OPTION_MASK_ISA_X86_64 64bit x86-64 code
OPTION_MASK_ISA_X32 32bit x86-64 code
How annoying, the first one doesn't mean
Backported from trunk to 4.7:
PR52737 - -mtiny-stack shall not influence multilib selection
http://gcc.gnu.org/viewcvs?root=gccview=revrev=185908
PR52692 - Add support for avr-specific built-ins + LTO
http://gcc.gnu.org/viewcvs?root=gccview=revrev=185911
http://gcc.gnu.org/viewcvs?root=gccview=revrev=185912
Reverts the changes for
PR51002 - SP_H register used even on targets without SP_H
PR51002 has been re-scheduled for 4.7
When I first tried to build mainline on Solaris 11 Update 1, the libgo
build failed. In gen-sysinfo.go, I have
type _zone_net_addr_t struct { zna_family uint16; zna_plen uint16; zna_addru
struct { znau_addr6 _in6_addr; }; }
type _zone_net_data_t struct { zn_type int; zn_linkid uint32; zn_naddrs
Hi!
The attached testcase shows that already for 32x signed char
vector shuffles using the index element type for computing
BIT_FIELD_REF positions is wrong - bytes 16 and above
in the vector are bits 128 and above, and if idx
has signed char type, that overflows.
Fixed thusly,
On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
This is a re-post of the patch I posted for comments in January to
address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589. The patch
modifies reassociation to expose repeated factors from
Hi!
The builtin_decl_explicit_p changes broke the __builtin_va_start
- __builtin_next_arg folding, previously it was testing that
built_in_decls[BUILT_IN_NEXT_ARG] == NULL (and giving up in that case),
so the conversion missed !.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
On 03/28/2012 02:39 AM, Ye Joey wrote:
On Wed, Mar 28, 2012 at 1:07 AM, Vladimir Makarovvmaka...@redhat.com wrote:
The following patch implements general spilling one class pseudos
into another class hard registers *instead of memory* in LRA.
Can't find the patch itself
Sorry, my bad.
For arrays of size zero the C++ frontend generates a TYPE_DOMAIN
using build_index_type (which is hardcoded to unsigned sizetype)
passing it -1 (in ssizetype ...) as the maximum index (build_index_type
will use size_zero_node as minimum index). That works all well
as long as sizetype constants
On Wed, Mar 28, 2012 at 4:00 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
The builtin_decl_explicit_p changes broke the __builtin_va_start
- __builtin_next_arg folding, previously it was testing that
built_in_decls[BUILT_IN_NEXT_ARG] == NULL (and giving up in that case),
so the conversion
I am testing the following patch to remove the endless recursion
between rshift_double and lshift_double trying to make their
signed count argument positive by simple negation. I opted to
make rshift_double private because it is the deprecated interface
and is no longer used.
Bootstrap and
Hi,
this is a regression present on the mainline and 4.7 branch for platforms using
SJLJ exceptions, e.g. the ARM. The scenario is as follows: the main procedure
calls My_Iterators.Current which has a pragma Inline on it. The procedure
also has exceptions handlers so there is an abnormal edge
OK.
Jason
Hi,
another kind of bit fields supported in Ada are floating-point bit fields.
They work fine, except that varasm.c rejects static constants (CONSTRUCTORs)
containing them. The attached patch plugs this hole.
Tested on x86_64-suse-linux, OK for mainline?
2012-03-28 Eric Botcazou
Jason Merrill ja...@redhat.com writes:
+ /* This can happen for template parms of a template template
+parameter, e.g:
+
+templatetemplateclass T, class U class TT struct S;
+
+Consider the level of the parms of TT; T and U both have
+level 2; TT has
Hi again,
On 03/26/2012 09:31 PM, Jason Merrill wrote:
On 03/26/2012 07:22 AM, Paolo Carlini wrote:
My basic idea so far is very simple:
--- class.c (revision 185792)
+++ class.c (working copy)
@@ -1001,6 +1001,10 @@ add_method (tree type, tree method, tree
using_dec
destructor,
type);
}
+
Hi Jeff,
Thank you for replying to the post.
How is this different than the function vector support that is
already in GCC for the H8/300 series processors?
Current H8/300 implementation of function vector seems inappropriate.
This patch fixes following problems from it.
1. Attribute
On 03/28/2012 11:02 AM, Paolo Carlini wrote:
+ !comp_except_specs (new_exceptions, old_exceptions, ce_normal)
+ /* Special case in C++11: noexcept has been deduced as true for
+the declaration and there is no exception-specification on the
+definition. */
+
On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
For:
templateclass T, templateclass U, T class TT struct S;
the parms of TT do have a level 1 that contains the parm T. It seems to
me that we need T and U to have different levels here, so both cannot
have level 1.
Why do we need them to
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which may
even often be the only statement).
After playing with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int);
auto g(int i){return f(i);}
If T is a
On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
This is a re-post of the patch I posted for comments in January to
address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589. The patch
Jason Merrill ja...@redhat.com writes:
On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
For:
templateclass T, templateclass U, T class TT struct S;
the parms of TT do have a level 1 that contains the parm T. It seems to
me that we need T and U to have different levels here, so both
Hi,
when testing a different patch of mine I hit the assert in
insert_clobbers_for_var which is there to make sure that there is a
call to builtin_stack_save in a BB with or dominating a call to
builtin_alloca_with_align. In my case that was not true because the
DOM pass duplicated the call to
On Wed, 28 Mar 2012, Gabriel Dos Reis wrote:
On Wed, Mar 28, 2012 at 10:51 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Sun, 25 Mar 2012, Marc Glisse wrote:
- a first goal is simple functions, with a single return statement (which
may even often be the only statement).
After playing
On Wed, Mar 28, 2012 at 3:17 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Mar 27, 2012 at 7:48 PM, H.J. Lu hongjiu...@intel.com wrote:
OPTION_MASK_ISA_64BIT 32bit x86-64 code or 64bit x86-64 code
OPTION_MASK_ISA_X86_64 64bit x86-64 code
OPTION_MASK_ISA_X32
On Wed, 28 Mar 2012, H.J. Lu wrote:
collect2.c:/* TARGET_64BIT may be defined to use driver specific
functionality. */
collect2.c:#undef TARGET_64BIT
collect2.c:#define TARGET_64BIT TARGET_64BIT_DEFAULT
As previously discussed, this use is a bug; TARGET_64BIT should be
considered private to
On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
What do we do with TARGET_64BIT and TARGET_64BIT_DEFAULT? They
are used to indicate 64bit ISA like:
collect2.c:/* TARGET_64BIT may be defined to use driver specific
functionality. */
collect2.c:#undef TARGET_64BIT
On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
What do we do with TARGET_64BIT and TARGET_64BIT_DEFAULT? They
are used to indicate 64bit ISA like:
collect2.c:/* TARGET_64BIT may be defined to use
On Mar 28, 2012, at 12:44 PM, Joseph S. Myers wrote:
config/darwin.c: TARGET_64BIT
config/darwin.c: TARGET_64BIT
config/darwin.c: : (TARGET_64BIT ? 2
config/darwin.c: if (TARGET_64BIT global_options.x_flag_objc_abi 2)
config/darwin.c: if
On 03/28/2012 12:08 PM, Dodji Seketeli wrote:
On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
templateclass T, templateclass U, T class TT struct S;
Then, if U and T have the same level, how do we represent the full set
of template parms up to U for instance? I mean if that TREE_LIST of
Committed as trivial/obvious in revision 185924. Thanks to Brian Ames
for spotting the error!
2012-03-28 Paul Thomas pa...@gcc.gnu.org
Tobias Burnus bur...@gcc.gnu.org
PR fortran/52652
* match.c (gfc_match_allocate, gfc_match_deallocate): Change
not.. or to
On Tue, Mar 27, 2012 at 5:21 PM, Meador Inge mead...@codesourcery.com wrote:
Hi All,
This patch fixes an issue reported by one of our customers where an
instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
processor. The instruction causing the exception is
On 03/28/2012 03:20 PM, Marc Glisse wrote:
I agree that it works like initialization, and like lambdas, so that
ship has sailed. I assume there were good reasons for that, even if they
are not obvious, I know things can be trickier than they appear.
However, I can't help thinking that there is
On Wed, Mar 28, 2012 at 2:10 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Mar 28, 2012 at 10:13 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
What do we do
On 03/28/2012 03:59 PM, David Edelsohn wrote:
On Tue, Mar 27, 2012 at 5:21 PM, Meador Inge mead...@codesourcery.com wrote:
Hi All,
This patch fixes an issue reported by one of our customers where an
instruction
exception gets raised when using '__sync_fetch_and_add' on a PowerPC 440
This patch from Rémy Oudompheng fixes a couple of compiler crashes.
The compiler would crash on:
if true || x, y := 1, 2 {}
and
var s string
s = append(s, hello)
Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline and 4.7
branch.
Ian
diff -r f18209760e98
Hello!
Attached patch adds AVX modes to ix86_modes_tieable_p, in the same way
as other SSE and MMX modes.
Additionally, the patch removes unneeded gen_lowpart calls from
ix86_expand_vector_move_misalign. The mode function argument just
duplicates the mode of operands for convenience.
2012-03-28
Vector support has been seriously damaged in Ada since the re-implementation of
the VECTOR_CST node. This fixes crashes.
Tested on i586-suse-linux, applied on the mainline as obvious.
2012-03-28 Eric Botcazou ebotca...@adacore.com
* tree.c (tree_size) VECTOR_CST: New case.
On Wed, Mar 28, 2012 at 2:17 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Mar 28, 2012 at 2:10 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Mar 28, 2012 at 10:13 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Mar 28,
On Wed, 28 Mar 2012, H.J. Lu wrote:
Here is the updated patch. I will wait for OK from Joseph.
I have no comments on this patch.
--
Joseph S. Myers
jos...@codesourcery.com
This patch from Rémy Oudompheng avoids a Go frontend crash on the valid
Go code
package p
var v struct{ I }
type I interface{}
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 652c8036e264 go/gogo.cc
--- a/go/gogo.cc Wed Mar 28
This patch from Rémy Oudompheng avoids an ICE on invalid in the Go
frontend. Bootstrapped on x86_64-unknown-linux-gnu. Committed to
mainline and 4.7 branch.
Ian
diff -r c1a1b9b5894b go/expressions.cc
--- a/go/expressions.cc Wed Mar 28 15:20:12 2012 -0700
+++ b/go/expressions.cc Wed Mar 28
This Go frontend patch from Rémy Oudompheng avoids an ICE on an invalid
call to the builtin len function. Bootstrapped on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 5b52b07a8cf4 go/expressions.cc
--- a/go/expressions.cc Wed Mar 28 15:24:30 2012 -0700
+++
On Wed, Mar 28, 2012 at 3:07 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Wed, 28 Mar 2012, H.J. Lu wrote:
Here is the updated patch. I will wait for OK from Joseph.
I have no comments on this patch.
Given that my patch doesn't change any command line options,
I am checking it in.
Hi,
On 03/28/2012 11:02 AM, Paolo Carlini wrote:
+ !comp_except_specs (new_exceptions, old_exceptions, ce_normal)
+ /* Special case in C++11: noexcept has been deduced as true for
+ the declaration and there is no exception-specification on the
+ definition. */
+
Oops...
1- Turns out the check_bases_and_members change has to happen earlier,
because we want to fixup the exceptions before check_bases, otherwise
we reject things like (in the C++ library and elsewhere):
struct True2 { virtual ~True2() noexcept; };
template typename Base
struct C : Base
{
This patch looks good for Android toolchain. But I am not a maintainer.
Can any x86 backend maintainer help to review the patch?
Thanks,
Jing
On Tue, Mar 27, 2012 at 6:55 AM, Ilya Enkovich enkovich@gmail.com wrote:
Ping
13 марта 2012 г. 15:13 пользователь Ilya Enkovich
This patch looks good for Android toolchain. But I am not a maintainer.
Can any x86 backend maintainer help to review the patch?
Thanks,
Jing
On Tue, Mar 27, 2012 at 6:56 AM, Ilya Enkovich enkovich@gmail.com wrote:
Ping
13 марта 2012 г. 15:12 пользователь Ilya Enkovich
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
The following patch fixes this and allowed the bootstrap to complete,
but I wonder if it wouldn't be better to globally do a
sed -e 's/_in6_addr/[16]byte/'
instead of the current special-casing of _in6_addr in a couple of places.
Hi,
When --disable-multilib is used on Linux/x86-64 target, we still set
TM_MULTILIB_CONFIG=m64,m32
It isn't necessary and doesn't work if the default ABI is -mx32. This
patch checks --with-multilib-list for x86-64 Linux targets only if
multilib is enabled. OK for trunk?
Thanks.
H.J.
---
Hi,
This patch handles the comparison of iv against the loop iv initial
value. Previously, we only handle the comparison of iv against its
bound.
Bootstrapped and passed all regression tests.
Ok for google branches?
Thanks,
Dehao
2012-03-29 Dehao Chen de...@google.com
* predict.c
Can the test case be improved so that expected prediction results is
checked (with the help of more dumping such as blah blah is predicted
to be taken/not taken with probability xyz) ?
Also the more test cases need to be added to cover more cases base,
base +1, =base +2, base+1, =base+1 etc --
On Wed, Mar 28, 2012 at 4:43 PM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
When --disable-multilib is used on Linux/x86-64 target, we still set
TM_MULTILIB_CONFIG=m64,m32
It isn't necessary and doesn't work if the default ABI is -mx32. This
patch checks --with-multilib-list for x86-64 Linux
On Sun, Mar 25, 2012 at 2:27 PM, Nathanael Nerode (GCC)
ncn_gc...@fastmail.fm wrote:
Hi,
Can any build maintainers review this patch?
I don't feel comfortable reviewing this, because I don't fully
comprehend the intricacy of the interactions in this area. It *looks*
good, but I don't
Hi,
We shouldn't assume that we can define x86_64_fallback_frame_state
for other x86-64 C libraries, like Bionic. OK for trunk?
Thanks.
H.J.
---
2012-03-27 H.J. Lu hongjiu...@intel.com
* config/i386/linux-unwind.h (x86_64_fallback_frame_state): Define
only for glibc.
In my fix for PR 48051 I failed to audit all the users of
adjust_result_of_qualified_name_lookup to make sure it wasn't being
called for non-qualified lookups as well; in this case we were calling
it for an explicit destructor call, and now that we set
BASELINK_QUALIFIED_P in that function, we
Thanks, attached is the updated patch.
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 185903)
+++ gcc/testsuite/gcc.dg/predict-3.c(working copy)
@@ -10,10 +10,16 @@
int i,
Ok for google branches.
thanks,
David
On Wed, Mar 28, 2012 at 7:55 PM, Dehao Chen de...@google.com wrote:
Thanks, attached is the updated patch.
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
---
H.J. Lu hongjiu...@intel.com writes:
2012-03-27 H.J. Lu hongjiu...@intel.com
* config/i386/linux-unwind.h (x86_64_fallback_frame_state): Define
only for glibc.
This is OK.
Thanks.
Ian
The functions unsafe.Sizeof, unsafe.Alignof, and unsafe.Offsetof are
supported to return uintptr. The Go frontend was incorrectly having
them return int. This patch fixes the problem. This uncovered a couple
of problems in the gccgo-specific part of libgo, which are also fixed by
this patch.
On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote:
You should keep those *_SPEC and define them with new
GNU_*_SPEC in gnu-user.h since gnu-user.h is also used
by other non-linux targets. In linux.h, you undef *_SPEC
before defining them.
--
H.J.
Thanks for the note. Here is fixed
This is OK. I didn't encounter building shared libraries for Android when
developed the original Android support.
You can commit this under the obvious patch rule. [I've asked SC for
reviewer privileges for Android support, so that I can approve more complex
patches.]
Thank you,
--
Maxim
72 matches
Mail list logo
