Launchpad has imported 9 comments from the remote bug at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2011-05-17T19:11:01+00:00 Rmansfield-t wrote:

Created attachment 24268
preprocessed source

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi 
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi 
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
 --disable-multilib 
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
 --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 
--enable-long-long --enable-target-optspace 
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared 
--disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.7.0 20110517 (experimental) [trunk revision 173832] (GCC) 
$ ./xgcc -B.  -O1 ~/ice.i
/home/ryan/ice.i: In function 'bar':
/home/ryan/ice.i:33:1: internal compiler error: in get_arm_condition_code, at 
config/arm/arm.c:17180
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/0

------------------------------------------------------------------------
On 2011-05-20T09:50:09+00:00 Ibolton wrote:

I haven't been able to reproduce this.  Please can you include the args
that are being sent to cc1.

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/1

------------------------------------------------------------------------
On 2011-05-20T13:04:58+00:00 Rmansfield-t wrote:

With rev173940

$ ./cc1 -fpreprocessed ice.i -quiet -O1 
ice.i: In function 'bar':
ice.i:33:1: internal compiler error: in get_arm_condition_code, at 
config/arm/arm.c:17021
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/2

------------------------------------------------------------------------
On 2011-05-20T13:46:00+00:00 Ibolton wrote:

I was hoping the compiler command would tell me what -mcpu it was
defaulting to.

Anyway, I have managed to reproduce it now, by compiling as follows:

  cc1 -fpreprocessed 49030.i -quiet -O1 -o 49030.s -mcpu=arm7tdmi -marm

Note that it all works with -mthumb and/or -mcpu=cortex-a9.

I have tried this with my old toolchain and it is broken as far back as
r164700.

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/3

------------------------------------------------------------------------
On 2011-05-20T14:41:41+00:00 Rmansfield-t wrote:

(In reply to comment #3)
> I was hoping the compiler command would tell me what -mcpu it was defaulting
> to.

I'm using an arm-unknown-linux-gnueabi configuration which defaults an
arm10tdmi.

linux-eabi.h:#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/4

------------------------------------------------------------------------
On 2011-06-09T01:34:47+00:00 Michael Hope wrote:

The same assert is seen in
https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/689887 in Thumb-2
mode on trunk r174795.

Chung-Lin posted a patch at http://gcc.gnu.org/ml/gcc-
patches/2011-03/msg00790.html but there are bootstrap issues.

Adding -fno-if-conversion works around the problem.

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/5

------------------------------------------------------------------------
On 2011-06-10T19:02:07+00:00 Mikpe wrote:

It's caused by r161764:

Author: sandra
Date: Sat Jul  3 01:00:37 2010
New Revision: 161764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161764
Log:
2010-07-02  Daniel Jacobowitz  <d...@codesourcery.com>
            Julian Brown  <jul...@codesourcery.com>
            Sandra Loosemore <san...@codesourcery.com>

        gcc/
        * config/arm/arm.c (arm_canonicalize_comparison): Canonicalize DImode
        comparisons.  Adjust to take both operands.
        (arm_select_cc_mode): Handle DImode comparisons.
        (arm_gen_compare_reg): Generate a scratch register for DImode
        comparisons which require one.  Use xor for Thumb equality checks.
        (arm_const_double_by_immediates): New.
        (arm_print_operand): Allow 'Q' and 'R' for constants.
        (get_arm_condition_code): Handle new CC_CZmode and CC_NCVmode.
        ...

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/6

------------------------------------------------------------------------
On 2011-06-12T15:23:40+00:00 Mikpe wrote:

Created attachment 24503
more reduced test case, ICEs at -O1 for armv5te and armv6

Using this slightly more reduced test case I've found that gcc
transforms

(set (reg:CC_NCV ...) (compare:CC_NCV (reg:DI ...) (const_int 1 ...)))
(if_then_else (ge (reg:CC_NCV ...) ...) ...)

to

(set (reg:CC_NCV ...) (compare:CC_NCV (reg:DI ...) (const_int 0 ...)))
(if_then_else (gt (reg:CC_NCV ...) ...)

because ifcvt calls noce_get_condition which calls
canonicalize_condition, and the latter has a general rule to transform
(GE x const) to (GT x const-1).

So the careful code in e.g. cbranchdi4 to not generate unimplemented
comparisons is neutralized by generic code.

Do DImode comparisons really have to be asymmetric? I.e., could CC_NCV
be removed?  I see that LT is apparently supported so why can't GT be
too?

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/7

------------------------------------------------------------------------
On 2011-06-12T21:33:30+00:00 Mikpe wrote:

I have a preliminary patch which creates a clone of *arm_cmpdi_insn that
does a reverse comparison, via a new CC mode for must-be-reversed
comparisons, and corresponding updates to arm_select_cc_mode and
get_arm_condition_code.  It's the same transformation from eg (GT x y)
to (LT y x) that cstoredi4 does, only later so it can handle problematic
comparisons introduced by the middle-end.

This fixes the ICEs on the two test cases in this PR.  I'll do a full
bootstrap and regtest as soon as my test machine is done with its
current bootstrap and regtest cycle.

I'll send the FSF Yet Another Ping about my employer's copyright
disclaimer first thing tomorrow.  They've had the papers since January
or February...

Reply at: https://bugs.launchpad.net/gcc/+bug/809761/comments/8


** Changed in: gcc
       Status: Unknown => Confirmed

** Changed in: gcc
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/809761

Title:
  oss4 version 4.2-build2004-1ubuntu1 failed to build on armel

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/809761/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to