[PATCH] c/69540 - update documentation on -l
* doc/invoke.texi: update documentation WRT .so libraries in -l
---
gcc/ChangeLog | 4
gcc/doc/invoke.texi | 8 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1d60690..0a6acdb 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2016-01-30 Arkadiusz Drabczyk
+
+ * doc/invoke.texi: update documentation WRT .so libraries in -l
+
2016-01-29 Martin Jambor
* hsa-gen.c (get_memory_order_name): Mask with MEMMODEL_BASE_MASK.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ba0b4b2..8b1b329 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10440,9 +10440,11 @@ whose members are object files. The linker handles an
archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion. The only
-difference between using an @option{-l} option and specifying a file name
-is that @option{-l} surrounds @var{library} with @samp{lib} and @samp{.a}
-and searches several directories.
+difference between using an @option{-l} option and specifying a file
+name is that @option{-l} surrounds @var{library} with @samp{lib} and
+@samp{.so} on systems with shared libraries support or with @samp{.a} if
+@var{library} with @samp{.so} is not found and on all other systems and
+searches several directories.
@item -lobjc
@opindex lobjc
--
1.8.4
--
Arkadiusz Drabczyk
Re: [PATCH] c/69540 - update documentation on -l
On 2016-02-02, Sandra Loosemore wrote:
> I see that the documentation of -l does need to be updated to mention
> .so files, but I think your patch doesn't go far enough. It's already
> confusing because that sentence says "The only difference is...", and
> then mentions *two* things it does differently, and you're adding even
> more things.
>
> Instead, I suggest dropping this confusing sentence entirely and putting
> the new information a couple paragraphs higher up:
>
>> The linker searches a standard list of directories for the library,
>> which is actually a file named @file{lib@var{library}.a}. The linker
>> then uses this file as if it had been specified precisely by name.
>
> How about just changing that to read
>
> ...a file named @file{lib@var{library}.so}; or, if shared libraries are
> not supported, are disabled via @option{-static}, or no @samp{.so} file
> is found, @file{lib@var{library}.a}.
Nice, indeed, more readable than what I came up with plus info on
-static added. Looks good to me.
--
Arkadiusz Drabczyk
Re: [PATCH] c/69540 - update documentation on -l
On 2016-02-02, Arkadiusz Drabczyk wrote:
> On 2016-02-02, Sandra Loosemore wrote:
>> I see that the documentation of -l does need to be updated to mention
>> .so files, but I think your patch doesn't go far enough. It's already
>> confusing because that sentence says "The only difference is...", and
>> then mentions *two* things it does differently, and you're adding even
>> more things.
>>
>> Instead, I suggest dropping this confusing sentence entirely and putting
>> the new information a couple paragraphs higher up:
>>
>>> The linker searches a standard list of directories for the library,
>>> which is actually a file named @file{lib@var{library}.a}. The linker
>>> then uses this file as if it had been specified precisely by name.
>>
>> How about just changing that to read
>>
>> ...a file named @file{lib@var{library}.so}; or, if shared libraries are
>> not supported, are disabled via @option{-static}, or no @samp{.so} file
>> is found, @file{lib@var{library}.a}.
>
> Nice, indeed, more readable than what I came up with plus info on
> -static added. Looks good to me.
>
Hello,
What's the status of this patch? Will it be merged into trunk?
--
Arkadiusz Drabczyk
[PATCH] c/67925 - update documentation on `inline'
* gcc/doc/extend.texi: documentation says that functions declared
`inline' would not be integrated if they are called before they are
defined or if they are recursive. Both of these statements is now
false as shown in examples on Bugzilla.
---
gcc/doc/extend.texi | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79440d3..7ea4b62 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7088,12 +7088,9 @@ function are integrated into the caller, and the
function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option @option{-fkeep-inline-functions}.
-Some calls cannot be integrated for various reasons (in particular,
-calls that precede the function's definition cannot be integrated, and
-neither can recursive calls within the definition). If there is a
-nonintegrated call, then the function is compiled to assembler code as
-usual. The function must also be compiled as usual if the program
-refers to its address, because that can't be inlined.
+If there is a nonintegrated call, then the function is compiled to
+assembler code as usual. The function must also be compiled as usual if
+the program refers to its address, because that can't be inlined.
@opindex Winline
Note that certain usages in a function definition can make it unsuitable
--
2.3.5
--
Arkadiusz Drabczyk
Re: [PATCH] c/67925 - update documentation on `inline'
On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote:
> On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote:
> >* gcc/doc/extend.texi: documentation says that functions declared
> >`inline' would not be integrated if they are called before they are
> >defined or if they are recursive. Both of these statements is now
> >false as shown in examples on Bugzilla.
>
> It might also be worth updating the note in the subsequent
> paragraph and removing the mention of variable-length data types
> which no longer prevent inlining.
Done. I also removed the mention of nested functions as the following
code compiled with GCC 6.0 doesn't give any warning with -O2 -Winline
and main() is the only function defined in assembler code:
#include
#include
inline static int foo (int a, int b)
{
printf("a == %d\n", a);
inline int square (int z) { return z * z; }
return square (a) + square (b);
}
int main(int argc, char *argv[])
{
printf("%d\n", foo(atoi(argv[1]), atoi(argv[2])));
exit(0);
}
I also removed a reference to Bugzilla from the commit message, I
don't think it's necessary.
> FWIW, the list of most -Winline warnings issued by GCC is here
> (there are two more in Ada which, AFAICT, have to do with nested
> functions):
>
> $ grep -A1 "can never be inlined" gcc/tree-inline.c
> (...)
> --
> = G_("function %q+F can never be inlined because "
> "it uses non-local goto");
I tested of all of these and listed them in the documentation but
wasn't able to reproduce this one. The following code does not give
any warning with -O2 -Winline:
#include
#include
#include
static jmp_buf buf;
inline static void longjmp_test(int n)
{
puts("hi");
if (n == 2)
longjmp(buf, 2);
}
int main(int argc, char *argv[])
{
printf("%d\n", setjmp(buf));
longjmp_test(atoi(argv[1]));
puts("next line in a normal execution");
exit(0);
}
Is this test case correct? However, I get the following warning using
__builtin_longjmp() instead of longjmp():
warning: function 'longjmp_test' can never be inlined because it uses
setjmp-longjmp exception handling [-Winline]
>8--8<
* gcc/doc/extend.texi: documentation says that functions declared
`inline' would not be integrated if they are called before they are
defined, if they are recursive, if they use variable-length data types
or if they are nested. All of these statements are now false and have
been removed. Mention of setjmp(), __builtin_return() and
__builtin_apply_args() has been added.
---
gcc/doc/extend.texi | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79440d3..be95cc3 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7088,21 +7088,18 @@ function are integrated into the caller, and the
function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option @option{-fkeep-inline-functions}.
-Some calls cannot be integrated for various reasons (in particular,
-calls that precede the function's definition cannot be integrated, and
-neither can recursive calls within the definition). If there is a
-nonintegrated call, then the function is compiled to assembler code as
-usual. The function must also be compiled as usual if the program
-refers to its address, because that can't be inlined.
+If there is a nonintegrated call, then the function is compiled to
+assembler code as usual. The function must also be compiled as usual if
+the program refers to its address, because that can't be inlined.
@opindex Winline
Note that certain usages in a function definition can make it unsuitable
-for inline substitution. Among these usages are: variadic functions, use of
-@code{alloca}, use of variable-length data types (@pxref{Variable Length}),
-use of computed goto (@pxref{Labels as Values}), use of nonlocal goto,
-and nested functions (@pxref{Nested Functions}). Using @option{-Winline}
-warns when a function marked @code{inline} could not be substituted,
-and gives the reason for the failure.
+for inline substitution. Among these usages are: variadic functions,
+use of @code{alloca}, use of computed goto (@pxref{Labels as Values}),
+use of @code{setjmp} and use of @code{__builtin_return} or
+@code{__builtin_apply_args}. Using @option{-Winline} warns when a
+function marked @code{inline} could not be substituted, and gives the
+reason for the failure.
@cindex automatic @code{inline} for C++ member fns
@cindex @code{inline} automatic for C++ member fns
--
2.3.5
--
Arkadiusz Drabczyk
Re: [PATCH] c/67925 - update documentation on `inline'
On Wed, Oct 14, 2015 at 06:18:03PM -0600, Martin Sebor wrote:
> On 10/14/2015 03:42 PM, Arkadiusz Drabczyk wrote:
> >On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote:
> >>On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote:
> >>>* gcc/doc/extend.texi: documentation says that functions declared
> >>>`inline' would not be integrated if they are called before they are
> >>>defined or if they are recursive. Both of these statements is now
> >>>false as shown in examples on Bugzilla.
> >>
> >>It might also be worth updating the note in the subsequent
> >>paragraph and removing the mention of variable-length data types
> >>which no longer prevent inlining.
> >
> >Done. I also removed the mention of nested functions as the following
> >code compiled with GCC 6.0 doesn't give any warning with -O2 -Winline
> >and main() is the only function defined in assembler code:
>
> I think this is the Ada-specific warning I mentioned (see
> check_inlining_for_nested_subprog in gcc/ada/gcc-interface/trans.c)
> so the part about nested functions needs to stay.
Ok, I brought it back.
> >> = G_("function %q+F can never be inlined because "
> >> "it uses non-local goto");
> >
> >I tested of all of these and listed them in the documentation but
> >wasn't able to reproduce this one. The following code does not give
> >any warning with -O2 -Winline:
>
> The warning above is issued for non-local and computed goto. You can
> find examples of both in the test suite (find gcc/testsuite/ -name
> "*goto*.[cC]")
Aha, ok, I just thought that longjmp() counts as a non-local goto
here. Indeed, this code invokes `function 'bar' can never be inlined
because it uses non-local goto' with -O2 -Winline (but only if
function that contains goto is nested, otherwise it fails to compile):
#include
#include
int main (void)
{
__label__ l1;
void foo (void)
{
inline void bar (void)
{
puts ("goto l1");
goto l1;
}
bar ();
}
foo ();
abort ();
l1:
puts ("label l1");
return 0;
}
I brought back a mention of nonlocal goto and added a mention of
__builtin_longjmp() as the usual longjmp() does not prevent inlining.
>8--8<
* gcc/doc/extend.texi: documentation says that functions declared
`inline' would not be integrated if they are called before they are
defined, if they are recursive, if they use variable-length data types
or if they are nested. All of these statements are now false and have
been removed. Mention of setjmp(), __builtin_longjmp(),
__builtin_return() and __builtin_apply_args() has been added.
---
gcc/doc/extend.texi | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79440d3..bd559af 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7088,21 +7088,19 @@ function are integrated into the caller, and the
function's address is
never used, then the function's own assembler code is never referenced.
In this case, GCC does not actually output assembler code for the
function, unless you specify the option @option{-fkeep-inline-functions}.
-Some calls cannot be integrated for various reasons (in particular,
-calls that precede the function's definition cannot be integrated, and
-neither can recursive calls within the definition). If there is a
-nonintegrated call, then the function is compiled to assembler code as
-usual. The function must also be compiled as usual if the program
-refers to its address, because that can't be inlined.
+If there is a nonintegrated call, then the function is compiled to
+assembler code as usual. The function must also be compiled as usual if
+the program refers to its address, because that can't be inlined.
@opindex Winline
Note that certain usages in a function definition can make it unsuitable
-for inline substitution. Among these usages are: variadic functions, use of
-@code{alloca}, use of variable-length data types (@pxref{Variable Length}),
-use of computed goto (@pxref{Labels as Values}), use of nonlocal goto,
-and nested functions (@pxref{Nested Functions}). Using @option{-Winline}
-warns when a function marked @code{inline} could not be substituted,
-and gives the reason for the failure.
+for inline substitution. Among these usages are: variadic functions,
+use of @code{alloca}, use of computed goto (@pxref{Labels as Values}),
+use of nonlocal goto, use of nested functions, use of @code{setjmp}, use
+of @code{__builtin_longjmp}
