On Wed, 28 Mar 2012, Marc Glisse 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 with it a bit, I am not sure how to use it in the simple
forwarding case:
T f(int)
Seems like libstdc++.a has suffered a bit in the transition to a more
modular convenience-library build system.
Here's a patch to clean up the compatibility symbols throughout
libstdc++, to insure that necessary symbols for versioning purposes are
only in shared binaries, ie libstdc++.so. Most o
On Wed, 28 Mar 2012, Jason Merrill wrote:
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.
How
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
On 28/02/2012, at 3:39 AM, Ilya Enkovich wrote:
>>
>> Undef TARGET_OS_CPP_BUILTINS and define TARGET_OS_CPP_BUILTINS
>> in linux.h with GNU_USER_TARGET_OS_CPP_BUILTINS and
>> ANDROID_TARGET_OS_CPP_BUILTINS.
>>
>>
>> --
>> H.J.
>
> Hello,
>
> Here is a variant with linux.h modification. Does i
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. H
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. Bo
"H.J. Lu" writes:
> 2012-03-27 H.J. Lu
>
> * config/i386/linux-unwind.h (x86_64_fallback_frame_state): Define
> only for glibc.
This is OK.
Thanks.
Ian
Ok for google branches.
thanks,
David
On Wed, Mar 28, 2012 at 7:55 PM, Dehao Chen wrote:
> Thanks, attached is the updated patch.
>
> Dehao
>
> Index: gcc/testsuite/gcc.dg/predict-3.c
> ===
> --- gcc/testsuite/gcc.dg/predict-3.c
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, r
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
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
* config/i386/linux-unwind.h (x86_64_fallback_frame_state): Define
only for glibc.
diff --git a/gcc/confi
On Sun, Mar 25, 2012 at 2:27 PM, Nathanael Nerode (GCC)
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 trust my review
On Wed, Mar 28, 2012 at 4:43 PM, H.J. Lu 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 targets only
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
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
* predict.c (predict_iv_compar
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.
---
20
Rainer Orth 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.
Yeah, probably.
> 2012-03-
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 wrote:
> Ping
>
> 13 марта 2012 г. 15:12 пользователь Ilya Enkovich
> написал:
>> Ping
>>
>> 27 февраля 20
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 wrote:
> Ping
>
> 13 марта 2012 г. 15:13 пользователь Ilya Enkovich
> написал:
>> Ping
>>
>> 27 февраля 20
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
struct C : Base
{
~C();
};
L
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. */
+&& !(DECL_DESTR
On Wed, Mar 28, 2012 at 3:07 PM, Joseph S. Myers
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. Please let me k
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
+++ b/go/ex
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 15:24
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 14:
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
On Wed, Mar 28, 2012 at 2:17 PM, H.J. Lu wrote:
> On Wed, Mar 28, 2012 at 2:10 PM, Uros Bizjak wrote:
>> On Wed, Mar 28, 2012 at 10:13 PM, H.J. Lu wrote:
>>> On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak wrote:
On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu wrote:
> What do we do with
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
* tree.c (tree_size) : New case.
2012-03-28 Eric Botcazou
*
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
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 g
On 03/28/2012 03:59 PM, David Edelsohn wrote:
> On Tue, Mar 27, 2012 at 5:21 PM, Meador Inge 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 i
On Wed, Mar 28, 2012 at 2:10 PM, Uros Bizjak wrote:
> On Wed, Mar 28, 2012 at 10:13 PM, H.J. Lu wrote:
>> On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak wrote:
>>> On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu wrote:
>>>
What do we do with TARGET_64BIT and TARGET_64BIT_DEFAULT? They
are us
On Wed, Mar 28, 2012 at 10:13 PM, H.J. Lu wrote:
> On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak wrote:
>> On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu wrote:
>>
>>> What do we do with TARGET_64BIT and TARGET_64BIT_DEFAULT? They
>>> are used to indicate 64bit ISA like:
>>>
>>> collect2.c:/* TARGET_
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 so
On Tue, Mar 27, 2012 at 5:21 PM, Meador Inge 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 'lwsync'. Luckily
Committed as trivial/obvious in revision 185924. Thanks to Brian Ames
for spotting the error!
2012-03-28 Paul Thomas
Tobias Burnus
PR fortran/52652
* match.c (gfc_match_allocate, gfc_match_deallocate): Change
"not.. or" to "neither.. nor".
* parse.c (
On 03/28/2012 12:08 PM, Dodji Seketeli wrote:
On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
template 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
parms still has two entries
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:
On Wed, Mar 28, 2012 at 12:51 PM, Uros Bizjak wrote:
> On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu 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
>> functionali
On Wed, Mar 28, 2012 at 9:33 PM, H.J. Lu 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
> collect2.c:#define T
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
On Wed, Mar 28, 2012 at 3:17 AM, Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 7:48 PM, H.J. Lu 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
On Wed, 28 Mar 2012, Gabriel Dos Reis wrote:
On Wed, Mar 28, 2012 at 10:51 AM, Marc Glisse 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 with it a bit, I am not
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 bu
On Wed, Mar 28, 2012 at 10:51 AM, Marc Glisse 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 with it a bit, I am not sure how to use it in the simple
> for
Jason Merrill writes:
> On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
>> For:
>>
>> template 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
On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
> On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
> 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 reass
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 r
On 03/28/2012 11:02 AM, Dodji Seketeli wrote:
For:
template 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 have different levels? They
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. */
+&& !(DECL_DEST
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 sy
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);
}
+
Jason Merrill writes:
>> + /* This can happen for template parms of a template template
>> +parameter, e.g:
>> +
>> +template class TT> struct S;
>> +
>> +Consider the level of the parms of TT; T and U both have
>> +level 2; TT has no template parm of level 1
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
*
OK.
Jason
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
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 regte
On Wed, Mar 28, 2012 at 4:00 PM, Jakub Jelinek 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 missed !.
>
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 ar
On 03/28/2012 02:39 AM, Ye Joey wrote:
On Wed, Mar 28, 2012 at 1:07 AM, Vladimir Makarov 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. Here is the patch.
In
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 i686-linu
On Wed, Mar 28, 2012 at 3:54 PM, Jakub Jelinek wrote:
> 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
On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
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 __builtin_pow*
> calls, optimally
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, bootstrapped/regte
On 27 March 2012 21:23, Andrew Stubbs wrote:
> On 08/03/12 18:03, Richard Henderson wrote:
>>
>> On 03/08/12 08:19, Andrew Stubbs wrote:
>>>
>>> + (set_attr "arch" "nota8,*,*,onlya8")
>>> + (set_attr_alternative "insn_enabled"
>>> + [(if_then_else (match_test "TARGET_NEON")
>>> +
On Fri, 23 Mar 2012, Richard Guenther wrote:
> On Wed, 21 Mar 2012, Richard Sandiford wrote:
>
> > Richard Guenther writes:
> > > This patch makes us preserve loop structures from the start of tree
> > > loop optimizers to the end of RTL loop optimizers. It uses a new
> > > property, PROP_loops
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
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185912
Reverts the changes for
PR51002 - SP_H register used even on targets without SP_H
PR51002 has been re-scheduled for 4.7
Backported from trunk to 4.7:
PR52737 - -mtiny-stack shall not influence multilib selection
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185908
PR52692 - Add support for avr-specific built-ins + LTO
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185911
On Tue, Mar 27, 2012 at 7:48 PM, H.J. Lu 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 what it says.
OPT
On Wed, Mar 28, 2012 at 11:57 AM, Richard Guenther
wrote:
> On Tue, Mar 27, 2012 at 3:17 PM, Ramana Radhakrishnan
> wrote:
>> And the patch is now attached
>
> This does not look like it would compile on any other target.
Looks like the macros are pre-existing in rtl.h. With that the ivopt
On Wed, Mar 28, 2012 at 12:23 AM, Steven Bosscher wrote:
> On Tue, Mar 27, 2012 at 11:51 PM, Steven Bosscher
> wrote:
>> On Tue, Mar 27, 2012 at 11:07 PM, Eric Botcazou
>> wrote:
With this patch a variable named "_Jv_CLS" is written out. The
assembly before and after the patch is the
On Tue, Mar 27, 2012 at 3:17 PM, Ramana Radhakrishnan
wrote:
> And the patch is now attached
This does not look like it would compile on any other target.
Richard.
> Ramana
Vladimir Makarov 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 FPU?
-Andi
--
a...
> 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
On 03/27/2012 05:42 PM, Andreas Schwab wrote:
Sebastian Huber 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:
extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o
On Sat, Mar 24, 2012 at 16:13, Thomas Koenig 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 itself.
>
> This sh
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
> >
> > PR rtl-optimization/52629
> > * reload1.c (count_pseudo): Short-circuit
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
>
> PR middle-end/51893
> * expmed.c (store_bit_field_1): Fix wordnum val
80 matches
Mail list logo
