[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jiwang at gcc dot gnu.org,
                   |                            |zhenqiang.chen at arm dot com

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems this is because of the gen_ccmp_{first,next} stuff that is being
constantly added and reverted again.
How can it work reliably?  I mean, if expansion of something returns you
something in completely different mode, how do you ensure that the side that
consumes it will know it has to handle it specially?  Some new RTX code
signalizing that would at least make it more clear, but you'd need to ensure
that if you don't handle it specially, that it will be automatically turned
back to the expansion that didn't do anything special.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson <rth at gcc dot gnu.org> ---
Hmm.  I'm not even getting that far with r219852

gcc/expmed.h: In function ‘void init_expmed()’:
gcc/expmed.h:613:77: error: array subscript is above array bounds
[-Werror=array-bounds]
   return &this_target_expmed->x_mul_highpart_cost[speed][mode - MIN_MODE_INT];
                                                                             ^
gcc/expmed.h:263:33: error: array subscript is below array bounds
[-Werror=array-bounds]
   return &costs->cost[speed][idx];
                                 ^
gcc/expmed.h:263:33: error: array subscript is below array bounds
[-Werror=array-bounds]
   return &costs->cost[speed][idx];
                                 ^
gcc/expmed.h:263:33: error: array subscript is above array bounds
[-Werror=array-bounds]
   return &costs->cost[speed][idx];
                                 ^
gcc/expmed.h:263:33: error: array subscript is above array bounds
[-Werror=array-bounds]
   return &costs->cost[speed][idx];
>From gcc-bugs-return-473919-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 19 22:10:19 2015
Return-Path: <gcc-bugs-return-473919-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25847 invoked by alias); 19 Jan 2015 22:10: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 25804 invoked by uid 48); 19 Jan 2015 22:10:15 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/64668] [5 Regression] internal compiler error: in compare_ssa_name, at ipa-icf-gimple.c:120
Date: Mon, 19 Jan 2015 22:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64668-4-B1x3z49HcY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64668-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64668-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-01/txt/msg01913.txt.bz2
Content-length: 433

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed.
>From gcc-bugs-return-473920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 19 22:14:20 2015
Return-Path: <gcc-bugs-return-473920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29786 invoked by alias); 19 Jan 2015 22:14: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 29061 invoked by uid 48); 19 Jan 2015 22:14:11 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677
Date: Mon, 19 Jan 2015 22:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak 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:
Message-ID: <bug-63741-4-Xa1kmG4UOw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63741-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63741-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-01/txt/msg01914.txt.bz2
Content-length: 1922

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Joel Sherrill from comment #3)
> Added the dwarf maintainers hoping to get an answer. From an RTEMS
> perspective, the lm32 is not usable. Both 4.9 and the head are broken.
> Hoping you two have an idea. Happy to help since this is a cross target.

This is a target problem.

Please see stack_adjust function, where emit_move_insn is used to move an
immediate to r10. However, emit_move_insn with (const_int -32812) generates two
insn sequence:

(insn 952 123 953 2 (set (reg:SI 10 r10)
        (const_int -65536 [0xffffffffffff0000]))
../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1
     (nil))
(insn/f 953 952 954 2 (set (reg:SI 10 r10)
        (ior:SI (reg:SI 10 r10)
            (const_int 32724 [0x7fd4])))
../../../../../../rtems/c/src/../../cpukit/libdl/fastlz.c:167 -1
     (expr_list:REG_EQUAL (const_int -32812 [0xffffffffffff7fd4])
        (nil)))

However:

      /* r10 is caller saved so it can be used as a temp reg.  */
      rtx r10;
      r10 = gen_rtx_REG (word_mode, 10);
      insn = emit_move_insn (r10, GEN_INT (amount));
      if (amount < 0)
    RTX_FRAME_RELATED_P (insn) = 1;

emit_move_insn returns only the *last* insn of the sequence (insn 953 in the
above dump). (insn 952) doesn't get RTX_FRAME_RELATED_P flag set - please note
lack of /f modifier - and consequently dwarf2out_frame_debug_expr trips in Rule
7 due to unknown cfa_temp.reg (which would be otherwise initialized in insn
952, following Rule 6).

So, considering that emit_move_insn can generate a sequence of insns, but only
the last insn is returned as a return value of a function,

      insn = emit_move_insn (r10, GEN_INT (amount));
      RTX_FRAME_RELATED_P (insn) = 1;

is not the correct way to set /f flags to all insn of the generated sequence.
>From gcc-bugs-return-473921-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 19 22:27:43 2015
Return-Path: <gcc-bugs-return-473921-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1773 invoked by alias); 19 Jan 2015 22:27:42 -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 1676 invoked by uid 48); 19 Jan 2015 22:27:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
Date: Mon, 19 Jan 2015 22:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jiwang at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64669-4-U5JtOHmnsS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64669-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64669-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-01/txt/msg01915.txt.bz2
Content-length: 149

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That was the --disable-werror.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang <jiwang at gcc dot gnu.org> ---
haven't enable go front end,

../gcc/configure --enable-languages=c,c++,fortran --disable-libsanitizer
--enable-checking=release --disable-werror 


with make -j16 profiledbootstrap, I got several 

../../../gcc/libgcc/libgcc2.c:858:1: internal compiler error: Segmentation
fault

and then the following final errors during stage2, will do further
investigation tomorrow.

tall-after-patch/aarch64-unknown-linux-gnu/bin/
-B/home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/lib/
-isystem
/home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/include
-isystem
/home/jiowan01/COMMUNITY/install-after-patch/aarch64-unknown-linux-gnu/sys-include
 -g -O2 -O2  -g -O2 -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS  -o _clrsbdi2.o -MT _clrsbdi2.o
-MD -MP -MF _clrsbdi2.dep -DL_clrsbdi2 -c ../../../gcc/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
0x645377 crash_signal
        ../../gcc/gcc/toplev.c:372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [_popcountdi2.o] Error 1
make[3]: *** Waiting for unfinished jobs....
0x645377 crash_signal
        ../../gcc/gcc/toplev.c:372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [_popcountsi2.o] Error 1
make[3]: Leaving directory
`/home/jiowan01/COMMUNITY/build-after-patch/aarch64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stagefeedback-target-libgcc] Error 2
make[2]: Leaving directory `/home/jiowan01/COMMUNITY/build-after-patch'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/home/jiowan01/COMMUNITY/build-after-patch'
make: *** [profiledbootstrap] Error 2
~

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jiwang at gcc dot gnu.org]

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

--- Comment #5 from Jiong Wang <jiwang at gcc dot gnu.org> ---
Created attachment 34502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34502&action=edit
kk.ii

attachment is the reduced testcase.

  ./cc1 -g -O2 -fprofile-use  -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -nostdinc++ kk.ii

I found there are two issues,

the first is in kk.ii.183t.optimized

  <bb 15>:
  _10 = _48 == 39;
  _11 = _48 == 10;
  _12 = _10 | _11;
  if (_12 <= 0)
    goto <bb 16>;
  else
    goto <bb 17>;


although there is no correctness issue with the "if (_27 <= 0)", but I think
for boolean type "<= 0" is exactly "== 0", so the "<" is uncessary.

and in this testcase, "_27" happen to be a CCMP candidate, while CCMP code in
aarch64 backend is with the assumption that only EQ/NE comparison will happen
on it. in the bottom of aarch64_get_condition_code_1, if comp_cond is not
NE/EQ, then -1 always returned. So, I think we should treate LE/LEU as EQ?

the second is in do_compare_and_jump in dojump.c, we should use GET_MODE (op0)
to get the mode passed to do_compare_rtx_and_jump instead of use TYPE_MODE
(type) ? 

any thoughts?

after hack above two issues, pass the testcase. (If the tree level never
generate <= for boolean, then only need to modify dojump.c) I am doing more
tests and understand the issue in a systematic way...

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jiwang at gcc dot gnu.org]

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

--- Comment #6 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to Jiong Wang from comment #5)
> Created attachment 34502 [details]
> kk.ii
> 

this testcase reproduce exactly what Jakub reported.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to Jiong Wang from comment #5)
> although there is no correctness issue with the "if (_27 <= 0)", but I think
> for boolean type "<= 0" is exactly "== 0", so the "<" is uncessary.

True, but at some point in the optimization of this function
it wasn't "<= 0" but "<= variable", which made a lot more sense.

> and in this testcase, "_27" happen to be a CCMP candidate, while CCMP code
> in aarch64 backend is with the assumption that only EQ/NE comparison will
> happen on it. in the bottom of aarch64_get_condition_code_1, if comp_cond is
> not NE/EQ, then -1 always returned. So, I think we should treate LE/LEU as
> EQ?

No, see above.  If we hadn't propagated the 0, we really would
be asking X <= Y, which is nice shorthand for Y | !X.

It would be good if when we folded variable to 0, that we also 
simplify the condition, but that's really unrelated.

> the second is in do_compare_and_jump in dojump.c, we should use GET_MODE
> (op0) to get the mode passed to do_compare_rtx_and_jump instead of use
> TYPE_MODE (type) ? 

No, there's a large layering violation going here between expand and
do_compare_rtx_and_jump.  We ought not return a value of an incorrect
mode from expand_normal in the first place.

If we need to do something at the do_compare_and_jump level to emit
branches using the CCmode... so be it.  But don't split this logic
across multiple functions at multiple levels.

I suspect that we don't need to special case this at all.  I suspect
that we can emit a setcc, and then a branch off of that, and then have
the setcc and branch merge during combine.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Henderson from comment #8)
> I think I was wrong to approve the ccmp patch with the used_in_cond_stmt_p
> logic in the first place, and that it should all be removed.

I tend to agree because it was a premature optimization.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|jiwang at gcc dot gnu.org          |rth at gcc dot gnu.org

--- Comment #11 from Richard Henderson <rth at gcc dot gnu.org> ---
Created attachment 34506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34506&action=edit
proposed patch

This is what I'm currently testing.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is no
typedef __SIZE_TYPE__ size_t;
in the testcase
(or sed -i -e s/size_t/__SIZE_TYPE__/g pr64669.C ).

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[jiwang at gcc dot gnu.org]

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

--- Comment #13 from Jiong Wang <jiwang at gcc dot gnu.org> ---
(In reply to Richard Henderson from comment #11)
> Created attachment 34506 [details]
> proposed patch
> 
> This is what I'm currently testing.

passed profiledbootstrap on top of 219849.
spec2kint/spec2k6int built OK.

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[rth at gcc dot gnu.org]

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

--- Comment #14 from Richard Henderson <rth at gcc dot gnu.org> ---
Author: rth
Date: Wed Jan 21 15:47:49 2015
New Revision: 219951

URL: https://gcc.gnu.org/viewcvs?rev=219951&root=gcc&view=rev
Log:
PR target/64669

 * ccmp.c (used_in_cond_stmt_p): Remove.
 (expand_ccmp_expr): Don't use it.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr64669.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ccmp.c

[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

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

--- Comment #15 from Richard Henderson <rth at gcc dot gnu.org> ---
Fixed.