[Bug lto/95846] New: Combination of LTO and -Wl,--defsym causes symbol to be resolved as NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95846
Bug ID: 95846
Summary: Combination of LTO and -Wl,--defsym causes symbol to
be resolved as NULL
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The following program demonstrates this problem:
==< test1.c >==
#include
void f(void);
void g(void);
void f(void)
{
printf("in f()\n");
g();
printf("back in f()\n");
}
==< test2.c >==
#include
void f(void);
void real_g(void)
{
printf("in real_g()\n");
}
int main()
{
real_g();
f();
}
== end ==
$ gcc -Os -c test1.c
$ gcc -O2 -flto -c test2.c
$ gcc -O2 test1.o test2.o -o test -Wl,--defsym,g=real_g
$ ./test
in real_g()
in f()
Segmentation fault (core dumped)
The segfault is caused because there is no real_g symbol and g has been
resolved to NULL.
00401146 :
401146: 50 push %rax
401147: bf 15 20 40 00 mov$0x402015,%edi
40114c: e8 df fe ff ff callq 401030
401151: e8 aa ee bf ff callq 0 < oops!
401156: bf 10 20 40 00 mov$0x402010,%edi
40115b: 5a pop%rdx
40115c: e9 cf fe ff ff jmpq 401030
401161: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
401168: 00 00 00
40116b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
Seen on Fedora 32 (gcc 10.1.1, binutils 2.34) and Ubuntu 18.04 (gcc 7.5.0,
binutils 2.30)
[Bug lto/95846] Combination of LTO and -Wl, --defsym causes symbol to be resolved as NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95846 --- Comment #2 from cbaylis at gcc dot gnu.org --- Reported to binutils bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=26163
[Bug target/61551] [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551 cbaylis at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from cbaylis at gcc dot gnu.org --- This was fixed in https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=612ea540d2e1fe5eae5213823a3cec0d3d864fb2 This patch adds support for modelling the varying costs of different addressing modes. This patch adds support for modelling the varying costs of different addressing modes. The generic cost table treats all addressing modes as having equal cost. gcc/ChangeLog: 2017-11-23 Charles Baylis * config/arm/arm-protos.h (enum arm_addr_mode_op): New. (struct addr_mode_cost_table): New. (struct tune_params): Add field addr_mode_costs. * config/arm/arm.c (generic_addr_mode_costs): New. (arm_slowmul_tune): Initialise addr_mode_costs field. (arm_fastmul_tune): Likewise. (arm_strongarm_tune): Likewise. (arm_xscale_tune): Likewise. (arm_9e_tune): Likewise. (arm_marvell_pj4_tune): Likewise. (arm_v6t2_tune): Likewise. (arm_cortex_tune): Likewise. (arm_cortex_a8_tune): Likewise. (arm_cortex_a7_tune): Likewise. (arm_cortex_a15_tune): Likewise. (arm_cortex_a35_tune): Likewise. (arm_cortex_a53_tune): Likewise. (arm_cortex_a57_tune): Likewise. (arm_exynosm1_tune): Likewise. (arm_xgene1_tune): Likewise. (arm_cortex_a5_tune): Likewise. (arm_cortex_a9_tune): Likewise. (arm_cortex_a12_tune): Likewise. (arm_cortex_a73_tune): Likewise. (arm_v7m_tune): Likewise. (arm_cortex_m7_tune): Likewise. (arm_v6m_tune): Likewise. (arm_fa726te_tune): Likewise. (arm_mem_costs): Use table lookup to calculate cost of addressing mode. From-SVN: r255112
[Bug target/68532] [ARM] Incorrect code result on arm big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532 --- Comment #3 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Tue Feb 9 18:47:55 2016 New Revision: 233251 URL: https://gcc.gnu.org/viewcvs?rev=233251&root=gcc&view=rev Log: [ARM] PR68532: Fix up vuzp for big endian gcc/ChangeLog: 2016-02-09 Charles Baylis PR target/68532 * config/arm/arm.c (neon_endian_lane_map): New function. (neon_vector_pair_endian_lane_map): New function. (arm_evpc_neon_vuzp): Allow for big endian lane order. * config/arm/arm_neon.h (vuzpq_s8): Adjust shuffle patterns for big endian. (vuzpq_s16): Likewise. (vuzpq_s32): Likewise. (vuzpq_f32): Likewise. (vuzpq_u8): Likewise. (vuzpq_u16): Likewise. (vuzpq_u32): Likewise. (vuzpq_p8): Likewise. (vuzpq_p16): Likewise. gcc/testsuite/ChangeLog: 2016-02-09 Charles Baylis PR target/68532 * gcc.c-torture/execute/pr68532.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr68532.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm_neon.h trunk/gcc/testsuite/ChangeLog
[Bug target/68532] [ARM] Incorrect code result on arm big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532 --- Comment #4 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Tue Feb 9 18:49:05 2016 New Revision: 233252 URL: https://gcc.gnu.org/viewcvs?rev=233252&root=gcc&view=rev Log: [ARM] PR68532 Fix up vzip recognition for big endian gcc/ChangeLog: 2016-02-09 Charles Baylis PR target/68532 * config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane order. * config/arm/arm_neon.h (vzipq_s8): Adjust shuffle patterns for big endian. (vzipq_s16): Likewise. (vzipq_s32): Likewise. (vzipq_f32): Likewise. (vzipq_u8): Likewise. (vzipq_u16): Likewise. (vzipq_u32): Likewise. (vzipq_p8): Likewise. (vzipq_p16): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm_neon.h
[Bug target/68532] [ARM] Incorrect code result on arm big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from cbaylis at gcc dot gnu.org --- Fixed by these patches https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00630.html https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00632.html
[Bug target/69770] New: [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770
Bug ID: 69770
Summary: [ARM] -mlong-calls does not affect calls to
__gnu_mcount_nc generated by -pg
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
Target Milestone: ---
When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc function
are not generated as long calls.
extern void g(void);
int f() { g(); return 0; }
compiles to:
push{r4, lr}
push{lr}
bl __gnu_mcount_nc;// not a long call
ldr r3, .L2
blx r3 ;// a long call to g()
mov r0, #0
pop {r4, pc}
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 cbaylis at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-11 Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from cbaylis at gcc dot gnu.org --- I will post a patch to the list shortly
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 --- Comment #2 from cbaylis at gcc dot gnu.org --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00881.html
[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802
cbaylis at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |INVALID
--- Comment #4 from cbaylis at gcc dot gnu.org ---
I managed to look into this in more detail with a colleague. The segfault
happens because the implementation of __tls_get_addr in glibc returns an
invalid pointer. This seems to be a problem with static linking only, and
dynamic linking will avoid the problem.
A slightly simplified test case (without the exception handling) is:
#include
#include
__thread int __attribute__ ((tls_model ("global-dynamic"))) x = 10;
class Thread {
public:
void operator()(){
fprintf(stderr, "testing (%i) ...\n", x);
}
};
int main(void){
Thread t;
std::thread th(std::ref(t));
th.join();
return 0;
}
If you install a copy of jessie filesystem somewhere on your build machine, you
should be able to compile and link against the libraries on that version using
--sysroot=/path/to/fs. This should allow you to create dynamically linked
binaries which work on your target
I've created a glibc bug for this
https://sourceware.org/bugzilla/show_bug.cgi?id=19826.
Since I don't think this is a bug in gcc, I'll close this bug.
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 cbaylis at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #3 from cbaylis at gcc dot gnu.org --- new patch posted to mailing list https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01403.html
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 --- Comment #9 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu May 8 17:06:04 2014 New Revision: 210227 URL: http://gcc.gnu.org/viewcvs?rev=210227&root=gcc&view=rev Log: 2014-05-08 Charles Baylis Backport from mainline 2014-04-07 Charles Baylis PR target/60609 * config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove. (LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after ADDR_DIFF_VEC. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr60609.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/arm.h
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 --- Comment #8 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu May 8 17:06:01 2014 New Revision: 210226 URL: http://gcc.gnu.org/viewcvs?rev=210226&root=gcc&view=rev Log: 2014-05-08 Charles Baylis Backport from mainline 2014-04-07 Charles Baylis PR target/60609 * config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove. (LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after ADDR_DIFF_VEC. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr60609.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm.h --- Comment #9 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu May 8 17:06:04 2014 New Revision: 210227 URL: http://gcc.gnu.org/viewcvs?rev=210227&root=gcc&view=rev Log: 2014-05-08 Charles Baylis Backport from mainline 2014-04-07 Charles Baylis PR target/60609 * config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove. (LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after ADDR_DIFF_VEC. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr60609.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/arm.h
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 --- Comment #8 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu May 8 17:06:01 2014 New Revision: 210226 URL: http://gcc.gnu.org/viewcvs?rev=210226&root=gcc&view=rev Log: 2014-05-08 Charles Baylis Backport from mainline 2014-04-07 Charles Baylis PR target/60609 * config/arm/arm.h (ASM_OUTPUT_CASE_END): Remove. (LABEL_ALIGN_AFTER_BARRIER): Align barriers which occur after ADDR_DIFF_VEC. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr60609.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm.h
[Bug target/60609] [4.8 Regression] Error: value of 256 too large for field of 1 bytes at 68242
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||cbaylis at gcc dot gnu.org Known to work||4.8.3 Resolution|--- |FIXED --- Comment #10 from cbaylis at gcc dot gnu.org --- Now also fixed on 4.7 and 4.8 branches.
[Bug target/61411] New: [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411
Bug ID: 61411
Summary: [NEON] ICE in reload_cse_simplify_operands, at
postreload.c:411
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
Target: aarch64-oe-linux
Created attachment 32890
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32890&action=edit
Reduced test case
The attached test case results in an ICE when compiled with gcc 4.9
$ aarch64-oe-linux-gcc -O3 -c test.c
test.c: In function ‘vp9_idct16x16_256_add_neon_pass2’:
test.c:126:1: error: insn does not satisfy its constraints:
}
^
(insn 198 110 159 2 (set (reg:V8QI 37 v5 [orig:118 D.16400 ] [118])
(mem:V8QI (plus:DI (reg/v/f:DI 20 x20 [orig:202 dest ] [202])
(reg:DI 8 x8 [340])) [2 MEM[(const int64_t *)dest_44]+0 S8
A64]))
/home/cbaylis/tools/tools-aarch64-oe-linux-4.9/lib/gcc/aarch64-oe-linux/4.9.1/include/arm_neon.h:3646
735 {*aarch64_simd_movv8qi}
(nil))
test.c:126:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:411
0x7fc47a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/rtl-error.c:109
0x7fc49f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/rtl-error.c:120
0x7bdbd9 reload_cse_simplify_operands
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:411
0x7bf69c reload_cse_simplify
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:181
0x7bf69c reload_cse_regs_1
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:220
0x7bfa8b reload_cse_regs
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:68
0x7bfa8b rest_of_handle_postreload
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:2332
0x7bfa8b execute
/home/cbaylis/srcarea/gcc/gcc-4_9-branch/gcc/postreload.c:2368
There is a patch which appears to fix this problem at
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02397.html
[Bug target/61551] New: [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551
Bug ID: 61551
Summary: [NEON] alter costs to allow use of post-indexed
addressing modes for VLD{2..4}/VST{2..4}
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com
Target: arm-unknown-linux-gnueabi
Created attachment 32967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32967&action=edit
test for NEON addressing modes
The attached test case demonstrates that GCC does not exploit the post-indexed
addressing mode for NEON structure loads and stores: VLDn, VSTn where n>=2.
Generated code for VLD1/VST1 (using desired post-indexed addressing)
test_ld1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0], r1
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0], r1
vld1.8 {d16}, [r0], r1
vst1.8 {d16}, [r0]
bx lr
Generated code for VLD2:
test_ld2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
addsr3, r0, r1
vld2.8 {d16-d17}, [r0]
addsr0, r3, r1
addsr2, r0, r1
vst2.8 {d16-d17}, [r3]
addsr3, r2, r1
vld2.8 {d16-d17}, [r0]
add r1, r1, r3
vst2.8 {d16-d17}, [r2]
vld2.8 {d16-d17}, [r3]
vst2.8 {d16-d17}, [r1]
bx lr
A proof of concept patch is posted at:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01361.html
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #5 from cbaylis at gcc dot gnu.org --- Committed to trunk http://gcc.gnu.org/r227407 and gcc/ChangeLog corrected in http://gcc.gnu.org/r227534
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #11 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Wed Nov 11 01:05:16 2015 New Revision: 230142 URL: https://gcc.gnu.org/viewcvs?rev=230142&root=gcc&view=rev Log: [ARM] PR63870 Add qualifiers for NEON builtins 2015-11-11 Charles Baylis PR target/63870 * config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator qualifier_struct_load_store_lane_index. (builtin_arg): New enumerator NEON_ARG_STRUCT_LOAD_STORE_LANE_INDEX. (arm_expand_neon_args): New parameter. Remove ellipsis. Handle NEON argument qualifiers. (arm_expand_neon_builtin): Handle new NEON argument qualifier. * config/arm/arm.h (NEON_ENDIAN_LANE_N): New macro. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #12 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Wed Nov 11 01:08:43 2015 New Revision: 230143 URL: https://gcc.gnu.org/viewcvs?rev=230143&root=gcc&view=rev Log: [ARM] PR63870 Mark lane indices of vldN/vstN with appropriate qualifier 2015-11-11 Charles Baylis PR target/63870 * config/arm/arm-builtins.c: (arm_load1_qualifiers) Use qualifier_struct_load_store_lane_index. (arm_storestruct_lane_qualifiers) Likewise. * config/arm/neon.md: (neon_vld1_lane) Reverse lane numbers for big-endian. (neon_vst1_lane) Likewise. (neon_vld2_lane) Likewise. (neon_vst2_lane) Likewise. (neon_vld3_lane) Likewise. (neon_vst3_lane) Likewise. (neon_vld4_lane) Likewise. (neon_vst4_lane) Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/neon.md
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #13 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Wed Nov 11 01:11:20 2015 New Revision: 230144 URL: https://gcc.gnu.org/viewcvs?rev=230144&root=gcc&view=rev Log: [ARM] PR63870 Remove error for invalid lane numbers 2015-11-11 Charles Baylis PR target/63870 * config/arm/neon.md (neon_vld1_lane): Remove error for invalid lane number. (neon_vst1_lane): Likewise. (neon_vld2_lane): Likewise. (neon_vst2_lane): Likewise. (neon_vld3_lane): Likewise. (neon_vst3_lane): Likewise. (neon_vld4_lane): Likewise. (neon_vst4_lane): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #7 from cbaylis at gcc dot gnu.org --- I am backporting the fix to GCC 5 now. I'll close it once committed.
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #8 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Nov 16 15:01:01 2015 New Revision: 230427 URL: https://gcc.gnu.org/viewcvs?rev=230427&root=gcc&view=rev Log: backport of fix for PR67280 (r227407) 2015-11-16 Charles Baylis Backport from mainline r227407 PR ipa/67280 * cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external in new callgraph edge. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/cgraphunit.c
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from cbaylis at gcc dot gnu.org --- Closed as this is now fixed on trunk and in gcc-5-branch
[Bug target/68532] [ARM] Incorrect code result on arm big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532
cbaylis at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-11-25
CC||cbaylis at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from cbaylis at gcc dot gnu.org ---
This is a simplified test case, which shows the incorrect way elements are
being read from the vector loads done in the vectorized loop.
#include
#include
#define SIZE 128
unsigned short alignas(16) in[SIZE];
unsigned short alignas(16) out[SIZE];
__attribute__ ((noinline)) void
test (unsigned short *restrict out, unsigned short *restrict in)
{
int i;
for (int j = 0; j < SIZE; j+=8)
out[i++] = in[j];
}
int main()
{
for (int i = 0; i : 0 1 2 3 4 5 6 7
: 8 9 10 11 12 13 14 15
: 16 17 18 19 20 21 22 23
: 24 25 26 27 28 29 30 31
layout of q8 after vld1.64 {d16-d17}, [r1:64] (showing architectural lanes 0 to
7, in ascending order)
q8 = { 3, 2, 1, 0, 7, 6, 5, 4 }
So, the first 64 bits are loaded into lanes 0-3, but in big endian order, and
the 2nd 64 bits are loaded into lanes 4-7, also in big endian order.
The vectorizer expects that the result of loading a 128-bit vector into memory,
should be:
q8 = { 7, 6, 5, 4, 3, 2, 1, 0 }
but the back end does not do that, in an attempt to support the EABI memory
ordering for 128 bit vectors. The behaviour of 128-bit vector loads/stores is
defined by output_move_neon(). There is a large comment in arm.c above
output_move_neon ("WARNING: The ordering of elements is weird in big-endian
mode...") which explains this.
The ARM back-end already uses a strategy of representing lane numbers in a "GCC
numbering", and transforming them to architectural numbering when generating
assembly. This is currently a simple reversal in big-endian mode, and a 1:1 map
in little endian.
I think this bug could be fixed by using a mapping lane numbers so that the
behaviour of output_move_neon() is taken into account. This would prevent the
vectorizer from using VUZP for the VEC_PERM_EXPR() in big-endian mode, because
the lanes specified would not match the behaviour of VUZP on 128 bit vectors.
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #6 from cbaylis at gcc dot gnu.org --- There is still a lot to do. I have patches in progress for Aarch64 loads and stores. Aarch64 shifts still need doing, and everything for ARM.
[Bug rtl-optimization/44404] auto-inc-dec generates an invalid assembly instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44404 cbaylis at gcc dot gnu.org changed: What|Removed |Added CC||gilles.chanteperdrix@xenoma ||i.org --- Comment #9 from cbaylis at gcc dot gnu.org --- *** Bug 38674 has been marked as a duplicate of this bug. ***
[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||cbaylis at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from cbaylis at gcc dot gnu.org --- This appears to have been fixed by r161920 2010-07-07 Bernd Schmidt PR rtl-optimization/44404 * auto-inc-dec.c (find_inc): Avoid calling count_occurrences if possible, use reg_overlap_mentioned_p instead. *** This bug has been marked as a duplicate of bug 44404 ***
[Bug rtl-optimization/65304] New: [4.9] [ARM] incorrect "asm operand has impossible constraints" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65304
Bug ID: 65304
Summary: [4.9] [ARM] incorrect "asm operand has impossible
constraints" error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
Target: arm-unknown-linux-gnueabihf
Created attachment 34940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34940&action=edit
Original test case
The attached test case, and reduced variant result in an error: "asm operand
has impossible constraints". This is a regression since 4.8.
$ arm-unknown-linux-gnueabihf-gcc -O2 -S orig.c -mbig-endian -mthumb
-march=armv7-a -mtune=cortex-a8
orig.c: In function ‘rpc_print_iostats’:
orig.c:169:4: error: ‘asm’ operand has impossible constraints
asm ( "umlal %R0, %Q0, %R2, %Q3\n\t" \
^
orig.c:215:2: note: in expansion of macro ‘do_div’
do_div(t, 100);
^
-
or
$ arm-unknown-linux-gnueabihf-gcc -O2 -S reduced.c -mbig-endian -mthumb
-march=armv7-a -mtune=cortex-a8
reduced.c: In function ‘fn2’:
reduced.c:26:7: error: ‘asm’ operand has impossible constraints
asm("@asm2 %R0 %Q0 %R1 %R2 %Q2 %R3 %Q3" : "+&r"(n), "+&r"(q) :
"r"(o), "r"(p));
^
This does not occur on trunk, due to commit r209615:
2014-04-22 Ramana Radhakrishnan
* config/arm/arm.c (arm_hard_regno_mode_ok): Loosen
restrictions on core registers for DImode values in Thumb2.
However, since similar restrictions still exist in ARM state, it is possible
that there remains a latent bug on trunk.
This bug was originally reported in Linaro bugzilla
https://bugs.linaro.org/show_bug.cgi?id=1199
[Bug rtl-optimization/65304] [4.9] [ARM] incorrect "asm operand has impossible constraints" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65304 --- Comment #1 from cbaylis at gcc dot gnu.org --- Created attachment 34941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34941&action=edit automatically reduced test case
[Bug target/63870] New: [Aarch64] [ARM] Errors in use of NEON instrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 Bug ID: 63870 Summary: [Aarch64] [ARM] Errors in use of NEON instrinsics are reported incorrectly Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: cbaylis at gcc dot gnu.org Reporter: cbaylis at gcc dot gnu.org CC: alan.lawrence at arm dot com Target: arm-unknown-linux-gnueabi, aarch64-linux-gnu Created attachment 33972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33972&action=edit Example tests Several NEON intrinsics have arguments which must be a constant integer in a fixed range. At present, these constraints are enforced for most intrinsics during assembly output, or, in some cases, not checked at all. This can be fixed by using the %K format specifier to the error message. See https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01248.html for a proposed patch and explanation. Once that patch is applied, it is necessary to rework the expansion of the builtins so that the constraints are checked during expansion. Some of this work has been started for Aarch64 (https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00421.html) Example demonstration of incorrect error messages using attached test cases on an ARM target. Note that the error message is reported at the end of each function, rather than the line where the error occurs. $ arm-unknown-linux-gnueabihf-gcc -c neon_const_range_tests/* -mfpu=neon neon_const_range_tests/vld1.c: In function ‘f_vld1_lane’: neon_const_range_tests/vld1.c:10:1: error: lane out of range } ^ neon_const_range_tests/vld4.c: In function ‘f_vld4_lane’: neon_const_range_tests/vld4.c:10:1: error: lane out of range } ^ neon_const_range_tests/vmul_lane.c: In function ‘f_vmul_lane’: neon_const_range_tests/vmul_lane.c:10:1: error: lane out of range } ^ neon_const_range_tests/vshl.c: In function ‘f_vshl’: neon_const_range_tests/vshl.c:10:1: error: constant out of range } ^ neon_const_range_tests/vshrn_n.c: In function ‘f_vshrn_n’: neon_const_range_tests/vshrn_n.c:10:1: error: constant out of range } ^ neon_const_range_tests/vst1.c: In function ‘f_vst1_lane’: neon_const_range_tests/vst1.c:9:1: error: lane out of range } ^ neon_const_range_tests/vst4.c: In function ‘f_vst4_lane’: neon_const_range_tests/vst4.c:9:1: error: lane out of range } ^
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #2 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu Nov 20 16:26:54 2014 New Revision: 217885 URL: https://gcc.gnu.org/viewcvs?rev=217885&root=gcc&view=rev Log: PR target/63870 * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass expression to aarch64_simd_lane_bounds. * config/aarch64/aarch64-protos.h (aarch64_simd_lane_bounds): Update prototype. * config/aarch64/aarch64-simd.md: (aarch64_combinez): Update call to aarch64_simd_lane_bounds. (aarch64_get_lanedi): Likewise. (aarch64_ld2_lane): Likewise. (aarch64_ld3_lane): Likewise. (aarch64_ld4_lane): Likewise. (aarch64_im_lane_boundsi): Likewise. * config/aarch64/aarch64.c (aarch64_simd_lane_bounds): Add exp parameter. Report calling function in error message if exp is non-NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-builtins.c trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/config/aarch64/aarch64.c
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||cbaylis at gcc dot gnu.org Resolution|--- |INVALID --- Comment #7 from cbaylis at gcc dot gnu.org --- This is caused by an invalid implementation of memset in (old versions of) the Linux kernel. I investigated this, a longer description is on the Linaro bugzilla at https://bugs.linaro.org/show_bug.cgi?id=928#c7
[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #29 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Sat Jul 5 11:58:06 2014 New Revision: 212303 URL: https://gcc.gnu.org/viewcvs?rev=212303&root=gcc&view=rev Log: [ARM] PR target/49423 2014-07-05 Charles Baylis PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand. Remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/constraints.md
[Bug target/49423] [4.8/4.9/4.10 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||cbaylis at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot gnu.org --- Comment #31 from cbaylis at gcc dot gnu.org --- I intend to backport to 4.8 and 4.9, once this change has had a week of testing on trunk.
[Bug target/61948] New: [ARM] [4.9 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948
Bug ID: 61948
Summary: [ARM] [4.9 regression] ICE with DImode shift by 1 bit
(in copyprop_hardreg_forward_1)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: cbaylis at gcc dot gnu.org
Reporter: cbaylis at gcc dot gnu.org
Target: arm-unknown-linux-gnueabihf
Created attachment 33202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33202&action=edit
Original test case, needs -std=c++11
Originally reported at:
https://bugs.linaro.org/show_bug.cgi?id=176
The lshrdi3_neon,ashrdi3_neon,ashldi3_neon patterns can call
gen_arm_di3_1bit without checking that the register allocation
constraints of the resulting insn are satisfied. This results in an ICE:
Simplified test case:
--<
long long f (long long *c)
{
long long t = c[0];
/* force t into [r1,r2] */
asm ("nop" : : : "r0", "r3", "r4", "r5",
"r6", "r7", "r8", "r9",
"r10", "r11", "r12", "memory");
return t >> 1;
}
===>---
$ arm-unknown-linux-gnueabihf-gcc -O2 -mfpu=neon -mthumb -c t.c
t.c: In function ‘f’:
t.c:8:1: error: insn does not satisfy its constraints:
}
^
(insn 18 7 14 2 (parallel [
(set (reg/i:DI 0 r0)
(ashiftrt:DI (reg/v:DI 1 r1 [orig:110 t ] [110])
(const_int 1 [0x1])))
(clobber (reg:CC 100 cc))
]) t.c:8 131 {arm_ashrdi3_1bit}
(expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
t.c:8:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775
[Bug target/61948] [ARM] [4.9 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-29 Ever confirmed|0 |1
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 --- Comment #2 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu Jul 31 14:27:58 2014 New Revision: 213376 URL: https://gcc.gnu.org/viewcvs?rev=213376&root=gcc&view=rev Log: PR target/61948 gcc/ChangeLog: 2014-07-29 Charles Baylis PR target/61948 * config/arm/neon.md (ashldi3_neon): Don't emit arm_ashldi3_1bit unless constraints are satisfied. (di3_neon): Likewise. gcc/testsuite/ChangeLog: 2014-07-29 Charles Baylis PR target/61948 * gcc.target/arm/pr61948.c: New test case. Added: trunk/gcc/testsuite/gcc.target/arm/pr61948.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md trunk/gcc/testsuite/ChangeLog
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from cbaylis at gcc dot gnu.org --- Fixed in r213376 Mailing list thread: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02009.html
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 cbaylis at gcc dot gnu.org changed: What|Removed |Added CC||cbaylis at gcc dot gnu.org --- Comment #5 from cbaylis at gcc dot gnu.org --- Created attachment 33244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33244&action=edit Reduced test case $ arm-unknown-linux-gnueabihf-gcc -S -O2 -g reduced1.cpp
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #6 from cbaylis at gcc dot gnu.org --- git bisect points to r211625 as the revision which fixes/hides this bug on trunk. 2014-06-13 Richard Biener * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Rewrite to propagate the VN result into all uses where possible and to remove stmts becoming dead because of that. (eliminate): Generalize stmt removal handling, remove in reverse dominator order to support proper debug stmt generation. Update stmts before removing stmts. * tree-ssa-propagate.c (propagate_tree_value): Remove bogus assert.
[Bug target/63277] ARM - NEON excessive use of vmov for vtbl2 / uint8x8x2 for shuffling data unnecessarily around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63277
cbaylis at gcc dot gnu.org changed:
What|Removed |Added
CC||cbaylis at gcc dot gnu.org
--- Comment #4 from cbaylis at gcc dot gnu.org ---
A much simplified test case based on arm_neon_excessive_vmov_wo_vcombine.c
$ arm-unknown-linux-gnueabihf-gcc -O2 -S -o - -mfpu=neon mini.c
#include
void f(int8_t *p)
{
int8x16_t v;
int8x8_t v2;
int8x8x2_t vx;
v=vld1q_s8(p);
v2=vld1_s8(p);
vx.val[0] = vget_low_s8(v);
vx.val[1] = vget_high_s8(v);
v2 = vtbl2_s8(vx, v2);
vst1_s8(p, v2);
}
With -dp, the generated code is:
f:
vld1.8 {d18-d19}, [r0] @ 6 neon_vld1v16qi [length = 4]
vmovd16, d18 @ v8qi@ 10*neon_movv8qi/1 [length = 4]
vld1.8 {d20}, [r0] @ 7 neon_vld1v8qi [length = 4]
vmovd17, d19 @ v8qi@ 11*neon_movv8qi/1 [length = 4]
vtbl.8 d16, {d16, d17}, d20@ 12neon_vtbl2v8qi [length = 4]
vst1.8 {d16}, [r0] @ 13neon_vst1v8qi [length = 4]
bx lr @ 24*thumb2_return [length = 4]
By the time IRA runs, the insns which result in the moves look like this:
(insn 9 18 11 2 (set (subreg:V8QI (reg/v:TI 116 [ vx ]) 0)
(subreg:V8QI (reg:V16QI 114 [ D.14019 ]) 0)) /tmp/mini.c:11 827
{*neon_movv8qi}
The registers 116 and 114 are allocated to different hard registers, as they
conflict. Presumably, the register allocator could be taught to treat this
subreg->subreg move as a copy and allow the same hard register to be allocated.
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #33 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 16:47:31 2014 New Revision: 215685 URL: https://gcc.gnu.org/viewcvs?rev=215685&root=gcc&view=rev Log: 2014-09-29 Charles Baylis Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/arm-protos.h branches/gcc-4_9-branch/gcc/config/arm/arm.c branches/gcc-4_9-branch/gcc/config/arm/arm.md branches/gcc-4_9-branch/gcc/config/arm/constraints.md
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #34 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 17:07:47 2014 New Revision: 215686 URL: https://gcc.gnu.org/viewcvs?rev=215686&root=gcc&view=rev Log: 2014-09-29 Charles Baylis Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm-protos.h branches/gcc-4_8-branch/gcc/config/arm/arm.c branches/gcc-4_8-branch/gcc/config/arm/arm.md branches/gcc-4_8-branch/gcc/config/arm/constraints.md
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from cbaylis at gcc dot gnu.org --- Backports committed to 4.8 and 4.9
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #14 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Nov 30 17:11:16 2015 New Revision: 231077 URL: https://gcc.gnu.org/viewcvs?rev=231077&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2015-11-30 Charles Baylis PR target/63870 * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f16_indices_1.c (f_vld2_lane_f16): Remove xfails for arm targets. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c (f_vld2_lane_f32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c (f_vld2_lane_f64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_p8_indices_1.c (f_vld2_lane_p8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s16_indices_1.c (f_vld2_lane_s16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s32_indices_1.c (f_vld2_lane_s32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s64_indices_1.c (f_vld2_lane_s64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s8_indices_1.c (f_vld2_lane_s8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u16_indices_1.c (f_vld2_lane_u16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u32_indices_1.c (f_vld2_lane_u32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u64_indices_1.c (f_vld2_lane_u64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u8_indices_1.c (f_vld2_lane_u8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f16_indices_1.c (f_vld2q_lane_f16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f32_indices_1.c (f_vld2q_lane_f32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f64_indices_1.c (f_vld2q_lane_f64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_p8_indices_1.c (f_vld2q_lane_p8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s16_indices_1.c (f_vld2q_lane_s16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s32_indices_1.c (f_vld2q_lane_s32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s64_indices_1.c (f_vld2q_lane_s64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s8_indices_1.c (f_vld2q_lane_s8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u16_indices_1.c (f_vld2q_lane_u16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u32_indices_1.c (f_vld2q_lane_u32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u64_indices_1.c (f_vld2q_lane_u64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u8_indices_1.c (f_vld2q_lane_u8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f16_indices_1.c (f_vld3_lane_f16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f32_indices_1.c (f_vld3_lane_f32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f64_indices_1.c (f_vld3_lane_f64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_p8_indices_1.c (f_vld3_lane_p8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s16_indices_1.c (f_vld3_lane_s16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s32_indices_1.c (f_vld3_lane_s32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s64_indices_1.c (f_vld3_lane_s64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s8_indices_1.c (f_vld3_lane_s8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u16_indices_1.c (f_vld3_lane_u16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u32_indices_1.c (f_vld3_lane_u32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u64_indices_1.c (f_vld3_lane_u64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_u8_indices_1.c (f_vld3_lane_u8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f16_indices_1.c (f_vld3q_lane_f16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f32_indices_1.c (f_vld3q_lane_f32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_f64_indices_1.c (f_vld3q_lane_f64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_p8_indices_1.c (f_vld3q_lane_p8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s16_indices_1.c (f_vld3q_lane_s16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s32_indices_1.c (f_vld3q_lane_s32): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s64_indices_1.c (f_vld3q_lane_s64): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_s8_indices_1.c (f_vld3q_lane_s8): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u16_indices_1.c (f_vld3q_lane_u16): Ditto. * gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_u32_indices_1.c (f_vld3q_lane_u32): Ditto. * gcc.target
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from cbaylis at gcc dot gnu.org --- Now fixed on trunk, for both ARM and AArch64 targets.
[Bug target/68532] [ARM] Incorrect code result on arm big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532 --- Comment #2 from cbaylis at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01644.html
[Bug target/68802] seg fault when non-main thread calls std::current_exception ARMv7-A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68802 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-12 CC||cbaylis at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from cbaylis at gcc dot gnu.org --- Also happens on trunk. I'm taking a look at this
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 cbaylis at gcc dot gnu.org changed: What|Removed |Added CC||cbaylis at gcc dot gnu.org --- Comment #40 from cbaylis at gcc dot gnu.org --- The kernel does support a mechanism to add a command line option for only compilers which support it. Documentation/kbuild/makefiles.txt: cc-option cc-option is used to check if $(CC) supports a given option, and if not supported to use an optional second option. I think you could therefore add this line to arch/arm64/Makefile KBUILD_CFLAGS += $(call cc-option,-mpc-relative-literal-loads)
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #42 from cbaylis at gcc dot gnu.org --- While we're suggesting fixes to the kernel, wouldn't it be better if CONFIG_ARM64_ERRATUM_843419 forced the kernel to be built with the linker workarounds if the kernel is configured KBUILD_LDFLAGS += --fix-cortex-a53-843419 or maybe KBUILD_LDFLAGS += $(call ld-option, --fix-cortex-a53-843419)
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #8 from cbaylis at gcc dot gnu.org --- Patch posted to the mailing list https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00799.html
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 --- Comment #9 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Wed Jul 22 10:44:16 2015 New Revision: 226059 URL: https://gcc.gnu.org/viewcvs?rev=226059&root=gcc&view=rev Log: gcc/ChangeLog: 2015-07-22 Charles Baylis PR target/63870 * config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers): Add qualifier_struct_load_store_lane_index. (aarch64_types_loadstruct_lane_qualifiers): Use qualifier_struct_load_store_lane_index for lane index argument for last argument. (aarch64_types_storestruct_lane_qualifiers): Ditto. (builtin_simd_arg): Add SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX. (aarch64_simd_expand_args): Add new argument describing mode of builtin. Check lane bounds for arguments with SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX. (aarch64_simd_expand_builtin): Emit error for incorrect lane indices if marked with SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX. (aarch64_simd_expand_builtin): Handle arguments with qualifier_struct_load_store_lane_index. Pass machine mode of builtin to aarch64_simd_expand_args. * config/aarch64/aarch64-simd-builtins.def: Declare ld[234]_lane and vst[234]_lane with BUILTIN_VALLDIF. * config/aarch64/aarch64-simd.md: (aarch64_vec_load_lanesoi_lane): Use VALLDIF iterator. Perform endianness reversal on lane index. (aarch64_vec_load_lanesci_lane): Ditto. (aarch64_vec_load_lanesxi_lane): Ditto. (vec_store_lanesoi_lane): Use VALLDIF iterator. (vec_store_lanesci_lane): Ditto. (vec_store_lanesxi_lane): Ditto. (aarch64_ld2_lane): Use VALLDIF iterator. Remove endianness reversal of lane index. (aarch64_ld3_lane): Ditto. (aarch64_ld4_lane): Ditto. (aarch64_st2_lane): Ditto. (aarch64_st3_lane): Ditto. (aarch64_st4_lane): Ditto. * config/aarch64/arm_neon.h (__LD2_LANE_FUNC): Rename mode parameter to qmode. Add new mode parameter. Update uses. (__LD3_LANE_FUNC): Ditto. (__LD4_LANE_FUNC): Ditto. (__ST2_LANE_FUNC): Ditto. (__ST3_LANE_FUNC): Ditto. (__ST4_LANE_FUNC): Ditto. gcc/testsuite/ChangeLog: 2015-07-22 Charles Baylis * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_p8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s16_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_s8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u16_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_u8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_f64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_p8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s16_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_s8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u16_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_u8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_f64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_p8_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s16_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld3_lane_s64_indices_1.c: New test. * gcc.target/aarch64
[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-20 CC||cbaylis at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |cbaylis at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from cbaylis at gcc dot gnu.org --- I will have a look at this.
[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280
--- Comment #2 from cbaylis at gcc dot gnu.org ---
Minimum optimisations to reproduce this are -O1 -fipa-icf-functions -fipa-sra.
These options also allow the bug to be reproduced on trunk (with -O2 the bug is
latent, I haven't investigated why).
The analysis here also uses -fno-inline, because the wrapper function is more
clearly visible. The problem occurs with and without inlining.
The failure is caused because the function:
std::_Function_handler::_M_invoke(std::_Any_data const&)
is compiled to:
_ZNSt17_Function_handlerIFvvEZ4mainEUlvE_E9_M_invokeERKSt9_Any_data:
.fnstart
.LFB2010:
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, lr}
bl
_ZNSt17_Function_handlerIFvvEZ4mainEUlvE0_E9_M_invokeERKSt9_Any_data
.cantunwind
.fnend
This includes .cantunwind which is an ARM-specific directive which causes the
exception unwinder to stop at this function which causes execution to
terminate.
Going further back, the ARM backend emits this directive because the function
is marked "nothrow" in the ipa-pure-const phase. This is visible in the dump:
foo.cc.062i.pure-const:Function found to be nothrow: static void
std::_Function_handler::_M_invoke(const
std::_Any_data&, _ArgTypes&& ...) [with _Functor = main()::;
_ArgTypes = {}]
This is clearly wrong, because this function calls the lambda, which contains a
throw. This happens on all targets, but does not seem to cause problems on
non-ARM targets because they use the standard/generic unwinder mechanism.
The _ZNSt17_Function_handlerIFvvEZ4mainEUlvE_E9_M_invokeERKSt9_Any_data is a
wrapper, created by cgraph_node::create_wrapper(). When this function updates
the callgraph and creates the edge to the target function, it unconditionally
sets ->can_throw_external to false, which causes the ipa-pure-const phase to
mark the wrapper function as nothrow.
I will send a patch to the mailing list shortly.
[Bug target/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #3 from cbaylis at gcc dot gnu.org --- Patch at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01791.html
