[Bug rtl-optimization/64003] New: valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[Bug rtl-optimization/64003] New: valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

            Bug ID: 64003
           Summary: valgrind complains about get_attr_length_nobnd in
                    insn-attrtab.c from i386.md
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
              Host: x86_64-unknown-linux-gnu
            Target: x86_64-unknown-linux-gnu
             Build: x86_64-unknown-linux-gnu

Created attachment 34057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34057&action=edit
Reproducer

When I run the jit testsuite under valgrind I consistently see reports from
here:

Conditional jump or move depends on uninitialised value(s)
   at 0x5721AED: get_attr_length_nobnd(rtx_insn*) (i386.md:6236)
   by 0x5715F3A: insn_min_length(rtx_insn*) (i386.md:510)
   by 0x4F4BE0A: shorten_branches(rtx_insn*) (final.c:1208)
   by 0x4F52A5A: rest_of_handle_shorten_branches() (final.c:4567)
   by 0x4F52AAE: (anonymous
namespace)::pass_shorten_branches::execute(function*) (final.c:4596)
   by 0x522354D: execute_one_pass(opt_pass*) (passes.c:2306)
   by 0x52237C4: execute_pass_list_1(opt_pass*) (passes.c:2358)
   by 0x52237F5: execute_pass_list_1(opt_pass*) (passes.c:2359)
   by 0x52237F5: execute_pass_list_1(opt_pass*) (passes.c:2359)
   by 0x5223832: execute_pass_list(function*, opt_pass*) (passes.c:2369)
   by 0x4E4884F: cgraph_node::expand() (cgraphunit.c:1773)
   by 0x4E48EE9: expand_all_functions() (cgraphunit.c:1909)

I can reproduce this with cc1 with the attached file at -O2 and above:
  valgrind ./cc1 get-attr-length-i386.c -O2

This is with r217427 on x86_64-unknown-linux-gnu, configuring with:
 --enable-valgrind-annotations 


Turning off the writing of #line directives in read-md.c shows that it's at
line 18500 of the generated insn-attrtab.c:

==5819==    at 0xD952E2: get_attr_length_nobnd(rtx_insn*)
(insn-attrtab.c:18500)

somewhere within this monster conditional:

 18493  int
 18494  get_attr_length_nobnd (rtx_insn *insn ATTRIBUTE_UNUSED)
 18495  {
 18496    switch (recog_memoized (insn))
 18497      {
 18498      case 610:  /* *jcc_1 */
 18499        extract_insn_cached (insn);
>18500        if ((((INSN_ADDRESSES_SET_P () ? INSN_ADDRESSES (INSN_UID (GET_CODE (operands[0]) == LABEL_REF ? XEXP (operands[0], 0) : operands[0])) : 0) - (insn_current_reference_address (insn))) >= (-126)) && (((INSN_ADDRESSES_SET_P () ? INSN_ADDRESSES (INSN_UID (GET_CODE (operands[0]) == LABEL_REF ? XEXP (operands[0], 0) : operands[0])) : 0) - (insn_current_reference_address (insn))) < (128)))

[Bug rtl-optimization/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #1 from dmalcolm at gcc dot gnu.org ---
Marking as "Blocks" bug 63854, since I'd prefer to get the jit entirely clean
under valgrind.

[Bug rtl-optimization/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #2 from dmalcolm at gcc dot gnu.org ---
FWIW, line 6236 of i386.md is here:
  6229  (define_insn "*subv<mode>4_1"
  6230    [(set (reg:CCO FLAGS_REG)
  6231          (eq:CCO (minus:<DWI>
  6232                     (sign_extend:<DWI>
  6233                        (match_operand:SWI 1 "nonimmediate_operand" "0"))
  6234                     (match_operand:<DWI> 3 "const_int_operand" "i"))
  6235                  (sign_extend:<DWI>
>>6236                     (minus:SWI (match_dup 1)
  6237                                (match_operand:SWI 2
"x86_64_immediate_operand"
  6238                                                     "<i>")))))
  6239     (set (match_operand:SWI 0 "nonimmediate_operand" "=<r>m")
  6240          (minus:SWI (match_dup 1) (match_dup 2)))]
  6241    "ix86_binary_operator_ok (MINUS, <MODE>mode, operands)
  6242     && CONST_INT_P (operands[2])
  6243     && INTVAL (operands[2]) == INTVAL (operands[3])"
  6244    "sub{<imodesuffix>}\t{%2, %0|%0, %2}"
  6245    [(set_attr "type" "alu")
  6246     (set_attr "mode" "<MODE>")
  6247     (set (attr "length_immediate")
  6248          (cond [(match_test "IN_RANGE (INTVAL (operands[2]), -128,
127)")
  6249                    (const_string "1")
  6250                 (match_test "<MODE_SIZE> == 8")
  6251                    (const_string "4")]
  6252                (const_string "<MODE_SIZE>")))])

[Bug rtl-optimization/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #3 from dmalcolm at gcc dot gnu.org ---
fwiw, "insn" seems to be:

(jump_insn:TI 10 4 56 2 (set (pc)
        (if_then_else (eq (reg:CCGC 17 flags)
                (const_int 0 [0]))
            (label_ref 29)
            (pc)))
/home/david/coding-3/gcc-git-jit-valgrind/get-attr-length-i386.c:3 610 {*jcc_1}
     (int_list:REG_BR_PROB 2000 (nil))
 -> 29)

[Bug rtl-optimization/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #4 from dmalcolm at gcc dot gnu.org ---
(In reply to dmalcolm from comment #3)
> fwiw, "insn" seems to be:
> 
> (jump_insn:TI 10 4 56 2 (set (pc)
>         (if_then_else (eq (reg:CCGC 17 flags)
>                 (const_int 0 [0]))
>             (label_ref 29)
>             (pc)))
> /home/david/coding-3/gcc-git-jit-valgrind/get-attr-length-i386.c:3 610
> {*jcc_1}
>      (int_list:REG_BR_PROB 2000 (nil))
>  -> 29)
...so presumably it's the attr highlighted below:

 10920  (define_insn "*jcc_1"
 10921    [(set (pc)
 10922          (if_then_else (match_operator 1 "ix86_comparison_operator"
 10923                                        [(reg FLAGS_REG) (const_int 0)])
 10924                        (label_ref (match_operand 0))
 10925                        (pc)))]
 10926    ""
 10927    "%!%+j%C1\t%l0"
 10928    [(set_attr "type" "ibr")
 10929     (set_attr "modrm" "0")
>10930     (set (attr "length_nobnd")
>10931             (if_then_else (and (ge (minus (match_dup 0) (pc))
>10932                                    (const_int -126))
>10933                                (lt (minus (match_dup 0) (pc))
>10934                                    (const_int 128)))
>10935               (const_int 2)
>10936               (const_int 6)))])
 10937

[Bug rtl-optimization/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #5 from dmalcolm at gcc dot gnu.org ---
Running valgrind with --track-origins=yes shows:
==9952==  Uninitialised value was created by a heap allocation
==9952==    at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9952==    by 0x12BF3B7: xmalloc (xmalloc.c:147)
==9952==    by 0x7876A4: shorten_branches(rtx_insn*) (final.c:1022)
==9952==    by 0x787F5F: (anonymous
namespace)::pass_shorten_branches::execute(function*) (final.c:4567)
==9952==    by 0x994581: execute_one_pass(opt_pass*) (passes.c:2269)
==9952==    by 0x994B95: execute_pass_list_1(opt_pass*) (passes.c:2321)
==9952==    by 0x994BA7: execute_pass_list_1(opt_pass*) (passes.c:2322)
==9952==    by 0x994BA7: execute_pass_list_1(opt_pass*) (passes.c:2322)
==9952==    by 0x994BE8: execute_pass_list(function*, opt_pass*)
(passes.c:2332)
==9952==    by 0x6B87E3: cgraph_node::expand() (cgraphunit.c:1773)
==9952==    by 0x6B9DB8: symbol_table::compile() (cgraphunit.c:1909)
==9952==    by 0x6BB69C: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2325)

specifically, it's reading uninitialized data from the insn_lengths array
allocated here:
  insn_lengths = XNEWVEC (int, max_uid);

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #6 from dmalcolm at gcc dot gnu.org ---
If I'm reading things right, this loop in shorten_branches populates
insn_lengths[uid] in order of the NEXT_INSN () iteration:

  int (*length_fun) (rtx_insn *) = increasing ? insn_min_length :
insn_default_length;

  for (insn_current_address = 0, insn = first;
       insn != 0;
       insn_current_address += insn_lengths[uid], insn = NEXT_INSN (insn))
    {
      uid = INSN_UID (insn);

      insn_lengths[uid] = 0;

      /* lots of logic, which can call length_fun, and hence insn_min_length. 
*/
    }

and "length_fun" can call into insn_min_length, and hence this calls into the
get_attr_length_nobnd, which AIUI for this case is accessing lengths of other
insns before they've been populated: presumably for a jump forwards?


FWIW this untested patch silences the valgrind warning:

diff --git a/gcc/final.c b/gcc/final.c
index c3805c9..0805418 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1019,7 +1019,7 @@ shorten_branches (rtx_insn *first)
     return;

   /* Allocate the rest of the arrays.  */
-  insn_lengths = XNEWVEC (int, max_uid);
+  insn_lengths = XCNEWVEC (int, max_uid);
   insn_lengths_max_uid = max_uid;
   /* Syntax errors can lead to labels being outside of the main insn stream.
      Initialize insn_addresses, so that we get reproducible results.  */
@@ -1127,8 +1127,6 @@ shorten_branches (rtx_insn *first)
     {
       uid = INSN_UID (insn);

-      insn_lengths[uid] = 0;
-
       if (LABEL_P (insn))
        {
          int log = LABEL_TO_ALIGNMENT (insn);

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #7 from dmalcolm at gcc dot gnu.org ---
A more minimal reproducer:

$ cat get-attr-length-i386.c
int test_pr64003 (int p)
{
  if (p == 0)
    return 5;
  if (p == 1)
    return 7;

  return 0;
}

$ valgrind ./cc1 get-attr-length-i386.c -O2

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #8 from dmalcolm at gcc dot gnu.org ---
Created attachment 34165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34165&action=edit
Patch to add instrumentation to final.c to track the reads/writes of
insn_lengths

The attached patch adds instrumentation of all reads/writes of the insn_lengths
array.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #9 from dmalcolm at gcc dot gnu.org ---
Created attachment 34166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34166&action=edit
Dump of RTL from the reproducer

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #10 from dmalcolm at gcc dot gnu.org ---
Created attachment 34167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34167&action=edit
Log from gdb session, with a conditional breakpoint to trap uninitialized reads

This is a log of a gdb session debugging cc1 compiling the reproducer from
comment #7, using the instrumentation patch from comment #8.

I put a breakpoint on:
  fancy_element::operator int () const
with condition that result == 0xabababab to handle reads of uninitialized
elements from insn_lengths[].

I took a backtrace both times that the conditional breakpoint occurred.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #11 from dmalcolm at gcc dot gnu.org ---
Investigating the backtrace at the point of the uninit read shows that
the issue occurs in shorten_branches here:

#5  0x00000000006f3263 in shorten_branches (first=0x7ffff1687700) at
../../src/gcc/final.c:1286
1284          else if (GET_CODE (body) != USE && GET_CODE (body) != CLOBBER)
1285        {
1286          insn_lengths[uid] = length_fun (insn);
1287          varying_length[uid] = insn_variable_length_p (insn);
1288        }

(gdb) p uid
$7 = 10
(gdb) p length_fun
$8 = (int (*)(rtx_insn *)) 0xbeb5d1 <insn_min_length(rtx_insn*)>
(gdb) call debug(insn)
(jump_insn:TI 10 4 16 2 (set (pc)
        (if_then_else (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref:DI 52)
            (pc)))
/home/david/coding-3/gcc-git-jit-valgrind/get-attr-length-i386.c:3 610 {*jcc_1}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (int_list:REG_BR_PROB 3300 (nil)))
 -> 52)

I put insn-attrtab.c through GNU indent to make the conditional easier to read:

(gdb) down
#4  0x0000000000beb7b7 in insn_min_length (insn=0x7ffff1685b40) at
insn-attrtab.c:276
276        (ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
(gdb) list
271        case 611:            /* *jcc_2 */
272        case 610:            /* *jcc_1 */
273          extract_constrain_insn_cached (insn);
274          return
275    /*line 516 "../../src/gcc/config/i386/i386.md"*/
276        (ix86_bnd_prefixed_insn_p (insn)) + get_attr_length_nobnd (insn);
277    
278        case 163:            /* *truncxfdf2_mixed */
279        case 162:            /* *truncxfsf2_mixed */
280        case 160:            /* *truncdfsf_i387 */

(gdb) down
#3  0x0000000000bf73b4 in get_attr_length_nobnd (insn=0x7ffff1685b40) at
insn-attrtab.c:19152
19152            (insn_current_reference_address (insn))) >= (-126))
(gdb) list
19147          if ((((INSN_ADDRESSES_SET_P ()?
19148             INSN_ADDRESSES (INSN_UID
19149                     (GET_CODE (operands[0]) ==
19150                      LABEL_REF ? XEXP (operands[0],
19151                            0) : operands[0])) : 0) -
19152            (insn_current_reference_address (insn))) >= (-126))
19153          &&
19154          (((INSN_ADDRESSES_SET_P ()?
19155             INSN_ADDRESSES (INSN_UID
19156                     (GET_CODE (operands[0]) ==

(gdb) down
#2  0x00000000006f1e23 in insn_current_reference_address
(branch=0x7ffff1685b40) at ../../src/gcc/final.c:754
754              - align_fuzz (seq, dest, length_unit_log, ~0));
(gdb) list
749         BRANCH also has no INSN_SHUID.  */
750      if (INSN_SHUID (seq) < INSN_SHUID (dest))
751        {
752          /* Forward branch.  */
753          return (insn_last_address + insn_lengths[seq_uid]
754              - align_fuzz (seq, dest, length_unit_log, ~0));
755        }
756      else
757        {
758          /* Backward branch.  */

(gdb) down
#1  0x00000000006f1c4e in align_fuzz (start=0x7ffff1685b40, end=0x7ffff17b8900,
known_align_log=0, growth=4294967295)
    at ../../src/gcc/final.c:703
703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
(gdb) list
698      for (align_label = uid_align[uid]; align_label; align_label =
uid_align[uid])
699        {
700          int align_addr, new_align;
701    
702          uid = INSN_UID (align_label);
703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];
704          if (uid_shuid[uid] > end_shuid)
705        break;
706          known_align_log = LABEL_TO_ALIGNMENT (align_label);
707          new_align = 1 << known_align_log;

i.e. the uninitialized read occurs within align_fuzz in "insn_lengths[uid]" in
this expressions:

703          align_addr = INSN_ADDRESSES (uid) - insn_lengths[uid];

(gdb) p uid
$10 = 52

handling a forward branch within a "*jcc_2" insn.

Running valgrind with vgdb to get the precise location of its
warnings indicates they are here within get_attr_length_nobnd in
insn-attrtab.c:19152:

19147          if ((((INSN_ADDRESSES_SET_P ()?
19148             INSN_ADDRESSES (INSN_UID
19149                     (GET_CODE (operands[0]) ==
19150                      LABEL_REF ? XEXP (operands[0],
19151                            0) : operands[0])) : 0) -
19152            (insn_current_reference_address (insn))) >= (-126))
19153          &&
19154          (((INSN_ADDRESSES_SET_P ()?
19155             INSN_ADDRESSES (INSN_UID
19156                     (GET_CODE (operands[0]) ==

i.e. at the logical-AND at line 19153.

Valgrind presumably is noticing the "uninitialized" trait of this
read, then propagating it through to the result of align_fuzz,
and thence to insn_current_reference_address, and hence to the whole
of the first argument of the logical-AND.

Hence the decision about whether to process the second argument of
the logical-AND is a jump that relies on an uninitialized value, and
hence valgrind complains.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[dmalcolm at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4843 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #12 from dmalcolm at gcc dot gnu.org ---
(In reply to dmalcolm from comment #11)
> Running valgrind with vgdb to get the precise location of its
> warnings indicates they are here within get_attr_length_nobnd in
> insn-attrtab.c:19152:
> 
> 19147	      if ((((INSN_ADDRESSES_SET_P ()?
> 19148		     INSN_ADDRESSES (INSN_UID
> 19149				     (GET_CODE (operands[0]) ==
> 19150				      LABEL_REF ? XEXP (operands[0],
> 19151							0) : operands[0])) : 0) -
> 19152		    (insn_current_reference_address (insn))) >= (-126))
> 19153		  &&
> 19154		  (((INSN_ADDRESSES_SET_P ()?
> 19155		     INSN_ADDRESSES (INSN_UID
> 19156				     (GET_CODE (operands[0]) ==
> 
> i.e. at the logical-AND at line 19153.
> 
> Valgrind presumably is noticing the "uninitialized" trait of this
> read, then propagating it through to the result of align_fuzz,
> and thence to insn_current_reference_address, and hence to the whole
> of the first argument of the logical-AND.
> 
> Hence the decision about whether to process the second argument of
> the logical-AND is a jump that relies on an uninitialized value, and
> hence valgrind complains.

i.e. the issue is that evaluating both sides of the (and) expression at line
10931 in:

 10920  (define_insn "*jcc_1"
 10921    [(set (pc)
 10922          (if_then_else (match_operator 1 "ix86_comparison_operator"
 10923                                        [(reg FLAGS_REG) (const_int 0)])
 10924                        (label_ref (match_operand 0))
 10925                        (pc)))]
 10926    ""
 10927    "%!%+j%C1\t%l0"
 10928    [(set_attr "type" "ibr")
 10929     (set_attr "modrm" "0")
 10930     (set (attr "length_nobnd")
>10931             (if_then_else (and (ge (minus (match_dup 0) (pc))
 10932                                    (const_int -126))
 10933                                (lt (minus (match_dup 0) (pc))
 10934                                    (const_int 128)))
 10935               (const_int 2)
 10936               (const_int 6)))])
 10937

for a forward jump, leads to reads of uninitialized items from insn_lengths in
align_fuzz for the uid for the jump target.

Hence we have an (and (UNINITIALIZED_1) (WILL_BE_UNINITIALIZED_2)) and hence
the decision about whether to short-circuit the read of WILL_BE_UNINITIALIZED_2
is a conditional jump that depends on UNINITIALIZED_1.
>From gcc-bugs-return-469232-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 02 16:27:01 2014
Return-Path: <gcc-bugs-return-469232-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24747 invoked by alias); 2 Dec 2014 16:27:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24678 invoked by uid 48); 2 Dec 2014 16:26:55 -0000
From: "nickc at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function
Date: Tue, 02 Dec 2014 16:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nickc at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc attachments.created
Message-ID: <bug-64010-4-LyS6EpkuGD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64010-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64010-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00239.txt.bz2
Content-length: 546

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd010

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Created attachment 34168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4168&actioníit
Patch for reload to avoid using argument regiesters when reloading a call insn

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #13 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #6)
> If I'm reading things right, this loop in shorten_branches populates
> insn_lengths[uid] in order of the NEXT_INSN () iteration:
> 
>   int (*length_fun) (rtx_insn *) = increasing ? insn_min_length :
> insn_default_length;
> 
>   for (insn_current_address = 0, insn = first;
>        insn != 0;
>        insn_current_address += insn_lengths[uid], insn = NEXT_INSN (insn))
>     {
>       uid = INSN_UID (insn);
> 
>       insn_lengths[uid] = 0;
> 
>       /* lots of logic, which can call length_fun, and hence
> insn_min_length.  */
>     }
> 
> and "length_fun" can call into insn_min_length, and hence this calls into
> the get_attr_length_nobnd, which AIUI for this case is accessing lengths of
> other insns before they've been populated: presumably for a jump forwards?

insn_min_length is not supposed to use current insn lengths.
genattrtab does not follow attributes for the purposes of determining
insn current length dependence.
So far we consider it the job of the port to provide
a length attribute that allows the calculation of minimum/maximum instruction
lengths with this limitation in mind.
That means the length attribute in i386.md is broken.
The get_attr_length_nobnd attribute need to be either inlined, or its use
guarded in a clause that appears to be length depepdent and supplies minimum
and maximum values.

AFAICS, the length attribute was broken in r217125
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00133.html

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|amylaar at gcc dot gnu.org         |enkovich.gnu at gmail dot com

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
Damn Joern, I was looking at this comment in the PA port last night wondering
if it was relevant to this discussion:

;; We use function calls to set the attribute length of calls and millicode
;; calls.  This is necessary because of the large variety of call sequences.
;; Implementing the calculation in rtl is difficult as well as ugly.  As
;; we need the same calculation in several places, maintenance becomes a
;; nightmare.
;;
;; However, this has a subtle impact on branch shortening.  When the
;; expression used to set the length attribute of an instruction depends
;; on a relative address (e.g., pc or a branch address), genattrtab
;; notes that the insn's length is variable, and attempts to determine a
;; worst-case default length and code to compute an insn's current length.

;; The use of a function call hides the variable dependence of our calls
;; and millicode calls.  The result is genattrtab doesn't treat the operation
;; as variable and it only generates code for the default case using our
;; function call.


Is this documented anywhere?  I certainly don't recall this restriction, but it
does answer one of the questions I'd been kicking around in my head.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #15 from Jeffrey A. Law <law at redhat dot com> ---
Just to be clear, that was a "Damn" as in "Damn good find", sorry if it came
out the wrong way.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu.org

--- Comment #16 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #14)

> Is this documented anywhere?  I certainly don't recall this restriction, but
> it does answer one of the questions I'd been kicking around in my head.

I've put a comment into sh.md to that effect - can't put a link to the
gcc-cvs archive here because the code is from 1998, but here's an excerpt:

;; ??? This should use something like *branch_p (minus (match_dup 0) (pc)),
;; but getattrtab doesn't understand this.
(define_attr "length" ""
  (cond [(eq_attr "type" "cbranch")
         (cond [(eq_attr "short_cbranch_p" "yes")
                (const_int 2)
                (eq_attr "med_cbranch_p" "yes")
                (const_int 6)
                (eq_attr "braf_cbranch_p" "yes")
                (const_int 12)
;; ??? using pc is not computed transitively.
                (ne (match_dup 0) (match_dup 0))
                (const_int 14)
...

The (ne (match_dup 0) (match_dup 0)) clause tells genattrtab that this
cond form is length-varying.

I had a patch to clear this up with a usable & documented interface:
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00473.html
It got stuck in code review, so it's now a local patch in the
Synopsys toolchains.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #17 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
(In reply to Jorn Wolfgang Rennecke from comment #13)
>  
> AFAICS, the length attribute was broken in r217125
> https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00133.html

If I understand the problem correctly the root is in attempt to get length of
following instructions computing length for forwrad jump instruction.  How
comes r217125 is guilty for that? It doesn't introduce such computations, it
just renames "length" attribute into "length_nobnd" for mentioned jump
patterns.  Do I miss something here?

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #18 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to Ilya Enkovich from comment #17)
> If I understand the problem correctly the root is in attempt to get length
> of following instructions computing length for forwrad jump instruction. 
> How comes r217125 is guilty for that? It doesn't introduce such
> computations, it just renames "length" attribute into "length_nobnd" for
> mentioned jump patterns.  Do I miss something here?

The length attribute is treated specially by genattrtab.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
I was thinking more along the lines of documented in the texi documention for
Length attributes.    Useful to have in sh.md, but better documented in a
location that is more likely to be read.

I don't think that inlining ix86_bnd_prefixed_insn_p in the attribute stuff is
really wise.

Are you suggesting that we can put in a dummy clause similar to the sh or pa
ports to resolve this issue?

For reference the PA port's hack looks like:

   (set (attr "length")
        (cond [(and (const_int 0) (eq (const_int 0) (pc))) (const_int 8)]
              (symbol_ref "pa_attr_length_call (insn, 0)")))])

The result of this hack is that during shortening these insns are considered as
having a fixed length (8 bytes).  So we might overestimte their actual size and
generate more long branches than necessary.  We have the length right by final,
so the final version may be shorter than the conservative estimate during
shorten-branches.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #20 from Jeffrey A. Law <law at redhat dot com> ---
Ilya, it's the function call in this code I think:

  (cond [(eq_attr "length_nobnd" "!0")
           (plus (symbol_ref ("ix86_bnd_prefixed_insn_p (insn)"))
                 (attr "length_nobnd"))

You're calling out to ix86_bnd_prefixed_insn_p, and that's problematical for
branch shortening if I'm understanding Joern's comments here and David's
comments in the PA port correctly.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #21 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #20)
> Ilya, it's the function call in this code I think:
> 
>   (cond [(eq_attr "length_nobnd" "!0")
>            (plus (symbol_ref ("ix86_bnd_prefixed_insn_p (insn)"))
>                  (attr "length_nobnd"))
> 
> You're calling out to ix86_bnd_prefixed_insn_p, and that's problematical for
> branch shortening if I'm understanding Joern's comments here and David's
> comments in the PA port correctly.

Then we have three problematic patterns and the easiest way to handle it is to
get rid of ix86_bnd_prefixed_insn_p call in length computation for them.  I
think the easiest way to do it is to have separate bnd and nobnd patterns for
these instructions.  Attached patch helps me to resolve valgrind error.  Is
such approach fine?

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #22 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
Created attachment 34195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34195&action=edit
Proposed patch

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #23 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Ilya Enkovich from comment #21)

> Then we have three problematic patterns and the easiest way to handle it is
> to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> I think the easiest way to do it is to have separate bnd and nobnd patterns
> for these instructions.  Attached patch helps me to resolve valgrind error. 
> Is such approach fine?

Maybe "enabled" attribute can help here to avoid unnecessary duplication.
>From gcc-bugs-return-469530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 05 10:49:20 2014
Return-Path: <gcc-bugs-return-469530-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21607 invoked by alias); 5 Dec 2014 10:49:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21563 invoked by uid 48); 5 Dec 2014 10:49:15 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
Date: Fri, 05 Dec 2014 10:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: y.gribov at samsung dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63888-4-3cFDaBdiWi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63888-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00537.txt.bz2
Content-length: 735

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc888

--- Comment #11 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Jakub Jelinek from comment #9)
> An ODR violation is IMHO something different, it is the case where you have
> the same symbol name (but, you'd need to distinguish between globally
> visible symbols that should be ODR checked and local symbols and/or symbols
> from languages you don't want to check for it) registered multiple times for
> multiple addresses.  So you'd need to hash based on the symbol name if
> marked for ODR checking, and check if the same (non-comdat) global isn't
> registered several times.

There is already proposal to this in UBSan:
http://llvm.org/bugs/show_bug.cgi?id!498

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #23)
> (In reply to Ilya Enkovich from comment #21)
> 
> > Then we have three problematic patterns and the easiest way to handle it is
> > to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> > I think the easiest way to do it is to have separate bnd and nobnd patterns
> > for these instructions.  Attached patch helps me to resolve valgrind error. 
> > Is such approach fine?
> 
> Maybe "enabled" attribute can help here to avoid unnecessary duplication.

No, please disregard the above sentence. The aproach with two patterns looks OK
AFAICS.
>From gcc-bugs-return-469532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 05 11:03:40 2014
Return-Path: <gcc-bugs-return-469532-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28591 invoked by alias); 5 Dec 2014 11:03:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28553 invoked by uid 48); 5 Dec 2014 11:03:34 -0000
From: "petschy at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64191] New: -march=native messes up dead code elimination in loop calling dtor
Date: Fri, 05 Dec 2014 11:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: petschy at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-64191-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00539.txt.bz2
Content-length: 6269

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd191

            Bug ID: 64191
           Summary: -march=native messes up dead code elimination in loop
                    calling dtor
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: petschy at gmail dot com

Without -march=native, the loops in the 3 fns are eliminated as expected,
resulting in single retq's.

With -march=native, the loop which calls the defined, but empty dtor is
compiled into something rather weird. However, the other empty Nop() call is
optimized away as expected.

g++-5.0.0 -g -O3 -Wall -Wextra -c 20141205-dtor_loop.cpp
g++-5.0.0 -g -O3 -Wall -Wextra -o 20141205-dtor_loop 20141205-dtor_loop.o

Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int):
   0x0000000000400570 <+0>:    repz retq
Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int):
   0x0000000000400580 <+0>:    repz retq
Dump of assembler code for function bar_nop_loop(Bar*, unsigned int):
   0x0000000000400590 <+0>:    repz retq

So far so good.

g++-5.0.0 -g -O3 -march=native -Wall -Wextra -c 20141205-dtor_loop.cpp
g++-5.0.0 -g -O3 -march=native -Wall -Wextra -o 20141205-dtor_loop
20141205-dtor_loop.o

Dump of assembler code for function foo_dtor_loop(Foo*, unsigned int):
   0x0000000000400570 <+0>:    retq

Dump of assembler code for function bar_dtor_loop(Bar*, unsigned int):
   0x0000000000400578 <+0>:     test   %rdi,%rdi
   0x000000000040057b <+3>:     je     0x4005b8 <bar_dtor_loop(Bar*, unsigned
int)+64>
   0x000000000040057d <+5>:     mov    %esi,%esi
   0x000000000040057f <+7>:     lea    (%rdi,%rsi,4),%rax
   0x0000000000400583 <+11>:    cmp    %rax,%rdi
   0x0000000000400586 <+14>:    jae    0x4005b8 <bar_dtor_loop(Bar*, unsigned
int)+64>
   0x0000000000400588 <+16>:    mov    $0x3,%edx
   0x000000000040058d <+21>:    lea    -0x4(%rax),%rsi
   0x0000000000400591 <+25>:    sub    %rdi,%rdx
   0x0000000000400594 <+28>:    add    %rsi,%rdx
   0x0000000000400597 <+31>:    mov    %rdx,%rcx
   0x000000000040059a <+34>:    shr    $0x2,%rcx
   0x000000000040059e <+38>:    lea    0x1(%rcx),%r8
   0x00000000004005a2 <+42>:    dec    %rcx
   0x00000000004005a5 <+45>:    shr    %rcx
   0x00000000004005a8 <+48>:    lea    0x2(%rcx,%rcx,1),%rcx
   0x00000000004005ad <+53>:    cmp    $0x2f,%rdx
   0x00000000004005b1 <+57>:    jbe    0x4005b8 <bar_dtor_loop(Bar*, unsigned
int)+64>
   0x00000000004005b3 <+59>:    cmp    %rcx,%r8
   0x00000000004005b6 <+62>:    je     0x4005b8 <bar_dtor_loop(Bar*, unsigned
int)+64>
   0x00000000004005b8 <+64>:    retq

Dump of assembler code for function bar_nop_loop(Bar*, unsigned int):
   0x00000000004005c0 <+0>:     retq

The bar_dtor_loop() fn is clearly a mess, unfortunately I can't follow the
computation.

The bar_inc_loop() does a single int increment on each object, to see what loop
code is generated if not empty fns are called. It is as expected: the loop is
unrolled 16x times, and the residual part is executed in a tight loop:
   0x0000000000400648 <+120>:    sub    $0x4,%rdx
   0x000000000040064c <+124>:    incl   (%rdx)
   0x000000000040064e <+126>:    cmp    %rdx,%rdi
   0x0000000000400651 <+129>:    jb     0x400648 <bar_inc_loop(Bar*, unsigned
int)+120>

g++-5.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.0.0
Thread model: posix
gcc version 5.0.0 20141027 (experimental) (GCC)

cat /proc/cpuinfo
processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 1
model name    : AMD FX(tm)-8150 Eight-Core Processor
stepping    : 2
microcode    : 0x6000626
cpu MHz        : 1400.000
cache size    : 2048 KB
physical id    : 0
siblings    : 8
core id        : 0
cpu cores    : 4
apicid        : 16
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb
rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni
pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb
hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
decodeassists pausefilter pfthreshold
bugs        : fxsave_leak
bogomips    : 7624.63
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb

Unfortunately, I couldn't test with the latest version since the build fails
with
../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file or
directory
a while know, even after deleting everything and doing a git reset --hard HEAD.

----8<----8<----8<----
struct Foo
{
        int i;
};
void foo_dtor_loop(Foo* p, unsigned int n)
{
        if (p) {
                Foo* e = p + n;
                while (e > p) {
                        --e;
                        e->~Foo();
                }
        }
}

struct Bar
{
        int i;
        ~Bar() { }
        void Nop() { }
        void Inc() { ++i; }
};
void bar_dtor_loop(Bar* p, unsigned int n)
{
        if (p) {
                Bar* e = p + n;
                while (e > p) {
                        --e;
                        e->~Bar();
                }
        }
}
void bar_nop_loop(Bar* p, unsigned int n)
{
        if (p) {
                Bar* e = p + n;
                while (e > p) {
                        --e;
                        e->Nop();
                }
        }
}
void bar_inc_loop(Bar* p, unsigned int n)
{
        if (p) {
                Bar* e = p + n;
                while (e > p) {
                        --e;
                        e->Inc();
                }
        }
}

int main()
{
}

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #25 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Ilya Enkovich from comment #21)
> (In reply to Jeffrey A. Law from comment #20)
> > Ilya, it's the function call in this code I think:
> > 
> >   (cond [(eq_attr "length_nobnd" "!0")
> >            (plus (symbol_ref ("ix86_bnd_prefixed_insn_p (insn)"))
> >                  (attr "length_nobnd"))
> > 
> > You're calling out to ix86_bnd_prefixed_insn_p, and that's problematical for
> > branch shortening if I'm understanding Joern's comments here and David's
> > comments in the PA port correctly.
> 
> Then we have three problematic patterns and the easiest way to handle it is
> to get rid of ix86_bnd_prefixed_insn_p call in length computation for them. 
> I think the easiest way to do it is to have separate bnd and nobnd patterns
> for these instructions.  Attached patch helps me to resolve valgrind error. 
> Is such approach fine?

If all you want to do is add 1 byte to the length to account for a prefix
then it might be cleaner to use ADJUST_INSN_LENGTH.  You could then keep
the single nobnd patterns.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[enkovich.gnu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #26 from Ilya Enkovich <enkovich.gnu at gmail dot com> ---
(In reply to rsandifo@gcc.gnu.org from comment #25)
> 
> If all you want to do is add 1 byte to the length to account for a prefix
> then it might be cleaner to use ADJUST_INSN_LENGTH.  You could then keep
> the single nobnd patterns.

Currently i386 target doesn't have ADJUST_INSN_LENGTH defined.  So I prefer to
keep it so and have all length definitions explicit in md file.

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #27 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Fri Dec  5 16:00:52 2014
New Revision: 218426

URL: https://gcc.gnu.org/viewcvs?rev=218426&root=gcc&view=rev
Log:
    PR target/64003
    * config/i386/i386.md (*jcc_1_bnd): New.
    (*jcc_2_bnd): New.
    (jump_bnd): New.
    (*jcc_1): Remove bnd prefix.
    (*jcc_2): Likewise.
    (jump): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Ilya Enkovich <ienkovich at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ienkovich at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #28 from Ilya Enkovich <ienkovich at gcc dot gnu.org> ---
Fixed

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #29 from Uroš Bizjak <ubizjak at gmail dot com> ---
*** Bug 66987 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-493173-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 08:32:28 2015
Return-Path: <gcc-bugs-return-493173-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4186 invoked by alias); 24 Jul 2015 08:32:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4106 invoked by uid 48); 24 Jul 2015 08:32:24 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66987] valgrind error in get_attr_length_nobnd
Date: Fri, 24 Jul 2015 08:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-66987-4-cyFxTEY1b1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66987-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66987-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02063.txt.bz2
Content-length: 643

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66987

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
This is actualy a dup of 64003, I removed extra jmp patterns in r225138.

Let's fix this properly using ADJUST_INSN_LENGTH, as suggested in the PR 64003

*** This bug has been marked as a duplicate of bug 64003 ***
>From gcc-bugs-return-493175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 08:34:13 2015
Return-Path: <gcc-bugs-return-493175-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27115 invoked by alias); 24 Jul 2015 08:34:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27085 invoked by uid 48); 24 Jul 2015 08:34:09 -0000
From: "neleai at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66989] New: poor performance of builtin_isfinite on x64
Date: Fri, 24 Jul 2015 08:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: neleai at seznam dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66989-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02065.txt.bz2
Content-length: 6066

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf989

            Bug ID: 66989
           Summary: poor performance of builtin_isfinite on x64
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: neleai at seznam dot cz
  Target Milestone: ---

This is another part of considering floating classification builtin
performance. This starts to be more cpu dependent as benchmark show large
improvement for core2 but almost none for haswell.

#define EXTRACT_WORDS64(i, d)                                                 \
  do {                                                                        \
    int64_t i_;                                                               \
    asm ("movq %1, %0" : "=rm" (i_) : "x" ((double) (d)));                   \
    (i) = i_;                                                                 \
  } while (0)


int I2
isfinite2 (double dx)
{
  unsigned long x;
  EXTRACT_WORDS64(dx, x);
  if (2 * x < 0xffe0000000000000)
    return 1;
  else
    return 0;
}


core2:
don't inline
conditional add
branched

real    0m1.334s
user    0m1.334s
sys     0m0.000s
builtin

real    0m1.577s
user    0m1.576s
sys     0m0.000s
branch
branched

real    0m1.453s
user    0m1.452s
sys     0m0.000s
builtin

real    0m1.335s
user    0m1.334s
sys     0m0.000s
sum
branched

real    0m1.336s
user    0m1.335s
sys     0m0.000s
builtin

real    0m1.575s
user    0m1.573s
sys     0m0.000s
inline outer call
conditional add
branched

real    0m1.046s
user    0m1.046s
sys     0m0.000s
builtin

real    0m0.972s
user    0m0.971s
sys     0m0.000s
branch
branched

real    0m0.849s
user    0m0.845s
sys     0m0.003s
builtin

real    0m0.971s
user    0m0.970s
sys     0m0.002s
sum
branched

real    0m1.097s
user    0m1.095s
sys     0m0.000s
builtin

real    0m1.104s
user    0m1.100s
sys     0m0.003s
inline inner call
conditional add
branched

real    0m0.981s
user    0m0.980s
sys     0m0.000s
builtin

real    0m0.971s
user    0m0.971s
sys     0m0.000s
branch
branched

real    0m0.849s
user    0m0.848s
sys     0m0.000s
builtin

real    0m0.970s
user    0m0.969s
sys     0m0.000s
sum
branched

real    0m1.094s
user    0m1.094s
sys     0m0.000s
builtin

real    0m1.101s
user    0m1.100s
sys     0m0.000s
tigth loop
conditional add
branched

real    0m0.365s
user    0m0.364s
sys     0m0.000s
builtin

real    0m0.433s
user    0m0.433s
sys     0m0.000s
branch
branched

real    0m0.126s
user    0m0.126s
sys     0m0.000s
builtin

real    0m0.368s
user    0m0.367s
sys     0m0.000s
sum
branched

real    0m0.367s
user    0m0.365s
sys     0m0.000s
builtin

real    0m0.632s
user    0m0.631s
sys     0m0.000s

fx10
don't inline
conditional add
branched

real    0m1.297s
user    0m1.295s
sys     0m0.004s
builtin

real    0m1.300s
user    0m1.299s
sys     0m0.004s
branch
branched

real    0m0.657s
user    0m0.658s
sys     0m0.000s
builtin

real    0m0.677s
user    0m0.677s
sys     0m0.000s
sum
branched

real    0m1.296s
user    0m1.295s
sys     0m0.004s
builtin

real    0m1.313s
user    0m1.315s
sys     0m0.000s
inline outer call
conditional add
branched

real    0m1.296s
user    0m1.298s
sys     0m0.000s
builtin

real    0m1.297s
user    0m1.298s
sys     0m0.000s
branch
branched

real    0m0.365s
user    0m0.366s
sys     0m0.000s
builtin

real    0m0.412s
user    0m0.409s
sys     0m0.004s
sum
branched

real    0m1.302s
user    0m1.304s
sys     0m0.000s
builtin

real    0m1.305s
user    0m1.307s
sys     0m0.000s
inline inner call
conditional add
branched

real    0m1.299s
user    0m1.300s
sys     0m0.000s
builtin

real    0m1.296s
user    0m1.297s
sys     0m0.000s
branch
branched

real    0m0.509s
user    0m0.509s
sys     0m0.000s
builtin

real    0m0.539s
user    0m0.539s
sys     0m0.001s
sum
branched

real    0m1.301s
user    0m1.303s
sys     0m0.000s
builtin

real    0m1.307s
user    0m1.309s
sys     0m0.000s
tigth loop
conditional add
branched

real    0m0.369s
user    0m0.369s
sys     0m0.000s
builtin

real    0m0.362s
user    0m0.362s
sys     0m0.000s
branch
branched

real    0m0.152s
user    0m0.152s
sys     0m0.000s
builtin

real    0m0.260s
user    0m0.257s
sys     0m0.004s
sum
branched

real    0m0.362s
user    0m0.362s
sys     0m0.001s
builtin

real    0m0.399s
user    0m0.399s
sys     0m0.001s

haswelldon't inline
conditional add
branched

real    0m0.697s
user    0m0.698s
sys     0m0.000s
builtin

real    0m0.802s
user    0m0.803s
sys     0m0.000s
branch
branched

real    0m0.697s
user    0m0.698s
sys     0m0.000s
builtin

real    0m0.796s
user    0m0.793s
sys     0m0.003s
sum
branched

real    0m0.717s
user    0m0.717s
sys     0m0.000s
builtin

real    0m0.802s
user    0m0.802s
sys     0m0.000s
inline outer call
conditional add
branched

real    0m0.695s
user    0m0.695s
sys     0m0.000s
builtin

real    0m0.695s
user    0m0.695s
sys     0m0.000s
branch
branched

real    0m0.390s
user    0m0.387s
sys     0m0.003s
builtin

real    0m0.413s
user    0m0.412s
sys     0m0.000s
sum
branched

real    0m0.695s
user    0m0.702s
sys     0m0.000s
builtin

real    0m0.696s
user    0m0.697s
sys     0m0.000s
inline inner call
conditional add
branched

real    0m0.695s
user    0m0.696s
sys     0m0.000s
builtin

real    0m0.696s
user    0m0.692s
sys     0m0.003s
branch
branched

real    0m0.388s
user    0m0.388s
sys     0m0.000s
builtin

real    0m0.388s
user    0m0.388s
sys     0m0.000s
sum
branched

real    0m0.695s
user    0m0.695s
sys     0m0.000s
builtin

real    0m0.695s
user    0m0.695s
sys     0m0.000s
tigth loop
conditional add
branched

real    0m0.233s
user    0m0.232s
sys     0m0.000s
builtin

real    0m0.232s
user    0m0.232s
sys     0m0.000s
branch
branched

real    0m0.080s
user    0m0.080s
sys     0m0.000s
builtin

real    0m0.161s
user    0m0.160s
sys     0m0.000s
sum
branched

real    0m0.232s
user    0m0.232s
sys     0m0.000s
builtin

real    0m0.310s
user    0m0.310s
sys     0m0.000s

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2015-07-24
                 CC|                            |ubizjak at gmail dot com
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

--- Comment #30 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Ilya Enkovich from comment #28)
> Fixed

Let's fix this in the correct way, using ADJUST_INSN_LENGTH.

We really don't want duplicated patterns.
>From gcc-bugs-return-493177-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 08:36:20 2015
Return-Path: <gcc-bugs-return-493177-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28768 invoked by alias); 24 Jul 2015 08:36:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28500 invoked by uid 48); 24 Jul 2015 08:36:15 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug jit/63854] Fix memory leaks seen in JIT
Date: Fri, 24 Jul 2015 08:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: dep_changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: jit
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63854-4-EaD1W5g6r5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63854-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63854-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02067.txt.bz2
Content-length: 498

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc854
Bug 63854 depends on bug 64003, which changed state.

Bug 64003 Summary: valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?idd003

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #32 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jul 24 16:25:56 2015
New Revision: 226173

URL: https://gcc.gnu.org/viewcvs?rev=226173&root=gcc&view=rev
Log:
        PR target/64003
        * config/i386/i386.h (ADJUST_INSN_LENGTH): New define.
        * config/i386/i386.md (maybe_prefix_bnd): New attribute.
        (*jcc_1, *jcc_2, jump, simple_return_internal)
        (simple_return_pop_internal): Set attribute maybe_prefix_bnd.
        Set length_nobnd attribute instead of length attribute.
        (indirect_jump, *tablejump_1): Set attribute maybe_prefix_bnd.
        (length_nobnd): Remove attribute.
        (length): Remove length_nobnd processing.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/i386/i386.md

[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #33 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed in mainline SVN by introducing ADJUST_INSN_LENGTH.
>From gcc-bugs-return-493256-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 16:31:36 2015
Return-Path: <gcc-bugs-return-493256-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 70223 invoked by alias); 24 Jul 2015 16:31:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 69959 invoked by uid 48); 24 Jul 2015 16:31:31 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug jit/63854] Fix memory leaks seen in JIT
Date: Fri, 24 Jul 2015 16:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: dep_changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: jit
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63854-4-H7XQEs2Jya@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63854-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63854-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02146.txt.bz2
Content-length: 500

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc854
Bug 63854 depends on bug 64003, which changed state.

Bug 64003 Summary: valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?idd003

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED