[Bug other/62248] Configure error with --with-fpu=fp-armv8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62248 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added CC||yvan.roux at linaro dot org --- Comment #1 from Yvan Roux yvan.roux at linaro dot org --- Indeed --with-fpu provides the default value for -mfpu option, thus it should match its possible values.
[Bug target/45360] arm: -mhard-float != -mfloat-abi=hard during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added CC||yvan.roux at linaro dot org --- Comment #3 from Yvan Roux yvan.roux at linaro dot org --- This is fixed on trunk, and I guess since Joseph's commit on 4.7. Do we need to check that to close the PR ?
[Bug regression/60726] New: [AArch64] pr40074.c regression after intrinsics a53 tuning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60726 Bug ID: 60726 Summary: [AArch64] pr40074.c regression after intrinsics a53 tuning Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: yvan.roux at linaro dot org Hi, there is a regression on aarch64-none-linux-gnu for pr40074.c after http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=208910 Passed now fails [PASS = FAIL]: gcc.dg/vect/pr40074.c -flto -ffat-lto-objects execution test gcc.dg/vect/pr40074.c execution test
[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60726 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- I don't observe the regression in aarch64-none-elf on my side too. I'm looking for the configuration...
[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60726 --- Comment #4 from Yvan Roux yvan.roux at linaro dot org --- I just find the logs from the build farm, and it is indeed a qemu uncaught signal. Sorry for the false alert !
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #11 from Yvan Roux yvan.roux at linaro dot org --- Thanks for the analysis Vladimir, let me know if I can help you for the validation.
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #5 from Yvan Roux yvan.roux at linaro dot org --- Validation shows that it still fails for arm-none-linux-gnueabihf. I didn't investigate further yet.
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #7 from Yvan Roux yvan.roux at linaro dot org --- The same kind of issue is reported on the same build, but with a different set of options. I'm reducing the testcase (still too big...)
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #8 from Yvan Roux yvan.roux at linaro dot org --- Created attachment 32500 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32500action=edit 2nd reduced testcase
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #9 from Yvan Roux yvan.roux at linaro dot org --- the new command line is : cc1 -O2 -fno-omit-frame-pointer -march=armv7-a xfs_bmap_util.i
[Bug rtl-optimization/60650] New: [ARM] LRA ICE assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 Bug ID: 60650 Summary: [ARM] LRA ICE assign_by_spills Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yvan.roux at linaro dot org reported when building linux btrfs module. slightly reduced preprocessed test case attached. command line : cc1 -O2 -fno-omit-frame-pointer -mabi=apcs-gnu -march=armv7-a file-item.i cc1 outputs : In file included from /git/arm-soc/fs/btrfs/transaction.h:21:0, from /git/arm-soc/fs/btrfs/file-item.c:25: /git/arm-soc/fs/btrfs/btrfs_inode.h: In function ‘truncate_one_csum’: /git/arm-soc/fs/btrfs/btrfs_inode.h:214:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1286 0x9ddf78 assign_by_spills /work/sources/gcc-fsf/trunk/gcc/lra-assigns.c:1286 0x9de921 lra_assign() /work/sources/gcc-fsf/trunk/gcc/lra-assigns.c:1444 0x9d865a lra(_IO_FILE*) /work/sources/gcc-fsf/trunk/gcc/lra.c:2370 0x98669b do_reload /work/sources/gcc-fsf/trunk/gcc/ira.c:5457 0x9869e4 rest_of_handle_reload /work/sources/gcc-fsf/trunk/gcc/ira.c:5598 0x986a2e execute /work/sources/gcc-fsf/trunk/gcc/ira.c:5627
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #1 from Yvan Roux yvan.roux at linaro dot org --- testcase is to big to be attached... reducing...
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Created attachment 32449 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32449action=edit reduced testcase
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 --- Comment #7 from Yvan Roux yvan.roux at linaro dot org --- Thanks for the quick fix Jakub.
[Bug middle-end/60482] New: Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Bug ID: 60482
Summary: Loop optimization regression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: yvan.roux at linaro dot org
Created attachment 32323
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32323action=edit
trunk.s
Hi,
I didn't had time to investigate further, but I want to raise quickly that the
code bellow was optimized at r204283 by taking into account the trip count
information of the loop and is not with the trunk (I spotted the issue on
AArch64 and x86_64).
code:
typedef double adouble __attribute__ ((__aligned__(16)));
double p1(adouble *x, int n)
{
double p1_ = 0.0;
(!(n % 128) == 0) ? __builtin_unreachable() : 1 ;
for (int i=0; in; i++)
p1_ += x[i] ;
return p1_ ;
}
compiled with flags : -Ofast -std=c99
x86_64 generated assembly at r204283:
p1:
.LFB0:
.cfi_startproc
testl %esi, %esi
jle .L5
pxor%xmm1, %xmm1
shrl%esi
xorl%eax, %eax
.L4:
movq%rax, %rdx
addq$1, %rax
salq$4, %rdx
cmpl%eax, %esi
addpd (%rdi,%rdx), %xmm1
ja .L4
movapd %xmm1, %xmm0
unpckhpd%xmm1, %xmm1
addsd %xmm1, %xmm0
ret
.p2align 4,,10
.p2align 3
.L5:
pxor%xmm0, %xmm0
ret
.cfi_endproc
X86_64 trunk generated assembly is attached.
Thanks,
Yvan
[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Yes, I fixed it at r205581 but the PR reference in the ChangeLog disappeared between the submission and the commit :( Yvan
[Bug target/58785] [ARM] LRA issue in Thumb mode with movhi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58785 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added CC||yvan.roux at linaro dot org --- Comment #5 from Yvan Roux yvan.roux at linaro dot org --- Yes, I've tried with foundation_v8, and not only it extremely slow, but also it fails here. compiling gcc in qemu takes 5hours, but takes one week (someone told me) in foudation model. for another simulator, do you have any suggestion? is the foundation model failing for the same reason here (i.e. not recognizing the cmeq instruction) ?
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #8 from Yvan Roux yvan.roux at linaro dot org --- Forget my previous comment, I can reproduce it after a rebase.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #7 from Yvan Roux yvan.roux at linaro dot org --- I'm not able to reproduce with today's trunk or rev #205887 built for arm-none-linux-gnueabi, as the compiler ICEs in assign_by_spills (lra-assign.c). What is your configuration ?
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #3 from Yvan Roux yvan.roux at linaro dot org --- Validation ends without any regression on ARM targets (armv5, a9, a9hf, a15).
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Yvan Roux yvan.roux at linaro dot org --- Fix committed at rev. 201005
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #6 from Yvan Roux yvan.roux at linaro dot org --- Nice feature, I'll try to remember it ;) Thanks
[Bug target/57909] New: [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 Bug ID: 57909 Summary: [ARM] ICE with internal memcpy and -mno-unaligned-access Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: yvan.roux at linaro dot org Created attachment 30510 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30510action=edit reduced test case compilling the attached reduced test case with the following command line produces an ICE. arm-linux-gnueabi-gcc -marm -march=armv7-a -mtune=cortex-a15 -mno-unaligned-access -c -o panic.o panic.i panic.i: In function 'bug': panic.i:10:1: error: unrecognizable insn: } ^ (insn 9 8 10 2 (set (reg:SI 114) (zero_extend:SI (unspec:HI [ (mem/u/c:HI (reg:SI 113) [0 MEM[(void *)aa]+0 S2 A32]) ] UNSPEC_UNALIGNED_LOAD))) panic.i:9 -1 (nil)) panic.i:10:1: internal compiler error: in extract_insn, at recog.c:2150
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Created attachment 30511 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30511action=edit a first fix
[Bug target/57909] [ARM] ICE with internal memcpy and -mno-unaligned-access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 --- Comment #1 from Yvan Roux yvan.roux at linaro dot org --- The issue is that an UNSPEC_UNALIGNED_LOAD insn is emitted whereas the flag -mno-unaligned-access is passed, which implies that this insn is not recognized. The generation of the unaligned load is made in the gen_movmem_ldrd_strd function introduced at rev198970, there is a test that prevent doing calls to gen_unaligned_loadhiu when unaligned access are not authorized and src and dst are unaligned, but if they are aligned the call is made. The attached patch fixes the issue, but is still under validation.
[Bug middle-end/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 --- Comment #8 from Yvan Roux yvan.roux at linaro dot org 2012-12-14 10:14:15 UTC --- Hi Richard, Thanks for having applied and cleaned my patch. Regarding this cleanup, if we want to be consistant I think we have to remove the memory model test in expand_atomic_store (see the peace of patch below) as the atomic_store valid memory model variants are RELAXED, SEQ_CST, and RELEASE and that expand_mem_thread_fence doesn't emit any barrier in the RELEASE model case. Thanks, Yvan @@ -7537,8 +7537,7 @@ expand_atomic_store (rtx mem, rtx val, enum memmodel model, bool use_release) } /* Otherwise assume stores are atomic, and emit the proper barriers. */ - if (model == MEMMODEL_SEQ_CST || model == MEMMODEL_RELEASE) -expand_mem_thread_fence (model); + expand_mem_thread_fence (model); emit_move_insn (mem, val);
[Bug target/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org 2012-11-29 09:51:41 UTC --- Thanks Andrew for the review, I can't commit the patch myself, can you do it, or have I to post it on the mailing list ?
[Bug target/55492] New: __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492
Bug #: 55492
Summary: __atomic_load doesn't match ACQUIRE memory model
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yvan.r...@linaro.org
Created attachment 28796
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28796
Generic expansion patch proposal
Compiling this code for ARMv7
int v;
int foo()
{
return __atomic_load_n (v, __ATOMIC_ACQUIRE);
}
generates a data memory barrier defore the load:
foo:
movwr3, #:lower16:v
movtr3, #:upper16:v
dmb sy
ldr r0, [r3, #0]
bx lr
But, the `Acquire’ semantics imply that no reads in the current thread
dependent on the value currently loaded can be reordered before this load.
Thus, the barrier needs to be after the load and not before.
The issue seems to be in expand_atomic_load which put a memory fence before
the load in any memory model. The attached patch fixes the problem.
