[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51432 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope 2012-09-10 03:59:49 UTC --- The fault also happens natively: cbuild@ursa2:~$ g++ -flto -std=c++0x -g -xc++ /dev/null -include functional In file included from /usr/include/c++/4.6/functional:59:0, from :0: /usr/include/c++/4.6/bits/functional_hash.h: In instantiation of 'std::size_t std::hash<_Tp>::operator()(_Tp) const [with _Tp = long double, std::size_t = unsigned int]': /usr/include/c++/4.6/functional:2267:1: instantiated from here /usr/include/c++/4.6/bits/functional_hash.h:184:5: internal compiler error: in write_builtin_type, at cp/mangle.c:2168 cbuild@ursa2:~$ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 This isn't FSF 4.6.3 but is pretty close.
[Bug target/55218] New: armv6 doesn't use unaligned access for packed structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218 Bug #: 55218 Summary: armv6 doesn't use unaligned access for packed structures Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.h...@linaro.org Created attachment 28622 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28622 Test case The GCC ARM target uses the armv6 and above unaligned loads for packed structures and block copies. This works correctly for -march=armv7-a and -march=armv6t2, but generates the old byte-by-byte field access for -march=armv6. The block copy is fine. readelf -A shows that the compiler intended to use unaligned access. I'm suspicious that GCC is using the extv pattern to extract the field, and this pattern is only available on cores with Thumb-2 support.
[Bug target/55218] armv6 doesn't use unaligned access for packed structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218 Michael Hope changed: What|Removed |Added Target||arm --- Comment #1 from Michael Hope 2012-11-05 22:04:03 UTC --- See also: http://lists.linaro.org/pipermail/linaro-toolchain/2012-November/002921.html
[Bug target/50193] New: ARM: ICE on a | (b << negative-constant)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50193
Bug #: 50193
Summary: ARM: ICE on a | (b << negative-constant)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org
trunk r178025, 4.6.1, and 4.5.3 all ICE with unsatisfied constraints on the
following code:
int foo(int a, int b)
{
return a | (b << -3);
}
shift.c: In function 'foo':
shift.c:3:5: warning: left shift count is negative [enabled by default]
shift.c:4:1: error: insn does not satisfy its constraints:
(insn 14 9 17 2 (set (reg/i:SI 0 r0)
(ior:SI (ashift:SI (reg:SI 1 r1 [ b ])
(const_int -3 [0xfffd]))
(reg:SI 0 r0 [ a ]))) shift.c:4 259 {*arith_shiftsi}
(expr_list:REG_DEAD (reg:SI 1 r1 [ b ])
(nil)))
shift.c:4:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2030
This happens with -mcpu=cortex-a9 -mthumb. With -marm, GCC recognises that the
shift is unusual, loads it into a register, then uses this in the
register-shifted-register form of ORR. This form isn't available in Thumb-2.
The problem was originally seen in libtheora:lib/mathops.c when built with -O3
-funroll-loops when a shift by negative 8 is generated.
[Bug target/50193] ARM: ICE on a | (b << negative-constant)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50193
--- Comment #1 from Michael Hope 2011-08-28
21:40:01 UTC ---
Also occurs when building LLVM trunk. See:
http://builds.linaro.org/toolchain/llvm-3.0~svn138625/logs/armv7l-natty-cbuild172-ursa1-cortexa9r1/llvm-build.txt
/scratch/cbuild/slave/slaves/ursa1/llvm-3.0~svn138625/llvm/llvm-3.0~/tools/clang/unittests/AST/APValueTest.cpp:
In member function 'virtual void
{anonymous}::APValue_Diagnostics_Test::TestBody()':
/scratch/cbuild/slave/slaves/ursa1/llvm-3.0~svn138625/llvm/llvm-3.0~/tools/clang/unittests/AST/APValueTest.cpp:77:1:
error: insn does not satisfy its constraints:
(insn 1267 1266 1269 72 (set (subreg:SI (reg:DI 1327) 0)
(ior:SI (ashift:SI (reg:SI 1330)
(const_int -16 [0xfff0]))
(subreg:SI (reg:DI 1327) 0)))
/scratch/cbuild/slave/slaves/ursa1/llvm-3.0~svn138625/llvm/llvm-3.0~/include/llvm/ADT/APInt.h:140
257 {*arith_shiftsi}
(nil))
/scratch/cbuild/slave/slaves/ursa1/llvm-3.0~svn138625/llvm/llvm-3.0~/tools/clang/unittests/AST/APValueTest.cpp:77:1:
internal compiler error: in extract_constrain_insn_cached, at recog.c:2028
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Michael Hope 2011-09-04 23:55:51 UTC --- Seen also when building perl with -marm: https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/838994 Exists in 4.6.1 and trunk r178025. Does not exist in 4.5.3.
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099
--- Comment #7 from Michael Hope 2011-09-05
00:05:23 UTC ---
arm_legitimate_index_p() seems to be wrong. Near the end it has:
/* For ARM v4 we may be doing a sign-extend operation during the
load. */
if (arm_arch4)
{
if (mode == HImode
|| mode == HFmode
|| (outer == SIGN_EXTEND && mode == QImode))
range = 256;
else
range = 4096;
}
else
range = (mode == HImode || mode == HFmode) ? 4095 : 4096;
The final 4096 range is incorrect for ARM mode sign extends. The arm_arch4
path looks good.
[Bug target/50022] [4.7 regression] "incorrect condition in IT block" when building mozilla code base for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50022 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Michael Hope 2011-09-07 02:21:02 UTC --- For reference, I ran this against the different builds I have lying about. The fault occurs in r177688, is gone in r178025, and does not exist in 4.5.3, 4.6.1, or gcc-linaro-4.6-2011.08. The 4.6 and earlier compilers generate a branch instead of the itt block.
[Bug other/49930] Need some adjustments for bionic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49930 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #2 from Michael Hope 2011-09-07 02:30:14 UTC --- Note that sincos() was introduced with Android 2.3. The initial version calls sin() then calls cos() so there's no immediate advantage.
[Bug target/50313] New: ARM: PIC code references a non-existant label
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313
Bug #: 50313
Summary: ARM: PIC code references a non-existant label
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org
Created attachment 25211
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25211
Preprocessed source
Building gmime with GCC 4.6.1 for ARM gives the following error:
michaelh@ursa1:~/linaro/bugs$ gcc -c -O2 -fPIC -save-temps gmime2.i
gmime2.s: Assembler messages:
gmime2.s:1007: Error: can't resolve `.rodata' {.rodata section} - `.LPIC18'
{*UND* section}
The assembler is correct - the code references a label which doesn't exist.
The suspicious code is around:
bl g_hash_table_new(PLT)
mov sl, r0
add r0, sp, #32
bl g_mime_decode_lwsp(PLT)
ldr r3, .L146+24
ldr r1, [sp, #4]
str r3, [sp, #16]
ldr r3, [sp, #32]
...
.L146:
...
.word .LANCHOR0-(.LPIC18+4)
The 'ldr r3, .L146+24' references the offset. The value is spilt to the stack
before the normal `add r3, pc` and doesn't seem to be used afterwards.
The work-around is to compile at -O1 or -O3. The fault also exists in
gcc-4.6.1. It does not exist in gcc-4.5.3 or trunk r178025.
This is in a Cortex-A9+NEON+Thumb-2 configuration.
[Bug target/50305] Inline asm reload failure when building Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50305 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #2 from Michael Hope 2011-09-11 21:47:59 UTC --- Note that the fault goes away with -mfpu=neon and returns with -mfpu=vfpv3. You might want to add an explicit fpu to the dg-options. For reference, I could reproduce the fault in r177688, r178025, r178624, and gcc-linaro-4.5-2011.08. It does not exist in 4.5.3, 4.6.1, or gcc-linaro-4.6-2011.08.
[Bug middle-end/50770] New: limits-fndefn.c times out on ARM; runs 22 x faster with -fno-var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50770 Bug #: 50770 Summary: limits-fndefn.c times out on ARM; runs 22 x faster with -fno-var-tracking Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.h...@linaro.org On a Cortex-A9 with recent trunk: cbuild@tcpanda01:~$ time ./gcc-4.7~svn179959-armv7l-natty-cbuild199-tcpanda06-cortexa9r1/bin/gcc -O3 -g -c limits-fndefn.c real17m44.543s user7m7.477s sys10m33.117s Adding -fno-var-tracking gives: cbuild@tcpanda01:~$ time ./gcc-4.7~svn179959-armv7l-natty-cbuild199-tcpanda06-cortexa9r1/bin/gcc -O3 -g -fno-var-tracking -c limits-fndefn.c real0m31.788s user0m30.398s sys0m0.937s The times are similar on the 4.6 branch. This isn't causing problems, but suggests that the var tracking code could be improved.
[Bug middle-end/50770] limits-fndefn.c times out on ARM; runs 22 x faster with -fno-var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50770 Michael Hope changed: What|Removed |Added Target||arm --- Comment #3 from Michael Hope 2011-10-25 23:05:46 UTC --- Added target. The logs are available at: http://builds.linaro.org/toolchain/gcc-4.7~svn179959/logs/armv7l-natty-cbuild199-tcpanda06-cortexa9r1/ GCC was configured with: --prefix=/scratch/cbuild/slave/slaves/tcpanda06/gcc-4.7~svn179959/gcc/default/install --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon More information on the host is at: http://builds.linaro.org/toolchain/gcc-4.7~svn179959/logs/armv7l-natty-cbuild199-tcpanda06-cortexa9r1/host.txt The test case is gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c. I'm building r180460 at the moment and will see how that goes.
[Bug bootstrap/50878] New: ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 Bug #: 50878 Summary: ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.h...@linaro.org trunk r180460 fails during stage 2 with the following error: ../../../gcc-4.7~/gcc/config/arm/predicates.md: In function 'bool constraint_satisfied_p(rtx, constraint_num)': ../../../gcc-4.7~/gcc/config/arm/predicates.md:924:1: error: dominator of 12 should be 6, not 5 ../../../gcc-4.7~/gcc/config/arm/predicates.md:924:1: internal compiler error: in verify_dominators, at dominance.c:1041 This happens on ARM in an ARMv5 configuration and Cortex-A9 configuration. The full build log is here: http://builds.linaro.org/toolchain/gcc-4.7~svn180460/logs/armv7l-natty-cbuild205-tcpanda04-cortexa9r1/gcc-build.txt The Cortex-A9 configure flags are: --prefix=/scratch/cbuild/slave/slaves/tcpanda04/gcc-4.7~svn180460/gcc/default/install --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon More information about the host is here: http://builds.linaro.org/toolchain/gcc-4.7~svn180460/logs/armv7l-natty-cbuild205-tcpanda04-cortexa9r1/host.txt
[Bug bootstrap/50878] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 Michael Hope changed: What|Removed |Added Target||arm-linux-gnueabi --- Comment #1 from Michael Hope 2011-10-26 22:03:10 UTC --- According to gcc-testresults, r180308 bootstrapped OK.
[Bug bootstrap/51068] New: 4.7 Regression] ARM bootstrap failure due to ICE in rtl_verify_flow_info_1 at cfgrtl.c:2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51068
Bug #: 51068
Summary: 4.7 Regression] ARM bootstrap failure due to ICE in
rtl_verify_flow_info_1 at cfgrtl.c:2001
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org
trunk r181189 fails during stage1-target-libstdc++-v3 with the following error:
libtool: compile:
"/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/./gcc/xgcc"
-shared-libgcc
"-B/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/./gcc"
-nostdinc++
"-L/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/armv7l-unknown-linux-gnueabi/libstdc++-v3/src"
"-L/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/armv7l-unknown-linux-gnueabi/libstdc++-v3/src/.libs"
"-B/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/install/armv7l-unknown-linux-gnueabi/bin/"
"-B/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/install/armv7l-unknown-linux-gnueabi/lib/"
-isystem
"/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/install/armv7l-unknown-linux-gnueabi/include"
-isystem
"/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/install/armv7l-unknown-linux-gnueabi/sys-include"
"-I/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/gcc-4.7~/libstdc++-v3/../libgcc"
"-I/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/armv7l-unknown-linux-gnueabi/libstdc++-v3/include/armv7l-unknown-linux-gnueabi"
"-I/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/default/build/armv7l-unknown-linux-gnueabi/libstdc++-v3/include"
"-I/scratch/cbuild/slave/slaves/tcpanda01/gcc-4.7~svn181189/gcc/gcc-4.7~/libstdc++-v3/libsupc++"
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=new_opvnt.lo -g -O2 -D_GNU_SOURCE -c
"../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opvnt.cc" -fPIC -DPIC -o
new_opvnt.o
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc: In function 'void*
operator new [](std::size_t)':
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: missing
REG_EH_REGION note in the end of bb 2
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: call
edges for non-call insn in bb 2
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: in basic
block 2:
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:34:1: error: flow
control insn inside a basic block
(call_insn 7 3 63 2 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI ("_Znwj") [flags 0x41]
) [0 operator new S4 A32])
(const_int 0 [0])))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
]) ../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:33 248
{*call_value_symbol}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil))
(expr_list:REG_CFA_WINDOW_SAVE (use (reg:SI 0 r0))
(nil)))
../../../../../gcc-4.7~/libstdc++-v3/libsupc++/new_opv.cc:34:1: internal
compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:2001
This happens on ARM in an ARMv5 configuration and Cortex-A9 configuration.
The full build log is here:
http://builds.linaro.org/toolchain/gcc-4.7~svn181189/logs/armv7l-natty-cbuild205-tcpanda01-cortexa9r1/gcc-build.txt
The Cortex-A9 configure flags are:
--prefix=/scratch/cbuild/slave/slaves/tcpanda04/gcc-4.7~svn180460/gcc/default/install
--enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb
--with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon
More information about the host is here:
http://builds.linaro.org/toolchain/gcc-4.7~svn181189/logs/armv7l-natty-cbuild205-tcpanda01-cortexa9r1/host.txt
r181070 was OK so the problem has occurred since then.
[Bug target/50493] ICE in neon_disambiguate_copy, at config/arm/arm.c:20388
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50493 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope 2011-11-09 20:58:41 UTC --- I'm seeing similar at: https://bugs.launchpad.net/gcc/+bug/809446 and: https://bugs.launchpad.net/gcc-linaro/+bug/885393 but it's a bit random. Richard Earnshaw was looking at this recently. I'll ping him.
[Bug testsuite/53170] ERROR: g++.dg/cpp0x/variadic-value1.C: syntax error in target selector "target c++11" for " dg-do 2 run { target c++11 } "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53170 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #1 from Michael Hope 2012-05-18 01:38:31 UTC --- Added as part of r186122 to fix PR c++/52796.
[Bug testsuite/53170] ERROR: g++.dg/cpp0x/variadic-value1.C: syntax error in target selector "target c++11" for " dg-do 2 run { target c++11 } "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53170 --- Comment #2 from Michael Hope 2012-05-23 21:43:15 UTC --- Fixed in r187813. See the follow up in PR52796.
[Bug go/52218] [4.7/4.8 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Michael Hope 2012-03-06 20:25:18 UTC --- The getcontext() routines have now landed in glibc-ports and should be available in glibc 2.16: http://sourceware.org/ml/libc-ports/2012-02/msg00079.html I'll ask if they can be included in Ubuntu Precise.
[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #15 from Michael Hope 2011-12-22 16:07:46 UTC --- I'm away of holiday until the 4th of January. For anything urgent, please contact k...@linaro.org. -- Michael
[Bug fortran/47976] [4.5 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope 2011-03-15 02:07:16 UTC --- The failure also exists in 4.6.0 20110308 [trunk revision 170780]. See: https://lists.launchpad.net/linaro-toolchain-builds/msg00290.html for test results. Sorry that these aren't posted to gcc-testresults@gcc yet but I'm ironing out kinks. Running target unix FAIL: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/pr45636.f90 -O scan-tree-dump-times forwprop2 "memset" 0 WARNING: program timed out. FAIL: gfortran.dg/vect/fast-math-pr38968.f90 execution test FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect "vectorized 1 loops" WARNING: program timed out. FAIL: gfortran.fortran-torture/execute/entry_6.f90 compilation, -O2
[Bug fortran/47976] [4.5 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976 --- Comment #4 from Michael Hope 2011-03-16 21:18:59 UTC --- Not present in svn168270, svn169407, svn169832 Present in svn170086. This leaves the following commits: r170086 | gerald | 2011-02-13 08:22:17 +1300 (Sun, 13 Feb 2011) r170053 | bernds | 2011-02-12 05:01:19 +1300 (Sat, 12 Feb 2011) r170040 | danglin | 2011-02-11 15:06:55 +1300 (Fri, 11 Feb 2011) r170013 | ro | 2011-02-11 06:23:21 +1300 (Fri, 11 Feb 2011) r169972 | ro | 2011-02-10 03:40:15 +1300 (Thu, 10 Feb 2011) r169951 | ebotcazou | 2011-02-09 11:56:06 +1300 (Wed, 09 Feb 2011) r169944 | redi | 2011-02-09 09:39:29 +1300 (Wed, 09 Feb 2011) r169883 | ro | 2011-02-08 02:15:14 +1300 (Tue, 08 Feb 2011) r169868 | gerald | 2011-02-07 10:08:58 +1300 (Mon, 07 Feb 2011) r170086 is ada only r170040 is pa only r170013 should be mips only r169972 is libffi testsuite only r169951 is for multilibs r169944 is documentation r169883 is x86/avx only r169868 is documentation making r170053 the most likely. I'll build 170040 and 170053 to confirm.
[Bug fortran/47976] [4.5 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976 --- Comment #5 from Michael Hope 2011-03-20 21:10:37 UTC --- Problem is introduced by r170053. See: http://ex.seabright.co.nz/build/gcc-4.5~svn170053/logs/armv7l-maverick-cbuild88-carina7-cortexa8r1/gcc-testsuite.txt The commit before it does not have the problem: http://ex.seabright.co.nz/build/gcc-4.5~svn170040/logs/armv7l-maverick-cbuild88-ursa2-cortexa8r1/gcc-testsuite.txt
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #20 from Michael Hope 2011-04-13 07:23:49 UTC --- I'm seeing this problem with r172238 on i686. See: http://builds.linaro.org/toolchain/gcc-4.5+svn172238%5Eprofiled/logs/i686-lucid-cbuild109-scorpius-profiled/ 4.6.0 is fine.
[Bug middle-end/47976] [4.5/4.6/4.7 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47976 --- Comment #10 from Michael Hope 2011-04-19 01:05:42 UTC --- The proposed patch bootstraps fine on i686, x86_64, and armv7l. See: https://code.launchpad.net/~michaelh1/gcc-linaro/pr47976/+merge/58062 -FAIL: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +PASS: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test -FAIL: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test +PASS: gfortran.dg/actual_array_constructor_3.f90 -O3 -fomit-frame-pointer -funroll-loops execution test -FAIL: 27_io/basic_streambuf/sputc/wchar_t/1057.cc execution test +PASS: 27_io/basic_streambuf/sputc/wchar_t/1057.cc execution test The 1057.cc change is probably due to a change in binutils.
[Bug c/48783] New: ARM: kernel compiled at -O2 has a unused reference to __aeabi_uldivmod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Summary: ARM: kernel compiled at -O2 has a unused reference to
__aeabi_uldivmod
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org
Created attachment 24107
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24107
Preprocessed source
When compiled, the attached code refers to the 64 bit unsigned divmod helper
function '__aeabi_uldivmod' even though the function is never called. This
causes a link error when cross-compiling an ARM Linux 2.6.38 kernel.
To reproduce:
* Make a arm-linux-gnueabi cross compiler configured with --with-mode=thumb
--with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon
* Compile the attached code with 'arm-linux-gnueabi-gcc -O2 -S wm8974.i'
* See a '.global __aeabi_uldivmod' in the header of wm8974_set_dai_pll
Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before the
call to do_div() works around the problem.
[Bug c/48783] ARM: kernel compiled at -O2 has a unused reference to __aeabi_uldivmod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 --- Comment #2 from Michael Hope 2011-04-27 09:52:09 UTC --- Sorry, the original attachment included the __attribute__((noinline)) workaround on pll_factors(). Attached is the original that shows the fault.
[Bug c/48783] ARM: kernel compiled at -O2 has a unused reference to __aeabi_uldivmod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 --- Comment #3 from Michael Hope 2011-04-27 09:54:56 UTC --- Created attachment 24111 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24111 Preprocessed source
[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope 2011-05-17 22:05:00 UTC --- I see the same thing in trunk and 4.6.0. 4.5.2 is fine. michaelh@ursa1:~$ /scratch/michaelh/toolchains/gcc-4.6.0-armv7l-maverick-cbuild102-ursa1-cortexa9r1/bin/gcc -O2 pr48335-2.c pr48335-2.c: In function 'f1': pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6918 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. michaelh@ursa1:~$ /scratch/michaelh/toolchains/gcc-4.6+svn173722-armv7l-maverick-cbuild114-ursa4-cortexa9r1/bin/gcc -O2 pr48335-2.c pr48335-2.c: In function 'f1': pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6949 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. michaelh@ursa1:~$ /tools/toolchains/gcc-4.5.2-armv7l-maverick-cbuild93-ursa1-cortexa8r1/bin/gcc -O2 -c pr48335-2.c See also: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01661.html
[Bug testsuite/48283] gcc.dg/graphite/block-[3478].c timeouts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48283 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #4 from Michael Hope 2011-05-17 23:36:51 UTC --- Note that compiling block-4.c on a 1 GHz Cortex-A9 takes 2:30 s on GCC 4.5.2.
[Bug rtl-optimization/49169] New: ARM: optimisations strip the Thumb/ARM mode bit off function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169
Summary: ARM: optimisations strip the Thumb/ARM mode bit off
function pointers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org
ARM devices encode the instruction set mode in the LSB of the function address.
Functions are word aligned on ARM. If you try to test the LSB of a function
pointer then GCC assumes that the two least significant bits are zero and
optimises away the test.
This problem is seen in Mono and was originally reported at:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/721531
A reduced test case is:
void main() {
void *p = main;
if ((int)p & 1) printf ("HIT!\n");
}
When compiled with -march=armv7-a -mthumb -O0 then the word 'HIT!' will show.
When compiled with -O2, the branch is not taken.
The problem does not occur in 4.4.5. It does occur in 4.5.2, 4.6.0, and trunk
r174044.
[Bug target/49335] New: ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335 Summary: ARM: Invalid assembler generated while compiling C++ code from 'codeblocks' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.h...@linaro.org Created attachment 24468 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24468 Reduced test case The attached testcase is derived from codeblocks 10.05 and fails to build on ARM due to generating invalid assembler. To reproduce: michaelh@ursa2:~/linaro/bugs$ ~/linaro/toolchains/gcc-4.7~svn174795-armv7l-maverick-cbuild127-ursa3-cortexa9r1/bin/g++ -c -O2 -save-temps lp791327.cpp lp791327.s: Assembler messages: lp791327.s:76: Error: r13 not allowed here -- `rsb r0,sp,r0,lsl#2' The fault occurs in 4.6.0 and current trunk. It does not occur in 4.5.3. Originally reported at https://bugs.launchpad.net/ubuntu/+source/codeblocks/+bug/791327
[Bug target/49335] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335 --- Comment #1 from Michael Hope 2011-06-08 22:33:32 UTC --- Forgot the configuration: Configured with: '../../gcc-4.7~/configure' --prefix='/scratch/cbuild/slave/slaves/ursa3/gcc-4.7~svn174795/gcc/default/install' --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon Thread model: posix gcc version 4.7.0 20110608 (experimental) [trunk revision 174795] (GCC) michaelh@ursa2:~/linaro/bugs$ as -v GNU assembler version 2.20.51 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.20.51-system.20100908 michaelh@ursa2:~/linaro/bugs$ uname -a Linux ursa2 2.6.35.3-cbuild2+ #8 SMP Mon Apr 4 12:46:46 NZST 2011 armv7l GNU/Linux michaelh@ursa2:~/linaro/bugs$ lsb_release -a No LSB modules are available. Distributor ID:Ubuntu Description:Ubuntu 10.10 Release:10.10 Codename:maverick The fault also occurs at -O1 and -O3 but not at -O0. The assembly in the region is: .L33: movsr1, #0 movsr2, #64 movr0, sp movr9, sp blmemset cmpr4, #4 beq.L11 addr0, r8, r4, lsl #2 rsbr6, r8, #4 lslsr6, r6, #2 rsbr1, r4, #4 rsbr0, sp, r0, lsl #2 movr4, sp movlr, #0 which matches the final lines of the function. It looks like the code should be using r9 instead of sp.
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #5 from Michael Hope 2011-06-09 01:34:47 UTC --- 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.
[Bug c++/48660] ARM ICE in expand_expr_real_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #1 from Michael Hope 2011-06-09 02:51:33 UTC --- Occurs in trunk r174795, 4.6.0, and 4.5.3.
[Bug target/49335] [4.6/4.7 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335 --- Comment #4 from Michael Hope 2011-06-16 01:31:43 UTC --- Also affects gimp. See LP: #791279. Doesn't appear in trunk r172224 but does in r174795.
[Bug target/48803] arm: Bad assembler produced by bit extract/shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #2 from Michael Hope 2011-07-11 00:19:52 UTC --- Part of the difference is that 4.5 inlines the other functions and 4.6 doesn't. Adding an __attribute__((always_inline)) to both gives the following: For 4.5, main is: main: movwr3, #22136 movtr3, 4660 and r3, r0, r3 cbnzr3, .L10 mvn r3, #15 lslsr2, r0, r3 ubfxr0, r0, #30, #10 and r3, r0, #768 lsrsr0, r2, #24 orr r0, r3, r0 bx lr .L10: ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 orr r0, r3, r0 bx lr For 4.6 it becomes: main: movwr3, #22136 movtr3, 4660 andsr3, r3, r0 cbz r3, .L13 ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 .L12: orrsr0, r0, r3 bx lr .L13: mov r0, r3 b .L12
