similar to: [Bug 881] New: SIGSEGV on startup

Displaying 20 results from an estimated 200 matches similar to: "[Bug 881] New: SIGSEGV on startup"

2020 Jul 09
2
[RFC] carry-less multiplication instruction
05.07.2020, 05:22, "Roman Lebedev" <lebedev.ri at gmail.com>: > On Sun, Jul 5, 2020 at 12:18 PM Shawn Landden via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more. >> >>  This proposal is to add a
2020 Jul 05
8
[RFC] carry-less multiplication instruction
<div> </div><div><div><p>Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more.</p><p>This proposal is to add a <code>llvm.clmul</code> instruction. Or if that is contentious, <code>llvm.experimental.bitmanip.clmul</code> instruction.
2012 Apr 28
9
[Bug 49243] New: graphical corruption with GeForce 6150SE nForce 430
https://bugs.freedesktop.org/show_bug.cgi?id=49243 Bug #: 49243 Summary: graphical corruption with GeForce 6150SE nForce 430 Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:
2016 Nov 15
0
Crashing when run against OpenSSL 1.1.0c
On 15.11.2016 13:27, Michael Marley wrote: > Hi, > > I am running Dovecot 2.2.26.0 compiled against OpenSSL 1.1 and, since > upgrading to OpenSSL 1.1.0c, the "lmtp" process has been crashing with > SIGSEGV whenever it receives SIGINT. This always happens a minute or so > after the lmtp process handles a message. It can also be manually > reproduced by sending
2020 Jul 05
5
[RFC] carry-less multiplication instruction
On 05.07.20 12:21, Roman Lebedev via llvm-dev wrote: > On Sun, Jul 5, 2020 at 12:18 PM Shawn Landden via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more. >> >> This proposal is to add a
2019 May 29
3
Basic block merging
Am Mi., 29. Mai 2019 um 13:31 Uhr schrieb Shawn Landden via llvm-dev <llvm-dev at lists.llvm.org>: > > On Wed, May 29, 2019 at 10:49 AM David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Under certain circumstances, my compiler outputs basic blocks having the same function: > > > > bb_97: ;
2019 Jun 24
2
RFC: Interface user provided vector functions with the vectorizer.
For example, Type 2 case, scalar-foo used call by value while vector-foo used call by ref. The question Johannes is asking is whether we can decipher that after the fact, only by looking at the two function signatures, or need some more info (what kind, what's minimal)? I think we need to list up cases of interest, and for each vector ABI of interest, we need to work on the requirements and
2019 Jun 24
3
RFC: Interface user provided vector functions with the vectorizer.
> On Jun 24, 2019, at 10:53 AM, Tian, Xinmin <xinmin.tian at intel.com> wrote: > > To me, it is also an issue related to SIMD signature matching when the vectorizer kicks in. Losing info from FE to BE is not good in general. > Yes, we cannot loose such information. In particular, the three examples I reported are all generating i64 in the scalar function signature: // Type 1
2016 Nov 15
2
Crashing when run against OpenSSL 1.1.0c
Hi, I am running Dovecot 2.2.26.0 compiled against OpenSSL 1.1 and, since upgrading to OpenSSL 1.1.0c, the "lmtp" process has been crashing with SIGSEGV whenever it receives SIGINT. This always happens a minute or so after the lmtp process handles a message. It can also be manually reproduced by sending SIGINT to one of the running lmtp processes. I am compiling and running on an
2016 Nov 15
1
Crashing when run against OpenSSL 1.1.0c
Hi You can't think how glad I am that SSL issues rise again in a new Dovecot version with next Ubuntu release with a new OpenSSL library. Some days ago I have posted something similar about Ubuntu 14.04 - Dovecot 2.2.9 - OpenSSL 1.0 (Dovecot processes turning zombie) but noone cared about. I still think is somehow related to ssl-param process + config + auth + ...whatever (all of them
2019 Jun 24
4
RFC: Interface user provided vector functions with the vectorizer.
@Xinmin, Saito: If Clang/the frontend generates the version there is no problem, or is there? The frontend knows about the original source type and it's ABI specific lowering already. @Francesco, we should even consider putting the generating capabilities outside of the OpenMP code generation (in the future). That could allow easier reuse by other frontends. Get Outlook for
2019 May 29
2
Basic block merging
Under certain circumstances, my compiler outputs basic blocks having the same function: bb_97: ; preds = %bb_1 %476 = getelementptr inbounds %LMtop.I0.ARType, %LMtop.I0.ARType* %0, i64 0, i32 6 %477 = bitcast i8** %476 to %LBstd.Cprocess.CRType** %478 = load %LBstd.Cprocess.CRType*, %LBstd.Cprocess.CRType** %477, align 8 %479 = getelementptr
2019 Jun 24
2
RFC: Interface user provided vector functions with the vectorizer.
>Thank you everybody for their input, and for your patience. This is proving harder than expected! :) Thank you for doing the hard part of the work. Hideki -----Original Message----- From: Francesco Petrogalli [mailto:Francesco.Petrogalli at arm.com] Sent: Monday, June 24, 2019 11:26 AM To: Saito, Hideki <hideki.saito at intel.com> Cc: Doerfert, Johannes <jdoerfert at anl.gov>;
2019 Jun 21
2
RFC: Interface user provided vector functions with the vectorizer.
>In all cases, the IR type of the parameters in `foo` is i64, therefore is not possible to distinguish what C type generated the signature of `foo`. Ouch. >I don’t know if this is going to be a problem for other architectures I haven't checked what IA-32/Intel64 should do for type 2, but I fully agree that this needs to be done properly according to the ABI. >Therefore, I would
2019 Jun 17
3
RFC: Interface user provided vector functions with the vectorizer.
I agree with Simon. This looks good conceptually. I have minor implementation comments but that can wait till the code reviews. Sorry for the delay and thanks for working on this. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Simon Moll <moll at cs.uni-saarland.de> Sent: Monday, June 17, 2019 10:02:58 AM To: Francesco Petrogalli; LLVM
2010 May 19
0
[PATCH] xentop: fix sigsegv
On my system, I''m getting SIGSEGVs in xentop because xenstat_node_domain() is returning NULL. Skip the loop if it does rather than crashing. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 9dda78d7af3b -r 5895ad758076 tools/xenstat/libxenstat/src/xenstat_linux.c --- a/tools/xenstat/libxenstat/src/xenstat_linux.c Tue May 18 15:38:36 2010 -0700 +++
2009 May 24
1
[Bug 21908] New: SIGSEGV when no kernel DRM present
http://bugs.freedesktop.org/show_bug.cgi?id=21908 Summary: SIGSEGV when no kernel DRM present Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org
2010 Nov 19
3
[LLVMdev] : SIGSEGV in compiled programs during stack unwinding
It seemed I found possible llvm-g++ bug. Programs compiled with llvm-g++ 4.5 crashed with SIGSEGV during stack unwinding in such testcase: chaos at chaos-desktop ~ % g++ --version g++ (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1 chaos at chaos-desktop ~ % echo "struct X{ ~X(){} }; int main() { X x; throw 1; }" > test.cpp && g++ test.cpp && ./a.out terminate called after
2010 Nov 20
0
[LLVMdev] : SIGSEGV in compiled programs during stack unwinding
Hi Chaos A.D., > It seemed I found possible llvm-g++ bug. > Programs compiled with llvm-g++ 4.5 crashed with SIGSEGV during stack unwinding > in such testcase: I can reproduce this - investigating. Ciao, Duncan.
2009 Sep 10
1
SIGSEGV at kickstart
Hi! I have a problem that i dont know how to tackle ... i have done kickstarting many times but know it seems i hit an wall ... i try to kickstart through nfs an 64 bit centos .. just after taking ip trough dhcp i receive an SIGSEGV ! i dont know what to do anymore as the same ks.cfg worked very well until now .. Many thanks! Adrian -------------- next part -------------- A non-text attachment