Re: Question on operand_equal_p on different type conversion expressions

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 not the > same. > > >> The problem is operand_equal_q simply

Re: Question on operand_equal_p on different type conversion expressions

On Mon, May 20, 2013 at 10:50 PM, Bin.Cheng wrote: > Hi, > I ran into a call of operand_equal_p for two type conversion tree nodes like: > arg0: > type size > unit size > align 16 symtab 0 alias set -1 canonical type 0xb74faae0 > precision 16 min max 0xb74e8a64 6

Question on operand_equal_p on different type conversion expressions

Hi, I ran into a call of operand_equal_p for two type conversion tree nodes like: arg0: unit size align 16 symtab 0 alias set -1 canonical type 0xb74faae0 precision 16 min max > arg 0 unit size align 32 symtab 0 alias set 5 canonical type 0xb74fa42

Re: Buzilla SVN commit messages

On 20 May 2013 17:23, Oleg Endo wrote: > On Sun, 2013-05-12 at 12:33 +0100, Jonathan Wakely wrote: >> On 12 May 2013 11:38, Oleg Endo wrote: >> > Hi, >> > >> > I've noticed that for some reason SVN commit messages stopped showing up >> > in Bugzilla PRs a while ago (before the Bugzilla 4.4 update).

Re: Buzilla SVN commit messages

On Sun, 2013-05-12 at 12:33 +0100, Jonathan Wakely wrote: > On 12 May 2013 11:38, Oleg Endo wrote: > > Hi, > > > > I've noticed that for some reason SVN commit messages stopped showing up > > in Bugzilla PRs a while ago (before the Bugzilla 4.4 update). > > It was the sourceware.org hardware upgra

Re: libbacktrace & plugins....

On Mon, May 20, 2013 at 08:43:06AM -0700, Ian Lance Taylor wrote: > On Mon, May 20, 2013 at 7:31 AM, Basile Starynkevitch > wrote: > > > > Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV) > > libbacktrace is apparently not able > > to show backtrace information inside the plug

Re: libbacktrace & plugins....

On Mon, May 20, 2013 at 7:31 AM, Basile Starynkevitch wrote: > > Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV) > libbacktrace is apparently not able > to show backtrace information inside the plugin[s]. > > I believe that, at least on GNU/Linux wich has dladdr, it would be

libbacktrace & plugins....

Hello All, Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV) libbacktrace is apparently not able to show backtrace information inside the plugin[s]. I believe that, at least on GNU/Linux wich has dladdr, it would be nice to extend libbacktrace to show backtrace information

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

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://sourceware.org/ml/libc-alpha/2013-02/msg00299.html and I also no

Re: Crashes inside libgcc_s_dw2-1.dll

On Sun, May 19, 2013 at 8:43 PM, Eli Zaretskii wrote: >> Date: Sun, 19 May 2013 17:48:06 -0700 >> From: Ian Lance Taylor >> >> It is not a fundamental bug to depend on libgcc as a shared library. >> The libgcc code is trying to do the right thing when the library is >> unloaded. I don't see any

Re: pure/const function attribute and memoization

> > > > The function is in glibc's math/atest-exp2.c file. I see, I was curious what made LLVM developers to implement the feature about making memory writes unreachable. While I see wild interpretation of the documentation allows it,

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

Hi, I've tried to compile upcoming glibc-2.18 with gcc-4.8.x and optimized with '-O3' and testsuite breaks horrible with SIGSEGV and eating up all available memory. I've tracked it down to the flag 'tree-loop-distribute-patterns' and can reproduce the problem with CFLAGS='-g -O2 -ftree-loop-distr

Re: Crashes inside libgcc_s_dw2-1.dll

2013/5/20 Eli Zaretskii : >> Date: Sun, 19 May 2013 17:48:06 -0700 >> From: Ian Lance Taylor >> Cc: gcc@gcc.gnu.org >> >> It is not a fundamental bug to depend on libgcc as a shared library. >> The libgcc code is trying to do the right thing when the library is >> unloaded. I don't see any obviou