https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654
David Woodhouse changed:
What|Removed |Added
CC||dwmw2 at infradead dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360
--- Comment #5 from David Woodhouse ---
Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't emit
it out-of-line. At least, from your citation, it mustn't emit it out-of-line
such that it can be seen from another translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360
--- Comment #3 from David Woodhouse ---
Thanks for the prompt response.
I'll stick with my original "compiler isn't required to emit" comment in my
referenced patch submission, which everyone had questioned...
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dwmw2 at infradead dot org
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Inline.html says:
> When an inline function is not static, then the compiler must assume
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
--- Comment #8 from David Woodhouse ---
(In reply to H.J. Lu from comment #7)
> As a workaround, you can try
> __builtin_ms_va_*
> instead of
> __builtin_va_*
The problem is that in the UEFI build we don't *know* what ABI we'll be built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169
--- Comment #4 from David Woodhouse ---
It's required by Windows but not by UEFI, which otherwise has the same ABI. We
had previously been able to build UEFI firmware with MinGW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169
--- Comment #2 from David Woodhouse dwmw2 at infradead dot org ---
(In reply to Andrew Pinski from comment #1)
I suspect i686-w64-mingw32 can never be used for self host binaries.
It has been. EDKII has toolchain configurations for it:
http
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dwmw2 at infradead dot org
Target Milestone: ---
$ echo 'void foo(void) { char lots[8192]; }' | i686-w64-mingw32-gcc -S -o- -xc
- -fstack-check=no
.file
.text
.globl _foo
.def_foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
David Woodhouse dwmw2 at infradead dot org changed:
What|Removed |Added
CC||dwmw2
: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: dwmw2 at infradead dot org
Target Milestone: ---
$ cat foo.S
.incbin foo.bin
$ gcc -Wp,-MD,foo.d -o foo.o -c foo.S
$ cat foo.d
foo.o: foo.S /usr/include/stdc-predef.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871
--- Comment #2 from David Woodhouse dwmw2 at infradead dot org ---
It would still be extremely useful for it to emit dependencies on those files
which are actually included (after preprocessing).
Otherwise we end up screwing around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #15 from David Woodhouse dwmw2 at infradead dot org ---
More missed optimistions (gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC))
I see it using movbe for the pointer_abuse() function, but can't see a simple
way to make it use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #17 from David Woodhouse dwmw2 at infradead dot org ---
Er, yes. Sorry, I originally tried it with uint16_t but it wasn't even using
movbe for the pointer_abuse() function then, so I made it 32-bit instead.
Badly. Come to think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #9 from David Woodhouse dwmw2 at infradead dot org ---
Thanks. This appears to work for me to build the Linux kernel's 16-bit boot
code with the patch at
http://lkml.kernel.org/r/1389180083-23249-3-git-send-email-david.woodho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #5 from David Woodhouse dwmw2 at infradead dot org ---
Note that LLVM/clang has a -m16 option now which does the same thing. Again,
not needing dirty hacks to ensure that asm(.code16gcc) really *is* the first
thing the assembler sees.
Assignee: unassigned at gcc dot gnu.org
Reporter: dwmw2 at infradead dot org
I'd like an attribute analogous to __attribute__((nonnull)) for function
arguments, except that it should indicate that an argument is *expected* to be
NULL. Or preferably, it could be applied to a *type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #9 from David Woodhouse dwmw2 at infradead dot org 2013-03-08
12:11:24 UTC ---
This is now enabled in the Linux kernel.
Core patch: http://git.kernel.org/linus/cf66bb93 (in v3.8 but does nothing
there)
x86:http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56370
Bug #: 56370
Summary: RFE: warn on 'foo = realloc(foo, …)'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #7 from David Woodhouse dwmw2 at infradead dot org 2012-11-08
14:29:37 UTC ---
Linux kernel patch to use the builtins at
http://marc.info/?l=linux-archm=135212414925921w=2
I think I have the GCC version checks right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
Bug #: 55177
Summary: Missed optimisation: bswap, mask with constant, bswap
back again.
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #1 from David Woodhouse dwmw2 at infradead dot org 2012-11-02
10:45:52 UTC ---
We have a similar issue with:
extern void func(void);
int baz(void)
{
if (__builtin_bswap32(x) 0x8)
func();
}
baz:
.LFB1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #3 from David Woodhouse dwmw2 at infradead dot org 2012-11-02
17:05:03 UTC ---
The first example isn't *that* dumb, as a cut-down test case of real code which
may look more complex in reality.
If the real code really
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #5 from David Woodhouse dwmw2 at infradead dot org 2012-11-02
19:41:28 UTC ---
Indeed. Bear in mind that sometimes we *hide* the actual variable (by prefixing
its name or putting it in a small struct of its own), just to *force
--- Comment #10 from dwmw2 at infradead dot org 2006-12-28 14:32 ---
Any progress on this?
--
dwmw2 at infradead dot org changed:
What|Removed |Added
CC
).
--
Summary: non-portable va_list abuse is permitted on i386
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2
--- Comment #2 from dwmw2 at infradead dot org 2006-12-12 17:33 ---
Yeah, fair enough. Enable the warning by default everywhere then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171
--- Comment #8 from dwmw2 at infradead dot org 2006-09-21 20:38 ---
Apologies -- GCC bugzilla mail was going missing due to being sent with a bogus
sender address. Will dig out a current test case if it's still an issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #1 from dwmw2 at infradead dot org 2006-08-19 09:26 ---
Created an attachment (id=12095)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12095action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #2 from dwmw2 at infradead dot org 2006-08-19 09:29 ---
Doesn't happen with '-O', or '-O2'. Only with '-Os' or '-O3'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #4 from dwmw2 at infradead dot org 2006-08-19 15:52 ---
/pmac/git/geode/include/linux/page-flags.h:252: error: conflicting types for
test_clear_page_dirty
Sounds like you don't have PR27898 fixed.
With -v ...
/opt/crosstool/gcc-4.1.0-glibc-2.3.6/i686-unknown-linux
--- Comment #5 from dwmw2 at infradead dot org 2006-08-18 08:10 ---
Yep, I got the mail. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
--- Comment #10 from dwmw2 at infradead dot org 2006-08-18 11:11 ---
I've hacked around this for now by reverting the patch for PR25795 and doing
this instead:
--- gcc/c-decl.c~ 2006-01-19 23:48:07.0 +
+++ gcc/c-decl.c2006-08-15 21:43:43.0 +0100
--- Comment #7 from dwmw2 at infradead dot org 2006-08-17 09:16 ---
The one with proc_mkdir was because the EXPORT_SYMBOL is in a different file to
the original function -- although my version was working correctly, I'm willing
to deal with that case.
The symbol 'proc_root' is also
--
Summary: duplicate members of arrays
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot
--- Comment #1 from dwmw2 at infradead dot org 2006-08-16 17:29 ---
Created an attachment (id=12084)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12084action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
--- Comment #2 from dwmw2 at infradead dot org 2006-08-16 17:33 ---
Mail should be sent from a valid address, because sending from an _invalid_
address can fall foul of antispam protection, as in the example shown.
Since the apparent sender does not accept bounces, the mail is rejected
--- Comment #6 from dwmw2 at infradead dot org 2006-08-16 18:11 ---
I don't think it's working right even with the new patch. I'll verify tomorrow,
and make sure I have all the correct patches included in my build. The point at
which I copied my ppc-cross-i386 'cc1' into
/usr/libexec
at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
--
Summary: Bugzilla mail sent from invalid address
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu
--- Comment #3 from dwmw2 at infradead dot org 2006-08-13 10:30 ---
That simple test case seems to have been fixed with your patch -- thanks.
Next failure reported as PR28706.
Full test cases in Red Hat bug #194327 at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194327
with --combine and packed structures.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27898
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27899
--
What|Removed |Added
CC||dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
CC: gcc-bugs at gcc dot gnu dot org,jakub at redhat dot com
http
--- Additional Comments From dwmw2 at infradead dot org 2005-05-18 12:33
---
Happens with gcc 3.4 too, and also on i386.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: ppc-redhat-linux
GCC target triplet: ppc64-redhat-linux
http://gcc.gnu.org/bugzilla
--- Additional Comments From dwmw2 at infradead dot org 2005-04-08 11:34
---
Created an attachment (id=8564)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8564action=view)
offending source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
50 matches
Mail list logo
