public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx @ 2014-12-19 17:11 christian.otterstad at gmail dot com 2015-01-15 9:52 ` [Bug target/64363] " enkovich.gnu at gmail dot com ` (3 more replies) 0 siblings, 4 replies; 5+ messages in thread From: christian.otterstad at gmail dot com @ 2014-12-19 17:11 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 Bug ID: 64363 Summary: Unresolved labels with -fcheck-pointer-bounds and -mmpx Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: christian.otterstad at gmail dot com I believe there is a problem with the -fcheck-pointer-bounds and -mmpx arguments for GCC. gcc test.c -c -std=gnu99 -O2 -Wall -fcheck-pointer-bounds -g -mmpx /tmp/ccugNfJ8.s: Assembler messages: /tmp/ccugNfJ8.s:67: Error: can't resolve `.L5' {*UND* section} - `.L6' {*UND* section} For the following source: #include <stdio.h> int main(int argc, char **argv) { static int array = &&label_B - &&label_A; label_A: printf("%d\n", array); label_B: return 0; } This is derived from code found in vfprintf.c in glibc (after a lot of rewriting). Attempting to compile glibc results in numerous such errors ("can't resolve") of the same type. Omitting -fcheck-pointer-bounds and -mmpx allows it (and all of glibc as well) to compile without errors. Part of the following assembly generated (using -S) is given here: __chkp_zero_bounds: .zero 16 .data .align 4 .type array.2314, @object .size array.2314, 4 array.2314: .long .L5-.L6 .section .text.unlikely No AS version appears to be able to assemble this, as .L5, .L6 doesn't exist anywhere in the assembly source file. At least the following versions appear to have this problem: gcc (GCC) 5.0.0 20141211 (experimental) using GNU assembler (Gentoo 2.24 p1.4) 2.24 gcc (GCC) 5.0.0 20141215 (experimental) using GNU assembler (Gentoo 2.24 p1.4) 2.24 gcc (GCC) 5.0.0 20141216 (experimental) using GNU assembler (Gentoo 2.24 p1.4) 2.24 gcc (GCC) 5.0.0 20141216 (experimental) using GNU assembler (GNU Binutils) 2.25.51.20141215 gcc (GCC) 5.0.0 20141216 (experimental) using GNU assembler (GNU Binutils) 2.25.51.20141216 gcc (GCC) 5.0.0 20140925 (experimental) using GNU assembler (GNU Binutils) 2.24.51.20140422 gcc (GCC) 5.0.0 20141218 (experimental) using GNU assembler (Gentoo 2.24 p1.4) Please note that gcc (GCC) 5.0.0 20140925 (experimental) is the same version provided by Intel (in both source and binary form) to be used experimentally with MPX. https://software.intel.com/en-us/articles/intel-software-development-emulator However I've also tried these other versions to see if the issue happened to be resolved. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx 2014-12-19 17:11 [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx christian.otterstad at gmail dot com @ 2015-01-15 9:52 ` enkovich.gnu at gmail dot com 2015-01-16 13:09 ` ienkovich at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 5+ messages in thread From: enkovich.gnu at gmail dot com @ 2015-01-15 9:52 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 Ilya Enkovich <enkovich.gnu at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |enkovich.gnu at gmail dot com --- Comment #1 from Ilya Enkovich <enkovich.gnu at gmail dot com> --- We copy function to instrument it but static var is initialized using labels from the original function and thus we get unresolved links. Suppose we would get the same problem with non local gotos. Suppose it would be more safe to just don't instrument such functions for now and get back to it at the next stage 1. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx 2014-12-19 17:11 [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx christian.otterstad at gmail dot com 2015-01-15 9:52 ` [Bug target/64363] " enkovich.gnu at gmail dot com @ 2015-01-16 13:09 ` ienkovich at gcc dot gnu.org 2015-01-26 17:09 ` christian.otterstad at gmail dot com 2015-04-16 14:05 ` ienkovich at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: ienkovich at gcc dot gnu.org @ 2015-01-16 13:09 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 --- Comment #2 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Jan 16 13:08:24 2015 New Revision: 219733 URL: https://gcc.gnu.org/viewcvs?rev=219733&root=gcc&view=rev Log: gcc/ PR target/64363 * ipa-chkp.h (chkp_instrumentable_p): New. * ipa-chkp.c: Include tree-inline.h. (chkp_instrumentable_p): New. (chkp_maybe_create_clone): Use chkp_instrumentable_p. Fix processing of not instrumentable functions. (chkp_versioning): Use chkp_instrumentable_p. Warn about not instrumentable functions. * tree-chkp.c (chkp_add_bounds_to_call_stmt): Use chkp_instrumentable_p. * tree-inline.h (copy_forbidden): New. * tree-inline.c (copy_forbidden): Not static anymore. gcc/testsuite/ PR target/64363 * gcc.target/i386/chkp-label-address.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/chkp-label-address.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-chkp.c trunk/gcc/ipa-chkp.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c trunk/gcc/tree-inline.c trunk/gcc/tree-inline.h ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx 2014-12-19 17:11 [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx christian.otterstad at gmail dot com 2015-01-15 9:52 ` [Bug target/64363] " enkovich.gnu at gmail dot com 2015-01-16 13:09 ` ienkovich at gcc dot gnu.org @ 2015-01-26 17:09 ` christian.otterstad at gmail dot com 2015-04-16 14:05 ` ienkovich at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: christian.otterstad at gmail dot com @ 2015-01-26 17:09 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 --- Comment #3 from Christian Otterstad <christian.otterstad at gmail dot com> --- Great, it seems this corrected the issue, but a new problem that didn't appear to exist before seems to have been introduced. I created a new bug issue for it. Bug 64805: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx 2014-12-19 17:11 [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx christian.otterstad at gmail dot com ` (2 preceding siblings ...) 2015-01-26 17:09 ` christian.otterstad at gmail dot com @ 2015-04-16 14:05 ` ienkovich at gcc dot gnu.org 3 siblings, 0 replies; 5+ messages in thread From: ienkovich at gcc dot gnu.org @ 2015-04-16 14:05 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 Ilya Enkovich <ienkovich at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |ienkovich at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Ilya Enkovich <ienkovich at gcc dot gnu.org> --- Fixed ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-16 14:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-19 17:11 [Bug c/64363] New: Unresolved labels with -fcheck-pointer-bounds and -mmpx christian.otterstad at gmail dot com 2015-01-15 9:52 ` [Bug target/64363] " enkovich.gnu at gmail dot com 2015-01-16 13:09 ` ienkovich at gcc dot gnu.org 2015-01-26 17:09 ` christian.otterstad at gmail dot com 2015-04-16 14:05 ` ienkovich at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).