arm target
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: i686-linux-gnu, x
--- Comment #5 from jingyu at google dot com 2009-04-14 22:35 ---
I found that gcc.c-torture/compile/pr11832.c and pr33009.c were deleted from
gcc trunk on 2009-03-31.
2009-03-31 Ramana Radhakrishnan
* gcc.c-torture/compile/pr33009.c: Delete.
* gcc.c-torture/compile
--- Comment #1 from jingyu at google dot com 2009-04-15 03:44 ---
Created an attachment (id=17640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17640&action=view)
assembly of gcc.dg/initpri1.c
This assembly was generated by this command:
$arm-eabi-gcc gcc.dg/initpri1.
--- Comment #2 from jingyu at google dot com 2009-04-15 03:45 ---
$arm-eabi-gcc -v Using built-in specs.
Target: arm-eabi
Configured with:
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/configure
--prefix=/usr/local/google/tmp/gcc4.4_dejagnu/install --target=arm-eabi
--build
--- Comment #1 from jingyu at google dot com 2009-04-15 20:41 ---
I have observed the same error on
host: x86_64-linux-gnu and i686-linux-gnu
target: arm-unknown-eabi
Executing on host: /usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/xgcc
-B/usr/local/google/tmp/gcc4.4_dejagnu/obj
--- Comment #3 from jingyu at google dot com 2009-04-15 23:35 ---
GCC puts destructors in .fini_array section in increasing order, and expects
linker executes entries in .fini_array in reverse order (according to ELF
specification). However, newlib executes entries in .fini_array in
duct: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: x86_64-linux-gnu, i686-linux-gnu
0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: ar
orture/pr39678.c fails if char type is unsigned
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at googl
--- Comment #2 from jingyu at google dot com 2009-04-21 00:54 ---
Subject: Re: gcc.dg/torture/pr39678.c fails if char type
is unsigned
Thanks H.J. for your quick response!
Do you want me to prepare a patch?
I don't have write permission though.
Thanks,
Jing
On Mon, A
--- Comment #4 from jingyu at google dot com 2009-04-21 01:29 ---
Created an attachment (id=17661)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17661&action=view)
Patch to fix the issue
2009-04-20 Jing Yu
PR testsuite/39830
* gcc.dg/torture/pr39678.c:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999
--- Comment #9 from Jing Yu 2011-02-22 01:53:11 UTC
---
I am on leave from 02/01/2011 to 05/30/2011. I may not reply your
email during this period.
If you have Android toolchain questions/issues/requests, please
contact Doug (dougk...@google.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
--- Comment #7 from Jing Yu 2011-03-01 18:08:57 UTC
---
I am on leave from 02/01/2011 to 05/30/2011. I may not reply your
email during this period.
If you have Android toolchain questions/issues/requests, please
contact Doug (dougk...@google.com
--- Comment #9 from jingyu at google dot com 2010-02-10 12:18 ---
I still get the 10-instruction code with trunk GCC I checked out today.
$arm-eabi-gcc -mthumb -mthumb-interwork -fpic -Os code.c -S
test:
push{lr}
sub sp, sp, #20
ldr r2, [r0
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: X86_64-linux-gnu
GCC host triplet: X86_64-linux-gnu
GCC target triplet: arm-unknown-eabi
htt
--- Comment #1 from jingyu at google dot com 2010-01-11 19:59 ---
I forgot to paste the wrong assembly code.
arm-eabi-g++ -Os -mthumb double.cpp --save-temps -c -o double.o
The assembly for the following part
_D_rep _D_inf = {{ 0, 0, 0, 0x7ff0 }};
if (*entry == _D_inf.val
--- Comment #3 from jingyu at google dot com 2010-01-12 02:45 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Mon, Jan 11, 2010 at 2:00 PM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01
--- Comment #5 from jingyu at google dot com 2010-01-12 22:21 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Tue, Jan 12, 2010 at 12:57 AM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #4 from ebotcazou at gcc dot gnu dot org 2010
--- Comment #6 from jingyu at google dot com 2010-01-13 01:18 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
> We should try and set changed_i3_dest to 1 in this particular case as well.
Here is the patch which only changes changed_i3_dest for two
particu
c
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: X86_64-linux-gnu
GCC host triplet: X86_64-linux-gnu
GCC target triplet: arm-unknown-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
--- Comment #8 from jingyu at google dot com 2010-01-13 20:03 ---
Yes. This is a regression from 4.2.1. I have not tried 4.3.x. But at least,
gcc-4.2.1 works correctly.
The following assembly is compiled out of gcc-4.2.1 with -mthumb -Os.
ldr r3, .L14+8
ldr
--- Comment #9 from jingyu at google dot com 2010-01-13 22:56 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
On Wed, Jan 13, 2010 at 2:03 AM, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-01
--- Comment #11 from jingyu at google dot com 2010-01-14 00:13 ---
Subject: Re: problematic REG_EQUAL note added to
SUBREG
> Yes, jumping to validate_replacement means that the other combinations are not
> tried. If the new pattern is not valid, the code will try to m
--- Comment #16 from jingyu at google dot com 2010-01-15 21:14 ---
Subject: Re: [4.4/4.5 regression] problematic
REG_EQUAL note added to SUBREG
Sorry. The following change would fix it on X86.
Index: testsuite/gcc.c-torture/execute/pr42691.c
--- Comment #18 from jingyu at google dot com 2010-01-15 21:46 ---
Subject: Re: [4.4/4.5 regression] problematic
REG_EQUAL note added to SUBREG
On Fri, Jan 15, 2010 at 1:42 PM, mikpe at it dot uu dot se
wrote:
>
>
> --- Comment #17 from mikpe at it dot uu dot se
--- Comment #23 from jingyu at google dot com 2010-01-15 22:25 ---
Subject: Re: [4.4/4.5 regression] problematic
REG_EQUAL note added to SUBREG
On Fri, Jan 15, 2010 at 1:59 PM, jakub at gcc dot gnu dot org
wrote:
>
>
> --- Comment #21 from jakub at gcc dot gn
--- Comment #26 from jingyu at google dot com 2010-01-20 23:48 ---
This bug is fixed in both trunk(4.5) and 4.4.
I will send a message to gcc-patches when I patch the test case.
--
jingyu at google dot com changed:
What|Removed |Added
--- Comment #1 from jingyu at google dot com 2010-01-29 23:33 ---
The problem also exists on non-FDO use. So I changed the title of the bug.
Since unswitch-loop is set at -O3, I give -O3 to the command line. Parameter
"max-unswitch-level" means we only do unswitch-loop at
--- Comment #3 from jingyu at google dot com 2010-01-29 23:59 ---
You must set "--param max-unswitch-level=0" to trigger the bug in non-FDO use.
I just tried gcc-4.2.4 on X86 platform. The problem exists.
$ gcc loop.cpp -O3 --param max-unswitch-level=0 -m32 -S
te
--- Comment #5 from jingyu at google dot com 2010-01-30 00:21 ---
>So the problem is really if (optimize_loop_for_size_p (loop)) . I think you
>need to figure out why that is returning true.
That's because after unswitch-loop, one copy of the loop becomes cold. Let's
--- Comment #11 from jingyu at google dot com 2010-01-30 23:33 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
> I agree that some of the checks in tree_unswitch_single_loop are badly placed
> -- it does not make sense to chec
--- Comment #12 from jingyu at google dot com 2010-02-02 23:57 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
Zdenek,
I did dejagnu tests on your patch. It gave no regression on
"--target_board=arm-sim/thumb".
Do you think this
gs in local constant pool
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
--- Comment #12 from Jing Yu 2011-04-16 10:36:27 UTC
---
I am on leave from 02/01/2011 to 05/30/2011. I may not reply your
email during this period.
If you have Android toolchain questions/issues/requests, please
contact Doug (dougk...@google.co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
--- Comment #14 from Jing Yu 2011-05-13 19:34:35 UTC
---
I am on leave from 02/01/2011 to 05/30/2011. I may not reply your
email during this period.
If you have Android toolchain questions/issues/requests, please
contact Doug (dougk...@google.co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
--- Comment #17 from Jing Yu 2011-05-18 11:06:35 UTC
---
I am on leave from 02/01/2011 to 05/30/2011. I may not reply your
email during this period.
If you have Android toolchain questions/issues/requests, please
contact Doug (dougk...@google.co
dTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: arm-linux-androideabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45097
--- Comment #1 from jingyu at google dot com 2010-07-28 01:09 ---
Created an attachment (id=21328)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21328&action=view)
test case to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45097
--- Comment #1 from jingyu at google dot com 2010-05-10 23:52 ---
I see the same error when compiling thumb2 libgcc.
Host=Build=x86_64-unknown-linux-gnu, Target=arm-unknown-eabi
The error message points to following lines in gcc/config/arm/lib1funcs.asm.
cmp \dividend, #0
--- Comment #3 from jingyu at google dot com 2010-05-11 17:56 ---
I configure gcc with --with-arch=armv5te. The default multilib will be compiled
in ARM mode.
The error happens when I build the armv7-a/thumb multilib.
I checked the config.log for armv7-a/thumb/libgcc, libgcc was indeed
--- Comment #15 from jingyu at google dot com 2010-05-13 18:09 ---
Patch was committed to trunk (4.6) r158138.
Resolved.
--
jingyu at google dot com changed:
What|Removed |Added
--- Comment #4 from jingyu at google dot com 2010-06-03 00:54 ---
I check out the trunk gcc (4.6.0 20100602). Configure gcc with the following:
/usr/local/google/home/projects/android-toolchain/build/../gcc/gcc-trunk/configure
--prefix=/usr/local --target=arm-linux-androideabi
--host
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: arm-linux-androideabi,arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44787
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: arm-linux-androideabi,arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44788
44 matches
Mail list logo
