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
wit
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 ---
(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://tianocore.sourceforge.net/w
onent: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
David Woodhouse changed:
What|Removed |Added
CC||dwmw2 at infradead dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66871
--- Comment #2 from David Woodhouse ---
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 with preprocessing it and then looking f
: 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/in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #17 from David Woodhouse ---
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 of it, the lack of movbe in the 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #15 from David Woodhouse ---
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 movbe *without* killing kitte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #9 from David Woodhouse ---
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...@intel.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #5 from David Woodhouse ---
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.
mponent: c
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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #9 from David Woodhouse 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://git.kernel.org/linus/83a57a4d
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
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #7 from David Woodhouse 2012-11-08
14:29:37 UTC ---
Linux kernel patch to use the builtins at
http://marc.info/?l=linux-arch&m=135212414925921&w=2
I think I have the GCC version checks right there, for the availability of the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #5 from David Woodhouse 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* people to
use the appropriate b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #3 from David Woodhouse 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 *is* as simple as my test case, you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #1 from David Woodhouse 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:
.cfi_startproc
movlx(%r
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: U
--- 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
--- 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
ReportedBy: dwmw2 at infradead dot org
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
--- 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-un
--- 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 #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=12095&action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
t gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- 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
--- 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 #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_roo
--- 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 'cc
--- 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 #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=12084&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
.long 39682
--
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 a
ned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
ignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
failure 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 or
--- 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
: 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
ty: 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=27899
Severity: normal
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
--
What|Removed |Added
CC||dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
--- 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
quot;",@progbits
--
Summary: GCC fails to merge ranges in comparison.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- 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=8564&action=view)
offending source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
: critical
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.or
50 matches
Mail list logo
