[Bug driver/37786] New: Documentation for `-symbolic' needs fixing
gcc has flags -Bsymbolic and -Bsymbolic-functions which are documented in the usage message. $ gcc -v --help 21 | grep symbolic -Bsymbolic Bind global references locally -Bsymbolic-functionsBind global function references locally However, the info pages are incorrect and incomplete. `-symbolic' Bind references to global symbols when building a shared object. Warn about any unresolved references (unless overridden by the link editor option `-Xlinker -z -Xlinker defs'). Only a few systems support this option. In fact, gcc does not appear to support any such flag `-symbolic'. `-symbolic' should probably be changed to `-Bsymbolic'. Also, please add info documentation for `-Bsymbolic-functions'. A motivating example for these options would be nice as well. (or maybe a link to any corresponding binutils documentation) -- Summary: Documentation for `-symbolic' needs fixing Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37786
[Bug driver/37786] Documentation for `-symbolic' needs fixing
--- Comment #3 from martinrb at google dot com 2008-10-09 19:26 --- (In reply to comment #2) Only a few systems support this option. x86-linux-gnu is one of those targets that don't support this option :). There is no changes needed here for the documentation as far as I can tell so closing as invalid. Dear bugmeister, At the very least the documentation could be made less confusing. The documentation for GNU ld gives: `-Bsymbolic' When creating a shared library, bind references to global symbols to the definition within the shared library, if any. Normally, it is possible for a program linked against a shared library to override the definition within the shared library. This option is only meaningful on ELF platforms which support shared libraries. The wording is sufficiently similar that one might think `-symbolic' and `-Bsymbolic' have the same meaning. Yet on x86-linux-gnu, the first fails, while the second appears to succeed. $ gcc -symbolic main.c; echo --; gcc -Bsymbolic main.c gcc: unrecognized option '-symbolic' -- Also, gcc has a documented `-B' flag with a completely different meaning. All in all, I think there is at least scope for improved clarity in the documentation. I've used gcc for decades, but am still confused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37786
[Bug driver/37786] Documentation for `-symbolic' needs fixing
--- Comment #5 from martinrb at google dot com 2008-10-09 23:10 --- (In reply to comment #4) If you want to use a specific linker option, use -Wl,XYZ or -Xlinker XYZ . Since those are the documented way to pass a linker option via gcc. I know about -Wl, and -Xlinker. I am trying to reduce confusion, for myself in part, but mostly for others. The flag `-Bsymbolic' works (or at least is accepted) despite the fact that it is not documented that such a flag is passed to the linker. This appears to be an undocumented use of `-B'. And on the other hand, the documented flag `-symbolic', which appears to have the same meaning, is rejected. Does this not seem disturbingly confusing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37786
[Bug driver/37786] Documentation for `-symbolic' needs fixing
--- Comment #7 from martinrb at google dot com 2008-10-09 23:16 --- The flag `-Bsymbolic' works (or at least is accepted) despite the fact that it is not documented that such a flag is passed to the linker. Ops. Please ignore my previous msg. I have misunderstood for years that `-Bsymbolic' is passed directly to the linker. Now I understand you need to do -Wl,-Bsymbolic -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37786
[Bug preprocessor/37549] New: gcc -E -dD prints predefined macros, contrary to docs
The docs for preprocessor -dD flag states `D' Like `M' except in two respects: it does _not_ include the predefined macros So one would expect -dD and -dM to differ substantially. But ([EMAIL PROTECTED]) ~ $ gcc -E -dM -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 /dev/null # 1 /dev/null ([EMAIL PROTECTED]) ~ $ wc /tmp/t[12] 111 340 3482 /tmp/t1 115 352 3552 /tmp/t2 226 692 7034 total ([EMAIL PROTECTED]) ~ $ gcc --version gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) -- Summary: gcc -E -dD prints predefined macros, contrary to docs Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
[Bug preprocessor/37550] New: Please document predefined sub-architecture support macros
The preprocessor symbol __MMX__ indicates whether this gcc includes mmx support. This is extremely useful, but undocumented. I only found out by finding the symbol in other peoples' code. The particular symbol __MMX__ should be documented in the obvious place, namely where the -mmmx flag is documented in the x86-specific page. And of course, similarly for other such predefined flags. I assume there's one for sse, but I haven't actually tried to find out. Here's a shell transcript, again compiling my favorite source file, /dev/null: ([EMAIL PROTECTED]) ~ $ gcc -mmmx -E -dD -x c /dev/null | sort /tmp/t1 ([EMAIL PROTECTED]) ~ $ gcc -mno-mmx -E -dD -x c /dev/null | sort /tmp/t2 ([EMAIL PROTECTED]) ~ $ diff /tmp/t[12] 92d91 #define __MMX__ 1 -- Summary: Please document predefined sub-architecture support macros Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37550
[Bug driver/37551] New: gcc help should provide subarchitecture details
How do I find out whether a particular gcc supports a particular subarchitecture, e.g. MMX instructions, by default? If the gcc has been configured --with-arch=, I can get that value using: gcc -v --help 21 | grep 'Configured with' but if the arch has defaulted based on the target triplet, it is less obvious. Is it documented that configure i486-xx is equivalent to configure --with-arch=i486 ? Even better, it would be nice if gcc -v --help said something like: mmx support is enabled (use -mno-mmx to disable it) sse support is disabled (use -msse to enable it) I would have guessed gcc -dumpspecs would give me this kind of information, but it appears not to. -- Summary: gcc help should provide subarchitecture details Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martinrb at google dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37551
[Bug preprocessor/37549] gcc -E -dD prints predefined macros, contrary to docs
--- Comment #2 from martinrb at google dot com 2008-09-17 04:27 --- I tried to check how -dM and -dD treats macros defined on the command line and in the source file: ([EMAIL PROTECTED]) ~/src/toy $ cat foo.c #define FOO 1 ([EMAIL PROTECTED]) ~/src/toy $ gcc -E -dM -x c -DBAR=1 foo.c | sort /tmp/t1 ([EMAIL PROTECTED]) ~/src/toy $ gcc -E -dD -x c -DBAR=1 foo.c | sort /tmp/t2 ([EMAIL PROTECTED]) ~/src/toy $ diff /tmp/t[12] 0a1,4 # 1 built-in # 1 command-line # 1 foo.c # 1 foo.c = No difference in the treatment of various classes of macros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37549
