http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48379
Andrew Church achurch+gcc at achurch dot org changed:
What|Removed |Added
CC||achurch+gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #6 from Andrew Church achurch+gcc at achurch dot org ---
Still broken for me, sorry. Using SVN r205727 with the patch, the assembly now
looks like:
_bar:
0: 55 push %ebp
1: 89 e5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #8 from Andrew Church achurch+gcc at achurch dot org ---
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
Andrew Church achurch+gcc at achurch dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
Andrew Church achurch+gcc at achurch dot org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #1 from Andrew Church achurch+gcc at achurch dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #2 from Andrew Church achurch+gcc at achurch dot org 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 #3 from Andrew Church achurch+gcc at achurch dot org 2013-04-02
07:53:08 UTC ---
The __chkstk_ms call comes from allocate_stack_worker_probe_mode in i386.md,
which is used in allocate_stack if the CHECK_STACK_LIMIT symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
--- Comment #22 from Andrew Church achurch+gcc at achurch dot org 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
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 undeclared identifier
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
--- Comment #27 from Andrew Church <achurch+gcc at achurch dot org> ---
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 ('.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
Andrew Church <achurch+gcc at achurch dot org> changed:
What|Removed |Added
Summary|__builtin_apply() tr
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=83292
--- Comment #3 from Andrew Church <achurch+gcc at achurch dot org> ---
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 arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
--- Comment #5 from Andrew Church <achurch+gcc at achurch dot org> ---
(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
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=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
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=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
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
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
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
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
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
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=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
--- 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
>
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
31 matches
Mail list logo
