https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #79 from Andrew Church ---
(In reply to Segher Boessenkool from comment #78)
> If someone (the user, the author, anyone) used warn_unused_result where it is
> not appropriate, just fix *that*. The attribute is specifically for cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #77 from Andrew Church ---
(In reply to Segher Boessenkool from comment #72)
> if (foo()) {
> /* The return value of foo can be ignored here because X and Y. */
> }
This is just another idiom, with "if(){}" replacing "(void)"; it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #70 from Andrew Church ---
(In reply to Jonathan Wakely from comment #69)
> Maybe you want:
>
> [[maybe_unused]] auto _ = foo();
If I could apply that attribute to the value itself, i.e.:
[[maybe_unused]] foo();
that woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #68 from Andrew Church ---
(In reply to uecker from comment #67)
> But also the library could switch to "discard" or add a condition that the
> lets the user of the library choose it.
The issue here is that the library user has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #66 from Andrew Church ---
(In reply to Andrew Church from comment #65)
> As one of the advocates for this behavior, it stems (at least in my case)
> from pre-C23 code in which [[attribute]] syntax was not available. If
> [[nodiscard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #65 from Andrew Church ---
(In reply to Segher Boessenkool from comment #63)
> So you are asking the compiler to warn whenever you do not use the result
> of a function call, and at the same time you do not use the result of a
> funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #61 from Andrew Church ---
For the record, I'll maintain a copy of my (unaccepted) patch to add
-Wunused-result=strict at: https://achurch.org/patch-pile/#gcc
(wur-strict.diff)
This flag obviously shouldn't be relied on in released p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #53 from Andrew Church ---
(In reply to Segher Boessenkool from comment #51)
> And that is the core of why this issue reinflames once in a while: some
> people
> abuse the attribute, and the compiler cannot read minds.
Ah, for a mind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #48 from Andrew Church ---
(In reply to rusty from comment #47)
> Civility please.
I have no intention of trying to start a fight :) Like you, I'm just trying to
improve the situation, and knowing that in my own open-source work I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #46 from Andrew Church ---
(In reply to Andrew Pinski from comment #45)
> But there is no general agreement at all. If clang behavior agreed with gcc,
> then there would be consensus here. In fact gcc behavior is older than clang
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #44 from Andrew Church ---
(In reply to Segher Boessenkool from comment #43)
> That is not the consensus, no. "Consensus" does not mean doing what the
> unthinking masses shout.
Merriam-Webster disagrees:
con.sen.sus
1 a: general ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #42 from Andrew Church ---
(In reply to Sam James from comment #41)
> Could you send it to the gcc-patches mailing list please? (Even if it is a
> PoC).
Sent as requested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Andrew Church changed:
What|Removed |Added
CC||achurch+gcc at achurch dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92167
--- Comment #1 from Andrew Church ---
A similar problem occurs when passing the wrong number of arguments to a
function which has been renamed with a macro -- the diagnostic is associated
with the renaming macro instead of the original source lin
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
Given a macro which expands to a function call and passes a macro argument as
an argument in that call, if the macro argument is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
--- Comment #7 from Andrew Church ---
Would it be reasonable to have the FE warning trigger only on a literal null
value and not on variables whose values are known to be null? I don't know the
history behind -Wnonnull warning at two separate po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
--- Comment #5 from Andrew Church ---
Simpler testcase (based on the testcase in bug 87041):
extern int strcmp(const char *a, const char *b) __attribute__((nonnull(1, 2)));
int foo(void) {
const char * const s = 0;
if (s)
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041
--- Comment #9 from Andrew Church ---
Trunk r265614 with the patch from comment #8 no longer emits spurious warnings
from -Wformat for all of my cases which previously triggered such warnings.
Thanks for the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041
--- Comment #3 from Andrew Church ---
I agree it's a good idea to warn if the code is reachable, but if not, it's
only so much noise.
I can see that in this case the second const makes no difference to code
generation, but I'd prefer not to modi
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
In GCC 8, the following code compiled with -O1 -Wformat warns about passing
NULL to a %s format token e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
--- Comment #5 from Andrew Church ---
(In reply to Uroš Bizjak from comment #4)
> You can use __attribute__((__target__("no-mmx"))):
Thanks, that's useful to know and it seems to work around the problem for my
use case. That said, if __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
--- Comment #3 from Andrew Church ---
I use __builtin_return(__builtin_apply(...)) in library function wrappers for
failure injection in tests, so that I don't need to explicitly write out all
the arguments multiple times for each wrapped functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
Andrew Church changed:
What|Removed |Added
Summary|__builtin_apply() triggers |__builtin_apply(),
|x8
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
Calling a function with __builtin_apply() on 32-bit x86 causes the next x87
instruction to raise an x87 stack exception, as a side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
--- Comment #27 from Andrew Church ---
I've updated the undeprecation patch at http://achurch.org/patch-pile/#gcc for
4.9.4 and 6.2.0 (sorry about laziness).
I'm mildly amused at how the quotation style ('...' vs `...') and line wrap
column in t
verity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
Given the following code:
extern void foo(void);
void bar(int a, unsigned short b)
{
if (a >= 0 &&
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
For the first undeclared identifier found in a source file, GCC outputs an
additional diagnostic, "note: each undecl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Andrew Church changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Andrew Church changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #8 from Andrew Church ---
Yes, by replacing "0 - allocate" with "allocate" it seems to work fine. Sorry
for not trying it out myself earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #6 from Andrew Church ---
Still broken for me, sorry. Using SVN r205727 with the patch, the assembly now
looks like:
<_bar>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48379
Andrew Church changed:
What|Removed |Added
CC||achurch+gcc at achurch dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #3 from Andrew Church 2013-04-02
07:53:08 UTC ---
The __chkstk_ms call comes from allocate_stack_worker_probe_ in i386.md,
which is used in allocate_stack if the CHECK_STACK_LIMIT symbol is defined to a
nonzero value. CHECK_ST
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #2 from Andrew Church 2013-04-02
07:48:35 UTC ---
Created attachment 29774
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29774
testcase-2.c
Contains the definition of foo().
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #1 from Andrew Church 2013-04-02
07:47:41 UTC ---
Created attachment 29773
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29773
testcase-1.c
This file contains the bulk of the testcase. The function foo() has to be
de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Bug #: 56807
Summary: mingw32: Conflict between stack realignment and stack
probe destroys function argument in EAX
Classification: Unclassified
Product: gcc
Version: 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
--- Comment #22 from Andrew Church 2012-02-02
13:38:49 UTC ---
Created attachment 26553
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26553
Remove deprecation warning for -I- (gcc-4.6.2)
Patch against gcc-4.6.2 to remove the deprecation wa
37 matches
Mail list logo
