[Bug 1783705] Re: clang errors with __float128 is not supported on this target on ppc64le

FYI, Jonathan Wakely has now backported both fixes to the GCC 8 branch in https://gcc.gnu.org/r263084. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783705 Title: clang errors with __float128 is

[Bug 1783705] Re: clang errors with __float128 is not supported on this target on ppc64le

Thanks, xnox, we will work to get those two patches upstream then. Much obliged! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1783705 Title: clang errors with __float128 is not supported on this

[Bug 1783705] Re: clang errors with __float128 is not supported on this target on ppc64le

Tulio pointed out to me that we also need the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672, which is caused by the fix for PR84654. ** Bug watch added: GCC Bugzilla #85672 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85672 -- You received this bug notification because you are a

[Bug 1783705] Re: clang errors with __float128 is not supported on this target on ppc64le

In my opinion, the GCC fix should have been proposed for 8.2 (just released), but it appears that it was not. We will work with the community to get it backported for 8.3 in December. Meanwhile, could Ubuntu apply the PR84654 patch for the gcc-8 package? -- You received this bug notification

[Bug 1758118] Re: src/mongo/db/fts/unicode is not optimised on ppc64el

Going back to c#1, though, I can definitely say that using 1 rather than 0 is correct behavior on little-endian machines. The question is whether this code is being used for big-endian also. If so, then this change will break the code on big-endian machines. This code needs to be endian-aware.

[Bug 1758118] Re: src/mongo/db/fts/unicode is not optimised on ppc64el

There was a bug in GCC that could cause incorrect code to be generated for -mcpu=power8 in a computation involving vec_vbpermq. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033. This bug has been fixed and backported to supported releases (GCC 6 and 7). Please ensure that your toolchain

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew, Canonical's plans for handling this in the short term are described here: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1642390. We will continue to work the POWER patch, but the SRU described there is all you should need to track for your relnote. Bill -- You received this

[Bug 1640518] Re: MongoDB Memory corruption

Patch submission is here: https://sourceware.org/ml/libc- alpha/2016-11/msg00568.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1640518 Title: MongoDB Memory corruption To manage

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew - I don't work directly in the glibc community, so I'm not completely familiar with their policies. However, the first step is to get a bug approved upstream so that it can be backported to the 2.23 release (in this case). Adam Conrad at Canonical has volunteered to help us shepherd

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew, Aaron has just opened https://sourceware.org/bugzilla/show_bug.cgi?id=20822. An odd confluence of vacations, world holidays, and family leave has conspired to take all of our glibc experts out of the office tomorrow, so we may be a little delayed with testing and submitting the final

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew, This is a POWER-specific "optimization" that dates to last December (so it in fact wouldn't show up in Ubuntu 15.04 or 15.10, it appears). The decrement used to be attached to the lock rather than the unlock and it was apparently moved to the present location because it showed a good

[Bug 1640518] Re: MongoDB Memory corruption

Ulrich Weigand made an interesting comment on the glibc code in our internal bug (no longer mirrored), so I'm mirroring it by hand here. --- Comment #77 from Ulrich Weigand --- According to comment #45, we see an invalid read at __lll_unlock_elision

[Bug 1640518] Re: MongoDB Memory corruption

Well, let me back that off a little. We're going to look into the TLE code a little more. The various __lll_*_elision routines are handed a pointer to short that they update, which certainly looks suspicious. So it's certainly possible that something in the pthreads implementation that calls

[Bug 1640518] Re: MongoDB Memory corruption

Given the results of Aaron's experiments over the weekend, here's a summary of what we think we're seeing: - There is an unsafe interaction between two threads. - This interaction can only be observed in a very small time window, and then relatively rarely. - The interaction is observable

[Bug 1640518] Re: MongoDB Memory corruption

We'll try to get to the bottom of the bugproxy oddity. It seems to be echoing a chunk out of comment #5 for no reason that I can see. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1640518 Title:

[Bug 1640518] Re: MongoDB Memory corruption

Here's another interesting data point. The original bug description specifies that the memory corruption is not seen on Ubuntu 15. Per https://bugzilla.linux.ibm.com/show_bug.cgi?id=117535, however, transactional lock elision has been enabled by default since Ubuntu 15.04 (glibc 2.21). Yet on

[Bug 1640518] Re: MongoDB Memory corruption

>From that debian thread: "Per logs from message #15 on bug #842796: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15 SIGSEGV on __lll_unlock_elision is a signature (IME with very high confidence) of an attempt to unlock an already unlocked lock while running under hardware lock

[Bug 1640518] Re: MongoDB Memory corruption

Per the blog post mentioned from the thread in #35, this sort of problem should also manifest on a Broadwell or Skylake processor. Andrew, have you tried running on such machines? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1560634] Re: [Ubuntu 16.04.1] Provide a way to dynamically enable lock elision on glibc

It looks like this has never been integrated? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560634 Title: [Ubuntu 16.04.1] Provide a way to dynamically enable lock elision on glibc To manage

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew, That indeed looks suspicious. I've been talking with our libc team. It appears that the existing patch that provides for disabling lock elision dynamically isn't present in the libc on Ubuntu 16.04, which is very unfortunate. They are thinking about other possible solutions. This

[Bug 1640518] Re: MongoDB Memory corruption

Hi Andrew -- not sure about Clang TSAN supporting exceptions at this point; it is probable that we don't have a solution there as I would expect that to require target support, and I've not heard of that happening for POWER. That said, I've been less connected to the Clang community for the last

[Bug 1640518] Re: MongoDB Memory corruption

I had another thought this evening. In case this is a threading problem, have you tried building with Clang and using ThreadSanitizer? Support for this was added to ppc64el in 2015. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1640518] Re: MongoDB Memory corruption

Andrew, according to the valgrind community, the error Memcheck: mc_machine.c:329 (get_otrack_shadow_offset_wrk): the 'impossible' happened. is probably due to the lock elision code accessing a hardware register that valgrind doesn't know about, so there isn't a shadow register to consult.

[Bug 1640518] Re: MongoDB Memory corruption

For what it's worth, GCC is just a placeholder package for now. The compiler and libraries aren't directly implicated, at least as of now. The origin of the stack corruption remains unknown. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1473674] Re: apt fails a test from the testsuite on ppc64el when built with gcc-5 and -O3

Spent some time trying to reproduce this upstream. From the information given, I am unable to do so. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1473674 Title: apt fails a test from the

[Bug 1473674] Re: apt fails a test from the testsuite on ppc64el when built with gcc-5 and -O3

As a guess, is FindPackages being inlined? If so, and if the parameter passed in as InfoDir isn't subsequently used, the compiler would be within its rights to remove the assignment to InfoDir. May want to check callers of FindPackages for this possibility. -- You received this bug

[Bug 1353142] Re: subversion tests fail on ppc64el when built with -O3

Agree that the code is wrong, and the vectorizer appears to be out of line. Out of curiosity, does anything change if the const is taken off of const char* source? It shouldn't make a difference without __restrict__, but I'm grasping at straws for why the vectorizer thinks source and target can

[Bug 1352836] Re: link failure when package is built with -O3 (14.10)

Referred to Alan Modra for initial investigation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1352836 Title: link failure when package is built with -O3 (14.10) To manage notifications about

[Bug 1334919] Re: gcc48, gcc49: vect-nop-move.c fails on powerpc64le-unknown-linux-gnu (FSF PR 61542)

** Package changed: ubuntu = gcc-4.8-ppc64el-cross (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1334919 Title: gcc48, gcc49: vect-nop-move.c fails on powerpc64le-unknown-linux-gnu (FSF

[Bug 1318690] Re: emacs aborts for ppc64el in 14.04

FWIW, I downloaded emacs24 sources from the GNU website and built emacs by hand. No problems during build/install and the resulting binaries work fine. Attaching config.log in case it offers any clues. ** Attachment added: config.log

[Bug 1318690] [NEW] emacs aborts for ppc64el in 14.04

Public bug reported: Using a fresh install of Ubuntu 14.04 and installing emacs produces an emacs that fails relatively quickly during an editing session. The immediate symptom is Fatal error 6: Aborted, without dumping core, and leaving a companion thread behind in a wait state. I normally use