https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174
--- Comment #7 from Arnd Bergmann ---
I confirmed that the patch from comment #6 addresses the build warnings I see
in the kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
--- Comment #2 from Arnd Bergmann ---
The warning is now turned off in the kernel as a workaround:
https://lore.kernel.org/all/CAHk-=whzbdlc024nxgjesfoopj9bo2bkuxhxr4h5wosyk9a...@mail.gmail.com/
Also, my local one-line workaround is applied fo
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #7
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
A warning showed up in Linux kernel builds with code that has a data structure
with sub-byte holes in it, making it appear as
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I tried to build a set of cross compilers for all target architectures. Build
architecture is arm64, host architecture is x86_64 or ppc64le, both of them
fail the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #19
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
During the discussion of increasing the C standard version of the Linux kernel
fro m gnu89 to gnu99 or higher, it turned out that gcc warns about code that
shifts negative signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
--- Comment #27 from Arnd Bergmann ---
The linux kernel instance from arch/parisc/ looks like a bug we fixed in
arch/arm a few years ago, by adding the required alignment directive to the
linker script.
If changing the linker script is not poss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
--- Comment #4 from Arnd Bergmann ---
I posted a set of kernel patches to address all the warnings I found at
https://lore.kernel.org/lkml/20210322160253.4032422-1-a...@kernel.org/T/#t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
--- Comment #2 from Arnd Bergmann ---
Thank you for the detailed analysis. This was the last such warning I get with
linux kernel randconfig build that I could not explain based on the earlier
discussion, so now I can submit the local workarounds
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
Bug 92860 depends on bug 99592, which changed state.
Bug 99592 Summary: arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
Arnd Bergmann changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
--- Comment #6 from Arnd Bergmann ---
Created attachment 50395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50395&action=edit
preprocessed /usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h
I've changed from the Ubuntu gcc-11 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600
--- Comment #9 from Arnd Bergmann ---
I now built gcc with and without the patch from attachment 50390 to find more
broken kernel configurations and verify that they are all fixed. So far, all
the broken configurations are fixed by the patch, I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
--- Comment #4 from Arnd Bergmann ---
$ arm-linux-gnueabihf-gcc-11 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/11/lto-wrapper
Target: arm-linux-gnueabihf
Configured wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
Arnd Bergmann changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600
Arnd Bergmann changed:
What|Removed |Added
CC||jakub at redhat dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600
--- Comment #1 from Arnd Bergmann ---
https://godbolt.org/z/z7h7r3
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Testing random Linux kernel builds with gcc-11 killed my box before I had a
reasonable "ulimit -d" limit set when it filled u
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into this internal compiler error while building the Linux kernel in
random configurations, made a reduced test case:
$ arm-linux-gnueabihf-gcc-11 -Os -mtune=xscale -c
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Including the arm_neon header fails when building with the 'pg' option
$ arm-linux-gnueabihf-gcc-11 --version
arm-linux-gnueabihf-gcc-11 (Ubuntu 11-2021031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #6 from Arnd Bergmann ---
I figured out the qnx4 warning in the end: https://godbolt.org/z/hvqjr3
struct qnx4_inode_entry {
char di_status;
union {
struct {
char di_fname[16];
char di_pad[32];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #5 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #4)
> Most warnings designed to detect invalid accesses (not just
> -Wstringop-overread but also -Wstringop-overflow and
> -Wformat-overflow/-truncation, -Wrestrict, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #3 from Arnd Bergmann ---
After some more analysis, I found that the -Wstringop-overread warning only
happens here (and presumably in all the other cases I found) because I disabled
-Warray-bounds for gcc-11.
I'm still looking at -Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #2 from Arnd Bergmann ---
Ok, I see. Thanks for the explanation!
I found a couple other instances (so far all false positive) and will see if
any of them have a sane workaround. I'll probably just turn off both flags
globally for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567
Arnd Bergmann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567
--- Comment #2 from Arnd Bergmann ---
*** Bug 99570 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570
Arnd Bergmann changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567
--- Comment #1 from Arnd Bergmann ---
*** Bug 99574 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99574
Arnd Bergmann changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This snippet from the Linux kernel reads a data structure from an
architecturally defined location in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570
--- Comment #1 from Arnd Bergmann ---
I suppose this is a duplicate of #99567 and #99574, these happen with different
compiler flags, but the backtrace is always the same.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Another internal compiler error from building a linux kernel, this time on
x86-32, reduced to:
$ cat sem.c
struct {
short a;
} * b
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This happens in a couple of files when building the linux kernel with -Os,
reduced a test case to:
$ cat compaction.i
typedef struct {
long a
} b;
enum c { d } e[];
af, ah;
f(b *g
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into an internal compiler error while building linux kernels with the
kernel address sanitizer. Reduced it to this test case
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Building an 'allmodconfig' linux kernel for ARC results in a failure to
assemble one file:
{standard input}
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I reported a bug against clang for a Linux kernel failure, but
it was suggested that the clang behavior is probably correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94881
--- Comment #2 from Arnd Bergmann ---
I ran into another file that triggered this problem, reducing that one gave me
a slightly simpler test case:
struct a {
char b[8];
};
struct e {
unsigned c;
struct a d[2];
};
void i(struct e *e, void *
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94076
--- Comment #2 from Arnd Bergmann ---
I'm not at the point of the bootstrap where I can attempt building llvm, but I
opened another report at https://bugs.llvm.org/show_bug.cgi?id=45138 anyway.
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I tried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #16 from Arnd Bergmann ---
Right, I was on the releases/gcc-9 branch, not HEAD. Sorry about the confusion.
I applied your fix and have a working 9.2 build that can build the kernel now.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84863
--- Comment #3 from Arnd Bergmann ---
The problem in the kernel then is that we then have to turn off the sanitizers
for the 'allmodconfig' build, since the recommended minimum regression testing
for kernel changes involves building a kernel with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #32 from Arnd Bergmann ---
(In reply to Martin Liška from comment #31)
> (In reply to Arnd Bergmann from comment #30)
> > (In reply to Martin Liška from comment #29)
> > > Which is very promising improvement I would say.
> >
> > Agre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #30 from Arnd Bergmann ---
(In reply to Martin Liška from comment #29)
> I'm got a patch candidate for which I did testing of allmodconfig
> configuration.
> Sorting all violations against 2KB of stack memory:
>
> Before:
> TOTAL war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #13 from Arnd Bergmann ---
(In reply to Andreas Schwab from comment #12)
> arch/h8300/kernel/sim-console.c: register const int fd __asm__("er0") =
> 1;
I found that too, and then noticed it is already fixed in linux-next:
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #11 from Arnd Bergmann ---
I have checked all instances of 'register const' or 'const register' in the
current linux kernel (4.18-rc), and we never assign a constant expression to
any of them, so I guess none of them are affected:
ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #9 from Arnd Bergmann ---
Reproduced on arm64 and x86 as well, see x86 version:
void fn1() {
register const int h asm("edx") = 1;
__asm__(".ifnc %0,edx; .err; .endif" :: "r"(h));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #5 from Arnd Bergmann ---
(In reply to Andreas Schwab from comment #4)
> Why are you using empty constraints when a register is required?
creduce did that, it had no effect on the result. The original source looks
like:
#define __ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
Arnd Bergmann changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #1 from Arnd Bergmann ---
Further inspection shows that this happens for the cases where the input
argument to the inline asm is a compile-time constant, but not for those that
are variables.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 44438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44438&action=edit
linux/n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85869
Arnd Bergmann changed:
What|Removed |Added
Keywords|build |
Target|x86_64-*-*, i?86-*-*
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I tried cross-building (for host=ppc64le) a set of cross-toolchain on an x86_64
build system. This fails for the target=i386 compiler with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
--- Comment #6 from Arnd Bergmann ---
I found that older versions (gcc-5 and before) did not warn when the type gets
changed to bitfield of '_Bool' rather than 'unsigned int'. It seems that this
was only because they tested each bit separately in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84732
--- Comment #9 from Arnd Bergmann ---
One more instance got added to the kernel today:
In file included from /git/arm-soc/include/trace/perf.h:90,
from /git/arm-soc/include/trace/define_trace.h:97,
from /git/arm
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
A Linux kernel patch that changed a few flags from type 'int' to a single-bit
bitfield caused a false-positive warning. I reduced a test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175
--- Comment #5 from Arnd Bergmann ---
Improving the optimizer will definitely help this one, but not the other
instances I found. Here's a list of the remaining warnings that got introduced
in the linux kernel by r257857 for reference:
https://e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175
--- Comment #3 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #2)
> So with the change above GCC is doing a better but imperfect job of
> determining the range. Changing the variable to unsigned constrains the
> lower bound to ze
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This snippet from the Linux kernel produces a bogus warning when built with gcc
-Os, using a recent snapshot (20180402
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84732
--- Comment #5 from Arnd Bergmann ---
Created attachment 43586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43586&action=edit
drivers/gpu/drm/drm_property.c, preprocessed
I found another case that appears to be related but not the same,
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #26 from Arnd Bergmann ---
(In reply to Martin Liška from comment #25)
> (In reply to Arnd Bergmann from comment #24)
>
> Ok, I don't have problem to implement the similar behavior in GCC 9. Looks
> most
> of warnings are in drivers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #24 from Arnd Bergmann ---
(In reply to Martin Liška from comment #23)
> That's definitely possible for GCC 9. Question is whether such change will
> be sufficient for you. Do you expect it will reduce stack usage in the
> desired wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #22 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #20)
> I haven't heard any answer to #c16 whether it actually helped the kernel or
> not.
Sorry about that. Yes, it definitely helped the kernel a lot. At this point,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #15 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #14)
> I applied the patches and seem to still get a warning for this
I also just got the one from comment #9 again and found that the reduced test
case is still affe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #14 from Arnd Bergmann ---
I applied the patches and seem to still get a warning for this:
$ x86_64-linux-gcc-8.0.1 -Wall -O2 -c nmi_int.c
nmi_int.c: In function 'nmi_setup':
nmi_int.c:43:3: warning: 'memcpy' source argument is the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #27 from Arnd Bergmann ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Arnd Bergmann from comment #25)
>
> > or to apply more force and add the ".arch" to each inline
> > asm individually.
>
> No, that would not b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #25 from Arnd Bergmann ---
(In reply to Tamar Christina from comment #24)
> Do you have a repro for this one? compiling the kernel with
> `CFLAGS="march=-armv4t"` doesn't seem to reproduce the original issue.
It needs to be a kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #23 from Arnd Bergmann ---
I've done some more testing with '#pragma GCC target("arch=armv5te")' in place,
but ran into another problem:
: note: this is the location of the previous definition
In file included from /git/arm-soc/inclu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #9 from Arnd Bergmann ---
I found another false-positive -Wrestrict warning, did a manual reduction. Let
me know if I should better open separate bugs for each test case, or you prefer
to have them all here.
$ aarch64-linux-gcc-8.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #8 from Arnd Bergmann ---
Created attachment 43295
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43295&action=edit
linux/drivers/isdn/isdnloop/isdnloop.c, preprocessed, compressed
This is the preprocessed file that showed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #19 from Arnd Bergmann ---
(In reply to Richard Earnshaw from comment #18)
>
> So you're changing the targetted architecture behind the compilers back. Ie
> you're lying to it. Frankly, you deserve to get burnt if you do things lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #16 from Arnd Bergmann ---
Here is a simplified version of the file in question, to try as standalone:
typedef unsigned int u32;
asm(".arch armv5te\n");
extern int cpuid;
static _Bool cpu_is_xscale_family()
{
/* this code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #6 from Arnd Bergmann ---
I got one file that produces a rather cryptic warning related to this:
In file included from /git/arm-soc/arch/x86/include/asm/page_32.h:35,
from /git/arm-soc/arch/x86/include/asm/page.h:14,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #5 from Arnd Bergmann ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related, shutti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
--- Comment #2 from Arnd Bergmann ---
Created attachment 43281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281&action=edit
preprocessed simplified sm_sideeffect.c, compressed
I managed to get a standalone testcase now, manually reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #3 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #2)
> (In reply to Arnd Bergmann from comment #0)
>
> Let me work on this.
>
> I tested the warning with the kernel but don't recall coming across this
> false positiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
--- Comment #3 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #1)
> I vaguely remember the behavior of packed + aligned(N) kept changing in the
> past, some versions of GCC treated it just like packed, others as aligned.
> Is this
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Marking a struct member as both 'packed' and 'aligned()' triggers a warning in
gcc-8:
struct s {
char x;
int y _
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I got an ICE while building the linux kernel module net/sctp/sctp.ko with
i386-linux-gcc
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I see multiple new warnings for correct code in the Linux kernel for code that
copies one array member into other members of the same array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038
Arnd Bergmann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985
--- Comment #7 from Arnd Bergmann ---
*** Bug 84038 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038
Arnd Bergmann changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #2 from Arnd Bergmann ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985
Arnd Bergmann changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83985
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #2
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 43240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43240&action=edit
linux/kernel/cpu.c, preprocessed and compressed
I tried build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #15 from Arnd Bergmann ---
(In reply to rguent...@suse.de from comment #14)
> Would be nice if somebody can bisect it. It doesn't look like a PRE
> specific issue because there's no relevant PRE changes in the rev. range.
> I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #13 from Arnd Bergmann ---
Created attachment 43185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43185&action=edit
Linux kernel version of AES algorithm, ported to standalone executable
I've had another look at extracting a t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #11 from Arnd Bergmann ---
Trying out the patch from comment 10 on the original preprocessed source as
attached to pr83356 also shows very noticeable improvements with stack spilling
there:
x86_64-linux-gcc-6.3.1 -Wall -O2 -S ./aes_g
1 - 100 of 228 matches
Mail list logo
