On Wed, May 08, 2013 at 01:03:41AM +0200, Marc Glisse wrote:
> On Tue, 7 May 2013, Marc Glisse wrote:
>
> > * fold-const.c (operand_equal_p): Use element_precision.
> > (fold_binary_loc): Handle vector types.
>
> Note that this causes a regression in some cases: it now recognizes
> LROTAT
binyG3NHBftCR.bin
Description: Binary data
This patch updated the unittest and doc for the new
-frecord-compilation-info-in-elf flag.
Bootstrapped and passed regression test.
OK for google-4_7 branch?
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/record-gcc-switches-in-elf-1.c
Thanks for the background. I had gone ahead and put it into gcc.dg,
but next time I can put it in gcc.dg/torture.
Teresa
On Mon, May 6, 2013 at 8:29 AM, Jakub Jelinek wrote:
> On Mon, May 06, 2013 at 09:24:28AM -0600, Jeff Law wrote:
>> On 05/03/2013 04:46 PM, Teresa Johnson wrote:
>> >On Fri, M
> > +;; This is weird. GCC testcase execute/20020615-1 compiled at -Os
>
> Another hack around a real problem, and a potential source of wrong
> code. Not OK IMHO.
I couldn't reproduce it, so I took it out. If it comes back, we'll
hit it harder :-)
> > - if (GET_MODE_BITSIZE (GET_MODE (op0)) < GET_MODE_BITSIZE
> > (GET_MODE (op1)))
> > + /* Don't try to sign-extend SImode to PSImode, for example. */
> > + if (GET_MODE_BITSIZE (GET_MODE (op0)) <= GET_MODE_BITSIZE
> > (GET_MODE (op1)))
>
> Can't you do just nothing
The assembler already exists (and is widely used, I think), and the
MSPABI specifies how registers and symbols are named at the assembler
level. Unfortunately, the MSPABI says that symbols should be like
||this|| when they need to mean "not a register" but our assembler
doesn't support that. The
On Tue, 7 May 2013, Marc Glisse wrote:
* fold-const.c (operand_equal_p): Use element_precision.
(fold_binary_loc): Handle vector types.
Note that this causes a regression in some cases: it now recognizes
LROTATE_EXPR for vectors, but then on x86_64 it isn't a supported vector
> Hi,
>
> the problem in PR 57084 is that late PRE devirtualization creates a
> direct call to a decl fro which we only have an inlined call graph
> mode in the given partition. I tried to find a most universal place
> where to fix it because this problem is not special to type-based
> devirtuali
Ping.
On Thu, May 2, 2013 at 3:51 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Apr 29, 2013 at 10:47 AM, Sriraman Tallam wrote:
>> On Thu, Apr 25, 2013 at 12:41 PM, Joseph S. Myers
>> wrote:
>>> On Tue, 16 Apr 2013, Sriraman Tallam wrote:
>>>
Ok, it is on by default now. There is a way
Ping.
On Thu, Apr 25, 2013 at 4:50 PM, Sriraman Tallam wrote:
> Attaching an updated patch.
>
> Thanks
> Sri
>
> On Thu, Apr 25, 2013 at 4:42 PM, Sriraman Tallam wrote:
>> On Tue, Apr 23, 2013 at 9:59 PM, Jakub Jelinek wrote:
>>> On Tue, Apr 23, 2013 at 03:58:06PM -0700, Sriraman Tallam wrote:
Hello,
this patch is about the use of TYPE_PRECISION for non-scalar types. For
complex types, it is unused (always 0) and for vectors, the field is used
to store the log of the number of elements, so in both cases we shouldn't
use the macro. I tried to enforce it, see the SCALAR_TYPE_CHECK in
OK for google branch. Should it also be in gcc4.8 branch?
thanks
Carrot
On Tue, May 7, 2013 at 12:01 PM, Han Shen(沈涵) wrote:
> Backport trunk@198344 - another fix to PR rtl-optimization/56847 - to
> google/gcc-4_8 branch.
>
> The first fix was trunk@198101 -
> http://gcc.gnu.org/ml/gcc-patches/2
Attached patch applied. As requested, methods are not inline anymore.
2013-05-07 François Dumont
* include/profile/unordered_base.h: New.
* include/Makefile.am: Add new profile header.
* include/Makefile.in: Regenerate.
* include/profile/impl/profiler.h
(__profcxx_ineffici
On 05/07/2013 11:20 AM, Han Shen(沈涵) wrote:
How do you plan on handling Florian's retslot issue? Are you going to scan
the gimple looking for suitable calls? How do you avoid instrumentation in
the callee for that case?
I find myself wondering if you'd be better off scanning the gimple
repres
On Tue, May 7, 2013 at 7:29 PM, Steve Ellcey wrote:
> On Tue, 2013-05-07 at 19:16 +0200, Steven Bosscher wrote:
>
>> On Tue, May 7, 2013 at 7:13 PM, Graham Stott wrote:
>> > Steven,
>> >
>> > The new execute mips_machine_reorrg2 part of the patch doesn't have a
>> > return value!
>>
>> Right, bri
Hello,
For my delay-slot filler, I need to be able to see if a ref is in
CALL_INSN_FUNCTION_USAGE to see if a REG is a valid candidate to fill
a CALL_INSN delay slot. If a ref is a real use in the pattern of the
call insn then the insn can't be delayed, but if it's only a use in
CALL_INSN_FUNCTION
Hi,
On 05/07/2013 06:49 PM, Jason Merrill wrote:
On 05/07/2013 06:24 AM, Paolo Carlini wrote:
I'm not sure if it would be more correct to explicitly
cp_parser_abort_tentative_parse before returning
Well, there needs to be something to match the
cp_parser_parse_tentatively before this function
On Tue, May 7, 2013 at 9:18 PM, Vladimir Makarov wrote:
> The following patch contains some work for porting LRA to PPC. The patch
> adds code analogous to recent changes made for reload.c::find_reloads (it
> permits to fix a lot testsuite failures for 32-bit ppc), improves address
> code genera
The following patch contains some work for porting LRA to PPC. The
patch adds code analogous to recent changes made for
reload.c::find_reloads (it permits to fix a lot testsuite failures for
32-bit ppc), improves address code generation for targets with
constraints on address displacement, i
Backport trunk@198344 - another fix to PR rtl-optimization/56847 - to
google/gcc-4_8 branch.
The first fix was trunk@198101 -
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01152.html - which was
backported to google/gcc-4_8 as gcc-4_8@198315
Unfortunately, it resulted in some libstdc++ test failur
The intent of conditional candidate processing in SLSR was always to
apply it only to CAND_MULT candidates [(base + index) * stride].
However, I neglected to actually enforce this, leading to wrong code
generated for CAND_ADD candidates. This patch adds the restriction.
My previous "fix" wasn't s
Hi,
the problem in PR 57084 is that late PRE devirtualization creates a
direct call to a decl fro which we only have an inlined call graph
mode in the given partition. I tried to find a most universal place
where to fix it because this problem is not special to type-based
devirtualization and in
Hello!
Attached patch merges and extends pextrb and pextrw vec_extract
patterns. Apart from merging where appropriate, the patch adds
extractions to non-zero-extended registers and HI/QImode extractions
from memory to integer registers.
While playing with patch, a deficiency in how mode attribute
On Tue, 2013-05-07 at 19:16 +0200, Steven Bosscher wrote:
> On Tue, May 7, 2013 at 7:13 PM, Graham Stott wrote:
> > Steven,
> >
> > The new execute mips_machine_reorrg2 part of the patch doesn't have a
> > return value!
>
> Right, brilliant... Thanks for spotting that.
>
> Steve, can you try
Updated patch according to Jeff Law's comments (
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00038.html )
Thanks,
H.
On Wed, Apr 17, 2013 at 11:40 AM, Han Shen(沈涵) wrote:
> Thanks.
>
> On Wed, Apr 17, 2013 at 2:26 AM, Florian Weimer wrote:
>> On 04/17/2013 02:49 AM, Han Shen wrote:
Indent
On Wed, May 1, 2013 at 2:00 PM, Jeff Law wrote:
> On 04/26/2013 10:45 AM, Han Shen(沈涵) wrote:
>>
>> Hi, I'd like to ping the patch '-fstack-protector-strong':
>>
>> - http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00945.html
>>Add a new option '-fstack-protector-strong' to protect only
>> stack-
Steven,
The new execute mips_machine_reorrg2 part of the patch doesn't have a return
value!
Graham
On Tue, May 7, 2013 at 6:50 PM, Steve Ellcey wrote:
> Yes, I did two builds, one with the git version just before this checkin
> and one with the checkin. This is the patch I am refering to, it
> doesn't seem VR4130 specific.
On Tue, May 7, 2013 at 7:13 PM, Graham Stott wrote:
> Steven,
>
> The
On Tue, May 7, 2013 at 6:50 PM, Steve Ellcey wrote:
> On Tue, 2013-05-07 at 18:39 +0200, Steven Bosscher wrote:
> Yes, I did two builds, one with the git version just before this checkin
> and one with the checkin. This is the patch I am refering to, it
> doesn't seem VR4130 specific.
Hmm, I can'
On Tue, 7 May 2013, Steven Bosscher wrote:
> > Index: gcc/config/msp430/README.txt
> > ===
> > --- gcc/config/msp430/README.txt(revision 0)
> > +++ gcc/config/msp430/README.txt(revision 0)
> > @@ -0,0 +1,7 @@
> > +Rand
On Mon, 6 May 2013, DJ Delorie wrote:
> Note that I had to make a few changes (fixes?) in the MI portions of
> gcc to avoid problems I encountered, I don't know if these changes are
> "correct" or if there are better ways to avoid those cases. Those
In any case, they should best be posted in se
This is another trivial patch, which fixes three regressions. The
following four regressions remain:
gfortran.dg/mvbits_7.f90
gfortran.dg/mvbits_8.f90
gfortran.dg/subref_array_pointer_2.f90
gfortran.dg/unlimited_polymorphic_1.f03
Committed as Rev. 198688 - after building and regtesting on
x86-
On Tue, 2013-05-07 at 18:39 +0200, Steven Bosscher wrote:
> On Tue, May 7, 2013 at 5:56 PM, Steve Ellcey wrote:
> >
> > Steven,
> >
> > This patch has broken the GCC build for my mips-mti-linux-gnu and
> > mips-mti-elf builds. The GCC build dies
> > when trying to configure libgcc. Do you have a
On 05/07/2013 06:24 AM, Paolo Carlini wrote:
I'm not sure if it would be more correct to explicitly
cp_parser_abort_tentative_parse before returning
Well, there needs to be something to match the
cp_parser_parse_tentatively before this function returns. But in this
case the code is indeed an
On Tue, May 7, 2013 at 5:56 PM, Steve Ellcey wrote:
>
> Steven,
>
> This patch has broken the GCC build for my mips-mti-linux-gnu and
> mips-mti-elf builds. The GCC build dies
> when trying to configure libgcc. Do you have any idea what might be going on?
Hello,
Are you sure this is caused by
On Tue, 2013-05-07 at 11:34 +0200, Jakub Jelinek wrote:
> On Mon, May 06, 2013 at 08:18:27PM -0500, Bill Schmidt wrote:
> > > AIL: gcc.dg/vect/vect-28.c -flto execution test
> > > FAIL: gcc.dg/vect/vect-28.c execution test
> > > FAIL: gfortran.dg/array_constructor_9.f90 -O3 -fomit-frame-pointer
>
On 05/07/2013 07:22 AM, Bill Schmidt wrote:
This handles the unlikely case where there are many different increments
associated with a group of related SLSR candidates, which could result
in poor performance when doing linear searches of the increment vector.
The size of the increment vector is l
Steven,
This patch has broken the GCC build for my mips-mti-linux-gnu and mips-mti-elf
builds. The GCC build dies
when trying to configure libgcc. Do you have any idea what might be going on?
Steve Ellcey
sell...@imgtec.com
checking for mips-mti-linux-gnu-gcc...
/local/home/sellcey/nightly
Dear Sales,
I'm interested in your products. Pls provide your best offer for the following:
(1) CIF Colombo
(2) Terms of payment (Irrevocable LC preferable)
We require 3 samples. Please quote us best possible Ex-Colombo, Bangladash
price.
Thanks.
Regards,
Vivian Jiang.
PRIME Shan
On Mon, 6 May 2013 11:53:20 -0600
Jeff Law wrote:
> On 05/03/2013 07:10 AM, Julian Brown wrote:
> > Hi,
> >
> > This is a patch which fixes a latent bug in RTL GCSE/PRE, described
> > more fully in:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
> >
> > I haven't been able to reproduce
On 1 May 2013 10:50, Ian Bolton wrote:
> Thanks for the review. I've fixed this up in the attached patch, by
> counting the number of matches for the first rule and expecting it to
> match additional times to cover the overlap with the lsl based rule.
>
> I've also renamed the testcases in line w
On Tue, 7 May 2013, Bill Schmidt wrote:
> This handles the unlikely case where there are many different increments
> associated with a group of related SLSR candidates, which could result
> in poor performance when doing linear searches of the increment vector.
> The size of the increment vector i
This handles the unlikely case where there are many different increments
associated with a group of related SLSR candidates, which could result
in poor performance when doing linear searches of the increment vector.
The size of the increment vector is limited to a reasonable constant,
and increment
The following patch finally makes setjmp LEAF after I figured
what breaks the original testcase. The inliner has an overzealous
assert that there cannot be new abnormal edges into the entry
block (the block preceeding the call we inline). But that can
perfectly well happen with
bb1:
setjmp ()
The following patch is a first step towards being able to enable
vectorizing of a subset of all vectorizable functions at -O2 by
default. Analysis of Polyhedron (loop heavy code) shows that
the cost of doing vectorizer analysis is in the noise but compile-time
(and binary size) grows only with th
On Tue, May 7, 2013 at 9:16 AM, Gopalasubramanian, Ganesh
wrote:
> The patch updates the alignment values for AMD BD and BT architectures.
>
> "make -k check" passes.
>
> Is it OK for upstream?
>
> 2013-05-07 Ganesh Gopalasubramanian
>
> * config/i386/i386.c (processor_target_table): Modif
On Tue, May 07, 2013 at 02:31:05PM +0200, Christophe Lyon wrote:
> On 7 May 2013 14:22, Jakub Jelinek wrote:
> > On Tue, May 07, 2013 at 02:18:35PM +0200, Christophe Lyon wrote:
> >> Thanks for your review, here is a new version taking your comments into
> >> account.
> >>
> >> Christophe.
> >>
>
On 7 May 2013 14:22, Jakub Jelinek wrote:
> On Tue, May 07, 2013 at 02:18:35PM +0200, Christophe Lyon wrote:
>> Thanks for your review, here is a new version taking your comments into
>> account.
>>
>> Christophe.
>>
>> 2013-05-06 Christophe Lyon
>
> Two spaces before <, instead of just one.
>
On Tue, May 07, 2013 at 02:18:35PM +0200, Christophe Lyon wrote:
> Thanks for your review, here is a new version taking your comments into
> account.
>
> Christophe.
>
> 2013-05-06 Christophe Lyon
Two spaces before <, instead of just one.
Otherwise it looks good to me, but if it depends on th
Thanks for your review, here is a new version taking your comments into account.
Christophe.
2013-05-06 Christophe Lyon
gcc/
* config/arm/arm.c (arm_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Define.
* config/arm/linux-eabi.h (ASAN_CC1_SPEC): Define.
(L
On Tue, 2013-05-07 at 11:34 +0200, Jakub Jelinek wrote:
> On Mon, May 06, 2013 at 08:18:27PM -0500, Bill Schmidt wrote:
> > > AIL: gcc.dg/vect/vect-28.c -flto execution test
> > > FAIL: gcc.dg/vect/vect-28.c execution test
> > > FAIL: gfortran.dg/array_constructor_9.f90 -O3 -fomit-frame-pointer
>
The following speeds up one of the bottle-necks of SCCVN/PRE when
compiling aermod.f90. It introduces a double_int::rshift function
that works on the whole representation and avoids some redundant type
construction. It also avoids re-allocating the vector of ops
by using the available shared vec
OK
/Marcus
On 7 May 2013 09:44, Sofiane Naci wrote:
> Hi,
>
> The attached patch is part of the ongoing work to enhance instruction
> scheduling opportunities in AArch64.
>
> This patch splits 2 alternatives of the aarch64_simd_mov pattern, which used
> to issue 2 consecutive instructions.
> Test
OK
On 7 May 2013 11:35, Hurugalawadi, Naveen
wrote:
> Hi,
>
> Please find attached the patch that restricts the shift value in
> comparison operation between 0-4.
>
> Please review the patch and let me know if its okay?
>
> 2013-05-07 Naveen H.S
>
> * config/aarch64/aarch64.md
>
On Tue, 7 May 2013, Richard Biener wrote:
On Tue, 7 May 2013, Marc Glisse wrote:
On Thu, 2 May 2013, Richard Biener wrote:
Can you followup with a patch to do
s/integer_all_onesp/integer_minus_onep/ where it makes sense?
This passes bootstrap+testsuite on x86_64-linux-gnu. I kept all_ones
On Tue, May 7, 2013 at 4:41 AM, DJ Delorie wrote:
> Index: gcc/cfgexpand.c
> ===
> --- gcc/cfgexpand.c (revision 198591)
> +++ gcc/cfgexpand.c (working copy)
> @@ -3090,13 +3090,14 @@ expand_debug_expr (tree exp)
> siz
The following fixes the SSA_NAME_OCCURS_IN_ABNORMAL_PHI flag when
we propagate the virtual operand during clobber sinking.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-06-07 Richard Biener
PR middle-end/57190
* tree-eh.c (sink_clobbers): Prope
Hi,
Please find attached the patch that restricts the shift value in
comparison operation between 0-4.
Please review the patch and let me know if its okay?
2013-05-07 Naveen H.S
* config/aarch64/aarch64.md
(cmp_swp__shft_): Restrict the
shift value between 0-4.
Thank
On Tue, 7 May 2013, Jakub Jelinek wrote:
> Hi!
>
> On the attached testcase we started to give false positive warnings
> when critedge has been changed to only use SSA_NAME_VAR for PHI result
> if all PHI arguments use that SSA_NAME_VAR.
>
> The fn3 function (inlined) contains a retval variable
Hi,
in this error recovery issue, we provide two correct error messages,
then a bogus one, and then we ICE because much later in
cp_parser_enum_specifier the is_ancestor helper cannot handle
error_mark_node as nested_name_specifier:
51226.C:6:19: error: wrong number of template arguments (0,
Hi!
On the attached testcase we started to give false positive warnings
when critedge has been changed to only use SSA_NAME_VAR for PHI result
if all PHI arguments use that SSA_NAME_VAR.
The fn3 function (inlined) contains a retval variable which has
false positive uninit warning disabled through
This patch properly sets the elem_len in gfc_array_init_size; it
probably could restricted to do so only for BT_CLASS and for
deferred-length BT_CHARACTER as otherwise the correct elem_len is set.
Additionally, the stride handling now uses elem_len to convert from/to
the stride multiplier inst
On Mon, May 06, 2013 at 08:18:27PM -0500, Bill Schmidt wrote:
> > AIL: gcc.dg/vect/vect-28.c -flto execution test
> > FAIL: gcc.dg/vect/vect-28.c execution test
> > FAIL: gfortran.dg/array_constructor_9.f90 -O3 -fomit-frame-pointer
> > execution test
> > FAIL: gfortran.dg/array_constructor_9.f90
Hi,
On 05/06/2013 10:00 PM, François Dumont wrote:
Hi
Here is the patch to fix the unordered containers profile mode.
There are a number of enhancements/fixes:
- Use inheritance to play code on instantiation/destruction. This way
some constructors and assignment operators can be defaulted
Could someone commit this patch please? I don't have commit access.
Regards
Senthil
On Wed, May 01, 2013 at 05:04:18PM -0700, Mike Stump wrote:
> On May 1, 2013, at 2:40 AM, Senthil Kumar Selvaraj
> wrote:
> > gcc.dg/torture/alias-1.c specifies -fschedule-insns in its dg-options,
> > and this c
On Tue, May 7, 2013 at 5:20 AM, Jason Merrill wrote:
> Most build_* functions have variadic versions, but build_constructor doesn't
> as of yet, and it would be convenient for a patch I'm working on. I decided
> to call it build_constructor_va, but am open to other naming ideas.
>
> Tested x86_64
Hi,
The attached patch is part of the ongoing work to enhance instruction
scheduling opportunities in AArch64.
This patch splits 2 alternatives of the aarch64_simd_mov pattern, which used
to issue 2 consecutive instructions.
Tested successfully with a full aarch64-elf regression run.
OK for trun
On Tue, 7 May 2013, Marc Glisse wrote:
> On Thu, 2 May 2013, Richard Biener wrote:
>
> > Can you followup with a patch to do
> > s/integer_all_onesp/integer_minus_onep/ where it makes sense?
>
> This passes bootstrap+testsuite on x86_64-linux-gnu. I kept all_ones for
> bitmask type of operations
On Mon, May 06, 2013 at 08:52:21PM +0200, Christophe Lyon wrote:
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -281,6 +281,8 @@ static unsigned arm_add_stmt_cost (void *data, int count,
>
> static void arm_canonicalize_comparison (int *code, rtx *op0, rtx *op1,
>
The rest of the patch is gcc-specific. Jakub?
On Tue, May 7, 2013 at 12:12 PM, Christophe Lyon
wrote:
> Oops, you are correct, I read the code too quickly and didn't notice
> the #endif right after the Thumb bit cancellation (I thought the
> function didn't return any value when on ARM).
>
> A wh
On Tue, May 7, 2013 at 12:16 AM, Bill Schmidt
wrote:
> This fixes the following bug:
>
> On Mon, 2013-05-06 at 21:25 +0200, Jakub Jelinek wrote:
>> On Sun, May 05, 2013 at 03:45:17PM -0500, Bill Schmidt wrote:
>> > 2013-05-05 Bill Schmidt
>> >
>> > * gimple-ssa-strength-reduction.c (slsr_pr
On Mon, May 6, 2013 at 5:42 PM, Bill Schmidt
wrote:
> This removes lazy_create_slsr_reg and replaces uses of make_ssa_name
> with make_temp_ssa_name, removing the need for a bunch of unnecessary
> vars.
>
> Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
> regressions. Ok for t
Oops, you are correct, I read the code too quickly and didn't notice
the #endif right after the Thumb bit cancellation (I thought the
function didn't return any value when on ARM).
A white line before #if defined(__powerpc__) would help readability :-)
Forget that part.
Thanks,
Christophe.
On Mon, 6 May 2013, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because DECL_INITIAL contains
> COMPOUND_LITERAL_EXPR, which expr.c assumes has been gimplified, but
> initializers aren't gimplified. Fixed thusly, bootstrapped/regtested on
> x86_64-linux and i686-linux, ok fo
This is a regression present on the mainline and 4.8 branch and introduced by
the latest series of sizetype changes. Associated adjustments were made in
the various front-ends for it, most notably Ada which was the most affected,
but this issue slipped through the cracks in the form of a bogus
Hello,
On 04/30/2013 09:05 PM, Cary Coutant wrote
>
> How about using dbx_reg_number (XVECEXP (regs, 0, i)) instead? The
> bare use of DBX_REGISTER_NUMBER earlier in that function is protected
> by a gcc_assert, but this one isn't.
OK dbx_reg_number better than DBX_REGISTER_NUMBER here.
while w
On Tue, May 07, 2013 at 08:22:48AM +0200, Jakub Jelinek wrote:
> On Mon, May 06, 2013 at 03:25:43PM -0400, Jason Merrill wrote:
> > On 05/06/2013 02:25 PM, Jakub Jelinek wrote:
> > >I did it that way because if I understand the code well, often
> > >grokdeclarator/start_decl/start_function/grokmeth
On Tue, May 7, 2013 at 9:33 AM, Konstantin Serebryany
wrote:
> +euge...@google.com (our ARM expert)
>
> Christophe,
>
> The change in sanitizer_common/sanitizer_stacktrace.cc changes the
> logic which is known to work well for us on Android/ARM.
> I'd like Evgeniy to comment on it.
>
> --kcc
>
> O
+euge...@google.com (our ARM expert)
Christophe,
The change in sanitizer_common/sanitizer_stacktrace.cc changes the
logic which is known to work well for us on Android/ARM.
I'd like Evgeniy to comment on it.
--kcc
On Mon, May 6, 2013 at 10:52 PM, Christophe Lyon
wrote:
> Hi,
>
> Here is a 2nd
Hi
The patch updates the alignment values for AMD BD and BT architectures.
"make -k check" passes.
Is it OK for upstream?
Regards
Ganesh
2013-05-07 Ganesh Gopalasubramanian
* config/i386/i386.c (processor_target_table): Modified default
alignment values for AMD BD and BT architec
81 matches
Mail list logo
