Re: [PATCH 0/6] Make df_ref representation more efficient

[Richard Sandiford]

Steven Bosscher  writes:
> On Sat, Jun 14, 2014 at 9:36 PM, Richard Sandiford wrote:
>> Using a linked list gives a consistent 2% compile-time improvement for
>> fold-const.ii -O0 and ~1% for various -O2 compiles I tried.  The df
>> routines do still show up high on the profile though.
>
> Can you explain a bit more about what shows up high?

For cc1plus -O0 on an oldish fold-const.ii I get:

 3.19%  cc1plus  cc1plus[.] record_reg_classes(int, int, 
rtx_def**, machine_mode*, char const**, rtx_def*, reg_class*) [clone 
.constprop.5]
 2.91%  cc1plus  cc1plus[.] 
cp_parser_skip_to_closing_parenthesis(cp_parser*, bool, bool, bool)
 1.42%  cc1plus  cc1plus[.] cp_lexer_consume_token(cp_lexer*)
 1.42%  cc1plus  cc1plus[.] 
df_ref_create_structure(df_ref_class, df_collection_rec*, rtx_def*, rtx_def**, 
basic_block_def*, df_insn_info*, df_ref_type, int)
 1.31%  cc1plus  cc1plus[.] ggc_internal_alloc(unsigned long, 
void (*)(void*), unsigned long, unsigned long)
 1.10%  cc1plus  cc1plus[.] df_ref_record(df_ref_class, 
df_collection_rec*, rtx_def*, rtx_def**, basic_block_def*, df_insn_info*, 
df_ref_type, int)
 0.89%  cc1plus  cc1plus[.] find_costs_and_classes(_IO_FILE*)
 0.89%  cc1plus  cc1plus[.] 
process_bb_node_lives(ira_loop_tree_node*)
 0.86%  cc1plus  cc1plus[.] bitmap_set_bit(bitmap_head*, int)
 0.82%  cc1plus  cc1plus[.] df_note_compute(bitmap_head*)
 0.77%  cc1plus  libc-2.18.so   [.] _int_malloc
 0.76%  cc1plus  cc1plus[.] ix86_decompose_address(rtx_def*, 
ix86_address*)
 0.76%  cc1plus  cc1plus[.] process_alt_operands(int)
 0.75%  cc1plus  cc1plus[.] general_operand(rtx_def*, 
machine_mode)
 0.72%  cc1plus  cc1plus[.] df_uses_record(df_collection_rec*, 
rtx_def**, df_ref_type, basic_block_def*, df_insn_info*, int)
 0.72%  cc1plus  cc1plus[.] pool_alloc(alloc_pool_def*)
 0.72%  cc1plus  cc1plus[.] lookup_name_real(tree_node*, int, 
int, bool, int, int)
 0.67%  cc1plus  cc1plus[.] 
df_insn_refs_collect(df_collection_rec*, basic_block_def*, df_insn_info*)
 0.67%  cc1plus  cc1plus[.] constrain_operands(int)
 0.66%  cc1plus  cc1plus[.] for_each_rtx_1(rtx_def*, int, int 
(*)(rtx_def**, void*), void*)
 0.63%  cc1plus  cc1plus[.] gimplify_expr(tree_node**, 
gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int)
 0.62%  cc1plus  cc1plus[.] grokdeclarator(cp_declarator 
const*, cp_decl_specifier_seq*, decl_context, int, tree_node**)
 0.62%  cc1plus  cc1plus[.] walk_tree_1(tree_node**, tree_node* 
(*)(tree_node**, int*, void*), void*, pointer_set_t*, tree_node* 
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, 
pointer_set_t*))
 0.59%  cc1plus  cc1plus[.] expand_expr_real_1(tree_node*, 
rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
 0.58%  cc1plus  cc1plus[.] df_ref_equal_p(df_ref_d*, df_ref_d*)
 0.57%  cc1plus  cc1plus[.] lra_create_live_ranges(bool)
 0.51%  cc1plus  cc1plus[.] lra_eliminate(bool, bool)
 0.51%  cc1plus  cc1plus[.] extract_insn(rtx_def*)
 0.51%  cc1plus  cc1plus[.] 
ix86_legitimate_address_p(machine_mode, rtx_def*, bool)
 0.50%  cc1plus  libc-2.18.so   [.] _IO_putc
 0.49%  cc1plus  libc-2.18.so   [.] memset
 0.49%  cc1plus  cc1plus[.] df_lr_bb_local_compute(unsigned int)
 0.47%  cc1plus  cc1plus[.] regstat_compute_ri()
 0.47%  cc1plus  cc1plus[.] _cpp_lex_direct
 0.46%  cc1plus  cc1plus[.] 
cp_parser_postfix_expression(cp_parser*, bool, bool, bool, bool, cp_id_kind*)
 0.44%  cc1plus  cc1plus[.] htab_find_slot_with_hash
 0.42%  cc1plus  libc-2.18.so   [.] malloc_consolidate
 0.42%  cc1plus  [kernel.kallsyms]  [k] clear_page_c_e
 0.41%  cc1plus  cc1plus[.] copy_rtx_if_shared_1(rtx_def**)
 0.41%  cc1plus  cc1plus[.] cleanup_cfg(int)

where df routines seem to be showing up a fair bit (3 in the top 10).
I realise that can be misleading since it might just be that the
df work is concentrated in a small number of functions.

This is after the patches.  malloc was in the top 5 before.

Thanks,
Richard

Re: [PATCH,MIPS] MIPS64r6 support

[Richard Sandiford]

Just to correct myself here:

Richard Sandiford  writes:
> The:
>
> # Handle dependencies between the pre-arch options and the arch option.
> # This should mirror the arch and post-arch code below.
> if { !$arch_test_option_p } {
>
> block should start with something like:
>
>   if (isa_rev >= 6
>   && ...tests for things r6 doesn't support..) {
>   if { $gp_size == 32 } {
>   mips_make_test_option options "-mips32r2"
>   } else {
>   mips_make_test_option options "-mips64r2"
>   }

r5 rather than r2 of course.  And...

> And:
>
> if { $arch_test_option_p } {
>
> should have a corresponding:
>
> if { $isa_rev > 5 } {
> ...force options that r6 doesn't support to off...
> }
>
> before the unsets.

...the "> 5" vs. ">= 6" difference wasn't intentional...

Thanks,
Richard

Re: [libgfortran, patch] Fix compilation on HP/UX 10

[FX]

Committed as rev. 211685, thanks for the review.

FX

breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Hans-Peter Nilsson]

On Sat, 14 Jun 2014, Richard Sandiford wrote:

> To make the final representation change easier, this patch introduces
> macros for iterating over lists of defs, uses and eq_uses.  At the
> moment there are three possible keys when accessing df_ref lists:
> the insn rtx (DF_INSN_*), the insn uid (DF_INSN_UID_*) and the
> df_insn_info (DF_INSN_INFO_*).  I don't think it's worth adding
> iterators for uids though.  Any code that's going to the trouble of
> caching the uid might as well go the whole hog and cache the underlying
> df_insn_info.
>
> After the feedback to the BB iterator patch:
>
>   https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00676.html
>
> I've kept the iterator variable definitions outside the FOR_* macros
> rather than make the FOR_* macros define the variables themselves.
>
> Richard
>
>
> gcc/
>   * df.h (DF_INSN_INFO_MWS, FOR_EACH_INSN_INFO_DEF): New macros.
>   (FOR_EACH_INSN_INFO_USE, FOR_EACH_INSN_INFO_EQ_USE): Likewise.
>   (FOR_EACH_INSN_DEF, FOR_EACH_INSN_USE, FOR_EACH_INSN_EQ_USE): Likewise.
>   * auto-inc-dec.c (find_inc, merge_in_block): Use them.


One of these patches (in 211677:211684) broke cris-elf:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
\
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macr\
os -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/tmp/hpautotest-gcc0/gcc/gcc -I/tmp/hpautotest-gcc0/g\
cc/gcc/. -I/tmp/hpautotest-gcc0/gcc/gcc/../include
-I/tmp/hpautotest-gcc0/gcc/gcc/../libcpp/include
-I/tmp/hpautotest-g\
cc0/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc0/gcc/gmp
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/./mpfr -I/tmp/hpautotes\
t-gcc0/gcc/mpfr -I/tmp/hpautotest-gcc0/gcc/mpc/src
-I/tmp/hpautotest-gcc0/gcc/gcc/../libdecnumber
-I/tmp/hpautotest-gc\
c0/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/tmp/hpautotest-gcc0/gcc/gcc/../libbacktrace-o
auto-inc-dec.o -M\
T auto-inc-dec.o -MMD -MP -MF ./.deps/auto-inc-dec.TPo
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
merge_in_block(int, basic_block_def*)':
/tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
was not declared in this scope
make[2]: *** [auto-inc-dec.o] Error 1

brgds, H-P

Re: [C++ Patch] PR 33101

[Jason Merrill]

On 06/15/2014 01:01 AM, Paolo Carlini wrote:

Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?


Hmm, apparently so.  Might as well apply the DR to C++98 mode as well.

Jason

Re: [C++ PATCH, RFC] PR c++/61491

[Jason Merrill]

On 06/13/2014 02:45 PM, Ville Voutilainen wrote:

Yeah, my point was just that unscoped enums (with an explicit underlying type)
as such are eligible for specialization


Yes, but if there is a template definition for the enum available when 
the specialization is declared, the enum template is implicitly 
instantiated along with its containing class, so the specialization is 
ill-formed because you can't define a specialization that has already 
been instantiated.  Which is what the example in the standard illustrates.


Jason

Re: [C++ PATCH, RFC] PR c++/61491

[Ville Voutilainen]

On 15 June 2014 16:37, Jason Merrill  wrote:
> Yes, but if there is a template definition for the enum available when the
> specialization is declared, the enum template is implicitly instantiated
> along with its containing class, so the specialization is ill-formed because
> you can't define a specialization that has already been instantiated.  Which
> is what the example in the standard illustrates.

Ah, I see. So it's not just the difference in the underlying type,
it's that an unscoped
enum cannot be specialized to begin with, even when it has an underlying type.

Ok, then the patch does need further work. I don't know how to solve
that part yet,
guidance would be welcome.

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Steven Bosscher]

On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> On Sat, 14 Jun 2014, Richard Sandiford wrote:
>
>> To make the final representation change easier, this patch introduces
>> macros for iterating over lists of defs, uses and eq_uses.  At the
>> moment there are three possible keys when accessing df_ref lists:
>> the insn rtx (DF_INSN_*), the insn uid (DF_INSN_UID_*) and the
>> df_insn_info (DF_INSN_INFO_*).  I don't think it's worth adding
>> iterators for uids though.  Any code that's going to the trouble of
>> caching the uid might as well go the whole hog and cache the underlying
>> df_insn_info.
>>
>> After the feedback to the BB iterator patch:
>>
>>   https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00676.html
>>
>> I've kept the iterator variable definitions outside the FOR_* macros
>> rather than make the FOR_* macros define the variables themselves.
>>
>> Richard
>>
>>
>> gcc/
>>   * df.h (DF_INSN_INFO_MWS, FOR_EACH_INSN_INFO_DEF): New macros.
>>   (FOR_EACH_INSN_INFO_USE, FOR_EACH_INSN_INFO_EQ_USE): Likewise.
>>   (FOR_EACH_INSN_DEF, FOR_EACH_INSN_USE, FOR_EACH_INSN_EQ_USE): Likewise.
>>   * auto-inc-dec.c (find_inc, merge_in_block): Use them.
>
>
> One of these patches (in 211677:211684) broke cris-elf:
>
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> \
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long
> -Wno-variadic-macr\
> os -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I/tmp/hpautotest-gcc0/gcc/gcc -I/tmp/hpautotest-gcc0/g\
> cc/gcc/. -I/tmp/hpautotest-gcc0/gcc/gcc/../include
> -I/tmp/hpautotest-gcc0/gcc/gcc/../libcpp/include
> -I/tmp/hpautotest-g\
> cc0/cris-elf/gccobj/./gmp -I/tmp/hpautotest-gcc0/gcc/gmp
> -I/tmp/hpautotest-gcc0/cris-elf/gccobj/./mpfr -I/tmp/hpautotes\
> t-gcc0/gcc/mpfr -I/tmp/hpautotest-gcc0/gcc/mpc/src
> -I/tmp/hpautotest-gcc0/gcc/gcc/../libdecnumber
> -I/tmp/hpautotest-gc\
> c0/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
> -I/tmp/hpautotest-gcc0/gcc/gcc/../libbacktrace-o
> auto-inc-dec.o -M\
> T auto-inc-dec.o -MMD -MP -MF ./.deps/auto-inc-dec.TPo
> /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c
> /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
> merge_in_block(int, basic_block_def*)':
> /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
> was not declared in this scope
> make[2]: *** [auto-inc-dec.o] Error 1
>
> brgds, H-P


Bah, this is why I just *hate* all the gcc code that's only compiled
if certain #defines are set...

Can you please try:

Index: auto-inc-dec.c
===
--- auto-inc-dec.c  (revision 211685)
+++ auto-inc-dec.c  (working copy)
@@ -1439,7 +1439,8 @@ merge_in_block (int max_reg, basic_block bb)
}
}
   else if (dump_file)
-   fprintf (dump_file, "skipping update of deleted insn %d\n", uid);
+   fprintf (dump_file, "skipping update of deleted insn %d\n",
+INSN_UID (insn));
 }

   /* If we were successful, try again.  There may have been several

Ciao!
Steven

Re: [fortran,patch] Binding label can be any initialisation expression

[FX]

ping

To reinforce the message in my earlier email: we can fine-tune the list of 
allowed characters in identifiers later, but I’d like to get this patch in 
already (so it gets large exposure before the 4.10 release).

FX



> Binding label can be any initialisation expression.  Well, only scalar 
> character of the default kind, but still…
> 
> This patch achieves this goal by following the obvious plan, which has not 
> changed since I wrote it in PR 36275 in 2008 :)
> The custom matcher for binding label, in gfc_match_bind_c(), is removed and 
> the generic matcher gfc_match_init_expr() is called, followed by checks that 
> the expression obtained fulfills the constraints of a C identifier.
> 
> So, now is the time to think about PR 38839 (what characters to allow as a 
> binding label): right now, I allow alphadecimals, underscore and dollar. 
> >From the PR comments, it seems like @ and ` might be also allowed for 
> universal-character names, but they are not supported by GCC on platforms I 
> tested right now. Let me know what you think, but I don’t think we should 
> worry to much about it.
> 
> Bootstrapped and regtested on x86_64-apple-darwin13, comes with testcases.
> OK to commit?
> 
> FX
> 
> 
> PS: you may notice I have had some time to hack at gfortran these past few 
> days... it feels good!



bind_c.ChangeLog
Description: Binary data


bind_c.diff
Description: Binary data

Re: [PATCH 0/6] Make df_ref representation more efficient

[Jan Hubicka]

> Walks of things like DF_REF_INSN_USES were showing up high in the profile
> of a fold-const.ii compilation.  These reference lists are represented
> as pointers to null-terminated lists of pointers, and since there's
> little locality when walking all insns, each loop over the uses or defs
> generally has two major cache misses before it can do anything
> (or one major cache miss before doing nothing), on top of accessing
> the underlying df_insn_info.  Also, for -O0, the overhead of mallocing
> lots of small arrays is itself noticeable.
> 
> I don't think there's any real need for this representation.  Each
> df_ref belongs to exactly one of these null-terminated pointer arrays,
> so using a normal linked list would be more efficient memory-wise
> (because we'd save on the null terminator and separate malloced memory).

I think situation here is simliar to ipa-ref.  Here I have two arrays 
in ipa_ref_list:
  /* Store actual references in references vector.  */
  vec *references;
  /* Referring is vector of pointers to references.  It must not live in GGC 
space
 or GGC will try to mark middle of references vectors.  */
  vec  GTY((skip)) referring;

So all references are stored in an array, while all referring are stored
as array of pointers to references within the arrays of refering nodes.

On resize of references array I need to check if all references has moved &
update referring arrays accordingly, but that is not so big deal. Also users
needs to be aware of fact that refernces do not have stable addresses.

Perhaps this representation would make sense for df? Especially when references
are collected for given function and thus we know the size of references array
in advance?

Honza
> 
> The idea might have been to allow the array to be sorted easily.
> That doesn't really apply now though.  We collect the references in a
> df_collection_rec and sort them there before populating the df_insn_info.
> After that we just insert single elements or merge two sorted lists.
> (Both of these are currently done as full qsorts, but don't need to be.)
> 
> Using a linked list gives a consistent 2% compile-time improvement for
> fold-const.ii -O0 and ~1% for various -O2 compiles I tried.  The df
> routines do still show up high on the profile though.
> 
> Tested on x86_64-linux-gnu.  OK to install?
> 
> Thanks,
> Richard

[MIPS r5900] libgcc floating point fixes

[Jürgen Urban]

Hello,

I found a problem in GCC on MIPS r5900: When printf() is used with type float, 
the converter function __extendsfdf2() is called. Parameters to printf() are 
always passed as double and not float. The function __extendsfdf2() calls 
itself to convert 32 bit float to 64 bit float. With Linux the __extendsfdf2() 
leads to a segfault when the stack limit is reached.
Here is the wrong code (mipsel-linux-gnu):

00402af0 <__extendsfdf2>:
  402af0:   3c1c0002lui gp,0x2
  402af4:   279c9b30addiu   gp,gp,-25808
  402af8:   0399e021addugp,gp,t9
  402afc:   8f9980a0lw  t9,-32608(gp)  # Load pointer to 
__extendsfdf2 into t9
  402b00:   27bdffe0addiu   sp,sp,-32
  402b04:   afbf001csw  ra,28(sp)
  402b08:   0320f809jalrt9 # Calls __extendsfdf2 
(itself)
  402b0c:   afbc0010sw  gp,16(sp)
  402b10:   8fbf001clw  ra,28(sp)
  402b14:   03e8jr  ra
  402b18:   27bd0020addiu   sp,sp,32
  402b1c:   nop

The problem happens with the r5900 hard float configurations, e.g.:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single 
--with-arch=r5900
I created the attached patch which fixes this problem for r5900 and another 
problem explained later.
The fixed code generates the following code which should be correct 
(mipsr5900el-ps2-elf):

00105440 <__extendsfdf2>:
  105440:   27bdffc8addiu   sp,sp,-56
  105444:   27a40028addiu   a0,sp,40
  105448:   27a50018addiu   a1,sp,24
  10544c:   afbf0034sw  ra,52(sp)
  105450:   0c0417b5jal 105ed4 <__unpack_f>
  105454:   e7ac0028swc1$f12,40(sp)
  105458:   8fa20024lw  v0,36(sp)
  10545c:   8fa40018lw  a0,24(sp)
  105460:   8fa5001clw  a1,28(sp)
  105464:   8fa60020lw  a2,32(sp)
  105468:   00021882srl v1,v0,0x2
  10546c:   00021780sll v0,v0,0x1e
  105470:   afa20010sw  v0,16(sp)
  105474:   0c041789jal 105e24 <__make_dp>
  105478:   afa30014sw  v1,20(sp)
  10547c:   8fbf0034lw  ra,52(sp)
  105480:   03e8jr  ra
  105484:   27bd0038addiu   sp,sp,56

The default targets mipsr5900el and mips64r5900el are not affected by the 
problem, because soft float is the default.

It also seems that the same problem occurs with the following configuration:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
I expected that this combination should work and a problem should already be 
detected. Can somebody confirm that the problem also occurs with default mipsel?

The second part of the patch fixes the following configuration:
configure --target=mipsel-linux-gnu --with-arch=r5900
It disables the mips16 stuff in the libgcc. This can't be compiled on r5900. 
This was already disabled for targets mipsr5900*el. I detected the problem, 
because the buildroot project uses this style which leads to less problems with 
existing software (because "mipsel" or "mips64el" is hardcoded in most 
configure scripts and don't expect "mipsr5900el" or "mips64r5900el").

Can someone please add the patch to the official GCC repository?

I am not sure whether I fixed all self-calling implementations. Does somebody 
know a way of finding selfcalling implementations?

I tried to find a FPU testsuite, but the testsuites are not designed to test 
non-standard FPUs or use double instead of float. So there can be more problems 
with FPU on r5900 which I don't see at the moment.

Best regards
Jürgen Urban--- gcc-4.9.0/libgcc/config/t-hardfp-sf	1970-01-01 01:00:00.0 +0100
+++ gcc-4.9.0-patched/libgcc/config/t-hardfp-sf	2014-05-07 00:14:27.093320928 +0200
@@ -0,0 +1,32 @@
+# Copyright (C) 2014 Free Software Foundation, Inc.
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+hardfp_float_modes := sf
+# di and ti are provided by libgcc2.c where needed.
+hardfp_int_modes := si
+hardfp_extensions :=
+hardfp_truncations :=
+
+# Emulate 64 bit float:
+FPBIT = true
+DPBIT = true
+# Don't build functions handled by 32 bit hardware:
+LIB2FUNCS_EXCLUDE = _addsub_sf _mul_sf _div_sf \
+_fpcmp_parts_sf _compare_sf _eq_sf _ne_

Re: [PATCH 0/6] Make df_ref representation more efficient

[Jan Hubicka]

> > Walks of things like DF_REF_INSN_USES were showing up high in the profile
> > of a fold-const.ii compilation.  These reference lists are represented
> > as pointers to null-terminated lists of pointers, and since there's
> > little locality when walking all insns, each loop over the uses or defs
> > generally has two major cache misses before it can do anything
> > (or one major cache miss before doing nothing), on top of accessing
> > the underlying df_insn_info.  Also, for -O0, the overhead of mallocing
> > lots of small arrays is itself noticeable.
> > 
> > I don't think there's any real need for this representation.  Each
> > df_ref belongs to exactly one of these null-terminated pointer arrays,
> > so using a normal linked list would be more efficient memory-wise
> > (because we'd save on the null terminator and separate malloced memory).
> 
> I think situation here is simliar to ipa-ref.  Here I have two arrays 
> in ipa_ref_list:
>   /* Store actual references in references vector.  */
>   vec *references;
>   /* Referring is vector of pointers to references.  It must not live in GGC 
> space
>  or GGC will try to mark middle of references vectors.  */
>   vec  GTY((skip)) referring;
> 
> So all references are stored in an array, while all referring are stored
> as array of pointers to references within the arrays of refering nodes.
> 
> On resize of references array I need to check if all references has moved &
> update referring arrays accordingly, but that is not so big deal. Also users
> needs to be aware of fact that refernces do not have stable addresses.
> 
> Perhaps this representation would make sense for df? Especially when 
> references
> are collected for given function and thus we know the size of references array
  
  instruction

Basically I think that most of time we can allocate the array only after we 
know the
size.

Honza
> in advance?
> 
> Honza
> > 
> > The idea might have been to allow the array to be sorted easily.
> > That doesn't really apply now though.  We collect the references in a
> > df_collection_rec and sort them there before populating the df_insn_info.
> > After that we just insert single elements or merge two sorted lists.
> > (Both of these are currently done as full qsorts, but don't need to be.)
> > 
> > Using a linked list gives a consistent 2% compile-time improvement for
> > fold-const.ii -O0 and ~1% for various -O2 compiles I tried.  The df
> > routines do still show up high on the profile though.
> > 
> > Tested on x86_64-linux-gnu.  OK to install?
> > 
> > Thanks,
> > Richard

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Hans-Peter Nilsson]

On Sun, 15 Jun 2014, Steven Bosscher wrote:
> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
> > merge_in_block(int, basic_block_def*)':
> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c:1442: error: 'uid'
> > was not declared in this scope
> > make[2]: *** [auto-inc-dec.o] Error 1
> >
> > brgds, H-P
>
>
> Bah, this is why I just *hate* all the gcc code that's only compiled
> if certain #defines are set...

I couldn't agree more.  Might not have been obvious when writing
the mosly-mechanical patch, still the auto-inc-dec.c name should
have been a red flag that a representative target should have
been tested (i.e. not x86_64 and i686).

>
> Can you please try:
>
> [...]

Thanks.  Looks pretty obvious.  I was heading for the door with
just enough time to report the issue, so I didn't actually look
at the code before.  I'll commit this on your behalf once build
has passed the point of failure.

brgds, H-P

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Hans-Peter Nilsson]

On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
> On Sun, 15 Jun 2014, Steven Bosscher wrote:
> > Can you please try:
> >
> > [...]
>
> Thanks.  Looks pretty obvious.  I was heading for the door with
> just enough time to report the issue, so I didn't actually look
> at the code before.  I'll commit this on your behalf once build
> has passed the point of failure.

...which includes not just compiling auto-inc-dec.c but also
compiling e.g. libgcc with the compiled compiler.  No such luck,
segv in that function (must be from Richard's code, not from the
patch as no dumps are output at that time).  Bah.

brgds, H-P

Move TLS_MODEL into symbol table

[Jan Hubicka]

Hello,
this patch continues on my work to move symbol related things into symbol table
rather than having them in decl_with_vis. This time I move TLS_MODEl, that is
relatively easy thing to do. I again followed same scheme as with sections and
comdat groups.

I tried to do this at once with DECL_VISBILITY but learnt the hard way that
DECL_VISBILITY matters for TYPE_DECLs, too, in C++ FE.

Jason, this is not the only case where I run into.  In fact I would like to get
DECL_SAVED_TREE, DECL_ARGUMENTS, DECL_RESULT and DECL_VINDEX out of
tree_decl_non_common that is shared by functions, variables, namespaces, type
decls and frontend's decls, such as templates. What would be preferred way of
getting these out of the tree.h into C++ specific representation?

Honza

Bootstrapped/regtested x86_64-linux, comitted.

* c-family/c-common.c (handle_tls_model_attribute): Use 
set_decl_tls_model.
* cgraph.h (struct varpool_node): Add tls_model.
* tree.c (decl_tls_model, set_decl_tls_model): New functions.
* tree.h (DECL_TLS_MODEL): Update.
(DECL_THREAD_LOCAL_P): Check that variable is static.
(decl_tls_model): Declare.
(set_decl_tls_model): Declare.
* tree-emutls.c (get_emutls_init_templ_addr): First build decl and then
set symbol prorperties.
(get_emutls_init_templ_addr): Cleanup.
(new_emutls_decl): Update.
* lto-cgraph.c (lto_output_varpool_node): Stream TLS model
(lto_input_varpool_node): Likewise.
* lto-streamer-out.c (hash_tree): Likewise.
* tree-streamer-in.c (unpack_ts_decl_with_vis_value_fields): Do
not stream DECL_TLS_MODEL.
* tree-profile.c (init_ic_make_global_vars): Use
set_decl_tls_model.
* tree-core.h (tree_decl_with_vis): Remove tls_model;
update comments.

* c-parser.c (c_parser_omp_threadprivate): Likewise.
* c-decl.c (merge_decls): Likewise.

* decl.c (duplicate_decls): Use set_decl_tls_model.
(grokdeclarator): Likewise.
* semantics.c (finish_id_expression): Check TLS only for
static variables.
(finish_omp_threadprivate): Use decl_default_tls_model.
* decl2.c (get_guard): Likewise.
* call.c (make_temporary_var_for_ref_to_temp): Likewise.

* gcc-interface/utils.c (process_attributes): Use
set_decl_tls_model.

* trans-common.c (build_common_decl): Use
set_decl_tls_model.
* trans-decl.c (gfc_finish_var_decl): Likewise.
(get_proc_pointer_decl): Likewise.

* lto.c (compare_tree_sccs_1): Do not compare DECL_TLS_MODEL.


Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 211688)
+++ c-family/c-common.c (working copy)
@@ -8036,7 +8036,7 @@ handle_tls_model_attribute (tree *node,
   else
 error ("tls_model argument must be one of \"local-exec\", 
\"initial-exec\", \"local-dynamic\" or \"global-dynamic\"");
 
-  DECL_TLS_MODEL (decl) = kind;
+  set_decl_tls_model (decl, kind);
   return NULL_TREE;
 }
 
Index: c/c-parser.c
===
--- c/c-parser.c(revision 211688)
+++ c/c-parser.c(working copy)
@@ -13557,7 +13557,7 @@ c_parser_omp_threadprivate (c_parser *pa
{
  if (! DECL_THREAD_LOCAL_P (v))
{
- DECL_TLS_MODEL (v) = decl_default_tls_model (v);
+ set_decl_tls_model (v, decl_default_tls_model (v));
  /* If rtl has been already set for this var, call
 make_decl_rtl once again, so that encode_section_info
 has a chance to look at the new decl flags.  */
Index: c/c-decl.c
===
--- c/c-decl.c  (revision 211688)
+++ c/c-decl.c  (working copy)
@@ -2294,7 +2294,7 @@ merge_decls (tree newdecl, tree olddecl,
   /* Merge the threadprivate attribute.  */
   if (TREE_CODE (olddecl) == VAR_DECL && C_DECL_THREADPRIVATE_P (olddecl))
 {
-  DECL_TLS_MODEL (newdecl) = DECL_TLS_MODEL (olddecl);
+  set_decl_tls_model (newdecl, DECL_TLS_MODEL (olddecl));
   C_DECL_THREADPRIVATE_P (newdecl) = 1;
 }
 
@@ -6345,7 +6345,7 @@ grokdeclarator (const struct c_declarato
  }
 
if (threadp)
- DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
+ set_decl_tls_model (decl, decl_default_tls_model (decl));
   }
 
 if ((storage_class == csc_extern
Index: cgraph.h
===
--- cgraph.h(revision 211688)
+++ cgraph.h(working copy)
@@ -708,6 +708,8 @@ public:
   /* Set if the variable is dynamically initialized, except for
  function local statics.   */
   unsigned dynamically_initialized : 1;
+
+  ENUM_BITFIELD(tls_model) tls_model : 3;
 };
 
 /* Every top level asm statement is put into a asm_node.  */
Index: tree.c

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[Hans-Peter Nilsson]

On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:

> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
> > On Sun, 15 Jun 2014, Steven Bosscher wrote:
> > > Can you please try:
> > >
> > > [...]
> >
> > Thanks.  Looks pretty obvious.  I was heading for the door with
> > just enough time to report the issue, so I didn't actually look
> > at the code before.  I'll commit this on your behalf once build
> > has passed the point of failure.
>
> ...which includes not just compiling auto-inc-dec.c but also
> compiling e.g. libgcc with the compiled compiler.  No such luck,
> segv in that function (must be from Richard's code, not from the
> patch as no dumps are output at that time).  Bah.

Ok, I'm out; I don't know why the insn_info is invalid here.
Hopefully obvious to you or Richard.  PR61516 for this.

brgds, H-P

Re: breakage with "[PATCH 1/6] Add FOR_EACH_INSN{_INFO}_{DEFS,USES,EQ_USES}"

[David Edelsohn]

The auto-inc-dec.c compilation fix gets us to the next error -- a
runtime failure in the file:


(gdb) run -g -O2 -mlong-double-128 -fbuilding-libgcc
-fno-stack-protector __gcc_bcmp.i
Starting program: /tmp/20140615/gcc/cc1 -g -O2 -mlong-double-128
-fbuilding-libgcc -fno-stack-protector __gcc_bcmp.i
 strtoimax select getdtablesize mode_size_inline mode_nunits_inline
mode_inner_inline __gcc_bcmp
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  
<*free_inline_summary>   
 Assembling
functions:
 __gcc_bcmp
Program received signal SIGSEGV, Segmentation fault.
0x10276e4c in _ZL14merge_in_blockiP15basic_block_def (max_reg=174,
bb=0x70001a00) at /nasfarm/edelsohn/src/src/gcc/auto-inc-dec.c:1427
1427  reg_next_use[DF_REF_REGNO (def)] = NULL;

- David

[PATCH] gcc/dwarf2asm.c: Add static_output_delta() with var_list for dw2_asm_output_delta()

[Chen Gang]

dw2_asm_output_vms_delta() calls dw2_asm_output_delta() in an abnormal
way, so need add a new function just like vprintf() for printf(), and
then the related call will be in normal way.

The related warning:

  ../../gcc/gcc/dwarf2asm.c: In function ‘void dw2_asm_output_vms_delta(int, 
const char*, const char*, const char*, ...)’:
  ../../gcc/gcc/dwarf2asm.c:167:50: warning: format not a string literal and no 
format arguments [-Wformat-security]


Signed-off-by: Chen Gang 
---
 gcc/ChangeLog   |  6 ++
 gcc/dwarf2asm.c | 21 +
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index edb3fc0..0e1df0e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2014-06-14  Chen Gang 
+
+   * dwarf2asm.c (dw2_asm_output_delta): Add static_output_delta() for
+   dw2_asm_output_delta(), just like vprintf() for printf(), so that
+   dw2_asm_output_vms_delta() can use it in normal way.
+
 2014-06-13  Vladimir Makarov  
 
* lra-assign.c (assign_by_spills): Add code to assign vector regs
diff --git a/gcc/dwarf2asm.c b/gcc/dwarf2asm.c
index 1372b23..fa2dd4f 100644
--- a/gcc/dwarf2asm.c
+++ b/gcc/dwarf2asm.c
@@ -123,14 +123,10 @@ dw2_asm_output_data (int size, unsigned HOST_WIDE_INT 
value,
impossible to do here, since the ASM_SET_OP for the difference
symbol must appear after both symbols are defined.  */
 
-void
-dw2_asm_output_delta (int size, const char *lab1, const char *lab2,
- const char *comment, ...)
+static void
+static_output_delta (int size, const char *lab1, const char *lab2,
+ const char *comment, va_list ap)
 {
-  va_list ap;
-
-  va_start (ap, comment);
-
 #ifdef ASM_OUTPUT_DWARF_DELTA
   ASM_OUTPUT_DWARF_DELTA (asm_out_file, size, lab1, lab2);
 #else
@@ -145,7 +141,16 @@ dw2_asm_output_delta (int size, const char *lab1, const 
char *lab2,
   vfprintf (asm_out_file, comment, ap);
 }
   fputc ('\n', asm_out_file);
+}
 
+void
+dw2_asm_output_delta (int size, const char *lab1, const char *lab2,
+ const char *comment, ...)
+{
+  va_list ap;
+
+  va_start (ap, comment);
+  static_output_delta(size, lab1, lab2, comment, ap);
   va_end (ap);
 }
 
@@ -164,7 +169,7 @@ dw2_asm_output_vms_delta (int size ATTRIBUTE_UNUSED,
 #ifndef ASM_OUTPUT_DWARF_VMS_DELTA
   /* VMS Delta is only special on ia64-vms, but this function also gets
  called on alpha-vms so it has to do something sane.  */
-  dw2_asm_output_delta (size, lab1, lab2, comment);
+  static_output_delta (size, lab1, lab2, comment, ap);
 #else
   ASM_OUTPUT_DWARF_VMS_DELTA (asm_out_file, size, lab1, lab2);
   if (flag_debug_asm && comment)
-- 
1.9.2.459.g68773ac

Re: [PATCH 1/n] Add conditional compare framework in middle-end

[Andrew Pinski]

On Sat, Jun 14, 2014 at 7:50 PM, Andrew Pinski  wrote:
> On Mon, Feb 24, 2014 at 1:18 AM, Zhenqiang Chen
>  wrote:
>> Hi,
>>
>> The patch (http://gcc.gnu.org/ml/gcc-patches/2014-11/msg03622.html) is
>> re-based (the arm port change is stripped as a separate patch), which
>> includes only the middle-end changes. The basic logic for the patch
>> is:
>>
>>   1) Identify conditional compare candidates when expanding one GIMPLE_COND.
>>   2) For a candidate, it uses two target hooks to generate the expected 
>> codes:
>>  - gen_ccmp_first expands the first compare in CCMP.
>>  - gen_ccmp_next expands the following compares.
>>
>>  Another hook select_ccmp_cmp_order is called to determine which compare
>>  is done first since not all combination of compares are legal in some
>>  target like ARM.  We might get more chance when swapping the compares.
>>  For AARCH64 and IA64, we do not need such check.
>>
>>  During expanding, we must make sure that no instruction can clobber the
>>  CC reg except the compares.
>>
>>  If the final result is not used in a COND_EXPR, it calls cstorecc4 
>> pattern
>>   to store the CC to a general register.
>>
>> Bootstrap and no make check regression on X86-64.
>
> I was testing this patch set out on AARCH64 with an addition patch to
> define cstorecc4 and found an issue:
> +  rtx target = gen_reg_rtx (word_mode);
> +  tmp = emit_cstore (target, icode, NE, CCmode, CCmode,
> + 0, tmp, const0_rtx, 1, word_mode);
> +  if (tmp)
> +return tmp;
>
> The wrong mode is being used in the above code.
> The testcase is:
> _Bool f(int a, int b)
> {
>   return a != 0 && b != 0;
> }
>  CUT 
>
> I am working on the patch to fix this issue.


I have a fix and it is unrelated really to this patch except it is
just exposed by it.  I will be submitting it in the next few days.

Thanks,
Andrew

>
> Thanks,
> Andrew
>
>
>>
>> Is is OK for next stage1?
>>
>> Thanks!
>> -Zhenqiang
>>
>> ChangeLog:
>> 2014-02-24  Zhenqiang Chen  
>>
>> * cfgexpand.c (expand_gimple_cond): Check ccmp support.
>> * doc/md.texi (ccmp): New index.
>> * doc/tm.texi (TARGET_SELECT_CCMP_CMP_ORDER, TARGET_GEN_CCMP_FIRST,
>> TARGET_GEN_CCMP_NEXT): New hooks.
>> * doc/tm.texi (TARGET_SELECT_CCMP_CMP_ORDER, TARGET_GEN_CCMP_FIRST,
>> TARGET_GEN_CCMP_NEXT): New hooks.
>> * doc/tm.texi.in (TARGET_SELECT_CCMP_CMP_ORDER, TARGET_GEN_CCMP_FIRST,
>> TARGET_GEN_CCMP_NEXT): New hooks.
>> * expmed.c (emit_cstore): Make it global.
>> * expr.c: Include tree-phinodes.h and ssa-iterators.h.
>> (ccmp_candidate_p, used_in_cond_stmt_p, check_clobber_cc, clobber_cc_p,
>> gen_ccmp_next, expand_ccmp_expr_1, expand_ccmp_expr): New functions.
>> (expand_expr_real_1): Handle conditional compare.
>> * optabs.c (get_rtx_code): Make it global and handle BIT_AND_EXPR and
>> BIT_IOR_EXPR.
>> * optabs.h (get_rtx_code, emit_cstore): New prototypes.
>> * recog.c (ccmp_insn_p): New function.
>> (simplify_while_replacing): Do not swap ccmp insn.
>> * target.def (select_ccmp_cmp_order, gen_ccmp_first, gen_ccmp_next):
>> Define hooks.
>> * targhooks.c (default_select_ccmp_cmp_order): New function.
>> * targhooks.h (default_select_ccmp_cmp_order): New prototypes.

Another AIX Bootstrap failure

[David Edelsohn]

Honza,

The cgraph patch in r211600 broke AIX bootstrap again.  I cannot find
the corresponding patch in the GCC Patches mailing list, so I do not
see where this was discussed or approved.

With the patch in r211600, the "gen*" programs in stage2 go into an
endless loop.

Please revert these comdat patches.  These were not tested appropriately.

Please create a branch and we can debug the problems on AIX.

Thanks, David

Re: Another AIX Bootstrap failure

[Jan Hubicka]

> Honza,
> 
> The cgraph patch in r211600 broke AIX bootstrap again.  I cannot find
> the corresponding patch in the GCC Patches mailing list, so I do not
> see where this was discussed or approved.

Sorry, I remember writting mail about this patch but also can't find it.  The
patch introduces reset_section that is used when function or variable is
brought local by the visibility code. In this case we previously incorrectly
cleared user sections and we forgot to introduce implicit sections with
-fdata-section and -ffunction-section.

I will revert this change and lets debug it.

> 
> With the patch in r211600, the "gen*" programs in stage2 go into an
> endless loop.
> 
> Please revert these comdat patches.  These were not tested appropriately.
> 
> Please create a branch and we can debug the problems on AIX.

What patches you refer to? I already disabled the localization within
initializers on AIX (well all targets w/o MAKE_ONE_ONLY support) and
I am testing patch reverting this change (I want to keep reset section
just remove the call to resolve unique section) and will commit once
it converges.

I will send you patch to enable those two changes and lets look into why 
they break. What is common to both patches is that they deal with static
symbol in named sections, perhaps that is not correctly supported by AIX
toolchain...

My apologizes for the breakage. I am attaching the patch for reference.
Honza


* symtab.c (symtab_node::reset_section): New method.
* cgraph.c (cgraph_node_cannot_be_local_p_1): Accept non-local
for localization.
* cgraph.h (reset_section): Declare.
* ipa-inline-analysis.c (do_estimate_growth): Check for comdat groups;
do not consider comdat locals.
* cgraphclones.c (set_new_clone_decl_and_node_flags): Get section
for new symbol.
* ipa-visiblity.c (cgraph_externally_visible_p): Cleanup.
(update_visibility_by_resolution_info): Consider UNDEF; fix checking;
reset sections of symbols dragged out of the comdats.
(function_and_variable_visibility): Reset sections of localized symbols.
Index: symtab.c
===
--- symtab.c(revision 211489)
+++ symtab.c(working copy)
@@ -1176,6 +1176,21 @@ symtab_node::set_section (const char *se
   symtab_for_node_and_aliases (this, set_section_1, const_cast(section), true);
 }
 
+/* Reset section of NODE.  That is when NODE is being brought local
+   we may want to clear section produced for comdat group and depending
+   on function-sections produce now, local, unique section for it.  */
+
+void
+symtab_node::reset_section ()
+{
+  if (!this->implicit_section)
+return;
+  this->set_section (NULL);
+  resolve_unique_section (this->decl, 0,
+ is_a  (this)
+ ? flag_function_sections : flag_data_sections);
+}
+
 /* Worker for symtab_resolve_alias.  */
 
 static bool
Index: cgraph.c
===
--- cgraph.c(revision 211488)
+++ cgraph.c(working copy)
@@ -2169,6 +2169,7 @@ cgraph_node_cannot_be_local_p_1 (struct
&& !node->forced_by_abi
&& !symtab_used_from_object_file_p (node)
&& !node->same_comdat_group)
+  || DECL_EXTERNAL (node->decl)
   || !node->externally_visible));
 }
 
@@ -2259,14 +2260,14 @@ cgraph_make_node_local_1 (struct cgraph_
 {
   symtab_make_decl_local (node->decl);
 
-  node->set_section (NULL);
   node->set_comdat_group (NULL);
   node->externally_visible = false;
   node->forced_by_abi = false;
   node->local.local = true;
-  node->set_section (NULL);
+  node->reset_section ();
   node->unique_name = (node->resolution == LDPR_PREVAILING_DEF_IRONLY
- || node->resolution == 
LDPR_PREVAILING_DEF_IRONLY_EXP);
+  || node->unique_name
+  || node->resolution == 
LDPR_PREVAILING_DEF_IRONLY_EXP);
   node->resolution = LDPR_PREVAILING_DEF_IRONLY;
   gcc_assert (cgraph_function_body_availability (node) == AVAIL_LOCAL);
 }
Index: cgraph.h
===
--- cgraph.h(revision 211489)
+++ cgraph.h(working copy)
@@ -208,6 +208,7 @@ public:
   /* Set section for symbol and its aliases.  */
   void set_section (const char *section);
   void set_section_for_node (const char *section);
+  void reset_section ();
 };
 
 enum availability
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c   (revision 211488)
+++ ipa-inline-analysis.c   (working copy)
@@ -3877,7 +3877,7 @@ do_estimate_growth (struct cgraph_node *
   /* COMDAT functions are very often not shared across multiple units
  since they come from various template instantiations.

Re: [PATCH, libgfortran] Add overflow check to xmalloc

[Janne Blomqvist]

On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
 wrote:
>
>> >> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>> >>  wrote:
>> >>> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>> >>>  wrote:
>>  Hi,
>> 
>>  a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that
>>  is, create space for an array of type foo_t with num_foo elements.
>>  There is a slight danger here in that the multiplication can overflow
>>  and wrap around, and then the caller thinks it has a larger array
>>  than
>>  what malloc has actually created. The attached patch changes the
>>  libgfortran xmalloc() function to have an API similar to calloc()
>>  with
>>  two arguments, and the implementation checks for wraparound.
>> >>>
>> >>> Hello,
>> >>>
>> >>> attached is an updated patch which instead introduces a new function,
>> >>> xmallocarray, with the overflow check, and leaves the existing xmalloc
>> >>> as is. Thus avoiding the extra checking in the common case where one
>> >>> of the arguments to xmallocarray would be 1.
>> >>>
>> >>> Tested on x86_64-unknown-linux-gnu, Ok for trunk?
>> >>>
>
>
> I would prefer if xcmalloc would not be named xmallocarray.

Hmm, never heard of that one before, but I have no particular
preference wrt the naming of the function. Ok with that rename?



-- 
Janne Blomqvist

[PATCH][PING] Fix for PR 61422

[Marat Zakirov]

-Original Message-
From: Marat Zakirov [mailto:m.zaki...@samsung.com] 
Sent: Friday, June 06, 2014 3:43 PM
To: 'gcc-patches@gcc.gnu.org'
Cc: 'Konstantin Serebryany'; 'Jakub Jelinek'; 'Slava Garbuzov'; Gribov Yury;
'Marat Zakirov'
Subject: [PATCH] Fix for PR 61422

Hi all,

Here's a patch for PR 61422
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422). 

It fixes false positive on 16 byte access in ffmpeg standard library opus
file NLSF_del_dec_quant.c.  

Reg. tested on x64.

--Marat


PR61422.diff
Description: Binary data