https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958
--- Comment #1 from Josh Poimboeuf jpoimboe at redhat dot com ---
Created attachment 33207
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33207action=edit
gzipped .i file for the good case
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Created attachment 33206
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33206action=edit
gzipped .i file for the bad case
When making changes to a certain source file in the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61958
--- Comment #2 from Josh Poimboeuf jpoimboe at redhat dot com ---
I see a similar issue with another patch to a different kernel file:
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index b10cd43a..40c275f 100644
--- a/net/ipv4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604
--- Comment #3 from Josh Poimboeuf ---
Hi Richard, thanks for looking at it!
(In reply to Richard Biener from comment #2)
> Are the cases you still see indirect jumps to only one active case or
> is it just that if()s with multiple cases would
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Target Milestone: ---
Created attachment 38226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38226=edit
iscsi_target.i.gz
The linux kernel has a new tool named "objtool" whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604
--- Comment #1 from Josh Poimboeuf ---
Created attachment 38227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38227=edit
Linux .config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #2 from Josh Poimboeuf ---
$ gcc -Wp,-MD,drivers/scsi/qla2xxx/.qla_attr.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include -I./arch/x86/include
-Iarch/x86/include/generated/uapi -Iarch/x86/include/generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #1 from Josh Poimboeuf ---
Created attachment 38256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38256=edit
Linux kernel config
: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Target Milestone: ---
Created attachment 38255
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38255=edit
qla_attr.i.gz
The linux kernel has a new tool named "objtool" which follows all possib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604
Josh Poimboeuf changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #17 from Josh Poimboeuf ---
(In reply to Richard Biener from comment #14)
> (In reply to Josh Poimboeuf from comment #13)
> > Interestingly, the function's epilogue (frame pointer restore) and return
> > instruction are also getting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #20 from Josh Poimboeuf ---
Thanks very much to everyone who has looked into this so far. It would be very
helpful to get answers to the following questions, so we can understand the
impact to the kernel:
1) Is there a reliable way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #13 from Josh Poimboeuf ---
So if I understand correctly, some reachable code is incorrectly getting marked
unreachable and then getting discarded.
Interestingly, the function's epilogue (frame pointer restore) and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #24 from Josh Poimboeuf ---
(In reply to Martin Jambor from comment #23)
> (In reply to Josh Poimboeuf from comment #20)
> > Thanks very much to everyone who has looked into this so far. It would be
> > very helpful to get answers
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Target Milestone: ---
In the Linux kernel, we found another case (other than bug 70646) where a
couple of functions are getting corrupted. Arnd Bergmann reduced it down to a
simple test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
--- Comment #6 from Josh Poimboeuf ---
(In reply to Arnd Bergmann from comment #5)
> 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?
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Target Milestone: ---
Created attachment 41968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41968=edit
fs_pin.i
With GCC 7.1, the kernel's object code static analysis tool (objtool) found
this unus
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
Target Milestone: ---
When compiling a patch for the Linux kernel, GCC crashes with the following
error:
gcc -Wp,-MD,arch/x86/events/.core.o.d -nostdinc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #3 from Josh Poimboeuf ---
This has been seen on Fedora GCC 7.1.1 and Debian GCC 6.2.0-3.
This bug can be recreated with the above kernel git branch and the attached
.config by typing "make ARCH=i386 arch/x86/events/core.o".
I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #2 from Josh Poimboeuf ---
Created attachment 42180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42180=edit
kernel config file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #1 from Josh Poimboeuf ---
Created attachment 42179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42179=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #7 from Josh Poimboeuf ---
Putting "sp" in the clobbers list is something that was suggested to me on the
GCC mailing list a while back. And, other than this rare bug, it seems to do
exactly what we want, which is, force GCC to save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #9 from Josh Poimboeuf ---
I might be misunderstanding, but I don't think we need DRAP for our use case.
We just need assurance that the frame pointer (RBP) has been set up before the
inline asm is inserted.
If clobbering "sp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #18 from Josh Poimboeuf ---
(In reply to H.J. Lu from comment #17)
> (In reply to Josh Poimboeuf from comment #7)
> > Putting "sp" in the clobbers list is something that was suggested to me on
> > the GCC mailing list a while back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #14 from Josh Poimboeuf ---
(In reply to H.J. Lu from comment #13)
> (In reply to Josh Poimboeuf from comment #12)
> > I would like to clarify that most of the time, when we use "sp" in the
> > clobbers list, the stack does *not*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #16 from Josh Poimboeuf ---
Ok. I thought you were saying that, with your new patch, putting "sp" in
clobbers would *always* force DRAP, even in cases where the function doesn't
need realignment.
If you're *not* saying that, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82221
--- Comment #12 from Josh Poimboeuf ---
While I know about DRAP, I'm otherwise not very familiar with GCC internals, so
I don't quite understand your points.
I would like to clarify that most of the time, when we use "sp" in the clobbers
list,
27 matches
Mail list logo
