Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C

On Tue, Oct 7, 2008 at 1:18 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote: > I have been looking at why g++.dg/tree-prof/indir-call-prof.C fails on > IA64 (HP-UX and Linux). It looks like the optimization (turning an > indirect call into a direct call) does not happen because the initial > run with -

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

On Tue, Oct 7, 2008 at 2:15 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote: > From: "Richard Guenther" <[EMAIL PROTECTED]> > >> On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> >> wrote: >>> >>> Okay for mainline? >> >> Ok if there are no objections within the week. >> >> Thanks, >>

A question regarding recognition of nop

Hello, Is there a general way to recognize a nop insn in RTL (using attributes?), or should I add a target hook for that? For example, I would like to recognize the following spu insn as a nop:?), (insn 555 210 203 11 (unspec_volatile [ (const_int 0 [0x0]) ] 14) 393 {lnop} (

Issue in building the libgcc-Os-4-200.a library for SH target

Hi, We have built a cross compiled toolchain for SH target using the following sources, gcc-4.3.1 [released], newlib-1.16.0 [released] binutils-2.18.50 [snapshot dated 30th July 2008], We have experienced following error, when building a C++ application using a toolchain built with the above men

Re: Autovectorizing does not work with classes

Georg Martius wrote: > Dear gcc developers, > > I am new to this list. > I tried to use the auto-vectorization (4.2.1 (SUSE Linux)) but unfortunately > with limited success. > My code is bassically a matrix library in C++. The vectorizer does not like > the member variables. Consider this code

Re: A question regarding recognition of nop

Revital1 Eres <[EMAIL PROTECTED]> writes: > Is there a general way to recognize a nop insn in RTL (using attributes?), > or should I add a target hook for that? > > For example, I would like to recognize the following spu insn as a nop:?), > > (insn 555 210 203 11 (unspec_volatile [ >

Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C

Steve Ellcey <[EMAIL PROTECTED]> writes: > Comparing x86 (where things work) and IA64 (where they do not), I see > the test case, when compiled with -fprofile-generate, has calls > __gcov_indirect_call_profiler in both cases. But on IA64, cur_func is > never equal to callee_func That's because c

Re: Autovectorizing does not work with classes

[EMAIL PROTECTED] wrote on 07/10/2008 10:48:29: > Dear gcc developers, > > I am new to this list. > I tried to use the auto-vectorization (4.2.1 (SUSE Linux)) but unfortunately > with limited success. > My code is bassically a matrix library in C++. The vectorizer does not like > the member vari

Autovectorizing does not work with classes

Dear gcc developers, I am new to this list. I tried to use the auto-vectorization (4.2.1 (SUSE Linux)) but unfortunately with limited success. My code is bassically a matrix library in C++. The vectorizer does not like the member variables. Consider this code compiled with gcc -ftree-vectorize

Re: Help with IA64 profiling bug - g++.dg/tree-prof/indir-call-prof.C

Steve Ellcey <[EMAIL PROTECTED]> writes: > This is about as far as I have gotten. I am not sure why there is this > difference or how to fix it. I *think* it may be related to the fact > that IA64 GCC defines TARGET_VTABLE_USES_DESCRIPTORS but my only reason > for thinking that is that IA64 is t

Re: Status of the DLX backend for GCC?

On Sat, 2008-10-04 at 18:48 +0200, Gerald Pfeifer wrote: > Thanks for the background on this, Peter, and the background on this > site disappearing. > > The reason I asked was that we have that reference from our site to that > URL and I failed to find any replacement so far. The first two hits t

Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

On Mon, Oct 06, 2008 at 04:10:04PM -0700, Kaveh R. Ghazi wrote: > From: "Adrian Bunk" <[EMAIL PROTECTED]> > >> On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote: >>> Since we're in stage3, I'm raising the issue of the MPFR version we >>> require for GCC, just as in last year's stage3 f

Re: cpp found limits.h in FIXED_INCLUDE_DIR, but not in STANDARD_INCLUDE_DIR

Hi, all, I think I've found the reason. It all comes from this gentoo patch: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/files/4.1.0/gcc-4.1.0-cross-compile.patch?rev=1.1&view=markup Specifically: -elif test "x$TARGET_SYSTEM_ROOT" != x; then +elif test "x$TARGET_SYSTEM_ROOT"

register class constraints question

I've got this code: (define_insn "andhi3_24" [(set (match_operand:HI 0 "mra_operand" "=Sd,Sd,*Rhl,*Rhl,RhiSd,??Rmm,RhiSd,??Rmm") (and:HI (match_operand:HI 1 "mra_operand" "%0,0,*0,*0,0,0,0,0") (match_operand:HI 2 "mrai_operand" "Imb,Imw,*Imb,*Imw,iRhiSd,?Rmm,?Rmm,iRhiS

Missing gen_sse2_cvtdq2p in convert splitter?

Hi, I386.md has (define_split [(set (match_operand:MODEF 0 "register_operand" "") (float:MODEF (match_operand:SI 1 "register_operand" "")))] "TARGET_SSE2 && TARGET_SSE_MATH && TARGET_USE_VECTOR_CONVERTS && optimize_function_for_speed_p (cfun) && reload_completed && (SSE_REG_P

Re: Missing gen_sse2_cvtdq2p in convert splitter?

On Wed, Oct 8, 2008 at 8:29 AM, H.J. Lu <[EMAIL PROTECTED]> wrote: > I386.md has > > (define_split > [(set (match_operand:MODEF 0 "register_operand" "") >(float:MODEF (match_operand:SI 1 "register_operand" "")))] > "TARGET_SSE2 && TARGET_SSE_MATH > && TARGET_USE_VECTOR_CONVERTS && opti