Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 11/17/21 20:27, Martin Sebor wrote:
On 11/17/21 12:21 PM, Martin Sebor wrote:
On 11/17/21 11:31 AM, Jason Merrill wrote:
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more
cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
+ allocated stroage might have a null address. */
typo.
OK with that fixed.
After retesting the patch before committing I noticed it triggers
a regression in weak/weak-3.c that I missed the first time around.
Here's the test case:
extern void * ffoo1f (void);
void * foo1f (void)
{
if (ffoo1f) /* { dg-warning "-Waddress" } */
ffoo1f ();
return 0;
}
void * ffoox1f (void) { return (void *)0; }
extern void * ffoo1f (void) __attribute__((weak, alias ("ffoox1f")));
The unexpected error is:
a.c: At top level:
a.c:1:15: error: ‘ffoo1f’ declared weak after being used
1 | extern void * ffoo1f (void);
| ^~
The error is caused by the new call to maybe_nonzero_address()
made from decl_with_nonnull_addr_p(). The call registers
the symbol as used.
So unless the error is desirable for this case I think it's
best to go back to the originally proposed solution. I attach
it for reference and will plan to commit it tomorrow unless I
hear otherwise.
Hmm, the error seems correct to me: we tested whether the address is
nonzero in the dg-warning line, and presumably evaluating that test
could depend on the absence of weak.
Sorry, I don't know enough yet to judge this.
I've created a test case involving just a weak symbol (no alias)
that shows that the front end folds to true a test of the address
of a symbol subsequently declared weak:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103310
Clang and ICC do the same thing here; only Clang and GCC issue
a warning that the inequality is folded to true (here's a live
link to it: https://godbolt.org/z/a8Tx9Psee).
This doesn't seem ideal but I wouldn't call it a serious problem.
The case in weak-3.c is different: there the weak symbol is
an alias for a locally defined function. There, the alias cannot
become null and so folding the test is safe and giving an error
for it would be a regression. I would tend to view issuing
a hard error in this case a more serious problem than the first
(especially after reading the discussion below), but YMMV.
Ah, very good point.
This issue seems to go back to Honza's r5-3627, which changed
symtab_node::get to symtab_node::get_create in the code that became
maybe_nonzero_address, so that we decide early whether a particular
function is weak or not.
This was done so that constant-evaluation could properly decide that the
address of a function is non-null. But it's harmful when we do that for
speculative folding; we should only return a definitive answer, and set
refuse_visibility_changes, when a constant result is required.
I guess we need a way to tell fold that we really want a constant value,
have the C++ front end set that for manifestly-constant-evaluated
expressions, and only use get_create in that case.
The weak-3.c test was added along with a fix for PR 6343.
Here's a discussion of the problem:
https://gcc.gnu.org/legacy-ml/gcc/2002-04/msg00838.html
Please let me know which of the alternatives below you prefer
or if you want something else.
Since the error is unrelated to what I'm fixing I would prefer
not to
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 11/17/21 12:21 PM, Martin Sebor wrote:
On 11/17/21 11:31 AM, Jason Merrill wrote:
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
+ allocated stroage might have a null address. */
typo.
OK with that fixed.
After retesting the patch before committing I noticed it triggers
a regression in weak/weak-3.c that I missed the first time around.
Here's the test case:
extern void * ffoo1f (void);
void * foo1f (void)
{
if (ffoo1f) /* { dg-warning "-Waddress" } */
ffoo1f ();
return 0;
}
void * ffoox1f (void) { return (void *)0; }
extern void * ffoo1f (void) __attribute__((weak, alias ("ffoox1f")));
The unexpected error is:
a.c: At top level:
a.c:1:15: error: ‘ffoo1f’ declared weak after being used
1 | extern void * ffoo1f (void);
| ^~
The error is caused by the new call to maybe_nonzero_address()
made from decl_with_nonnull_addr_p(). The call registers
the symbol as used.
So unless the error is desirable for this case I think it's
best to go back to the originally proposed solution. I attach
it for reference and will plan to commit it tomorrow unless I
hear otherwise.
Hmm, the error seems correct to me: we tested whether the address is
nonzero in the dg-warning line, and presumably evaluating that test
could depend on the absence of weak.
Sorry, I don't know enough yet to judge this.
I've created a test case involving just a weak symbol (no alias)
that shows that the front end folds to true a test of the address
of a symbol subsequently declared weak:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103310
Clang and ICC do the same thing here; only Clang and GCC issue
a warning that the inequality is folded to true (here's a live
link to it: https://godbolt.org/z/a8Tx9Psee).
This doesn't seem ideal but I wouldn't call it a serious problem.
The case in weak-3.c is different: there the weak symbol is
an alias for a locally defined function. There, the alias cannot
become null and so folding the test is safe and giving an error
for it would be a regression. I would tend to view issuing
a hard error in this case a more serious problem than the first
(especially after reading the discussion below), but YMMV.
The weak-3.c test was added along with a fix for PR 6343.
Here's a discussion of the problem:
https://gcc.gnu.org/legacy-ml/gcc/2002-04/msg00838.html
Please let me know which of the alternatives below you prefer
or if you want something else.
Since the error is unrelated to what I'm fixing I would prefer
not to introduce it in the same patch. I'm happy to open
a separate bug for the missing error for the test case above,
look some more into why it isn't issued, and if it's decided
the error is intended either add the call back to trigger it
or do whatever else may be more appropriate).
Are you okay with me going ahead and committing the most recent
patch as is?
If not, do you want me to commit the previous version and change
the weak-3.c test to expect the error?
Martin
PS I don't know enough about the logic behind issuing this error
in other situations to tell for sure that it's wrong in this one
but I see no difference in the emitted code for a case in the same
test that declares the alias first, before taking its address and
that's accepted and this one. I also
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 11/17/21 11:31 AM, Jason Merrill wrote:
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
+ allocated stroage might have a null address. */
typo.
OK with that fixed.
After retesting the patch before committing I noticed it triggers
a regression in weak/weak-3.c that I missed the first time around.
Here's the test case:
extern void * ffoo1f (void);
void * foo1f (void)
{
if (ffoo1f) /* { dg-warning "-Waddress" } */
ffoo1f ();
return 0;
}
void * ffoox1f (void) { return (void *)0; }
extern void * ffoo1f (void) __attribute__((weak, alias ("ffoox1f")));
The unexpected error is:
a.c: At top level:
a.c:1:15: error: ‘ffoo1f’ declared weak after being used
1 | extern void * ffoo1f (void);
| ^~
The error is caused by the new call to maybe_nonzero_address()
made from decl_with_nonnull_addr_p(). The call registers
the symbol as used.
So unless the error is desirable for this case I think it's
best to go back to the originally proposed solution. I attach
it for reference and will plan to commit it tomorrow unless I
hear otherwise.
Hmm, the error seems correct to me: we tested whether the address is
nonzero in the dg-warning line, and presumably evaluating that test
could depend on the absence of weak.
Sorry, I don't know enough yet to judge this.
Since the error is unrelated to what I'm fixing I would prefer
not to introduce it in the same patch. I'm happy to open
a separate bug for the missing error for the test case above,
look some more into why it isn't issued, and if it's decided
the error is intended either add the call back to trigger it
or do whatever else may be more appropriate).
Are you okay with me going ahead and committing the most recent
patch as is?
If not, do you want me to commit the previous version and change
the weak-3.c test to expect the error?
Martin
PS I don't know enough about the logic behind issuing this error
in other situations to tell for sure that it's wrong in this one
but I see no difference in the emitted code for a case in the same
test that declares the alias first, before taking its address and
that's accepted and this one. I also checked that both Clang and
ICC accept the code either way, so I'm inclined to think the error
would be a bug.
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 11/16/21 20:11, Martin Sebor wrote:
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
+ allocated stroage might have a null address. */
typo.
OK with that fixed.
After retesting the patch before committing I noticed it triggers
a regression in weak/weak-3.c that I missed the first time around.
Here's the test case:
extern void * ffoo1f (void);
void * foo1f (void)
{
if (ffoo1f) /* { dg-warning "-Waddress" } */
ffoo1f ();
return 0;
}
void * ffoox1f (void) { return (void *)0; }
extern void * ffoo1f (void) __attribute__((weak, alias ("ffoox1f")));
The unexpected error is:
a.c: At top level:
a.c:1:15: error: ‘ffoo1f’ declared weak after being used
1 | extern void * ffoo1f (void);
| ^~
The error is caused by the new call to maybe_nonzero_address()
made from decl_with_nonnull_addr_p(). The call registers
the symbol as used.
So unless the error is desirable for this case I think it's
best to go back to the originally proposed solution. I attach
it for reference and will plan to commit it tomorrow unless I
hear otherwise.
Hmm, the error seems correct to me: we tested whether the address is
nonzero in the dg-warning line, and presumably evaluating that test
could depend on the absence of weak.
PS I don't know enough about the logic behind issuing this error
in other situations to tell for sure that it's wrong in this one
but I see no difference in the emitted code for a case in the same
test that declares the alias first, before taking its address and
that's accepted and this one. I also checked that both Clang and
ICC accept the code either way, so I'm inclined to think the error
would be a bug.
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 11/16/21 1:23 PM, Jason Merrill wrote:
On 10/23/21 19:06, Martin Sebor wrote:
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
+ allocated stroage might have a null address. */
typo.
OK with that fixed.
After retesting the patch before committing I noticed it triggers
a regression in weak/weak-3.c that I missed the first time around.
Here's the test case:
extern void * ffoo1f (void);
void * foo1f (void)
{
if (ffoo1f) /* { dg-warning "-Waddress" } */
ffoo1f ();
return 0;
}
void * ffoox1f (void) { return (void *)0; }
extern void * ffoo1f (void) __attribute__((weak, alias ("ffoox1f")));
The unexpected error is:
a.c: At top level:
a.c:1:15: error: ‘ffoo1f’ declared weak after being used
1 | extern void * ffoo1f (void);
| ^~
The error is caused by the new call to maybe_nonzero_address()
made from decl_with_nonnull_addr_p(). The call registers
the symbol as used.
So unless the error is desirable for this case I think it's
best to go back to the originally proposed solution. I attach
it for reference and will plan to commit it tomorrow unless I
hear otherwise.
Martin
PS I don't know enough about the logic behind issuing this error
in other situations to tell for sure that it's wrong in this one
but I see no difference in the emitted code for a case in the same
test that declares the alias first, before taking its address and
that's accepted and this one. I also checked that both Clang and
ICC accept the code either way, so I'm inclined to think the error
would be a bug.
Restore ancient -Waddress for weak symbols [PR33925].
Resolves:
PR c/33925 - gcc -Waddress lost some useful warnings
PR c/102867 - -Waddress from macro expansion in readelf.c
gcc/c-family/ChangeLog:
PR c++/33925
PR c/102867
* c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address
and improve handling tof defined symbols.
gcc/c/ChangeLog:
PR c++/33925
PR c/102867
* c-typeck.c (maybe_warn_for_null_address): Suppress warnings for
code resulting from macro expansion.
gcc/cp/ChangeLog:
PR c++/33925
PR c/102867
* typeck.c (warn_for_null_address): Suppress warnings for code
resulting from macro expansion.
gcc/ChangeLog:
PR c++/33925
PR c/102867
* doc/invoke.texi (-Waddress): Update.
gcc/testsuite/ChangeLog:
PR c++/33925
PR c/102867
* g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning.
* c-c++-common/Waddress-5.c: New test.
* c-c++-common/Waddress-6.c: New test.
* g++.dg/warn/Waddress-7.C: New test.
* g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning.
* gcc.dg/weak/weak-3.c: Expect a warning.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 436df45df68..5ab34c9eed8 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3400,16 +3400,43 @@ c_wrap_maybe_const (tree expr, bool non_const)
/* Return whether EXPR is a declaration whose address can never be NULL.
The address of the first struct member could be NULL only if it were
- accessed through a NULL pointer, and such an access would be invalid. */
+ accessed through a NULL pointer, and such an access would be invalid.
+ The address of a weak symbol may be null unless it has a definition. */
bool
decl_with_nonnull_addr_p (const_tree expr)
{
- return (DECL_P (expr)
- && (TREE_CODE (expr) == FIELD_DECL
- || TREE_CODE (expr) == PARM_DECL
- || TREE_CODE (expr) ==
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 10/23/21 19:06, Martin Sebor wrote: On 10/4/21 3:37 PM, Jason Merrill wrote: On 10/4/21 14:42, Martin Sebor wrote: While resolving the recent -Waddress enhancement request (PR PR102103) I came across a 2007 problem report about GCC 4 having stopped warning for using the address of inline functions in equality comparisons with null. With inline functions being commonplace in C++ this seems like an important use case for the warning. The change that resulted in suppressing the warning in these cases was introduced inadvertently in a fix for PR 22252. To restore the warning, the attached patch enhances the decl_with_nonnull_addr_p() function to return true also for weak symbols for which a definition has been provided. I think you probably want to merge this function with fold-const.c:maybe_nonzero_address, which already handles more cases. maybe_nonzero_address() doesn't behave quite like decl_with_nonnull_addr_p() expects and I'm reluctant to muck around with the former too much since it's used for codegen, while the latter just for warnings. (There is even a case where the functions don't behave the same, and would result in different warnings between C and C++ without some extra help.) So in the attached revision I just have maybe_nonzero_address() call decl_with_nonnull_addr_p() and then refine the failing (or uncertain) cases separately, with some overlap between them. Since I worked on this someone complained that some instances of the warning newly enhanced under PR102103 aren't suppresed in code resulting from macro expansion. Since it's trivial, I include the fix for that report in this patch as well. + allocated stroage might have a null address. */ typo. OK with that fixed. Jason
PING 2 [PATCH] restore ancient -Waddress for weak symbols [PR33925]
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html On 11/7/21 4:31 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html On 10/23/21 5:06 PM, Martin Sebor wrote: On 10/4/21 3:37 PM, Jason Merrill wrote: On 10/4/21 14:42, Martin Sebor wrote: While resolving the recent -Waddress enhancement request (PR PR102103) I came across a 2007 problem report about GCC 4 having stopped warning for using the address of inline functions in equality comparisons with null. With inline functions being commonplace in C++ this seems like an important use case for the warning. The change that resulted in suppressing the warning in these cases was introduced inadvertently in a fix for PR 22252. To restore the warning, the attached patch enhances the decl_with_nonnull_addr_p() function to return true also for weak symbols for which a definition has been provided. I think you probably want to merge this function with fold-const.c:maybe_nonzero_address, which already handles more cases. maybe_nonzero_address() doesn't behave quite like decl_with_nonnull_addr_p() expects and I'm reluctant to muck around with the former too much since it's used for codegen, while the latter just for warnings. (There is even a case where the functions don't behave the same, and would result in different warnings between C and C++ without some extra help.) So in the attached revision I just have maybe_nonzero_address() call decl_with_nonnull_addr_p() and then refine the failing (or uncertain) cases separately, with some overlap between them. Since I worked on this someone complained that some instances of the warning newly enhanced under PR102103 aren't suppresed in code resulting from macro expansion. Since it's trivial, I include the fix for that report in this patch as well. Tested on x86_64-linux. Martin
PING [PATCH] restore ancient -Waddress for weak symbols [PR33925]
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html On 10/23/21 5:06 PM, Martin Sebor wrote: On 10/4/21 3:37 PM, Jason Merrill wrote: On 10/4/21 14:42, Martin Sebor wrote: While resolving the recent -Waddress enhancement request (PR PR102103) I came across a 2007 problem report about GCC 4 having stopped warning for using the address of inline functions in equality comparisons with null. With inline functions being commonplace in C++ this seems like an important use case for the warning. The change that resulted in suppressing the warning in these cases was introduced inadvertently in a fix for PR 22252. To restore the warning, the attached patch enhances the decl_with_nonnull_addr_p() function to return true also for weak symbols for which a definition has been provided. I think you probably want to merge this function with fold-const.c:maybe_nonzero_address, which already handles more cases. maybe_nonzero_address() doesn't behave quite like decl_with_nonnull_addr_p() expects and I'm reluctant to muck around with the former too much since it's used for codegen, while the latter just for warnings. (There is even a case where the functions don't behave the same, and would result in different warnings between C and C++ without some extra help.) So in the attached revision I just have maybe_nonzero_address() call decl_with_nonnull_addr_p() and then refine the failing (or uncertain) cases separately, with some overlap between them. Since I worked on this someone complained that some instances of the warning newly enhanced under PR102103 aren't suppresed in code resulting from macro expansion. Since it's trivial, I include the fix for that report in this patch as well. Tested on x86_64-linux. Martin
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On Tue, Nov 02, 2021 at 12:51:16PM -0600, Martin Sebor via Gcc-patches wrote: > On 10/4/21 4:39 PM, Eric Gallager wrote: > > On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches > > wrote: > > > > > > While resolving the recent -Waddress enhancement request (PR > > > PR102103) I came across a 2007 problem report about GCC 4 having > > > stopped warning for using the address of inline functions in > > > equality comparisons with null. With inline functions being > > > commonplace in C++ this seems like an important use case for > > > the warning. > > > > > > The change that resulted in suppressing the warning in these > > > cases was introduced inadvertently in a fix for PR 22252. > > > > > > To restore the warning, the attached patch enhances > > > the decl_with_nonnull_addr_p() function to return true also for > > > weak symbols for which a definition has been provided. > > > > > > Tested on x86_64-linux and by comparing the GCC output for new > > > test cases to Clang's which diagnoses all but one instance of > > > these cases with either -Wtautological-pointer-compare or > > > -Wpointer-bool-conversion, depending on context. > > > > Would it make sense to use the same names as clang's flags here, too, > > instead of dumping them all under -Waddress? I think the additional > > granularity could be helpful for people who only want some warnings, > > but not others. > > In general I agree. In this case I'm not sure. The options > that control these warnings in neither compiler make perfect > sense to me. Here's a breakdown of the cases: > >ClangGCC > array == array -Wtautological-compare -Warray-compare > == null -Wtautological-pointer-compare -Waddress > ==N/A N/A > > GCC has recently diverged from Clang by introducing the new > -Warray-compare option, and we don't have That's not exactly true: -Warray-compare is not meant to be -Wtautological-compare. I introduced -Warray-compare because the C++ standard now says that array == array is deprecated, but -Wtautological-compare comes from a different angle: it warns because the comparison always evaluates to a constant. > -Wtautological-pointer-compare. So while I think it makes > sense to use the same names for new features as those they > are controlled by in Clang, the argument to do the same for > simple enhancements to existing features is quite a bit less > compelling. We'd likely end up diagnosing different subsets > of the same problem under different options. Yeah, in this particular case I think it'd be better to simple enhance -Waddress rather than to invent a new option. Marek
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 10/4/21 4:39 PM, Eric Gallager wrote: On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches wrote: While resolving the recent -Waddress enhancement request (PR PR102103) I came across a 2007 problem report about GCC 4 having stopped warning for using the address of inline functions in equality comparisons with null. With inline functions being commonplace in C++ this seems like an important use case for the warning. The change that resulted in suppressing the warning in these cases was introduced inadvertently in a fix for PR 22252. To restore the warning, the attached patch enhances the decl_with_nonnull_addr_p() function to return true also for weak symbols for which a definition has been provided. Tested on x86_64-linux and by comparing the GCC output for new test cases to Clang's which diagnoses all but one instance of these cases with either -Wtautological-pointer-compare or -Wpointer-bool-conversion, depending on context. Would it make sense to use the same names as clang's flags here, too, instead of dumping them all under -Waddress? I think the additional granularity could be helpful for people who only want some warnings, but not others. In general I agree. In this case I'm not sure. The options that control these warnings in neither compiler make perfect sense to me. Here's a breakdown of the cases: ClangGCC array == array -Wtautological-compare -Warray-compare == null -Wtautological-pointer-compare -Waddress ==N/A N/A GCC has recently diverged from Clang by introducing the new -Warray-compare option, and we don't have -Wtautological-pointer-compare. So while I think it makes sense to use the same names for new features as those they are controlled by in Clang, the argument to do the same for simple enhancements to existing features is quite a bit less compelling. We'd likely end up diagnosing different subsets of the same problem under different options. Martin The one case where Clang doesn't issue a warning but GCC with the patch does is for a symbol explicitly declared with attribute weak for which a definition has been provided. I believe the address of such symbols is necessarily nonnull and so issuing the warning is helpful (both GCC and Clang fold such comparisons to a constant). Martin
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 10/4/21 3:37 PM, Jason Merrill wrote:
On 10/4/21 14:42, Martin Sebor wrote:
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
I think you probably want to merge this function with
fold-const.c:maybe_nonzero_address, which already handles more cases.
maybe_nonzero_address() doesn't behave quite like
decl_with_nonnull_addr_p() expects and I'm reluctant to muck
around with the former too much since it's used for codegen,
while the latter just for warnings. (There is even a case
where the functions don't behave the same, and would result
in different warnings between C and C++ without some extra
help.)
So in the attached revision I just have maybe_nonzero_address()
call decl_with_nonnull_addr_p() and then refine the failing
(or uncertain) cases separately, with some overlap between
them.
Since I worked on this someone complained that some instances
of the warning newly enhanced under PR102103 aren't suppresed
in code resulting from macro expansion. Since it's trivial,
I include the fix for that report in this patch as well.
Tested on x86_64-linux.
Martin
Restore ancient -Waddress for weak symbols [PR33925].
Resolves:
PR c/33925 - gcc -Waddress lost some useful warnings
PR c/102867 - -Waddress from macro expansion in readelf.c
gcc/c-family/ChangeLog:
PR c++/33925
PR c/102867
* c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address
and improve handling tof defined symbols.
gcc/c/ChangeLog:
PR c++/33925
PR c/102867
* c-typeck.c (maybe_warn_for_null_address): Suppress warnings for
code resulting from macro expansion.
gcc/cp/ChangeLog:
PR c++/33925
PR c/102867
* typeck.c (warn_for_null_address): Suppress warnings for code
resulting from macro expansion.
gcc/ChangeLog:
PR c++/33925
PR c/102867
* doc/invoke.texi (-Waddress): Update.
* fold-const.c (maybe_nonzero_address): Declare extern. Simplify
for readability.
* tree.h (maybe_nonzero_address): Declare.
gcc/testsuite/ChangeLog:
PR c++/33925
PR c/102867
* g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning.
* c-c++-common/Waddress-5.c: New test.
* c-c++-common/Waddress-6.c: New test.
* g++.dg/warn/Waddress-7.C: New test.
* g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning.
* gcc.dg/weak/weak-3.c: Expect a warning.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 32c7e3e8972..71cc74ac63d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3395,16 +3395,46 @@ c_wrap_maybe_const (tree expr, bool non_const)
/* Return whether EXPR is a declaration whose address can never be NULL.
The address of the first struct member could be NULL only if it were
- accessed through a NULL pointer, and such an access would be invalid. */
+ accessed through a NULL pointer, and such an access would be invalid.
+ The address of a weak symbol may be null unless it has a definition. */
bool
decl_with_nonnull_addr_p (const_tree expr)
{
- return (DECL_P (expr)
- && (TREE_CODE (expr) == FIELD_DECL
- || TREE_CODE (expr) == PARM_DECL
- || TREE_CODE (expr) == LABEL_DECL
- || !DECL_WEAK (expr)));
+ if (maybe_nonzero_address (const_cast (expr)) > 0)
+return true;
+
+ if (!DECL_P (expr))
+return false;
+
+ if (TREE_CODE (expr) == FIELD_DECL
+ || TREE_CODE (expr) == PARM_DECL
+ || TREE_CODE (expr) == LABEL_DECL)
+return true;
+
+ if (!VAR_OR_FUNCTION_DECL_P (expr))
+return false;
+
+ if (!DECL_WEAK (expr))
+/* Ordinary (non-weak) symbols have nonnull addresses. */
+return true;
+
+ if (DECL_INITIAL (expr) && DECL_INITIAL (expr) != error_mark_node)
+/* Initialized weak symbols have nonnull addresses. */
+return true;
+
+ if (DECL_EXTERNAL (expr) || !TREE_STATIC (expr))
+/* Uninitialized extern weak symbols and weak symbols with no
+ allocated stroage might have a null address. */
+return false;
+
+ tree attribs = DECL_ATTRIBUTES (expr);
+ if (lookup_attribute ("weakref", attribs))
+/* Weakref symbols might have a null address unless their referent
+ is known not to. Don't bother following weakref targets here. */
+return false;
+
+ return true;
}
/* Prepare expr to be an argument of a TRUTH_NOT_EXPR,
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 0aac978c02e..0ceedfa7b04 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -11571,7 +11571,10 @@ build_vec_cmp (tree_code code, tree type,
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches wrote: > > While resolving the recent -Waddress enhancement request (PR > PR102103) I came across a 2007 problem report about GCC 4 having > stopped warning for using the address of inline functions in > equality comparisons with null. With inline functions being > commonplace in C++ this seems like an important use case for > the warning. > > The change that resulted in suppressing the warning in these > cases was introduced inadvertently in a fix for PR 22252. > > To restore the warning, the attached patch enhances > the decl_with_nonnull_addr_p() function to return true also for > weak symbols for which a definition has been provided. > > Tested on x86_64-linux and by comparing the GCC output for new > test cases to Clang's which diagnoses all but one instance of > these cases with either -Wtautological-pointer-compare or > -Wpointer-bool-conversion, depending on context. Would it make sense to use the same names as clang's flags here, too, instead of dumping them all under -Waddress? I think the additional granularity could be helpful for people who only want some warnings, but not others. > The one case where Clang doesn't issue a warning but GCC > with the patch does is for a symbol explicitly declared with > attribute weak for which a definition has been provided. > I believe the address of such symbols is necessarily nonnull and > so issuing the warning is helpful > (both GCC and Clang fold such comparisons to a constant). > > Martin
Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]
On 10/4/21 14:42, Martin Sebor wrote: While resolving the recent -Waddress enhancement request (PR PR102103) I came across a 2007 problem report about GCC 4 having stopped warning for using the address of inline functions in equality comparisons with null. With inline functions being commonplace in C++ this seems like an important use case for the warning. The change that resulted in suppressing the warning in these cases was introduced inadvertently in a fix for PR 22252. To restore the warning, the attached patch enhances the decl_with_nonnull_addr_p() function to return true also for weak symbols for which a definition has been provided. I think you probably want to merge this function with fold-const.c:maybe_nonzero_address, which already handles more cases. Jason
[PATCH] restore ancient -Waddress for weak symbols [PR33925]
While resolving the recent -Waddress enhancement request (PR
PR102103) I came across a 2007 problem report about GCC 4 having
stopped warning for using the address of inline functions in
equality comparisons with null. With inline functions being
commonplace in C++ this seems like an important use case for
the warning.
The change that resulted in suppressing the warning in these
cases was introduced inadvertently in a fix for PR 22252.
To restore the warning, the attached patch enhances
the decl_with_nonnull_addr_p() function to return true also for
weak symbols for which a definition has been provided.
Tested on x86_64-linux and by comparing the GCC output for new
test cases to Clang's which diagnoses all but one instance of
these cases with either -Wtautological-pointer-compare or
-Wpointer-bool-conversion, depending on context. The one case
where Clang doesn't issue a warning but GCC with the patch does
is for a symbol explicitly declared with attribute weak for which
a definition has been provided. I believe the address of such
symbols is necessarily nonnull and so issuing the warning is
helpful (both GCC and Clang fold such comparisons to a constant).
Martin
PR c/33925 - missing -Waddress with the address of an inline function
gcc/c-family/ChangeLog:
PR c/33925
* c-common.c (decl_with_nonnull_addr_p): Also return true for weak
symbols for which a definition has been provided.
gcc/testsuite/ChangeLog:
PR c/33925
* c-c++-common/Waddress-5.c: New test.
* g++.dg/warn/Waddress-7.C: New test.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 9d19e352725..ba02d3981c0 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3395,7 +3395,8 @@ c_wrap_maybe_const (tree expr, bool non_const)
/* Return whether EXPR is a declaration whose address can never be NULL.
The address of the first struct member could be NULL only if it were
- accessed through a NULL pointer, and such an access would be invalid. */
+ accessed through a NULL pointer, and such an access would be invalid.
+ The address of a weak symbol may be null unless it has a definition. */
bool
decl_with_nonnull_addr_p (const_tree expr)
@@ -3404,7 +3405,9 @@ decl_with_nonnull_addr_p (const_tree expr)
&& (TREE_CODE (expr) == FIELD_DECL
|| TREE_CODE (expr) == PARM_DECL
|| TREE_CODE (expr) == LABEL_DECL
- || !DECL_WEAK (expr)));
+ || !DECL_WEAK (expr)
+ || (DECL_INITIAL (expr)
+ && DECL_INITIAL (expr) != error_mark_node)));
}
/* Prepare expr to be an argument of a TRUTH_NOT_EXPR,
diff --git a/gcc/testsuite/c-c++-common/Waddress-5.c b/gcc/testsuite/c-c++-common/Waddress-5.c
new file mode 100644
index 000..fa6658fa133
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Waddress-5.c
@@ -0,0 +1,133 @@
+/* PR c/33925 - missing -Waddress with the address of an inline function
+ { dg-do compile }
+ { dg-options "-Wall" }
+ { dg-require-weak "" } */
+
+extern inline int eifn (void);
+extern inline int eifn_def (void) { return 0; }
+
+static inline int sifn (void);
+static inline int sifn_def (void) { return 0; }
+
+inline int ifn (void);
+inline int ifn_def (void) { return 0; }
+
+extern __attribute__ ((weak)) int ewfn (void);
+extern __attribute__ ((weak)) int ewfn_def (void) { return 0; }
+
+__attribute__ ((weak)) int wfn (void);
+__attribute__ ((weak)) int wfn_def (void) { return 0; }
+
+static __attribute__((weakref ("ewfn"))) int swrfn;
+
+void test_function_eqz (int *p)
+{
+ *p++ = eifn == 0; // { dg-warning "-Waddress" }
+ *p++ = eifn_def == 0; // { dg-warning "-Waddress" }
+ *p++ = sifn == 0; // { dg-warning "-Waddress" }
+ *p++ = sifn_def == 0; // { dg-warning "-Waddress" }
+ *p++ = ifn == 0; // { dg-warning "-Waddress" }
+ *p++ = ifn_def == 0; // { dg-warning "-Waddress" }
+ *p++ = ewfn == 0;
+ *p++ = ewfn_def == 0; // { dg-warning "-Waddress" }
+ *p++ = wfn == 0;
+ *p++ = wfn_def == 0; // { dg-warning "-Waddress" }
+ *p++ = swrfn == 0;
+}
+
+
+int test_function_if (int i)
+{
+ if (eifn) // { dg-warning "-Waddress" }
+i++;
+ if (eifn_def) // { dg-warning "-Waddress" }
+i++;
+ if (sifn) // { dg-warning "-Waddress" }
+i++;
+ if (sifn_def) // { dg-warning "-Waddress" }
+i++;
+ if (ifn) // { dg-warning "-Waddress" }
+i++;
+ if (ifn_def) // { dg-warning "-Waddress" }
+i++;
+ if (ewfn)
+i++;
+ if (ewfn_def) // { dg-warning "-Waddress" }
+i++;
+ if (wfn)
+i++;
+ if(wfn_def) // { dg-warning "-Waddress" }
+i++;
+ if (swrfn)
+i++;
+ return i;
+}
+
+
+extern int ei;
+extern int ei_def = 1;
+
+static int si;
+static int si_def = 1;
+
