[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #10 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Jun 2 16:21:18 2015 New Revision: 224031 URL: https://gcc.gnu.org/viewcvs?rev=224031root=gccview=rev Log: [AArch64][PR 66136] rewrite geniterators.sh in awk 2015-06-02 Szabolcs Nagy szabolcs.n...@arm.com PR target/66136 * config/aarch64/geniterators.sh: Rewrite in awk. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/geniterators.sh
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||nsz at gcc dot gnu.org Resolution|--- |FIXED --- Comment #15 from nsz at gcc dot gnu.org --- fixed in trunk in r224031 and backported to branch 5 in r225170.
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #1 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Jul 6 11:00:03 2015 New Revision: 225450 URL: https://gcc.gnu.org/viewcvs?rev=225450root=gccview=rev Log: [AArch64] PR target/66731 Fix fnmul insn with -frounding-math gcc/Changelog: 2015-07-03 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.md (fnmulmode3): Handle -frounding-math. gcc/testsuite/Changelog: 2015-07-03 Szabolcs Nagy szabolcs.n...@arm.com * gcc.target/aarch64/fnmul-1.c: New. * gcc.target/aarch64/fnmul-2.c: New. * gcc.target/aarch64/fnmul-3.c: New. * gcc.target/aarch64/fnmul-4.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/fnmul-1.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-2.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-3.c trunk/gcc/testsuite/gcc.target/aarch64/fnmul-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #14 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Jun 30 10:07:03 2015 New Revision: 225170 URL: https://gcc.gnu.org/viewcvs?rev=225170root=gccview=rev Log: Backport of r224031 from mainline 2015-06-29 Szabolcs Nagy szabolcs.n...@arm.com Backport from mainline: 2015-06-02 Szabolcs Nagy szabolcs.n...@arm.com PR target/66136 * config/aarch64/geniterators.sh: Rewrite in awk. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/geniterators.sh
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #5 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Aug 3 14:27:43 2015 New Revision: 226507 URL: https://gcc.gnu.org/viewcvs?rev=226507root=gccview=rev Log: Backport form mainline r226496. gcc: Backport form mainline r226496. 2015-08-03 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/arm/vfp.md (negmuldf3_vfp): Add new pattern. (negmulsf3_vfp): Likewise. (muldf3negdf_vfp): Disable for -frounding-math. (mulsf3negsf_vfp): Likewise. * config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL, fix MULT cost with -frounding-math. gcc/testsuite: Backport form mainline r226496. 2015-08-03 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * gcc.target/arm/vnmul-1.c: New. * gcc.target/arm/vnmul-2.c: New. * gcc.target/arm/vnmul-3.c: New. * gcc.target/arm/vnmul-4.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-3.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/vnmul-4.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/arm/arm.c branches/gcc-5-branch/gcc/config/arm/vfp.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug other/67020] /gcc/gcc.c:878:32: error: macro CHOOSE_DYNAMIC_LINKER requires 4 arguments, but only 3 given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67020 nsz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from nsz at gcc dot gnu.org --- the musl patches are in gcc-trunk and were not yet backported to gcc-5 (or any 4.x branches), bug 58446 tracks their current state. it seems clfs has its own musl patch at http://patches.clfs.org/embedded-dev/gcc-4.7.3-musl-1.patch so this is not a gcc bug (ask on clfs or musl mailing lists for help). looking at the clfs patch i think it is ok, but it probably did not apply correctly to the gcc source you were using (e.g. it won't work for gcc-5.2, make sure you use the same gcc version as the patch).
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from nsz at gcc dot gnu.org --- both arm and aarch64 should be fixed now (fix is backported to 4.9 and 5 branches)
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #6 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Aug 3 17:04:29 2015 New Revision: 226519 URL: https://gcc.gnu.org/viewcvs?rev=226519root=gccview=rev Log: Backport form mainline r226496. gcc: Backport form mainline r226496. 2015-08-03 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/arm/vfp.md (negmuldf3_vfp): Add new pattern. (negmulsf3_vfp): Likewise. (muldf3negdf_vfp): Disable for -frounding-math. (mulsf3negsf_vfp): Likewise. * config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL, fix MULT cost with -frounding-math. gcc/testsuite: Backport form mainline r226496. 2015-08-03 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * gcc.target/arm/vnmul-1.c: New. * gcc.target/arm/vnmul-2.c: New. * gcc.target/arm/vnmul-3.c: New. * gcc.target/arm/vnmul-4.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-3.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vnmul-4.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/arm.c branches/gcc-4_9-branch/gcc/config/arm/vfp.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #4 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Aug 3 11:12:00 2015 New Revision: 226496 URL: https://gcc.gnu.org/viewcvs?rev=226496root=gccview=rev Log: [ARM] PR target/66731 Fix vnmul insn with -frounding-math gcc: PR target/66731 * config/arm/vfp.md (negmuldf3_vfp): Add new pattern. (negmulsf3_vfp): Likewise. (muldf3negdf_vfp): Disable for -frounding-math. (mulsf3negsf_vfp): Likewise. * config/arm/arm.c (arm_new_rtx_costs): Fix NEG cost for VNMUL, fix MULT cost with -frounding-math. gcc/testsuite: PR target/66731 * gcc.target/arm/vnmul-1.c: New. * gcc.target/arm/vnmul-2.c: New. * gcc.target/arm/vnmul-3.c: New. * gcc.target/arm/vnmul-4.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/vnmul-1.c trunk/gcc/testsuite/gcc.target/arm/vnmul-2.c trunk/gcc/testsuite/gcc.target/arm/vnmul-3.c trunk/gcc/testsuite/gcc.target/arm/vnmul-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/vfp.md trunk/gcc/testsuite/ChangeLog
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #9 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Aug 4 16:49:54 2015 New Revision: 226588 URL: https://gcc.gnu.org/viewcvs?rev=226588root=gccview=rev Log: Fix broken backport patch. gcc: Backport from mainline: 2015-08-04 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL. (aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math. Modified: branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #8 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Aug 4 16:43:46 2015 New Revision: 226587 URL: https://gcc.gnu.org/viewcvs?rev=226587root=gccview=rev Log: gcc: Backport from mainline: 2015-08-04 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL. (aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math. 2015-07-06 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.md (fnmulmode3): Handle -frounding-math. gcc/testsuite: Backport from mainline r225450: 2015-07-06 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * gcc.target/aarch64/fnmul-1.c: New. * gcc.target/aarch64/fnmul-2.c: New. * gcc.target/aarch64/fnmul-3.c: New. * gcc.target/aarch64/fnmul-4.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-1.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-2.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-3.c branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/fnmul-4.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/config/aarch64/aarch64.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #10 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Aug 4 17:42:05 2015 New Revision: 226592 URL: https://gcc.gnu.org/viewcvs?rev=226592root=gccview=rev Log: gcc: Backport from mainline: 2015-07-06 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.md (fnmulmode3): Handle -frounding-math. gcc/testsuite: Backport from mainline r225450: 2015-07-06 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * gcc.target/aarch64/fnmul-1.c: New. * gcc.target/aarch64/fnmul-2.c: New. * gcc.target/aarch64/fnmul-3.c: New. * gcc.target/aarch64/fnmul-4.c: New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-3.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/fnmul-4.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #7 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Aug 4 16:22:32 2015 New Revision: 226586 URL: https://gcc.gnu.org/viewcvs?rev=226586root=gccview=rev Log: [AArch64] PR target/66731 Fix fnmul insn with -frounding-math (rtx costs) 2015-08-04 Szabolcs Nagy szabolcs.n...@arm.com PR target/66731 * config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL. (aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/65711] arm*-linux* link spec passes '-dynamic-linker' even for '-shared'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711
--- Comment #10 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Jul 24 16:12:58 2015
New Revision: 226169
URL: https://gcc.gnu.org/viewcvs?rev=226169root=gccview=rev
Log:
Backported from mainline r226158.
2015-07-24 Szabolcs Nagy szabolcs.n...@arm.com
PR target/65711
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Move
-dynamic-linker within %{!static %{!shared, and -rdynamic within
%{!static.
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64-linux.h
[Bug target/65711] arm*-linux* link spec passes '-dynamic-linker' even for '-shared'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711
--- Comment #9 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Jul 24 16:00:26 2015
New Revision: 226165
URL: https://gcc.gnu.org/viewcvs?rev=226165root=gccview=rev
Log:
Backport from mainline r226158.
2015-07-24 Szabolcs Nagy szabolcs.n...@arm.com
PR target/65711
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Move
-dynamic-linker within %{!static %{!shared, and -rdynamic within
%{!static.
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64-linux.h
[Bug target/65711] arm*-linux* link spec passes '-dynamic-linker' even for '-shared'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711
--- Comment #8 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Fri Jul 24 14:27:55 2015
New Revision: 226158
URL: https://gcc.gnu.org/viewcvs?rev=226158root=gccview=rev
Log:
[AArch64] Fix LINUX_TARGET_LINK_SPEC to be consistent with ARM
2015-07-24 Szabolcs Nagy szabolcs.n...@arm.com
PR target/65711
* config/aarch64/aarch64-linux.h (LINUX_TARGET_LINK_SPEC): Move
-dynamic-linker within %{!static %{!shared, and -rdynamic within
%{!static.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-linux.h
[Bug target/66912] New: Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912
Bug ID: 66912
Summary: Copy relocation against protected symbol doesn't work
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
same as bug 65248 but for arm and aarch64.
On aarch64, gcc -S -O -fpic compiles
__attribute__((visibility(protected))) int n;
int f () { return n; }
into
f:
adrpx0, n
ldr w0, [x0, #:lo12:n]
ret
.size f, .-f
.protected n
.comm n,4,4
so the address of n is not loaded from GOT,
which means copy reloc against it in the main
executable won't work.
The expected code is
f:
adrpx0, :got:n
ldr x0, [x0, #:got_lo12:n]
ldr w0, [x0]
ret
[Bug target/58446] Support for musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #17 from nsz at gcc dot gnu.org --- gcc-trunk has most of the musl support patches (not backported yet to any release branch), the current state: libitm fix: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222325 fixincludes support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222327 unwind support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222328 gthread support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222329 config changes: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222904 stdint changes: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222905 aarch64 support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=223766 arm support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=223749 mips support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=222915 x86 support: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=223218 microblaze support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00437.html powerpc support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01640.html sh support: not yet committed https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01636.html
[Bug bootstrap/55807] Support musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55807 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||nsz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #13 from nsz at gcc dot gnu.org --- Bug 55807 has gcc-4.7 patches while 58446 has gcc-4.8 patches attached, however they are both outdated and about the same issue so closing this one (gcc-trunk already has some of the patches after gcc-5 was branched off). *** This bug has been marked as a duplicate of bug 58446 ***
[Bug target/58446] Support for musl libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 nsz at gcc dot gnu.org changed: What|Removed |Added CC||lu_zero at gentoo dot org --- Comment #16 from nsz at gcc dot gnu.org --- *** Bug 55807 has been marked as a duplicate of this bug. ***
[Bug target/66731] vnmul, fnmul patterns incorrect for -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66731 --- Comment #2 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Jul 15 09:03:15 2015 New Revision: 225810 URL: https://gcc.gnu.org/viewcvs?rev=225810root=gccview=rev Log: Add missing PR target/66731 to gcc/testsuite/Changelog Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/66912] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912 --- Comment #2 from nsz at gcc dot gnu.org --- protected only means it cannot be overridden. so we know the symbol will be resolved to the local one, however it may be visible externally and then the address must be the same in the other modules which is a problem if the main executable has a copy reloc against this symbol.
[Bug target/68059] [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 nsz at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-10-23 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #2 from nsz at gcc dot gnu.org --- bionic does not have __write either, it seems the android ndk changed it to write (which is not in the c namespace so might be wrong, but i guess the code is about to crash anyway). i'm reopening since i think the compiler should not assume such symbols to be available on a linux system (fwiw it is not part of the linux standard base abi core spec: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libc.html#AEN2405 or any other abi spec i'm aware of).
[Bug target/68059] New: [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 Bug ID: 68059 Summary: [arm] libgcc uses __write to report error Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- this bug was reported on the musl libc list: http://www.openwall.com/lists/musl/2015/10/22/3 libgcc/config/arm/linux-atomic-64bit.c references __write in __check_for_sync8_kernelhelper. __write is not a public abi symbol in libc, libgcc should not reference it. the standard way is to use assert, but in this case the error message seems superfluous: the crash is in a ctor, easily reproducible.
[Bug target/66912] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912 --- Comment #4 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Oct 20 09:50:58 2015 New Revision: 229030 URL: https://gcc.gnu.org/viewcvs?rev=229030=gcc=rev Log: Fix default_binds_local_p_2 for extern protected data Backport from mainline r229024 2015-10-20 Szabolcs Nagy <szabolcs.n...@arm.com> gcc: PR target/66912 * varasm.c (default_binds_local_p_2): Turn on extern_protected_data. gcc/testsuite: PR target/66912 * gcc.target/aarch64/pr66912.c: New. * gcc.target/arm/pr66912.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr66912.c branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr66912.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/varasm.c
[Bug target/66912] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #5 from nsz at gcc dot gnu.org --- fixed in r229030.
[Bug target/66912] Copy relocation against protected symbol doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66912 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Oct 20 09:37:27 2015 New Revision: 229024 URL: https://gcc.gnu.org/viewcvs?rev=229024=gcc=rev Log: Fix default_binds_local_p_2 for extern protected data gcc: PR target/66912 * varasm.c (default_binds_local_p_2): Turn on extern_protected_data. gcc/testsuite: PR target/66912 * gcc.target/aarch64/pr66912.c: New. * gcc.target/arm/pr66912.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr66912.c trunk/gcc/testsuite/gcc.target/arm/pr66912.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug other/67627] libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 --- Comment #1 from nsz at gcc dot gnu.org --- adding all-multi: $(libatomic_la_LIBADD) to libatomic/Makefile.in solves the problem for me, but i'm not sure what's the automake way of doing this
[Bug other/67627] New: libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 Bug ID: 67627 Summary: libatomic parallel build failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- hard to reproduce, but the failure is make[5]: Entering directory `/XX/obj/gcc4/arm-none-linux-gnueabihf/libatomic' .deps/fsub_8_.lo.Ppo:87: *** missing separator. Stop. and the cause is that .deps/fsub_8_.lo.Ppo is a makefile fragment generated by a compilation step that is run concurrently with another make reading this file. some relevant bits from libatomic/Makefile.in: ### begin LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_LTLIBRARIES) toolexeclib_LTLIBRARIES = libatomic.la noinst_LTLIBRARIES = libatomic_convenience.la libatomic_la_DEPENDENCIES = $(libatomic_la_LIBADD) $(libatomic_version_dep) libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \ _$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \ $(am__append_3) M_DEPS = -MT $@ -MD -MP -MF $(DEPDIR)/$(@F).Ppo libatomic.la: $(libatomic_la_OBJECTS) $(libatomic_la_DEPENDENCIES) $(EXTRA_libatomic_la_DEPENDENCIES). $(libatomic_la_LINK) -rpath $(toolexeclibdir) $(libatomic_la_OBJECTS) $(libatomic_la_LIBADD) $(LIBS) all-multi: $(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE) all-am: Makefile $(LTLIBRARIES) all-multi auto-config.h -include $(wildcard $(DEPDIR)/*.Ppo) %_.lo: Makefile $(LTCOMPILE) $(M_DEPS) $(M_SIZE) $(M_IFUNC) -c -o $@ $(M_SRC) ### end when all-am is built, building $(LTLIBRARIES) (the *_.lo targets) can run in parallel with all-multi. the all-multi target rereads the Makefile so reevaluates "-include $(wildcard $(DEPDIR)/*.Ppo)", but those files are generated in a non-atomic way by gcc -MF during the build of *_.lo targets.
[Bug other/67627] libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 --- Comment #2 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Jan 6 14:51:35 2016 New Revision: 232102 URL: https://gcc.gnu.org/viewcvs?rev=232102=gcc=rev Log: Fix libatomic multilib parallel build (PR other/67627) The all-multi target may be built in parallel with the %_.lo targets which generate make dependencies that are parsed during the build of all-multi. This patch forces all-multi to only run after the *_.lo targets are done. libatomic: PR other/67627 * Makefile.am (all-multi): Add dependency. * Makefile.in: Regenerate. Modified: trunk/libatomic/ChangeLog trunk/libatomic/Makefile.am trunk/libatomic/Makefile.in
[Bug other/67627] libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 --- Comment #4 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Jan 6 17:43:24 2016 New Revision: 232107 URL: https://gcc.gnu.org/viewcvs?rev=232107=gcc=rev Log: 2016-01-06 Szabolcs Nagy <szabolcs.n...@arm.com> Backport from mainline: 2016-01-06 Szabolcs Nagy <szabolcs.n...@arm.com> PR other/67627 * Makefile.am (all-multi): Add dependency. * Makefile.in: Regenerate. Modified: branches/gcc-4_9-branch/libatomic/ChangeLog branches/gcc-4_9-branch/libatomic/Makefile.am branches/gcc-4_9-branch/libatomic/Makefile.in
[Bug other/67627] libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from nsz at gcc dot gnu.org --- Fixed in r232102, backported to gcc-5 and gcc-49 branches.
[Bug other/67627] libatomic parallel build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67627 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Jan 6 17:32:41 2016 New Revision: 232105 URL: https://gcc.gnu.org/viewcvs?rev=232105=gcc=rev Log: 2016-01-06 Szabolcs Nagy <szabolcs.n...@arm.com> Backport from mainline: 2016-01-06 Szabolcs Nagy <szabolcs.n...@arm.com> PR other/67627 * Makefile.am (all-multi): Add dependency. * Makefile.in: Regenerate. Modified: branches/gcc-5-branch/libatomic/ChangeLog branches/gcc-5-branch/libatomic/Makefile.am branches/gcc-5-branch/libatomic/Makefile.in
[Bug c/50584] No warning for passing small array to C99 static array declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #12 from nsz at gcc dot gnu.org ---
(1) consider a simplified example from bug 17308
__attribute__((nonnull(1)))
void foo(char *bar) { if (!bar) __builtin_abort(); }
with gcc -O2 -fno-asynchronous-unwind-tables -fomit-frame-pointer -std=c99
-Wall
i get warnings:
a.c: In function 'foo':
a.c:2:27: warning: nonnull argument 'bar' compared to NULL [-Wnonnull]
void foo(char *bar) { if (!bar) __builtin_abort(); }
^
and asm code:
foo:
rep ret
(2) however code with similar semantics:
void foo(char bar[static 1]) { if (!bar) __builtin_abort(); }
gives no warnings and the generated asm is
foo:
testq %rdi, %rdi
je .L7
rep ret
.L7:
pushq %rax
callabort
the code in (2) should at least imply nonnull argument, since this is
the idiomatic nonnull annotation in c since c99.
(unfortunately it does not work for void* arguments, otherwise i think
it is useful for static analysis, but it won't be used in practice
unless compilers make use of it.)
[Bug target/68059] [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 --- Comment #4 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Nov 24 16:10:55 2015 New Revision: 230820 URL: https://gcc.gnu.org/viewcvs?rev=230820=gcc=rev Log: 2015-11-24 Szabolcs Nagy <szabolcs.n...@arm.com> Backport from mainline 2015-11-23 Szabolcs Nagy <szabolcs.n...@arm.com> PR target/68059 * config/arm/linux-atomic-64bit.c (__write): Rename to... (write): ...this and fix the return type. Modified: branches/gcc-5-branch/libgcc/ChangeLog branches/gcc-5-branch/libgcc/config/arm/linux-atomic-64bit.c
[Bug target/68059] [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 nsz at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #5 from nsz at gcc dot gnu.org --- fixed in r230820 (branch 5) and r230762 (mainline)
[Bug target/68059] [arm] libgcc uses __write to report error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68059 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Nov 23 15:17:55 2015 New Revision: 230762 URL: https://gcc.gnu.org/viewcvs?rev=230762=gcc=rev Log: [ARM] PR target/68059 libgcc should not use __write for printing fatal error libgcc/ PR target/68059 * config/arm/linux-atomic-64bit.c (__write): Rename to... (write): ...this and fix the return type. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/arm/linux-atomic-64bit.c
[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #2 from nsz at gcc dot gnu.org --- note that casting the return value of malloc is an anti-pattern in c and dangerous (unfortunately widespread due to c++). this effectively turns the type-checker off, which is an especially bad idea on a compiler that accepts implicitly declared function calls assuming int return type.
[Bug target/71615] wrong float point result with {-Ofast, -march=native, and valgrind}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71615 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #2 from nsz at gcc dot gnu.org --- see x86 floating-point limitations in valgrind: http://valgrind.org/docs/manual/manual-core.html#manual-core.limits
[Bug middle-end/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #2 from nsz at gcc dot gnu.org ---
int hallo ();
int dummy ()
{
char array[] = "abc";
hallo ();
return __builtin_strlen (array);
}
if strlen is pure then it cannot be evaluated at compile time because hallo
might modify global state, but strlen should be modeled with attribute const,
since the result cannot depend on global state.
i.e. in gcc/builtins.def
DEF_LIB_BUILTIN_CHKP (BUILT_IN_STRLEN, "strlen", BT_FN_SIZE_CONST_STRING,
ATTR_PURE_NOTHROW_NONNULL_LEAF)
the PURE should be CONST.
[Bug target/63359] aarch64: 32bit registers in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #13 from nsz at gcc dot gnu.org ---
there could be a format for reducing porting work between ilp32 and lp64 inline
asm:
asm ("ldr %?0, foo" : "=r"(ptr));
where %?0 behaves like %w0 on ilp32 and %x0 on lp64, which is a bit nicer than
doing preprocessor hacks like
#ifdef __LP64__
#define XW "x"
#else
#define XW "w"
#endif
asm ("ldr %" XW "0, foo" : "=r"(ptr));
[Bug middle-end/71625] missing strlen optimization on different array initialization style
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625 --- Comment #8 from nsz at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #6) > (In reply to Marc Glisse from comment #1) > > Or we could do like clang and improve alias analysis. We should know that > > array doesn't escape and thus that hallo() cannot write to it. > > The strlen pass uses the alias oracle, so the question is why it thinks the > call might affect the array. the optimization fails with const char array[] = "abc"; too (which is why i thought it was about pure strlen depending on global state other than the argument.. static const array works though).
[Bug lto/69271] LTO drops weak binding from aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271 --- Comment #5 from nsz at gcc dot gnu.org --- copy pasting from http://www.openwall.com/lists/musl/2016/01/13/2 (this is musl libc, but glibc has the same issue) lto breaks symbol binding for environ, _environ, ___environ. (they should be weak, without that environ in a main binary has different address than in libc.so) libc.so built with -flto: $ readelf --dyn-syms -W libc.so |grep envi 22: 0028eb90 8 OBJECT GLOBAL DEFAULT 15 __environ 398: 0028eb90 8 OBJECT GLOBAL PROTECTED 15 ___environ 1034: 0028eb90 8 OBJECT GLOBAL PROTECTED 15 _environ 1107: 0028eb90 8 OBJECT GLOBAL DEFAULT 15 environ libc.so without -flto: $ readelf --dyn-syms -W libc.so |grep envi 22: 0028d2d8 8 OBJECT GLOBAL DEFAULT 15 __environ 398: 0028d2d8 8 OBJECT WEAK PROTECTED 15 ___environ 1034: 0028d2d8 8 OBJECT WEAK PROTECTED 15 _environ 1107: 0028d2d8 8 OBJECT WEAK DEFAULT 15 environ
[Bug lto/69271] LTO drops weak binding from aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
--- Comment #6 from nsz at gcc dot gnu.org ---
to complete the example here is a test application:
#include
#include
extern char **environ;
int main()
{
printf(": %p, environ: %p, *environ: %p\n", , environ,
*environ);
clearenv(); // *environ = 0
putenv("TEST=1"); // should change environ
printf(": %p, environ: %p, *environ: %p\n", , environ,
*environ);
}
with correct libc.so:
$ gcc a.c
$ ./a.out
: 0x6008b0, environ: 0x7fffb9b0b478, *environ: 0x7fffb9b0d651
: 0x6008b0, environ: 0x600020, *environ: 0x400649
$ readelf --dyn-sym -W ./a.out |grep envi
2: 006008b0 8 OBJECT WEAK DEFAULT 19 _environ
5: 006008b0 8 OBJECT GLOBAL DEFAULT 19 __environ
7: 006008b0 8 OBJECT WEAK DEFAULT 19 environ
8: 006008b0 8 OBJECT WEAK DEFAULT 19 ___environ
if libc.so is compiled with -flto:
$ gcc a.c
$ ./a.out
: 0x600850, environ: 0x7fff52af6158, *environ: 0x7fff52af6651
: 0x600850, environ: 0x7fff52af6158, *environ: 0
$ readelf --dyn-sym -W ./a.out |grep envi
5: 00600850 8 OBJECT GLOBAL DEFAULT 19 environ
so environ is shared between a.out and libc.so
in the beginning (clearenv worked), but the
address of the symbol () is different
so changing it in the libc did not have an effect
in the main module (putenv failed).
this might be an issue in the static or dynamic
linker but the difference is observable.
[Bug lto/69271] New: LTO drops weak binding from aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
Bug ID: 69271
Summary: LTO drops weak binding from aliases
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i guess it is related to bug 67548
but it happens without -r now.
void foo(void) {}
extern void foo_alias(void) __attribute__((weak, alias("foo")));
int bar = 0;
extern int bar_alias __attribute__((weak, alias("bar")));
compiled as
gcc -shared -fPIC -flto -o foo.so foo.c
$ readelf --dyn-sym -W foo.so |grep foo
8: 0640 6 FUNCGLOBAL DEFAULT 10 foo_alias
9: 0640 6 FUNCGLOBAL DEFAULT 10 foo
$ readelf --dyn-sym -W foo.so |grep bar
4: 002008cc 4 OBJECT GLOBAL DEFAULT 21 bar
6: 002008cc 4 OBJECT GLOBAL DEFAULT 21 bar_alias
without -flto i get the expected
$ readelf --dyn-sym -W foo.so |grep foo
8: 0640 7 FUNCWEAK DEFAULT 10 foo_alias
9: 0640 7 FUNCGLOBAL DEFAULT 10 foo
$ readelf --dyn-sym -W foo.so |grep bar
4: 002008cc 4 OBJECT GLOBAL DEFAULT 21 bar
6: 002008cc 4 OBJECT WEAK DEFAULT 21 bar_alias
this silently breaks the libc if it's compiled with lto
my gcc version is 6.0.0 20160113, tested on x86_64 and aarch64 targets.
[Bug lto/69271] LTO drops weak binding from aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271 nsz at gcc dot gnu.org changed: What|Removed |Added Version|6.0 |5.3.1 --- Comment #1 from nsz at gcc dot gnu.org --- hm it happens on gcc-5 too, gcc-49 is ok.
[Bug driver/69690] New: -pg -fomit-frame-pointer fails with error even if -pg does not depend on frame pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69690
Bug ID: 69690
Summary: -pg -fomit-frame-pointer fails with error even if -pg
does not depend on frame pointers
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
common cc1 options in gcc/gcc.c has
"%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}"
but at least on arm and aarch64 -pg does not depend on the frame pointer.
in fact there is no frame pointer by default and -pg works fine,
however requesting -fomit-frame-pointer explicitly fails with
arm-none-linux-gnueabihf-gcc: error: -pg and -fomit-frame-pointer are
incompatible
this logic seems to be there since ancient times:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=11ce684d779b50cf49fa1a9216e55c2dca06b4fc
[Bug middle-end/69854] New: [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854 Bug ID: 69854 Summary: [6 regression] ICE: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- Created attachment 37725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37725=edit test case gcc -frounding-math -Ofast -c t.c t.c: In function 'acos': t.c:62:1: internal compiler error: tree check: expected class 'constant', have 'binary' (plus_expr) in generic_simplify_65, at generic-match.c:3110 } ^ 0xda99d7 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) S/gcc/tree.c:9688 0x5b706c tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) S/gcc/tree.h:3129 0x5b706c generic_simplify_65 B/gcc/generic-match.c:3110 0xf20cf5 generic_simplify_PLUS_EXPR B/gcc/generic-match.c:9662 0xf4213d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) B/gcc/generic-match.c:25902 0x84b7be fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) S/gcc/fold-const.c:9235 0x856eaa fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) S/gcc/fold-const.c:12451 0xd3a29f find_tail_calls S/gcc/tree-tailcall.c:561 0xd39bff find_tail_calls S/gcc/tree-tailcall.c:442 0xd3ae51 tree_optimize_tail_calls_1 S/gcc/tree-tailcall.c:982 Please submit a full bug report, with preprocessed source if appropriate. gcc version 6.0.0 20160217 (experimental) (GCC) i can reproduce it on arm, aarch64 and x86_64 with the attached test case. (found while building acos.c in musl libc with CFLAGS+=-Ofast, the test case is preprocessed and somewhat cleaned up, it's target independent)
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 nsz at gcc dot gnu.org changed: What|Removed |Added CC||anthony.ajw at gmail dot com --- Comment #13 from nsz at gcc dot gnu.org --- *** Bug 70298 has been marked as a duplicate of this bug. ***
[Bug libstdc++/70298] std::call_once hangs on second call if first threw an exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70298 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nsz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from nsz at gcc dot gnu.org --- i think this is the same as 66146, i'll add an update comment there. *** This bug has been marked as a duplicate of bug 66146 ***
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #14 from nsz at gcc dot gnu.org --- call_once is implemented on top of pthread_once in libstdc++ but pthead_once is not exception safe, only cancellation safe and it cannot be both at the same time in glibc with the current cancellation implementation (although there is ongoing work to fix that). in general this is problematic because it relies on an interface contract that pthread_once does not provide, so libstdc++ should fix it even if glibc makes pthread_once exception safe. (i was told that the underlying implementation is visible through "native handles" so a pthread-independent call_once implementation is problematic, this sounds to me like a c++ defect, such handles probably should not be exposed by libstdc++, it will break whenever there is divergence between posix and c++ requirements.. and there are plenty of that already.)
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #3 from nsz at gcc dot gnu.org ---
simplified a bit further:
void foo(void);
int vfork(void);
int *p;
void bar(void)
{
foo();
*p = vfork();
}
[Bug tree-optimization/71104] New: [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
Bug ID: 71104
Summary: [7 Regression] ICE: verify_ssa failed (with vfork /
error: definition in block 3 does not dominate use in
block 7 )
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
found this while cross compiling busybox to aarch64, i think it depends on
vfork being special.
gcc version 7.0.0 20160512
(trunk r236177)
$ cat a.c
struct globals { int helper_pid; };
extern struct globals *const ptr;
void foo(int);
int vfork(void);
void bar(void)
{
foo(0);
(*ptr).helper_pid = ({ int pid = vfork(); if (pid < 0) foo(0); pid; });
}
$ aarch64-none-linux-gnu-gcc -c a.c
a.c: In function 'bar':
a.c:12:1: error: definition in block 3 does not dominate use in block 7
}
^
for SSA_NAME: ptr.0_1 in statement:
# .MEM_12 = VDEF <.MEM_4>
ptr.0_1->helper_pid = _11;
a.c:12:1: internal compiler error: verify_ssa failed
0xd25da2 verify_ssa(bool, bool)
/w/src/gcc/gcc/tree-ssa.c:1039
0xa5be0d execute_function_todo
/w/src/gcc/gcc/passes.c:1971
0xa5c77b execute_todo
/w/src/gcc/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021 --- Comment #4 from nsz at gcc dot gnu.org --- this might be a different issue, but then i'm not sure how you made the gcc build to use the alternate glibc path. can you attach the libatomic/testsuite/Makefile (with the CC etc variables set)? i think the atomic tests should work without -pthread and i think libgomp just happens to pass because -fopenmp implies -pthread.
[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- i think target lib tests are broken in gcc (other than libstdc++ and libgfortran). if the build-sysroot paths were used then the right libc would be linked. but CC (with all the necessary flags) is not passed from make to the test system, instead dejagnu find_gcc is used and some heuristics to reconstruct the -B etc flags, and thus the build sysroot is missing. (e.g. getenv CC instead of find_gcc would be a correct fix in libatomic.exp.. +export CC in the makefile). others seem to have run into this too, but apparently it was not fixed: https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01181.html (the libstdc++ solution is also less than elegant: it generates a shell script that knows the paths/flags and call that repeatedly from the dejagnu tcl code.. instead of just passing the envvars from make to runtest) all target libs with tests need this fix when --with-build-sysroot is used.
[Bug c/71929] New: libcilkrts build failure because broken __cilkrts_yield and __cilkrts_idle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71929 Bug ID: 71929 Summary: libcilkrts build failure because broken __cilkrts_yield and __cilkrts_idle Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- os-unix.c is broken on *linux-musl targets. the portable way to yield is sched_yield, this should be called on all platforms including linux, except on systems where it does not exist (only __MIC__). pthread_yield should not be called on *linux-gnu either. sched_yield is declared in sched.h so it should be included on all targets. ../../../src_toolchain/libcilkrts/runtime/os-unix.c: In function '__cilkrts_yield': ../../../src_toolchain/libcilkrts/runtime/os-unix.c:471:5: warning: implicit declaration of function 'pthread_yield'; did you mean 'pthread_self'? [-Wimplicit-function-declaration] pthread_yield(); ^
[Bug testsuite/71931] New: build sysroot flags are not passed to target lib tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71931 Bug ID: 71931 Summary: build sysroot flags are not passed to target lib tests Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- when gcc is built --with-build-sysroot then $CC for the target libs includes --sysroot, but when the test is run for these target libs CC=xgcc is used without --sysroot libstdc++ tests have special workaround to pass build time CC and CFLAGS settings to the test system, same for libgfortran, but libatomic or libgomp tests fail when --with-build-sysroot is used. it was reported earlier but i could not find it in bugzilla: https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01181.html the root cause is that the dejagnu 'find_gcc' function is used as CC in the tests which is wrong if any special flag (like --sysroot) is needed for compilation/linking.
[Bug c/71928] New: installed libcilkrts.so has RPATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71928 Bug ID: 71928 Summary: installed libcilkrts.so has RPATH Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- installed libcilkrts.so has an RPATH setting that breaks when a cross toolchain is moved around or cross testing a toolchain. installed libraries should not have RPATH setting.
[Bug testsuite/71933] New: plugin tests fail when host!=target but tests are run locally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71933 Bug ID: 71933 Summary: plugin tests fail when host!=target but tests are run locally Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- if the test system is run locally (unix.exp) then LD_LIBRARY_PATH set during compilation and linking. this affects the dynamic linking of gcc and ld, not just the linking and execution of the test binary. normally this is not a problem because gcc does not depend on target libs that can be confused with host libraries (other than the libc), but plugins do. so glibc to musl cross compiler plugin tests fail. (i think other cross compilers that can be tested without remote target board setup would also fail.) gcc depends on host libc and the plugin.so depends on host libc, libgcc_s and libstdc++, but the dynamic linker finds the target libs first. (musl libc.so and glibc .so happen to have different name so plain gcc uses the right libc, but loading the plugin deps fail which depend on libc.so instead of libc.so.6.) i think only LD_RUN_PATH should be set for compilation and linking. example failures when running make check-gcc RUNTESTFLAGS=plugin.exp FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so (test for excess errors) Excess errors: cc1: error: cannot load plugin ./selfassign.so /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header FAIL: gcc.dg/plugin/ggcplug-test-1.c -fplugin=./ggcplug.so (test for excess errors) Excess errors: cc1: error: cannot load plugin ./ggcplug.so /usr/lib/x86_64-linux-gnu/libc.so: invalid ELF header
[Bug pch/71934] New: pch cannot be disabled so gcc cannot be position independent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934 Bug ID: 71934 Summary: pch cannot be disabled so gcc cannot be position independent Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- gcc should be possible to build as PIE by disabling PCH. (e.g. for running gcc natively on an fdpic target) some users might not care about PCH, but want PIE gcc, making PCH position independent can make it slower, but optionally disabling it should be non-controversial.
[Bug testsuite/71931] build sysroot flags are not passed to target lib tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71931 --- Comment #1 from nsz at gcc dot gnu.org --- a workaround is passing EXTRA_DEJAGNU_SITE_CONFIG=foo.exp to make, where foo.exp has set GCC_UNDER_TEST "build-dir/gcc/xgcc -Bbuild-dir/gcc --sysroot build-sysroot"
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- on a posix platform pthread_mutex_destroy should be called for a mutex if its life time ends, so the ifdef logic seems wrong (the initializer does not make a difference).
[Bug libstdc++/71684] Memory leak with std::mutex and std::lock_guard on freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71684 --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #3) > (In reply to nsz from comment #1) > > on a posix platform pthread_mutex_destroy should be called for a mutex if > > its life time ends, so the ifdef logic seems wrong (the initializer does not > > make a difference). > > I don't think that's clear from the POSIX spec. In previous versions > PTHREAD_MUTEX_INITIALIZER was only specified to be valid for statically > allocated objects, which live for the lifetime of the program and so there's > typically no need (or sensible time) to destroy them. > > http://austingroupbugs.net/view.php?id=70#c127 changed the rules > so now you can use the initializer for automatic objects, and structure > members, but it's unclear whether you do need to use pthread_mutex_destroy > on them. > Maybe POSIX should clarify. > i see. > On some older versions of FreeBSD using PTHREAD_MUTEX_INITIALIZER and then > pthread_mutex_destroy would segfault, see > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004905.html > > So it's not clear to me that using that combination is a good idea. in the current spec PTHREAD_MUTEX_INITIALIZER must have the same effect as pthread_mutex_init(,0) without error checks, which means pthread_mutex_destroy should work accordingly (and indeed pthread_mutex_lock should not fail with ENOMEM either). so this may need platform specific workarounds.
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 --- Comment #5 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Feb 7 12:47:51 2017 New Revision: 245246 URL: https://gcc.gnu.org/viewcvs?rev=245246=gcc=rev Log: [ARM][PR target/78945] Fix libatomic on armv7-m libatomic/ Backport from mainline: 2017-01-30 Szabolcs Nagy <szabolcs.n...@arm.com> PR target/78945 * config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32. Modified: branches/gcc-6-branch/libatomic/ChangeLog branches/gcc-6-branch/libatomic/config/arm/exch_n.c
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 Known to fail||5.4.0, 6.3.0 --- Comment #7 from nsz at gcc dot gnu.org --- fixed on trunk and backported to gcc-5 and gcc-6 branches.
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 --- Comment #6 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Feb 7 12:51:00 2017 New Revision: 245247 URL: https://gcc.gnu.org/viewcvs?rev=245247=gcc=rev Log: [ARM][PR target/78945] Fix libatomic on armv7-m libatomic/ Backport from mainline: 2017-01-30 Szabolcs Nagy <szabolcs.n...@arm.com> PR target/78945 * config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32. Modified: branches/gcc-5-branch/libatomic/ChangeLog branches/gcc-5-branch/libatomic/config/arm/exch_n.c
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 --- Comment #3 from nsz at gcc dot gnu.org --- (In reply to Ramana Radhakrishnan from comment #2) > A simple patch would be to check for __ARM_FEATURE_SAT in all those macros > in exch_n.c along with HAVE_STREXB etc .. __ARM_FEATURE_SIMD32 seems to be the right feature test macro, (_SAT is defined on armv7-m) and with that libatomic compiles.
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 --- Comment #4 from nsz at gcc dot gnu.org --- Author: nsz Date: Mon Jan 30 11:34:13 2017 New Revision: 245023 URL: https://gcc.gnu.org/viewcvs?rev=245023=gcc=rev Log: [ARM][PR target/78945] Fix libatomic on armv7-m ARM libatomic inline asm uses sel, uadd8, uadd16 instructions which are only available if __ARM_FEATURE_SIMD32 is defined. libatomic/ 2017-01-30 Szabolcs Nagy <szabolcs.n...@arm.com> PR target/78945 * config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32. Modified: trunk/libatomic/ChangeLog trunk/libatomic/config/arm/exch_n.c
[Bug target/77894] Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894 --- Comment #3 from nsz at gcc dot gnu.org --- currently --enable-gnu-indirect-function enables its use in gcc target libs like libatomic which breaks if the libc has no support for it. (In reply to Florian Weimer from comment #2) > (In reply to nsz from comment #1) > > the ifunc abi still has many problems and i don't think it's possible to > > detect > > dynamic linker support for cross compilation so if it is enabled do it only > > if > > the default libc is glibc (e.g. on linux musl, bionic and uclibc does not > > plan to implement it). > > Will GCC generate IFUNCs although the attribute is never used? > > If it is harmless to enable it, I'd suggest to do so unconditionally, so > that people can cross-build glibc on any Linux system using the system > compiler. currently --enable-gnu-indirect-function enables ifuncs in gcc target libs like libatomic, which breaks if the libc has no support for it (i think this is a significant abi commitment between gcc and libc which is not justified).
[Bug other/77894] Enable GNU indirect function support by default as it will be used in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- the ifunc abi still has many problems and i don't think it's possible to detect dynamic linker support for cross compilation so if it is enabled do it only if the default libc is glibc (e.g. on linux musl, bionic and uclibc does not plan to implement it).
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 --- Comment #2 from nsz at gcc dot gnu.org --- (In reply to Martin Sebor from comment #1) > sprintf(foo, "zz%.4s", s.buf); > > Please let me know if this isn't sufficient to resolve the problem report. in my case truncation is fatal error so using precision is not useful (other than suppressing the warning) and has a runtime cost (extra arg passing for %.*s).
[Bug c/77708] New: -Wformat-length %s warns for snprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708
Bug ID: 77708
Summary: -Wformat-length %s warns for snprintf
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
snprintf does not do oob memory access, so if the return value is checked then,
there should be no buffer overflow warning.
$ cat a.c
int snprintf (char*, __SIZE_TYPE__, const char*, ...);
struct { char buf[12]; } s;
int f(void)
{
char foo[7];
return snprintf(foo, sizeof foo, "zz%s", s.buf) >= sizeof foo;
}
$ gcc -c -Wall a.c
a.c: In function 'f':
a.c:8:10: warning: '%s' directive output may be truncated writing between 0 and
11 bytes into a region of size 5 [-Wformat-length=]
return snprintf(foo, sizeof foo, "zz%s", s.buf) >= sizeof foo;
^~~~
a.c:8:10: note: format output between 3 and 14 bytes into a destination of size
7
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 nsz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from nsz at gcc dot gnu.org --- (In reply to nsz from comment #2) > in my case truncation is fatal error so using precision is not useful (other > than suppressing the warning) and has a runtime cost (extra arg passing for > %.*s). nevermind, i'll just use snprintf.
[Bug c/77690] -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690 nsz at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from nsz at gcc dot gnu.org --- (In reply to Martin Sebor from comment #4) > Note that with snprintf GCC issues > > warning: ‘%s’ directive output may be truncated writing between 1 and 11 > bytes into a region of size 5 > > This is also by design though I'm on the fence about warning at the same > level or under the same option as for sprintf. > i opened another bug about snprintf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77708 i think warning for snprintf is almost surely a false positive, that is hard to suppress (and the suppression code is not idiomatic).
[Bug c/77690] New: -Wformat-length %s false positive after strlen check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77690
Bug ID: 77690
Summary: -Wformat-length %s false positive after strlen check
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
there is no obvious way to silence the sprintf %s warning.
(this currently breaks the gdb build)
$ cat a.c
int sprintf (char*, const char*, ...);
struct { char buf[12]; } s;
void f(void)
{
char foo[7];
if (__builtin_strlen(s.buf) > 3) // this check does not help
return;
sprintf(foo, "zz%s", s.buf);
}
$ gcc -Wall -c a.c
a.c: In function 'f':
a.c:10:19: warning: '%s' directive writing between 0 and 11 bytes into a region
of size 5 [-Wformat-length=]
sprintf(foo, "zz%s", s.buf);
^~ ~
a.c:10:3: note: format output between 3 and 14 bytes into a destination of size
7
sprintf(foo, "zz%s", s.buf);
^~~
[Bug libfortran/78314] New: [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 Bug ID: 78314 Summary: [aarch64] ieee_support_halting does not report unsupported fpu traps correctly Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- on aarch64 trapping fpu exceptions are optional, but ieee_support_halting(except_flag) does not report this correctly, so fortran tests that depend on trap bit changes would fail: Program aborted. Backtrace: #0 0x2472D3 FAIL: gfortran.dg/ieee/ieee_6.f90 -Os execution test
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #4 from nsz at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) > There are other reasons why using static libraries does not make sense for > libpthread. i can't immediately think of any, can you give a hint?
[Bug libgcc/78017] New: weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Bug ID: 78017 Summary: weak reference usage in gthr-posix.h (__gthread*) is broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- there seem to be no open bug for the issue discussed in https://gcc.gnu.org/ml/libstdc++/2014-11/msg00122.html i think libstdc++, libgfortran and libgcov are affected. libgcc/gthr-posix.h uses weak references for the pthread api to 1) detect single-threadedness 2) use pthread api without adding -lpthread dependency. this does not work a) with static linking: because 1) fails on the target: single threaded execution can be assumed if pthread_create and thrd_create are not referenced (on targets without libpthread dlopen support), but the gthr logic only checks pthread_create (on bionic) or pthread_cancel (on some targets as a misguided attempt to avoid detecting threads because of ldpreloaded pthread wrappers which "seem unlikely" to define pthread_cancel). symbols required by libstdc++ may be missing because of 2), (causing hard to debug runtime crashes): redhat puts all of libpthread into a single .o, others use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive linker flags as a workaround, but this should not be needed: if libstdc++.a semantically requires strong references then those references must be strong (the calls may be elided using the detection above). b) if there is dlopen support for libpthread then single-threadedness can change at runtime, so any check would break code like std::mutex m; m.lock(); dlopen(.. something that starts threads and use m ..) m.unlock(); various targets explicitly opt out from the weak ref hacks, (using gcc configure time hacks), i think instead the gthr logic should be safe by default: assume multi-threaded execution by default and only try to optimize the single threaded case when it is guaranteed to be safe.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #2 from nsz at gcc dot gnu.org --- i see the glibc threads linked from https://sourceware.org/bugzilla/show_bug.cgi?id=5784 but there are other libcs with static linking support, so even if weakrefs worked on glibc (now they don't) this would be a gcc bug on other targets.. when this came up with musl libc it required fair amount of debugging and i see other cases where people spent time on this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960 so i think it is worth changing the logic.
[Bug libfortran/78449] compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78449 --- Comment #1 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Nov 22 10:06:05 2016 New Revision: 242688 URL: https://gcc.gnu.org/viewcvs?rev=242688=gcc=rev Log: [PR libgfortran/78449] XFAIL ieee_8.f90 on aarch64 and arm ARM and AArch64 may not support trapping so runtime and compile time check can differ. gcc/testsuite/ PR libgfortran/78449 * gfortran.dg/ieee/ieee_8.f90 (aarch64*gnu, arm*gnu*): Mark xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ieee/ieee_8.f90
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 nsz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from nsz at gcc dot gnu.org --- waiting with the backport for bug 78449.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Nov 16 17:27:04 2016 New Revision: 242505 URL: https://gcc.gnu.org/viewcvs?rev=242505=gcc=rev Log: [PR libgfortran/78314] Fix ieee_support_halting ieee_support_halting only checked the availability of status flags, not trapping support. On some targets the later can only be checked at runtime: feenableexcept reports if enabling traps failed. So check trapping support by enabling/disabling it. Updated the test that enabled trapping to check if it is supported. gcc/testsuite/ PR libgfortran/78314 * gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting. libgfortran/ PR libgfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config/fpu-glibc.h
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 nsz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 Known to fail||5.4.0, 6.2.0
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #5 from nsz at gcc dot gnu.org --- i plan to backport the fix, but it seems my fix is not correct and broke the ieee_8.fp90 test.
[Bug libfortran/78449] New: compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78449 Bug ID: 78449 Summary: compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test ) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- on aarch64 and arm trapping support requires runtime check (bug 78314), but it seems fortran may need consistent result for ieee_support_halting at compile time and runtime (in which case the correct behaviour is to always return false on targets where there might be no support).
[Bug target/70191] libatomic library does not have lock-free implementation for 16-bytes data object on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70191 nsz at gcc dot gnu.org changed: What|Removed |Added Target||i386-*, x86_64-* Last reconfirmed||2016-11-29 CC||nsz at gcc dot gnu.org --- Comment #6 from nsz at gcc dot gnu.org --- affects all x86 targets (except *gnu unless gcc was configured with --disable-gnu-indirect-function ) libatomic needs a portable mechanism to dispatch between incompatible implementations when those can be inlined (or static linked). (currently there is no diagnostic when incompatible use of atomics are linked together which can cause dangerous runtime breakage.)
[Bug target/78945] New: [arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 Bug ID: 78945 Summary: [arm Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: ---
[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78945 nsz at gcc dot gnu.org changed: What|Removed |Added Target||arm-* --- Comment #1 from nsz at gcc dot gnu.org --- building a cross compiler with --with-mode=thumb --with-arch=armv7 fails with /tmp/ccCnEnAK.s:61: Error: selected processor does not support `uadd8 r3,r3,r3' in Thumb mode /tmp/ccCnEnAK.s:63: Error: selected processor does not support `sel r3,r1,r4' in Thumb mode because the asm in libatomic/config/arm/exch_n.c is not compatible with armv7-m.
[Bug c/80237] New: float to double conversion is not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80237
Bug ID: 80237
Summary: float to double conversion is not optimized away
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i get suboptimal code for
__attribute__((noinline))
static float f(float x)
{
return x*x;
}
static double g(float x)
{
return x>0 ? f(x) : x+1.0;
}
float foo(float x)
{
return g(x);
}
i expected a tail call because for float x, (float)(double)x conversion is a
nop, but with -O3 i get
f:
mulss %xmm0, %xmm0
ret
foo:
ucomiss .LC0(%rip), %xmm0
jbe .L8
callf / why not tail call?
cvtss2sd%xmm0, %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.L8:
cvtss2sd%xmm0, %xmm0
addsd .LC1(%rip), %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.LC0:
.long 0
.LC1:
.long 0
.long 1072693248
[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245
--- Comment #3 from nsz at gcc dot gnu.org ---
note that this may cause the omission of underflow, overflow and inexact
exceptions too (so in principle it's an invalid transformation even
without -frounding-math but with -ftrapping-math ):
float x,y;
void f(void)
{
x = 0x1p-1000; // truncated to 0
y = 0x1p1000; // truncated to inf
}
[Bug target/80450] New: -std=c99 breaks -frounding-math on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80450
Bug ID: 80450
Summary: -std=c99 breaks -frounding-math on i686
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
on i686 the following code is miscompiled with -std=c99:
void f() { volatile double x = 0x1p-1000*0x1p-1000; }
with -S -O2 -frounding-math:
f:
subl$20, %esp
fldl.LC0// 0x1p-1000
fmul%st(0), %st
fstpl 8(%esp)
addl$20, %esp
ret
with -S -O2 -frounding-math -std=c99 a.c:
f:
subl$20, %esp
fldz// unconditional 0.0
fstpl 8(%esp)
addl$20, %esp
ret
note that there is double rounding (first to 80bit floats then to 64bit),
but with upward rounding the result is non-zero either way so the -std=c99
code is wrong (in c99 only static initializers are evaluated in default fenv).
[Bug target/81800] New: [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 Bug ID: 81800 Summary: [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- recently lrint is inlined as frintx/fcvtzs on aarch64, but this is not valid on ilp32 where a non-integer double may be out-of-bound for a long and then the first instruction raises the inexact, the second one raises invalid exception and only the invalid should be raised in this case. so the inlining is only valid with -fno-trapping-math i think. gcc -O3 -mabi=ilp32 -S -fno-math-errno b.c compiles to f: frintx d0, d0 fcvtzs w0, d0 ret (the patch for the equivalent bug in glibc is https://sourceware.org/ml/libc-alpha/2017-08/msg00299.html which saves and restores the fenv around the instructions.)
[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #1 from nsz at gcc dot gnu.org ---
b.c:
long f(double x)
{
return __builtin_lrint(x);
}
and an example value where the exceptions are wrong is 0x1p32 + 0.5
[Bug c++/81846] New: [arm] constexpr ICE: in cxx_eval_constant_expression, at cp/constexpr.c:4556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81846
Bug ID: 81846
Summary: [arm] constexpr ICE: in cxx_eval_constant_expression,
at cp/constexpr.c:4556
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
following c++14 code fails to compile with ice on arm targets:
class A {
public:
constexpr A() {
return;
}
};
A mwi;
$ arm-none-linux-gnueabihf-g++ -S foo.cpp
foo.cpp:8:3: in constexpr expansion of ‘mwi.A::A()’
foo.cpp:8:3: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:4556
A mwi;
^~~
...
the assert is
4554case GOTO_EXPR:
4555 *jump_target = TREE_OPERAND (t, 0);
4556 gcc_assert (breaks (jump_target) || continues (jump_target));
4557 break;
the -tree-original output is unexpected on arm:
;; Function constexpr A::A() (null)
;; enabled by -tree-original
{
// predicted unlikely by goto predictor.;
goto ;
}
:;
return this;
e.g. on aarch64 it's:
;; Function constexpr A::A() (null)
;; enabled by -tree-original
{
return;
}
[Bug c++/81847] New: ICE: in finish_expr_stmt, at cp/semantics.c:678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81847
Bug ID: 81847
Summary: ICE: in finish_expr_stmt, at cp/semantics.c:678
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
following code fails with ice with gcc 7.1.1:
constexpr int nlz(int x) {
return __builtin_constant_p(x) ? 0 : 1;
}
struct A {
constexpr A() { nlz(0); }
};
constexpr A operator-(A x) { return x; }
constexpr A bar() {
constexpr A x;
A y = -x;
return y;
}
$ g++ -S bar.cpp
bar.cpp: In function 'constexpr A bar()':
bar.cpp:13:10: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:678
A y = -x;
^
...
[Bug c/80756] missing diagnostic on non-constant expression with function call such as fabs or fma in initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #3 from nsz at gcc dot gnu.org --- fabs and fma identifiers are reserved for the implementation and it is valid to treat them as constant expression in initializers based on c99 6.6p10 i think the gcc behaviour is reasonable.
[Bug tree-optimization/80854] New: hot path is slowed down when the cold return path is merged into it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80854
Bug ID: 80854
Summary: hot path is slowed down when the cold return path is
merged into it
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
i see subomptimal code gen for
float foo (float x)
{
if (__builtin_expect (x > 0, 0))
if (x>2) return 0;
return x*x;
}
because the return path merge causes extra register move in the hot path
https://godbolt.org/g/AZxxrR
x86_64:
foo:
pxor%xmm1, %xmm1
ucomiss %xmm1, %xmm0
ja .L8
.L2:
movaps %xmm0, %xmm1 // extra reg move
mulss %xmm0, %xmm1
.L1:
movaps %xmm1, %xmm0 // extra reg move
ret
.L8:
ucomiss .LC1(%rip), %xmm0
jbe .L2
jmp .L1 // need not jmp back
.LC1:
.long 1073741824
aarch64:
foo:
fcmpe s0, #0.0
bgt .L8
.L2:
fmuls1, s0, s0
.L1:
fmovs0, s1 // extra reg move
ret
.p2align 3
.L8:
fmovs2, 2.0e+0
moviv1.2s, #0
fcmpe s0, s2
ble .L2
b .L1// need not jmp back
i wonder if gcc could do better if there is information about hot/cold paths
(by not merging the hot/cold return paths in some cases).
[Bug c++/82025] New: ICE: in finish_expr_stmt, at cp/semantics.c:678
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82025
Bug ID: 82025
Summary: ICE: in finish_expr_stmt, at cp/semantics.c:678
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
following code fails with ice with gcc 7.2.1 and gcc 6.3.0 (works on gcc 8):
constexpr int nlz(int x) {
return __builtin_constant_p(x) ? 0 : 1;
}
struct A {
constexpr A() { nlz(0); }
};
constexpr A operator-(A x) { return x; }
constexpr A bar() {
constexpr A x;
A y = -x;
return y;
}
$ g++ -S bar.cpp
bar.cpp: In function 'constexpr A bar()':
bar.cpp:13:10: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:678
A y = -x;
^
0x695d33 finish_expr_stmt(tree_node*)
/S/gcc/cp/semantics.c:678
0x5c9e3f initialize_local_var
/S/gcc/cp/decl.c:6612
0x5c9e3f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/S/gcc/cp/decl.c:7173
0x65d60b cp_parser_init_declarator
/S/gcc/cp/parser.c:19403
0x65dd97 cp_parser_simple_declaration
/S/gcc/cp/parser.c:12786
0x65e97f cp_parser_block_declaration
/S/gcc/cp/parser.c:12611
0x65f2a7 cp_parser_declaration_statement
/S/gcc/cp/parser.c:12221
0x63fa27 cp_parser_statement
/S/gcc/cp/parser.c:10708
0x640e8b cp_parser_statement_seq_opt
/S/gcc/cp/parser.c:11040
0x640f4f cp_parser_compound_statement
/S/gcc/cp/parser.c:10994
0x652b43 cp_parser_function_body
/S/gcc/cp/parser.c:21455
0x652b43 cp_parser_ctor_initializer_opt_and_function_body
/S/gcc/cp/parser.c:21493
0x6594a3 cp_parser_function_definition_after_declarator
/S/gcc/cp/parser.c:26284
0x65da47 cp_parser_function_definition_from_specifiers_and_declarator
/S/gcc/cp/parser.c:26196
0x65da47 cp_parser_init_declarator
/S/gcc/cp/parser.c:19182
0x65dd97 cp_parser_simple_declaration
/S/gcc/cp/parser.c:12786
0x65e97f cp_parser_block_declaration
/S/gcc/cp/parser.c:12611
0x63c65b cp_parser_declaration
/S/gcc/cp/parser.c:12509
0x662eb3 cp_parser_declaration_seq_opt
/S/gcc/cp/parser.c:12385
0x6631e3 cp_parser_translation_unit
/S/gcc/cp/parser.c:4368
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug lto/81925] New: early lto debug link failure on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81925 Bug ID: 81925 Summary: early lto debug link failure on aarch64_be Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 42025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42025=edit save-temps and other output files following works without -g, with -g linking fails, readelf reports errors on linker input, files are attached in a tar: $ ./aarch64_be-none-elf-gcc -flto -specs=rdimon.specs -g a.c -v -save-temps Using built-in specs. Reading specs from /home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/lib/rdimon.specs rename spec lib to libc COLLECT_GCC=./aarch64_be-none-elf-gcc COLLECT_LTO_WRAPPER=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/lto-wrapper Target: aarch64_be-none-elf Configured with: /home/szabolcs/w/b/src/gcc/configure --target=aarch64_be-none-elf --prefix=/home/szabolcs/w/b/build-aarch64_be-none-elf/install --with-gmp=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools --with-mpfr=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools --with-mpc=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools --with-isl=/home/szabolcs/w/b/build-aarch64_be-none-elf/host-tools --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib : (reconfigured) Thread model: single gcc version 8.0.0 20170821 (experimental) (unknown) COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps' '-mbig-endian' '-mabi=lp64' /home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/cc1 -E -quiet -v a.c -mbig-endian -mabi=lp64 -flto -g -fworking-directory -fpch-preprocess -o a.i ignoring nonexistent directory "/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/sys-include" #include "..." search starts here: #include <...> search starts here: /home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/include /home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/include-fixed /home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/include End of search list. COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps' '-mbig-endian' '-mabi=lp64' /home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/cc1 -fpreprocessed a.i -quiet -dumpbase a.c -mbig-endian -mabi=lp64 -auxbase a -g -version -flto -o a.s GNU C11 (unknown) version 8.0.0 20170821 (experimental) (aarch64_be-none-elf) compiled by GNU C version 6.3.0 20170406, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2, isl version isl-0.15-2-g00f2e0ca-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C11 (unknown) version 8.0.0 20170821 (experimental) (aarch64_be-none-elf) compiled by GNU C version 6.3.0 20170406, GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.2, isl version isl-0.15-2-g00f2e0ca-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: c56b6c42715c65bbcbf1872ac0fefbbe COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps' '-mbig-endian' '-mabi=lp64' /home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/bin/as -EB -mabi=lp64 -o a.o a.s COMPILER_PATH=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/bin/ LIBRARY_PATH=/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/:/home/szabolcs/w/b/build-aarch64_be-none-elf/install/lib/gcc/aarch64_be-none-elf/8.0.0/../../../../aarch64_be-none-elf/lib/ COLLECT_GCC_OPTIONS='-flto' '-specs=rdimon.specs' '-g' '-v' '-save-temps' '-mbig-endian' '-mabi=lp64' /home/szabolcs/w/b/build-aarch64_be-none-elf/install/libexec/gcc/aarch64_be-none-elf/8.0.0/collect2 -plugin /home/szabolcs/w/b/build-aarch64_be
[Bug tree-optimization/81982] New: [arm] libstdc++ miscompiled, constant propagation is broken on native arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81982
Bug ID: 81982
Summary: [arm] libstdc++ miscompiled, constant propagation is
broken on native arm
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
Created attachment 42043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42043=edit
preprocessed libstdc++/libsupc++/guard.cc
since
https://gcc.gnu.org/viewcvs/gcc?view=revision=251260
i see gcc miscompiling guard.cc, but only if the gcc is
native arm-*-linux-gnu, a cross compiler compiles it correctly.
the difference between the native and cross compiler
first shows up at ccp1 in -ftree-dump-all, so i
suspect that tree-ssa-ccp.c got miscompiled in the
native gcc, but i'll need to investigate that further,
meanwhile the diff of the ccp1 output is
--- guard.ii.032t.ccp1.good 2017-08-24 18:41:32.875600385 +0100
+++ guard.ii.032t.ccp1.bad 2017-08-24 18:41:23.503495848 +0100
@@ -235,7 +235,21 @@
;; Function __cxxabiv1::__cxa_guard_acquire (__cxa_guard_acquire,
funcdef_no=227, decl_uid=6043, cgraph_uid=225, symbol_order=227)
+Folding predicate 0 != 0 to 0
+Folding predicate 0 != 0 to 0
+Folding predicate 1 != 0 to 1
+Folding predicate 0 != 0 to 0
+Folding predicate 1 != 0 to 1
+Removing basic block 7
+Removing basic block 9
+Removing basic block 18
+Removing basic block 13
Removing basic block 16
+Merging blocks 6 and 8
+Merging blocks 11 and 12
+Removing basic block 14
+Merging blocks 6 and 10
+Merging blocks 11 and 15
__cxxabiv1::__cxa_guard_acquire (__guard * g)
{
int D.13418;
@@ -254,8 +268,6 @@
int _1;
unsigned int pending_bit.3_2;
unsigned int newv.8_6;
- bool _7;
- int _11;
int _12;
bool _21;
bool retval.1_22;
@@ -263,8 +275,6 @@
int _25;
unsigned char _28;
unsigned char _30;
- bool retval.2_34;
- bool retval.7_37;
bool _47;
int _48;
int _50;
@@ -274,13 +284,7 @@
char _55;
int _56;
__complex__ unsigned int _74;
- unsigned int _75;
- unsigned int _76;
- int _77;
__complex__ unsigned int _80;
- unsigned int _81;
- unsigned int _82;
- int _83;
[100.00%] [count: INV]:
_30 = __atomic_load_1 (g_18(D), 2);
@@ -293,7 +297,7 @@
[0.00%] [count: INV]:
// predicted unlikely by early return (on trees) predictor.
- goto ; [INV] [count: INV]
+ goto ; [INV] [count: INV]
[100.00%] [count: INV]:
_47 = __gthrw___pthread_key_create != 0B;
@@ -304,7 +308,7 @@
if (retval.1_22 != 0)
goto ; [INV] [count: INV]
else
-goto ; [INV] [count: INV]
+goto ; [INV] [count: INV]
[100.00%] [count: INV]:
__u.__i = 0;
@@ -319,107 +323,50 @@
[0.00%] [count: INV]:
pending_bit.3_2 = (unsigned int) _52;
_74 = ATOMIC_COMPARE_EXCHANGE (g_18(D), 0, pending_bit.3_2, 4, 4, 2);
- _75 = IMAGPART_EXPR <_74>;
- retval.2_34 = (bool) _75;
- _76 = REALPART_EXPR <_74>;
- _77 = VIEW_CONVERT_EXPR(_76);
- if (retval.2_34 != 0)
+ if (_52 == 0)
goto ; [INV] [count: INV]
else
goto ; [INV] [count: INV]
[0.00%] [count: INV]:
- // predicted unlikely by early return (on trees) predictor.
- goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- if (_77 == 1)
-goto ; [INV] [count: INV]
- else
-goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- // predicted unlikely by early return (on trees) predictor.
- goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- if (_52 == _77)
-goto ; [INV] [count: INV]
- else
-goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- newv_35 = _50 | _77;
- newv.8_6 = (unsigned int) newv_35;
- _80 = ATOMIC_COMPARE_EXCHANGE (g_18(D), _76, newv.8_6, 4, 4, 2);
- _81 = IMAGPART_EXPR <_80>;
- _7 = (bool) _81;
- _82 = REALPART_EXPR <_80>;
- _83 = VIEW_CONVERT_EXPR(_82);
- retval.7_37 = ~_7;
- if (retval.7_37 != 0)
-goto ; [INV] [count: INV]
- else
-goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- if (_83 == 1)
-goto ; [INV] [count: INV]
- else
-goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- // predicted unlikely by early return (on trees) predictor.
- goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
- if (_83 == 0)
-goto ; [INV] [count: INV]
- else
-goto ; [INV] [count: INV]
-
- [0.00%] [count: INV]:
+ newv.8_6 = (unsigned int) _50;
+ _80 = ATOMIC_COMPARE_EXCHANGE (g_18(D), 0, newv.8_6, 4, 4, 2);
// predicted unlikely by continue predictor.
goto ; [INV] [count: INV]
- [0.00%] [count: INV]:
- # expected_84 = PHI <_77(10), newv_35(14), newv_35(11)>
- syscall (240, g_18(D), 0, expected_84, 0);
+ [0.00%] [count: INV]:
+ syscall (240, g_18(D), 0, 0, 0);
goto ; [INV] [count: INV]
- [0.00%] [count: INV]:
- # _11 = PHI <1(7), 0(9), 0(13)>
- goto ; [INV] [
