On Sat, 2017-03-04 at 23:54:34 UTC, Anton Blanchard wrote:
> From: Anton Blanchard
>
> I see a panic in early boot when building with a recent gcc toolchain.
> The issue is a divide by zero, which is undefined. Older toolchains
> let us get away with it:
>
> int foo(int a) { return a / 0; }
>
>
From: Segher Boessenkool
> Sent: 06 March 2017 14:18
> On Mon, Mar 06, 2017 at 01:03:19PM +0100, Gabriel Paubert wrote:
> > > > > The PowerPC divw etc. instructions do not trap by themselves, but
> > > > > recent
> > > > > GCC inserts trap instructions on code paths that are always undefined
> > >
On Mon, Mar 06, 2017 at 01:03:19PM +0100, Gabriel Paubert wrote:
> > > > The PowerPC divw etc. instructions do not trap by themselves, but recent
> > > > GCC inserts trap instructions on code paths that are always undefined
> > > > behaviour (like, dividing by zero).
> > >
> > > Is it systematic o
On Sun, Mar 05, 2017 at 11:24:56AM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote:
> > > > Erk sorry. One of the static checkers spotted it, but I hadn't got
> > > > around to fixing it because it seemed to not actually blow up, guess
> > > > not.
On Sun, 2017-03-05 at 18:10 -0600, Segher Boessenkool wrote:
> You cannot really have something at address 0, the way NULL pointers
> are represented in GCC. 0 in firmware, so *fun*, especially before
> the
> CFAR was invented. "Something jumped to 0, CTR is 0 so it's probably
> a BCTR, but which
On Mon, Mar 06, 2017 at 10:09:01AM +1100, Benjamin Herrenschmidt wrote:
> > The compiler can do whatever it likes with code that has undefined
> > behaviour. With this optimisation it a) can compile the conforming
> > code to something better; and b) undefined behaviour will trap instead
> > of do
On Sun, 2017-03-05 at 11:24 -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote:
> > > > Erk sorry. One of the static checkers spotted it, but I hadn't got
> > > > around to fixing it because it seemed to not actually blow up, guess
> > > > not.
> > >
On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote:
> > > Erk sorry. One of the static checkers spotted it, but I hadn't got
> > > around to fixing it because it seemed to not actually blow up, guess
> > > not.
> >
> > The PowerPC divw etc. instructions do not trap by themselves, but
On Sun, Mar 05, 2017 at 06:37:37AM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2017 at 09:26:47PM +1100, Michael Ellerman wrote:
> > > I see a panic in early boot when building with a recent gcc toolchain.
> > > The issue is a divide by zero, which is undefined. Older toolchains
> > > let us
On Sun, Mar 05, 2017 at 09:26:47PM +1100, Michael Ellerman wrote:
> > I see a panic in early boot when building with a recent gcc toolchain.
> > The issue is a divide by zero, which is undefined. Older toolchains
> > let us get away with it:
> >
> > int foo(int a) { return a / 0; }
> >
> > foo:
> >
Anton Blanchard writes:
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index adf2084..afd1c26 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -408,7 +408,8 @@ static void init_cache_info(struct ppc_cache_info *info,
> u32
Anton Blanchard writes:
> From: Anton Blanchard
>
> I see a panic in early boot when building with a recent gcc toolchain.
> The issue is a divide by zero, which is undefined. Older toolchains
> let us get away with it:
>
> int foo(int a) { return a / 0; }
>
> foo:
> li 9,0
> divw 3,
On Sun, 2017-03-05 at 11:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2017-03-05 at 10:54 +1100, Anton Blanchard wrote:
> > From: Anton Blanchard
> >
> > I see a panic in early boot when building with a recent gcc
> > toolchain.
> > The issue is a divide by zero, which is undefined. Older to
On Sun, 2017-03-05 at 10:54 +1100, Anton Blanchard wrote:
> From: Anton Blanchard
>
> I see a panic in early boot when building with a recent gcc
> toolchain.
> The issue is a divide by zero, which is undefined. Older toolchains
> let us get away with it:
Maybe we should panic though ... not hav
From: Anton Blanchard
I see a panic in early boot when building with a recent gcc toolchain.
The issue is a divide by zero, which is undefined. Older toolchains
let us get away with it:
int foo(int a) { return a / 0; }
foo:
li 9,0
divw 3,3,9
extsw 3,3
blr
But ne
15 matches
Mail list logo
