Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18

On Mon, May 20, 2013 at 4:28 PM, Winfried Magerl wrote: > Hi, > > On Mon, May 20, 2013 at 09:40:52AM -0300, Adhemerval Zanella wrote: >> Hi, >> >> Thanks for reporting it, I saw it too when building glibc with gcc-trunk. >> Carlos O'Donell already reported it could be an issue to glibc at >> http:

Re: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18

On Tue, May 21, 2013 at 10:34:35AM +0200, Richard Biener wrote: > On Mon, May 20, 2013 at 4:28 PM, Winfried Magerl > wrote: > > Hi, > > > > On Mon, May 20, 2013 at 09:40:52AM -0300, Adhemerval Zanella wrote: > >> Hi, > >> > >> Thanks for reporting it, I saw it too when building glibc with gcc-trun

Re: Question on operand_equal_p on different type conversion expressions

On Tue, May 21, 2013 at 8:38 AM, Bin.Cheng wrote: > On Tue, May 21, 2013 at 1:55 PM, Andrew Pinski wrote: >> On Mon, May 20, 2013 at 10:50 PM, Bin.Cheng wrote: > >> >> >> NOP_EXPR here is a misnamed tree really. It could also be a >> CONVERT_EXPR and still have the same issue as the types are n

ARM/AAarch64: NEON intrinsics in the kernel

Hello all, I am currently exploring various ways of using NEON instructions in kernel mode. One of the ways of doing so is using NEON intrinsics, which we would like to support in the kernel, but unfortunately, at the moment we can't because the support header arm_neon.h assumes C99 conformance an

Re: ARM/AAarch64: NEON intrinsics in the kernel

On 21/05/13 10:32, Ard Biesheuvel wrote: Hello all, I am currently exploring various ways of using NEON instructions in kernel mode. One of the ways of doing so is using NEON intrinsics, which we would like to support in the kernel, but unfortunately, at the moment we can't because the support h

Re: Question on operand_equal_p on different type conversion expressions

On Tue, May 21, 2013 at 4:50 PM, Richard Biener wrote: > On Tue, May 21, 2013 at 8:38 AM, Bin.Cheng wrote: >> On Tue, May 21, 2013 at 1:55 PM, Andrew Pinski wrote: >>> On Mon, May 20, 2013 at 10:50 PM, Bin.Cheng wrote: >> >>> >>> >>> NOP_EXPR here is a misnamed tree really. It could also be a

Re: ARM/AAarch64: NEON intrinsics in the kernel

On 21 May 2013 11:43, Richard Earnshaw wrote: > Why don't you add a (maybe cut-down) stdint.h to the kernel. It seems > bizarre to me that the kernel is trying to provide standard types through a > non-standard interface. > There have been heated debates going on for years about these things. Q

RFC: S/390 Transactional memory support - save/restore of FPRs

Hi, I'm currently implementing support for hardware transactional memory in the S/390 backend and ran into a problem with saving and restoring the floating point registers. On S/390 the tbegin instruction starts a transaction. If a subsequent memory access collides with another the transaction i

Re: RFC: S/390 Transactional memory support - save/restore of FPRs

On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote: > Hi, > > I'm currently implementing support for hardware transactional memory > in the S/390 backend and ran into a problem with saving and restoring > the floating point registers. > > On S/390 the tbegin instruction starts a transaction

Re: GCC 4.8.1 Release Candidate available from gcc.gnu.org

On Fri, May 17, 2013 at 07:11:24PM +0200, Jakub Jelinek wrote: > GCC 4.8.1 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.8.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.1-RC-20130517 > > and shortly its mirrors. It has been generated f

Re: GCC 4.8.1 Release Candidate available from gcc.gnu.org

On Tue, May 21, 2013 at 10:56:50AM -0400, Jack Howarth wrote: > On Fri, May 17, 2013 at 07:11:24PM +0200, Jakub Jelinek wrote: > > GCC 4.8.1 Release Candidate available from gcc.gnu.org > > > > The first release candidate for GCC 4.8.1 is available from > > > > ftp://gcc.gnu.org/pub/gcc/snapshot

Porting libsanitizer to aarch64

Hi, I have been looking at enabling libsanitizer for aarch64 GCC compilers. To make the build succeed, I had to modify libsanitizer code: - some syscalls are not available on aarch64 (libsanitizer uses some legacy ones such as open, readlink, stat, ...) - unwinding code needs to be added. What's

Re: Porting libsanitizer to aarch64

On Tue, May 21, 2013 at 05:35:45PM +0200, Christophe Lyon wrote: > I have been looking at enabling libsanitizer for aarch64 GCC compilers. > > To make the build succeed, I had to modify libsanitizer code: > - some syscalls are not available on aarch64 (libsanitizer uses some > legacy ones such as

Re: ARM/AAarch64: NEON intrinsics in the kernel

On Tue, 21 May 2013, Ard Biesheuvel wrote: > I am currently exploring various ways of using NEON instructions in > kernel mode. One of the ways of doing so is using NEON intrinsics, > which we would like to support in the kernel, but unfortunately, at > the moment we can't because the support head

Re: ARM/AAarch64: NEON intrinsics in the kernel

On 21 May 2013 18:22, Joseph S. Myers wrote: > On Tue, 21 May 2013, Ard Biesheuvel wrote: > >> I am currently exploring various ways of using NEON instructions in >> kernel mode. One of the ways of doing so is using NEON intrinsics, >> which we would like to support in the kernel, but unfortunatel

Re: RFC: S/390 Transactional memory support - save/restore of FPRs

On 05/21/2013 05:40 AM, Andreas Krebbel wrote: > Hi, > > I'm currently implementing support for hardware transactional memory > in the S/390 backend and ran into a problem with saving and restoring > the floating point registers. > > On S/390 the tbegin instruction starts a transaction. If a sub

Re: RFC: S/390 Transactional memory support - save/restore of FPRs

On 05/21/2013 07:28 AM, Torvald Riegel wrote: >> > The additional prologue/epilogue FPR backups for TXs can only be >> > avoided if the transaction is fully contained in the function body >> > (and does not use the FPRs). I call these non-escaping transactions. > That's what __transaction_atomic e

Re: Crashes inside libgcc_s_dw2-1.dll

> Date: Mon, 20 May 2013 06:37:31 -0700 > From: Ian Lance Taylor > Cc: gcc@gcc.gnu.org > > On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote: > >> I don't see any obvious bug in the code. Evidently > >> something is going wrong, but the e-mail messages you linked to don't > >> provide enough

Re: Crashes inside libgcc_s_dw2-1.dll

> Date: Mon, 20 May 2013 12:18:29 +0200 > From: Kai Tietz > Cc: Ian Lance Taylor , gcc Mailing List > > The issue is there that after an unload of libgcc on pe-coff, the > function __decregister_frame_info_bases might be not called. That's probably true (assuming that cygming-crtbegin.c decided

gcc 4.8: broken headers when using gnu-versioned-namespace

Hey all, I've just built gcc 4.8 with --enable-symvers=gnu-versioned-namespace and compilation of a small test fails with the following: In file included from /work/opt/gcc-4.8/include/c++/4.8.0/array:324:0, from /work/opt/gcc-4.8/include/c++/4.8.0/tuple:39, fr

Re: gcc 4.8: broken headers when using gnu-versioned-namespace

Oleg Smolsky ha scritto: >Should I re-open the bug? It's already fixed for 4.8.1 isn't it? As PR56834 Paolo

Re: Delay slot filling - what still matters, and what doesn't matter so much anymore?

(People, please don't use my @gcc.gnu.org address if you need to ping me; not sure why Steven used that. I also changed the other CC'ed addresses to the corresponding relevant one from MAINTAINERS. Looks like I'm month+ behind on reading the lists again... On the plus side, maybe a reply-bump rek