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
+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
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
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
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
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
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
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, 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
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
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 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,
>
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
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, 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
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
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
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
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
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
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,
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,
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
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
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
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
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
>
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
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
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
>
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, 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
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: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 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
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
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 ()
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
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
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 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
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
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
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
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 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 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, 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
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 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
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 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, 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
Steven,
The new execute mips_machine_reorrg2 part of the patch doesn't have a return
value!
Graham
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-
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 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
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
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
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
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 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
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
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
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
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
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
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
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
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
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:
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
> 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
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
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
> > - 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
> > +;; 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 :-)
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 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
binyG3NHBftCR.bin
Description: Binary data
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
81 matches
Mail list logo
