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=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.
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=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 *
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
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}
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=88879
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #14
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=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
: 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=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
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
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=85869
Arnd Bergmann changed:
What|Removed |Added
Keywords|build |
Target|x86_64-*-*, i?86-*-*
Severity: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312
--- Comment #8 from Arnd Bergmann ---
(In reply to David Malcolm from comment #7)
> Candidate patch:
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00778.html
I confirmed this fixes the problem on both the original source file as well as
the
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 42869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42869&action=edit
drivers/net/ethernet/cisco/enic/enic_main.c, preprocessed and compressed
Buil
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 42870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42870&action=edit
linux/lib/scatterlis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83408
--- Comment #2 from Arnd Bergmann ---
I've tried removing the architecture specific bits from the preprocessed file.
The issue is still unchanged on microblaze but I could not trigger it on x86,
the same file builds fine here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #10 from Arnd Bergmann ---
I have now observed the problem in another file, this one time that is more
commonly used, but not as drastic, as the stack usage is only around 1000
bytes.
The original source code is in
https://elixir.fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #11 from Arnd Bergmann ---
More testing reveals that a handful of files in the kernel are affected by this
bug in the BUG() definition on architectures that do not use an inline assembly
statement to trap during an assertion, around h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
--- Comment #5 from Arnd Bergmann ---
(In reply to Richard Biener from comment #3)
> That said, can't see an easy workaround but to change the source and/or
> not use -fsanitize= and expect decent code quality.
I don't see a good way to modify
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 42918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42918&action=edit
linux/drivers/tty/serial/8250/8250_core.c, preprocessed
I ran into one IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #12 from Arnd Bergmann ---
The first partial workaround for strncpy() got merged into Linux and stable
backports:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=146734b091430
Submitted a second partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83485
--- Comment #1 from Arnd Bergmann ---
Reduced test case:
struct uart_port {
char quirks;
};
struct uart_8250_port {
struct uart_port port;
int em485;
} b[1];
int a, c;
void fn1(void) {
struct uart_8250_port *d = &b[c];
d->port.quirks |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83409
Arnd Bergmann changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #1 from Arnd Bergmann ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
--- Comment #10 from Arnd Bergmann ---
I sent a (rather crude) workaround to the kernel mailing list now, mainly to
get the crypto maintainers involved in this as well. I also did further testing
and found that in the entire kernel, this is the o
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Following the discussion on PR83356, I did some more performance analysis of
the AES code with various compiler versions, by running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #1 from Arnd Bergmann ---
Before posting a new workaround for PR83356 (the workaround is to use -Os
instead of O2 for this file), I retested the performance numbers as well, and
got slightly different numbers this time. I don't know w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #16 from Arnd Bergmann ---
Created attachment 43056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43056&action=edit
linux/net/ipv6/route.c, preprocessed and compressed
To test the patch, I reverted the workaround that was adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #17 from Arnd Bergmann ---
Created attachment 43057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43057&action=edit
linux/drivers/scsi/lpfc/lpfc_bsg.c, preprocessed and compressed
A possibly related warning I just saw this wee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
--- Comment #11 from Arnd Bergmann ---
The second version of my workaround (build with 'gcc -Os' on gcc-7.1+) was
merged into mainline linux: https://patchwork.kernel.org/patch/10143607/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
--- Comment #12 from Arnd Bergmann ---
Unfortunately that patch caused a regression (nothing to do with the compiler
really, just the way powerpc linux uses some libgcc functions), and I've done
some more investigation. The new finding is that se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #2 from Arnd Bergmann ---
My kernel patch to use -Os got merged, but caused a regression, so I kept
experimenting with the libressl implementation. Apparently, turning off
-fcode-hoisting is a better way address PR83356, and the perfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #4 from Arnd Bergmann ---
(In reply to Aldy Hernandez from comment #3)
> (In reply to Arnd Bergmann from comment #0)
>
> > If there is enough interest in addressing the slowdown, it should be
> > possible to create a version of the k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
--- Comment #6 from Arnd Bergmann ---
Created attachment 43177
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43177&action=edit
Single-file version of aes benchmark
I've managed to condense the 'openssl speed aes-256-cbc' test into a singl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
Arnd Bergmann changed:
What|Removed |Added
Attachment #43177|0 |1
is obsolete|
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
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 #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
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=83985
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #2
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=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
--- 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
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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: 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 _
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
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=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 #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=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=82641
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #14
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
--- 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=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=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=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=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 #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=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=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
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=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.
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 #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
--- 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 #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 #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=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=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 #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=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 #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.
: 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=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, marxin
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
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
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
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 37604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37604&action=edit
standalone test case extracted from Linux kernel
With gcc versions 4.9 or high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702
--- Comment #2 from Arnd Bergmann ---
Thanks, I have now added -fno-tree-loop-im to the kernel gcov cflags, so files
we profile will be built with that. I can confirm that it fixes all stack size
warnings that show up with -fprofile-arcs, I found
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 37964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37964&action=edit
partially reduced test case
Using gcc-6.0 for building the Linux kernel, I see one file (out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #4 from Arnd Bergmann ---
I've tried out a few more things as well, to see if the alignment of the struct
lpfc_name type or the builtin memcpy makes a different. Replacing the array of
eight bytes with a single uint64_t and scalar ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #11 from Arnd Bergmann ---
For reference, I have sent a patch to the kernel to replace the open-coded
byteswap with a __builtin_bswap64. This produces much better object code with
both gcc-5 and gcc-6 than the original version, so it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #12 from Arnd Bergmann ---
Created attachment 37991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37991&action=edit
simpler test case without manual byte swap
For reference, I have sent a patch to the kernel to replace the ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #19 from Arnd Bergmann ---
I've confirmed that the current gcc trunk addresses the original problem in the
Linux kernel build, aside from the reduced test case. Thanks a lot for working
on this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
--- Comment #11 from Arnd Bergmann ---
(In reply to Nick Clifton from comment #10)
> Created attachment 38118 [details]
> This patch fixes your particular test case, but I am not sure if it will
> handle all of the ICEs in the kernel. Please c
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
After looking in more detail at -Wformat-overflow warnings in the linux
kernels, I managed to reduce one warning to this test case:
#include
void
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I came across a warning in the linux kernel with gcc-7.1.1:
arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
--- Comment #3 from Arnd Bergmann ---
It seems I got a little confused when I only looked at the initial patch that
was proposed, which was supposed to cover specifically the comparison followed
by ?: as in https://gcc.gnu.org/ml/gcc-patches/2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
--- Comment #5 from Arnd Bergmann ---
(In reply to Marek Polacek from comment #4)
> (In reply to Arnd Bergmann from comment #3)
> > It seems I got a little confused when I only looked at the initial patch
> > that was proposed, which was supposed
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
While testing the linux kernel with -fsanitize=signed-integer-overflow, I ran
into a bogus warning for sprintf format
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #4 from Arnd Bergmann ---
Thanks for the analysis. I have now submitted a local workaround for the
kernel, adding a temporary variable to avoid accessing the bitfield twice, see
https://patchwork.kernel.org/patch/9869037/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81592
--- Comment #2 from Arnd Bergmann ---
I have scanned the linux kernel sources for related bogus warnings and found
six others like this one that do not show up using gcc-7.1.1 without UBSAN but
do show up with UBSAN added in:
security/keys/proc.
1 - 100 of 228 matches
Mail list logo
