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
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
: 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
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
ignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
ned at gcc dot gnu dot org
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
.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
--- 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
--- 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 'cc
--- 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 #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
t gnu dot org
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=12095&action=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-un
--- 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
: 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
--- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654
David Woodhouse changed:
What|Removed |Added
CC||dwmw2 at infradead dot org
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 #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=55177
Bug #: 55177
Summary: Missed optimisation: bswap, mask with constant, bswap
back again.
Classification: Unclassified
Product: gcc
Version: unknown
Status: U
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
--- 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 #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 #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
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
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=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...
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=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
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.
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
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=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
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
: 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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
David Woodhouse changed:
What|Removed |Added
CC||dwmw2 at infradead dot org
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=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
--
What|Removed |Added
CC||dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
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-05-18 12:33
---
Happens with gcc 3.4 too, and also on i386.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21643
ReportedBy: dwmw2 at infradead dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171
--- 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 #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
50 matches
Mail list logo
