Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1206394
| From | Andy Lutomirski <luto@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' |
| Date | 2015-08-13 00:30 +0200 |
| Message-ID | <pWMH1-TY-27@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <pWxHY-4Bz-21@gated-at.bofh.it> <pWxHY-4Bz-23@gated-at.bofh.it> <pWxHY-4Bz-25@gated-at.bofh.it> <pWxHY-4Bz-15@gated-at.bofh.it> <pWGrV-hj-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 08/12/2015 08:49 AM, Linus Torvalds wrote: > On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead.org> wrote: >> >> Maybe it's time to rely on gcc to handle 64 bit divisions now? > > Ugh. gcc still does a pretty horrible job at it. While gcc knows that > a widening 32x32->64 multiplication can be simplified, it doesn't do > the same thing for a 64/32->64 division, and always calls __udivdi3 > for it. > > Now, __udivdi3 does avoid the general nasty case by then testing the > upper 32 bits of the divisor against zero, so it's not entirely > disastrous. It's just ugly. > > But perhaps more importantly, I'm not at all sure libgcc is > kernel-safe. In particular, I'm not at all sure it *remains* > kernel-safe. Just as an example: can you guarantee that libgcc doesn't > implement integer division on some architecture by using the FP > hardware? > > There's been a few cases where not having libgcc saved us headaches. I > forget the exact details, but it was something like several years ago > that we had gcc start to generate some insane crap exception handling > for C code generation, and the fact that we didn't include libgcc was > what made us catch it because of the resulting link error. > > libgcc just isn't reliable in kernel space. I'm not opposed to some > random architecture using it (arch/tile does include "-lgcc" for > example), but I _do_ object to the notion that we say "let's use > libgcc in general". > > So no. I do not believe that the occasional pain of a few people who > do 64-bit divides incorrectly is a good enough argument to start using > libgcc. > Does your objection still apply if we supplied our own implementations of a handful of libgcc helpers? --Andy > Linus > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Christoph Hellwig <hch@infradead.org> - 2015-08-12 08:30 +0200
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-12 17:50 +0200
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Andy Lutomirski <luto@kernel.org> - 2015-08-13 00:30 +0200
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Andy Lutomirski <luto@amacapital.net> - 2015-08-13 00:40 +0200
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 00:40 +0200
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Andrew Morton <akpm@linux-foundation.org> - 2015-08-13 05:30 +0200
csiph-web