[oops pushed] aarch64: Fix vld1/st1_x4 intrinsic definitions

Gah. As mentioned on irc, I'd written this patch to fix PR114521. The bug was fixed properly by Jonathan's struct rework in GCC 12, but that's much too invasive to backport. The attached patch therefore deals with the bug directly. Since it's new work, and since there's only one GCC 11 release

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

>>> Together with Dmitry (ldv) , we've discovered that running test suite >>> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 >>> or with gcc 7.2 , but not with gcc 6 : >> >> Please try this patch: > > Dave, > > this patch fixes OOPS, thanks. Tested on ldom (gcc 7.2, git kernel + > patch, git strace). Thanks for testing.

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

t; Together with Dmitry (ldv) , we've discovered that running test suite >>> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 >>> or with gcc 7.2 , but not with gcc 6 : >> >> Please try this patch: > > Dave, > > this patch fixes OOPS, tha

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

On Wed, Aug 16, 2017 at 7:30 AM, David Miller <da...@davemloft.net> wrote: > From: Anatoly Pugachev <mator...@gmail.com> > Date: Tue, 15 Aug 2017 21:50:45 +0300 > >> Together with Dmitry (ldv) , we've discovered that running test suite >> from strace produces ker

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

From: Anatoly Pugachev <mator...@gmail.com> Date: Tue, 15 Aug 2017 21:50:45 +0300 > Together with Dmitry (ldv) , we've discovered that running test suite > from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 > or with gcc 7.2 , but not with gcc 6 : Please try th

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

From: Anthony Yznaga Date: Tue, 15 Aug 2017 17:45:12 -0700 > I compiled a kernel with gcc 7 and found that the compiler inserted a > call to __multi3() in mq_attr_ok(). The sparc64 implementation of > __multi3() was added by 1b4af13ff2cc specifically for gcc 7 and

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

> On Aug 15, 2017, at 11:50 AM, Anatoly Pugachev <mator...@gmail.com> wrote: > > Hello. > > Together with Dmitry (ldv) , we've discovered that running test suite > from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 > or with gcc 7.2 , but not wi

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

On Tue, Aug 15, 2017 at 11:08 PM, Sam Ravnborg <s...@ravnborg.org> wrote: > Hi Anatoly. > > On Tue, Aug 15, 2017 at 09:50:45PM +0300, Anatoly Pugachev wrote: >> Hello. >> >> Together with Dmitry (ldv) , we've discovered that running test suite >> from s

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

Hi Anatoly. On Tue, Aug 15, 2017 at 09:50:45PM +0300, Anatoly Pugachev wrote: > Hello. > > Together with Dmitry (ldv) , we've discovered that running test suite > from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 > or with gcc 7.2 , but not with gcc 6 : F

[sparc64] kernel OOPS with gcc 7.1 / 7.2

Hello. Together with Dmitry (ldv) , we've discovered that running test suite from strace produces kernel OOPS, when kernel is compiled with gcc 7.1 or with gcc 7.2 , but not with gcc 6 : $ git clone https://github.com/strace/strace.git ttip:~/strace$ ./bootstrap ttip:~/strace$ ./configure

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 01/23/2017 11:24, Andrew Haley wrote: > On 23/01/17 16:11, Joshua Kinard wrote: >> So now the question is why stack-probing kills this machine on generic MIPS >> code that its smaller cousin is seemingly unaffected by. I do know that IP27 >> has a different set of memory initialization

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 23/01/17 16:11, Joshua Kinard wrote: > So now the question is why stack-probing kills this machine on generic MIPS > code that its smaller cousin is seemingly unaffected by. I do know that IP27 > has a different set of memory initialization routines in the MIPS code, so is > it possible that,

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 01/23/2017 10:34, Andrew Haley wrote: > On 23/01/17 15:26, Joshua Kinard wrote: >> I am not sure what this lone store-doubleword instruction is exactly doing, >> nor >> can I locate where in the gcc MIPS code it is being generated from. > > It's a stack probe, making sure that there is

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

On 23/01/17 15:26, Joshua Kinard wrote: > I am not sure what this lone store-doubleword instruction is exactly doing, > nor > can I locate where in the gcc MIPS code it is being generated from. It's a stack probe, making sure that there is enough stack space. Its only purpose is to provide a

Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

Hi, I am trying to use gcc-6.3.0 to cross-compile a kernel for an old mips64 platform, an SGI Onyx2 ("IP27"), however, it looks like a large number of functions within the compiled code are getting a common instruction emitted at the top of the function that breaks this particular machine. Doing

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 Manuel Rüger rueger at informatik dot hu-berlin.de changed: What|Removed |Added CC|

[Bug spam/45929] New: insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 Summary: insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops) Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 Jay jay.krell at cornell dot edu changed: What|Removed |Added Version|4.3.5 |4.5.1 --- Comment #1

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 --- Comment #3 from Jay jay.krell at cornell dot edu 2010-10-07 10:31:04 UTC --- I'll switch to gcc 4.x. It would be nice to keep the files/functions smaller for portability.

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot

[Bug middle-end/43997] New: -finline-small-functions related oops

, got_c, data[i].want_c, got, data[i].want, data[i].size); } while (0); } } mpn_aors_1_t fudge (mpn_aors_1_t f) { return f; } int main (void) { check_add_1 (); check_sub_1 (); return 0; } -- Summary: -finline-small-functions related oops Product: gcc

[Bug middle-end/43997] -finline-small-functions related oops

--- Comment #1 from dps at simpson dot demon dot co dot uk 2010-05-05 22:04 --- Created an attachment (id=20573) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20573action=view) code for test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43997

[Bug middle-end/43997] [4.6 Regression] -finline-small-functions related oops

Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Summary|-finline-small-functions|[4.6 Regression] -finline- |related oops|small

[Bug middle-end/43997] [4.6 Regression] -finline-small-functions related oops

--- Comment #3 from hjl dot tools at gmail dot com 2010-05-06 03:57 --- *** This bug has been marked as a duplicate of 43791 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added

Oops

Ignore that last email. It was sent to the wrong address. Peter Peter Gerdes -- [EMAIL PROTECTED] Find what I have to say interesting? Check out my blog or my analytic philosophy blog. On Jun 6, 2006, at 12:36 PM, Peter Michael Gerdes wrote: I've studied a fair bit of analytic

Re: Oops

On 6/6/06, Peter Michael Gerdes [EMAIL PROTECTED] wrote: Ignore that last email. It was sent to the wrong address. Thesis, antithesis, synthesis. -- David L Nicol fans of liza minelli should always be disconnected immediately -- Matthew Henry