https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #31 from joseph at codesourcery dot com ---
On Wed, 6 Dec 2017, glaubitz at physik dot fu-berlin.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
>
> --- Comment #30 from John Paul Adrian Glaubitz fu-berlin.de> ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #30 from John Paul Adrian Glaubitz ---
(In reply to jos...@codesourcery.com from comment #29)
> I don't see the issue building glibc with build-many-glibcs.py any more,
> hence it no longer uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #29 from joseph at codesourcery dot com ---
I don't see the issue building glibc with build-many-glibcs.py any more,
hence it no longer uses -fno-isolate-erroneous-paths-dereference
-fno-isolate-erroneous-paths-attribute for SH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #28 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #27)
>
> The problem is that with gcc-7 as the default compiler in Debian, this issue
> always results in glibc and the Linux kernel failing to build from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #27 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #26)
> What's the matter anyway? This issue has been around for like
> 2 years and now it can't wait a week or two?
The problem is that with gcc-7 as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #26 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Send it to gcc-patches@? If it is approved, I can commit it, sure.
>
> Ok, thanks! Will do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #25 from John Paul Adrian Glaubitz ---
(In reply to Segher Boessenkool from comment #24)
> Send it to gcc-patches@? If it is approved, I can commit it, sure.
Ok, thanks! Will do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #24 from Segher Boessenkool ---
Send it to gcc-patches@? If it is approved, I can commit it, sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #23 from John Paul Adrian Glaubitz ---
(In reply to Segher Boessenkool from comment #22)
> ?
>
> Why me? What do I have to do with this? It's SH code, I'm not
> an SH maintainer. /confused
I was wondering whether you could help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #22 from Segher Boessenkool ---
?
Why me? What do I have to do with this? It's SH code, I'm not
an SH maintainer. /confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #21 from John Paul Adrian Glaubitz ---
Maybe Segher could extende Oleg's patch and merge it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #20 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #19)
> (In reply to John Paul Adrian Glaubitz from comment #18)
>
> > I can confirm that the patch from comment #6 resolves the problem for me.
>
> Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #19 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> I can confirm that the patch from comment #6 resolves the problem for me.
Thanks for checking.
>
> Can we get it merged in one form or another?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #18 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #17)
> I'm testing the patch right now. Already rebuild gcc with the patch and I'm
> now building the kernel with that gcc.
I can confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #17 from John Paul Adrian Glaubitz ---
(In reply to Rich Felker from comment #16)
> The kernel build regression is just a gratuitous unresolved symbol; the code
> path where is happens should not be reachable or the kernel would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #16 from Rich Felker ---
The kernel build regression is just a gratuitous unresolved symbol; the code
path where is happens should not be reachable or the kernel would crash. So I
think the patch as-is is fine for fixing that issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #15 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #14)
> (In reply to John Paul Adrian Glaubitz from comment #13)
> >
> > What about glibc which originally resulted in this bug report?
>
> I have no idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #14 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #13)
>
> What about glibc which originally resulted in this bug report?
I have no idea about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #12)
> I don't think the patch will be immediately useful for a linux config. It
> will require more work.
What about glibc which originally resulted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #12 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> >
> > It's OK to add __builtin_trap to GCC 7.
> > Could you have a look and try the patch in Comment 6? I don't have so much
> > time for SH stuff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #11 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #10)
> > FYI this issue is currently a regression that prevents building Linux with
> > gcc7, since gcc7 introduced an optimization that transforms x/0 to
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #10 from Oleg Endo ---
(In reply to Rich Felker from comment #9)
> From a Linux standpoint, there is no trapa trap number defined that would
> cause a fatal signal. The ones that are defined are for syscalls and debug
> breakpoints.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #9 from Rich Felker ---
>From a Linux standpoint, there is no trapa trap number defined that would cause
a fatal signal. The ones that are defined are for syscalls and debug
breakpoints. On the other hand, a permanently-undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #8 from Oleg Endo ---
(In reply to Rich Felker from comment #7)
> Is there a reason we don't use an undefined instruction that will trap?
> 0xfffd is mentioned as permanently undefined here on page 85:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #7 from Rich Felker ---
Is there a reason we don't use an undefined instruction that will trap? 0xfffd
is mentioned as permanently undefined here on page 85:
http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #6 from Oleg Endo ---
Created attachment 38083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38083=edit
Proposed patch
This patch adds two new target options:
-msh4-trapa-sleep-bug
-mbuiltin-trap=
and two configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
Oleg Endo changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #3 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #2)
>
> I think that # less than 0x20 are reserved by kernel, gdb uses 0x20
> and 0xc3 and gcc uses 0x33 for profiling. Perhaps 0x54 (ascii 'T')
> or something?
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #2 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #1)
> For sh4-linux this option should be enabled by default with some useful trap
> number value. Which trap number should be used in this case?
I think that # less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
Oleg Endo changed:
What|Removed |Added
CC||aurelien at aurel32 dot net,
31 matches
Mail list logo
