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
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=edit
standalone test case extracted from Linux kernel
With gcc versions 4.9 or higher, the st
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
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=edit
partially reduced test case
Using gcc-6.0 for building the Linux kernel, I see one file (out of many
hund
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
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=edit
simpler test case without manual byte swap
For reference, I have sent a patch to the kernel to replace the
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #13 from Arnd Bergmann ---
(In reply to wilco from comment #12)
> Does wp512 use 64-bit types? If so, this is likely PR77308.
Yes, as seen in the attachment it uses lots of 64-bit operations. However, it
sounds like PR77308 is ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #11 from Arnd Bergmann ---
I've submitted a workaround for the kernel now, addressing the stack usage
warning on MIPS, as well as performance on ARM and others:
https://patchwork.kernel.org/patch/9555183/
The patch has two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #10 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #9)
> "-fsched-pressure" on mips64 helps a lot
> ...
> On arm and aarch64, "-fsched-pressure" has no effect
I realized later that on arm and aarch64,
rsion: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into a variant of pr78569, again building the kernel, reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
Arnd Bergmann changed:
What|Removed |Added
Version|7.0 |7.0.1
--- Comment #2 from Arnd Bergmann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
--- Comment #9 from Arnd Bergmann ---
I successfully rebuilt all the (now seven) previously failing kernel
configurations, no more ICE.
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
Arnd Bergmann changed:
What|Removed |Added
Attachment #40546|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #9 from Arnd Bergmann ---
The warning seems to reliably disappear with -fno-schedule-insns, on every
combination I've tried it produces better (smaller stack and faster code) or
identical results to -fno-sched-critical-path-heuristic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79210
--- Comment #5 from Arnd Bergmann ---
Created attachment 40596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40596=edit
test case with correct whitespace
I thought I had tried it with the source pasted from the bug last time, but
trying
Priority: P3
Component: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Building the Linux kernel with gcc-plugins enabled currently fails for ARM:
In file included from
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #30 from Arnd Bergmann ---
This seems to fix the majority of the failures I have run into, but I still see
the ICE with both the 0x2F25F020 and 0xB0981CD0 builds, see comments 18 through
21.
Should I open a new report for those?
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 40546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40546=edit
compressed preproces
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
A variant of pr79058, which is already fixed by r244535, but a couple remain,
and also bisect to r243578:
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #1 from Arnd Bergmann ---
Additional information:
I see the same behavior to a varying degree on most other architectures (but
notably not x86) using the preprocessed source from the MIPS kernel
configuration, these are always one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
--- Comment #5 from Arnd Bergmann ---
-fno-schedule-insns is comparable in stack frame size to
"-fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic" on all
architectures (give or take a few bytes), but actually produces much better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79777
--- Comment #3 from Arnd Bergmann ---
Fix confirmed with all configurations that previously showed the problem.
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
--- Comment #5 from Arnd Bergmann ---
I checked the test case using "-fsanitize=unreachable" and that avoids the
problem.
Josh, should we set that whenever we enable objtool in the kernel?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 40180
--> https://gcc.gnu.org/bugzilla/attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78169
--- Comment #5 from Arnd Bergmann ---
I just tried reproducing the earlier bug with my gcc build and failed to get
the ICE, so I assume this is a different problem despite also getting "internal
compiler error: in get_substring_ranges_for_loc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78169
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #4
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
When building a Linux kernel with arm-linux-gnueabi-gcc (GCC) 7.0.0 20161115, I
ran into an error from the assembler:
/tmp/cchIg3BB.s:589: Error: bit-field extends past end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78376
--- Comment #1 from Arnd Bergmann ---
Created attachment 40055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40055=edit
preprocessed drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
adding gzipped version of the preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78376
Arnd Bergmann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78364
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #20 from Arnd Bergmann ---
// new reduced test case, build with "arm-linux-gnueabi-gcc-7.0.0 -c -Os
-mbig-endian"
struct nilfs_segment_usage {
int su_flags;
} a;
enum { NILFS_SEGMENT_USAGE_ACTIVE, NILFS_SEGMENT_USAGE_DIRTY } fn1();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #21 from Arnd Bergmann ---
// reduced version of 0xB0981CD0 file
long a;
struct {
int su_flags;
} * b;
struct nilfs_segment_usage *e;
void fn1();
enum { NILFS_SEGMENT_USAGE_ACTIVE, NILFS_SEGMENT_USAGE_DIRTY } fn2() {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #19 from Arnd Bergmann ---
Created attachment 40516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40516=edit
preprocessed linux-4.10/fs/nilfs2/sufile.c source, 0xB0981CD0 build
Another version of the source file, also still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #17 from Arnd Bergmann ---
(In reply to Dominik Vogt from comment #16)
> Or rather this one which avoids triggering an assertion failure in
> in_hard_reg_set_p ():
I tried this version, and while it fixes the test case I originally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #18 from Arnd Bergmann ---
Created attachment 40515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40515=edit
preprocessed linux-4.10/fs/nilfs2/sufile.c source, 0x2F25F020 build
The file is slightly different, because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #5 from Arnd Bergmann ---
Created attachment 40511
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40511=edit
rtl dump 256r.ed_dce and 257r.combine
Here are four dumps, I hope this is what you are asking for:
latest gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
Arnd Bergmann changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 40502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40502=edit
preprocessed linux-4.10/fs/nilfs2/sufil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78569
--- Comment #7 from Arnd Bergmann ---
Confirmed fixed for all source files in which I'd seen the problem. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160
--- Comment #6 from Arnd Bergmann ---
I've run into a four other files in the kernel sources that show this bug. I've
confirmed that the patch in comment 4 addresses all of them.
: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 41032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41032=edit
linux/fs/eventpoll.c, preprocessed, compressed
After upgrading to r246365 and do
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 41033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41033=edit
linux/arch/x86/mm/pageattr.c preprocessed and compressed
I ran into this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
--- Comment #9 from Arnd Bergmann ---
Sent a kernel patch to avoid the problem:
http://www.spinics.net/lists/intel-gfx/msg123586.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
--- Comment #8 from Arnd Bergmann ---
Looking at the kernel code again, I came up with an alternative that avoids the
large stack size and produces good executable code in all configurations I
found with the file that showed up a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #8 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #6)
> If the warning has false positives, then I'm sure the kernel will turn it
> off anyway like it does with tons of other warnings.
That is well possible. I try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
--- Comment #2 from Arnd Bergmann ---
(In reply to Richard Biener from comment #1)
> Note such warning in the middle-end has the chance of false
> positives from (for example) path isolation.
Would it be possible to warn if a function always
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Building the kernel with gcc-7.0.1 (r245831 at the time of testing), we ran
into a warning from objtool about a function ending in an undefined
instruction:
drivers/pwm/pwm-hibvt.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79740
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #7
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 40860
--> ht
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
With the latest gcc-7.0.1 snapshot, I got lots of these failures building
random linux kernel configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79778
--- Comment #2 from Arnd Bergmann ---
(In reply to Richard Biener from comment #1)
> Dup of PR72785?
I thought we had worked around PR72785 in the kernel, and I had not run into
that problem until updating my gcc-7.0.1 snapshot yesterday.
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:
: 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/
: 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
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 41989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41989=edit
preprocessed linux/mm/shmem.c file, compressed
I ran into a few files in the li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #2 from Arnd Bergmann ---
This is a reduced test case that triggers with gcc-4.9 and higher (latest
tested is 7.1.1)
$ arm-linux-gnueabi-gcc-7.1.1 -mword-relocations -march=armv7-a -O2 -Wall -c
test-ww_mutex.c
$ objdump -dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #3 from Arnd Bergmann ---
The __builtin_prefetch() that caused the problem in the test case from comment
2 might be a red herring, I already noticed earlier that the bug shows up both
in configurations that use a built-in function
: 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
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: ?: using integer
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
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
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
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I keep seeing a class of false-positive -Wmaybe-uninitialized in the linux
kernel and have done countless kernel patches to work around them. The latest
one triggered me to look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
Arnd Bergmann changed:
What|Removed |Added
Known to work|6.3.1 |
--- Comment #1 from Arnd Bergmann ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #7 from Arnd Bergmann ---
Created attachment 42009
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42009=edit
preprocessed net/rds/recv.i
(In reply to ard.biesheuvel from comment #6)
> FWIW, the following makes the issue go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #3 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #2)
> Created attachment 42178 [details]
> preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed
>
> This is one of the typical files showing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #2 from Arnd Bergmann ---
Created attachment 42178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42178=edit
preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed
This is one of the typical files showing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
--- Comment #24 from Arnd Bergmann ---
Created attachment 42194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42194=edit
r234568 ported to gcc-5
I ran into this old bug again while build testing with gcc-4.9.4 and gcc-5.4.1.
I checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
--- Comment #25 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #24)
> Created attachment 42194 [details]
> r234568 ported to gcc-5
>
> I ran into this old bug again while build testing with gcc-4.9.4 and
> gcc-5.4.1. I checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #4 from Arnd Bergmann ---
Created attachment 42195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42195=edit
preprocessed net/wireless/nl80211.c, compressed
This is another file that shows the problem, in fact we hit this with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #6 from Arnd Bergmann ---
(In reply to Martin Liška from comment #5)
> I can confirm that for the biggest function 'nl80211_send_wiphy', it really
> contains majority of stack variables which are 4B large. Having an adaptive
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #8 from Arnd Bergmann ---
(In reply to Martin Liška from comment #7)
> Ok, I'm quite opened for changes that will make smaller red zones for
> smaller variables. However, in case of sanitization-aware inlining, it's
> probably too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #13 from Arnd Bergmann ---
Tested the fix with an x86 allmodconfig kernel (linux-next, with
-fsanitize-address-use-after-scope disabled manually). With an arbitrary limit
of 1500 bytes (the default is no limit when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #10 from Arnd Bergmann ---
As far as I can tell, gcc doesn't merge stack slots that came from inline
functions, as in comment 1, or this example:
void baz (int *, int *, int *, int *, int *, int *);
static inline void foo (int a,
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I found several instances of a new warning in the linux kernel, building with
"gcc-8.0.0 -std=gnu89", reduced a test case to this:
$
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
gcc-8 started warning about function aliases that have a non-matching
prototype. This seems rather useful in general, but it causes tons of warnings
in the Linux kernel, where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
--- Comment #10 from Arnd Bergmann ---
I get a clean kernel build now with that option, thanks a lot for your help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
--- Comment #5 from Arnd Bergmann ---
(In reply to Bernd Edlinger from comment #4)
> Arnd, excuse me for possibly silly question.
>
> Why is it necessary to have
> sys_bla(with correct paramters)
> and
> SyS_bla(with generic parameters)
>
> On
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I've looked at warnings I get in the Linux kernel with older compilers but not
with more modern versions. Unsurprisingly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #3
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This one seems to be related to pr77721 and pr81483. The first however only
happens with -Wformat-overflow=2, and the second one has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #3 from Arnd Bergmann ---
I tried replacing the call to a noreturn function with a
__builtin_unreachable() statement, same result.
However, adding an empty assembler statement before the noreturn statement or
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #10 from Arnd Bergmann ---
(In reply to Yvan Roux from comment #8)
>
> /* Nonzero if this chip provides the MOVW and MOVT instructions. */
> -#define TARGET_HAVE_MOVT (arm_arch_thumb2 || arm_arch8)
> +#define
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
building many random configurations of the linux kernel using a gcc-8.0.0
snapshot (20170821) found a couple of bugs with -Wmaybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82098
--- Comment #2 from Arnd Bergmann ---
The patch from comment fixes all instances for me, in nine distinct source
files.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Created attachment 42114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into a segmentation fault on today's snapshot (now at r251683):
$ x86_64-linux-gcc-8.0.0 -c pt3_i2c.c
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
On a current snapshot (tested with r251683), I get a warning that seems
unhelpful and probably should not be there.
This happened in exactly one file from the Linux kernel so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #6 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #5)
> Now, if you change the code so that
> i2c_new_device();
> comes first and then
> f(a);
> this would no longer be optimized, because in the common fortify_panic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82437
--- Comment #3 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #2)
> Untested fix.
This appears to address all instances of the problem for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
--- Comment #3 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #1)
> The warning can be selectively suppressed by declaring the alias to have no
> prototype, e.g., like so:
>
> int bar (int i) { return 0; }
> int foo ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
--- Comment #8 from Arnd Bergmann ---
I noticed that I never resubmitted my workaround for the kernel for this
problem, and nothing happened on the gcc side either. To make sure I capture
the situation correctly in the kernel patch changelog,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
--- Comment #5 from Arnd Bergmann ---
In that case, shouldn't we also warn if the conditional function call in front
of it wasn't there, or without the '__n != 0' check?
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=edit
drivers/net/ethernet/cisco/enic/enic_main.c, preprocessed and compressed
Building an 'allmodcon
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=edit
linux/lib/scatterlist.c,
1 - 100 of 227 matches
Mail list logo
