[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31383 --- Comment #8 from Andrew Pinski --- Moved to glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=31383
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #7 from Sergio Durigan Junior --- Ah, OK, I'll let you file the bug, then. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #6 from Sergio Durigan Junior --- Thanks for the quick analysis. It seems that the following glibc commit dropped size hints from access when FORTIFY_SOURCE=3: https://sourceware.org/git/?p=glibc.git;a=commit;h=e938c02748402c50f60ba0eb983273e7b52937d1 I'll report a bug against glibc and mention this conversation. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #5 from Andrew Pinski --- extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __wur __fortified_attr_access (__write_only__, 2, 3); ... /* For _FORTIFY_SOURCE == 3 we use __builtin_dynamic_object_size, which may use the access attribute to get object sizes from function definition arguments, so we can't use them on functions we fortify. Drop the object size hints for such functions. */ # if __USE_FORTIFY_LEVEL == 3 #define __fortified_attr_access(a, o, s) __attribute__ ((__access__ (a, o))) # else #define __fortified_attr_access(a, o, s) __attr_access ((a, o, s)) # endif Yes that is broken. Let me file the glibc issue.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #4 from Andrew Pinski --- POSIX definition of read: https://pubs.opengroup.org/onlinepubs/009604599/functions/read.html >Before any action described below is taken, and if nbyte is zero, the read() >function may detect and return errors as described below. In the absence of >errors, or if error detection is not performed, the read() function shall >return zero and have no other results. So yes it does look like the use of write_only access is incorrect ...
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #3 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute : >When no size-index argument is specified, the pointer argument must be either >null or point to a space that is suitably aligned and large for at least one >object of the referenced type (this implies that a past-the-end pointer is not >a valid argument). I think this is a bug in glibc and its (mis)use of the access and write only attribute without a size. It has: __attribute__ ((__access__ (__write_only__, 2))) but the documentation for this attribute does not correspond with the above.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #2 from Sergio Durigan Junior --- Created attachment 57431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57431&action=edit Preprocessed source Sure thing. Here it is.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source since this depends on glibc's FORTIFY_SOURCE for value of 3 which is only included in newer glibc's?
