[Bug c/57182] New: Documentation implies -fprofile-arcs required to create .text.unlikely sections
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57182 Bug #: 57182 Summary: Documentation implies -fprofile-arcs required to create .text.unlikely sections Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ru...@rustcorp.com.au >From info file (unchanged since before 4.4): `-freorder-functions' Reorder functions in the object file in order to improve code locality. This is implemented by using special subsections `.text.hot' for most frequently executed functions and `.text.unlikely' for unlikely executed functions. Reordering is done by the linker so object file format must support named sections and linker must place them in a reasonable way. Also profile feedback must be available in to make this option effective. See `-fprofile-arcs' for details. But -freorder-functions creates those sections without -fprofile-arcs for functions with attributes "hot" or "cold". So the last paragraph is misleading/obsolete. Does it really mean: The compiler relies on function attributes or profile feedback to determine how frequently functions are executed. See `-fprofile-arcs' for details. ? Thanks, Rusty.
[Bug c/57182] Documentation implies -fprofile-arcs required to create .text.unlikely sections
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57182 --- Comment #2 from rusty at rustcorp dot com.au 2013-05-06 07:59:02 UTC --- Sure, once I understood how it worked, I could parse the documentation. But that's a bit backwards :) Thanks, Rusty.
[Bug c/86584] New: Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584
Bug ID: 86584
Summary: Incorrect -Wsequence-point warning on structure member
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rusty at rustcorp dot com.au
Target Milestone: ---
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0, x86-64. Also in gcc-8 (Ubuntu
8.1.0-1ubuntu1) 8.1.0.
I have a macro which does an assignment, and also hands the address of the same
var to the function. The reduced version is below: it gives a spurious warning
when the var involved is a struct member:
struct s {
int f;
};
void func(int *f, int);
int main(void)
{
struct s s;
int f;
/* bad-warning-gcc.c:13:17: warning: operation on ‘s.f’ may be
undefined [-Wsequence-point] */
func(&s.f, s.f = 1);
/* No warning for this */
func(&f, f = 1);
return 0;
}
[Bug c/67793] New: Detect incorrect function arg sizes at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67793
Bug ID: 67793
Summary: Detect incorrect function arg sizes at compile time.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rusty at rustcorp dot com.au
Target Milestone: ---
It would be great if GCC warned on this:
extern int func_(char x[32]);
int main(int argc, char *argv[])
{
char p[8];
return func(p);
}
Failing that, if __builtin_object_size() returned a compile-time constant where
possible, we could do this (with __builtin_constant_p):
#define SIZE_CHECK(v,min) ({static_assert(__builtin_object_size((v), 0) >=
(min), "too small"); (v)})
extern int func_(char x[32]);
#define func(x) func_(SIZE_CHECK((x),32))
[Bug c/66425] New: (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Bug ID: 66425 Summary: (void) cast doesn't suppress __attribute__((warn_unused_result)) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rusty at rustcorp dot com.au Target Milestone: --- Yes, a repeat of 2005's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 The world, especially glibc and the Linux kernel, have adopted __wur with a passion, taking it well outside the "must" case (basically, realloc and nothing else) into the "should" case. For better or worse. Thus I politely request that an explicit (void) cast work to disable this warning. Having projects create their own custom macros/templates to do this is a worse outcome, and doesn't stop idiocy like ignoring realloc() anyway. Please consider. PS. Happy to create a patch, if that would help.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #3 from rusty at rustcorp dot com.au --- Indeed, cast to void has been a standard "I really want to ignore this" notation. It's intuitive and obvious, and ISTR seeing it in the early 90s for lint warning suppression, for example.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #19 from rusty at rustcorp dot com.au --- I like WUR as a sanity-check, and it is useful that more and more library authors are using it (generally quite well). As Andrew points out, this has taken 10 years! The downside is that false positives are becoming more common. For example, gnulib also includes a routine to handle this, since 2008: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/ignore-value.h;h=68521edb38f50cb2230c8560a125864be212db6a;hb=HEAD I believe that changing conditions call for a re-evaluation. And yes, I'd like to see a comment on any cast-to-void, not just for WUR. Thanks for your patience!
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #21 from rusty at rustcorp dot com.au --- jengelh at inai dot de writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 > > --- Comment #20 from Jan Engelhardt --- > Seems like the short route is to add a new attribute > ((warn_unused_result_with_void_cancelling)) that exhibits the "desired" > behavior of (void) cancelling the warning, and then make glibc use that. > Simple, no? Indeed! I'll produce the patch if anyone thinks it's worthwhile? It'll only take another 10 years to switch everyone :) Thanks, Rusty.
[Bug c/76733] New: GCC should warn on repeated initializer for same array element / struct member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76733
Bug ID: 76733
Summary: GCC should warn on repeated initializer for same array
element / struct member.
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rusty at rustcorp dot com.au
Target Milestone: ---
Hit a nasty cut & paste bug in my code (extra comma before +3):
int x[] = { [0] = 1, +3, [1] = 1 };
This double-initialization of x[1] should cause a warning. Similarly:
struct s { int a, b; } s = { .a = 1, .a = 2};
Thanks!
[Bug c/76732] GCC should warn on repeated initializer for same array element / struct member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76732
--- Comment #6 from rusty at rustcorp dot com.au ---
"manu at gcc dot gnu.org" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76732
>
> Manuel López-Ibáñez changed:
>
>What|Removed |Added
>
> CC||manu at gcc dot gnu.org
>
> --- Comment #3 from Manuel López-Ibáñez ---
> GCC already warns for this (for C)
>
> test.c:1:32: warning: initialized field overwritten [-Woverride-init]
> int x[] = { [0] = 1, +3, [1] = 1 };
Ah, thanks!
Surprised -Wall doesn't set -Woverride-init then; presume this was a
conscious decision?
I'll add it to my CFLAGS.
Thanks again!
Rusty.
[Bug c/106424] New: __attribute__ unused confuses -Wshadow when placed on internal parameter of fn ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106424
Bug ID: 106424
Summary: __attribute__ unused confuses -Wshadow when placed on
internal parameter of fn ptr
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rusty at rustcorp dot com.au
Target Milestone: ---
OK, this is a weird one. I have some automated code which adds attributes
and it (overzealously) added it to the internal parameter of a callback:
void func(char *arg,
void (*cb)(char *arg __attribute__((__unused__
{ }
With -Wshadow=local (and -Wshadow) this gives a spurious warning:
foo.c:2:28: warning: declaration of ‘arg’ shadows a parameter [-Wshadow]
2 | void (*cb)(char *arg __attribute__((__unused__
| ~~^~~
foo.c:1:17: note: shadowed declaration is here
1 | void func(char *arg,
| ~~^~~
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #47 from rusty at rustcorp dot com.au --- Civility please. We're all trying to find a path to improve things here. But accept that the conversation on this issue is only a weak indication of consensus. As Andrew Pinski says "people are mis-using this attribute", and Jakub Jelinek makes a similar point. The use of _wur has changed from "ignoring the result is criminally wrong" to "possibly wrong". I still put a comment complaining about this every time I hit it, which is about once or twice a year. But I have little more to say; it's been almost 20 year after all :)
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #81 from rusty at rustcorp dot com.au --- (In reply to Jakub Jelinek from comment #76) > (void) casts not quieting the warning was an intentional request when the > warning has been added, I really don't think it is a good idea to change > that. Indeed, but it wasn't called "dont_ignore_realloc", it seemed far more generic, and there wasn't an alternative for a long time. Once GLIBC started using it (such as for write()), it became an ongoing thorn in the side of many users :( The escalation continued with GNUlib implementing a suppression macro. (I'm not picking on the GNU project fighting itself here, but it's a clear case showing the problem). > Perhaps you can ask > glibc to recategorize some of the declarations to use [[nodiscard]] instead > of __attribute__((__warn_unused_result__)) ... > E.g. ignoring return value of realloc is pretty much always a bad idea and > just (void) realloc (...); is something that shouldn't be supported. Indeed! I think this is the solution (once [[nodiscard]] is old enough for projects to migrate). Not many function returns are as clearly required as realloc...
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #83 from rusty at rustcorp dot com.au --- > Then they shouldn't use warn_unused_result! The documentation of that is > very very clear: both about what it does, and about what situations it is > meant for. People who want something else should *use* something else! 1) In 2005 when this bug was reported, there was no alternative. There still isn't (for C, not C++). 2) Despite our best intentions, people use things in unintended ways, and it becomes something else. I have both sympathy for your viewpoint, and for users caught in the middle. Documentation says: "This is useful for functions where not checking the result is either a security problem or always a bug, such as ‘realloc’." If we added __attribute__((nodiscard)) a-la C++, then this would be a good place to recommend it for cases where you *almost* always want to consider the result. > The existing w_u_r is very obviously very useful though, as it is, and should > not be weakened in any way It is *so* useful it gets used anywhere you want to caution the user that they *probably* meant to check the result. But it does not follow that making (void) remove the warning vs a GNULib macro would not make it notably less useful.
