Does g++ have a intel/msdn __COUNTER__ macro equivalent??

Dear Sir/Madam I'm trying to specify random distributions throughout my program eg Uniform(1,0), Normal(10,2). Id like these replaced at the pre-processing stage with Uniform(__COUNTER__,1,0) & Normal(__COUNTER__,10,2) using macros such as #define U(a,b) U(__COUNTER__,a,b) etc The point of this

RE: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

On 04 September 2007 10:05, me wrote: > The point of this is that __COUNTER__ would assign consecutive numbers > I can not find g++'s equivalent & wonder how I could achieve the same > thing? This feature was just added recently. It will be in all upcoming gcc-4.3 and later series releases.

Re: [PATCH PR31490] Re: another build failure on ppc64-linux

On 9/2/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > Bootstrap of current trunk on powerpc64-linux fails in libstdc++ > > building system_error.lo. The code that fails was added a few days > > ago, > > but the failure seems to be the same as the one reported in PR 31490. > > I > > verified

IA64 optimizations..

Hi, I am interested in understanding the limitations/optimization opportunities of the IA64 version of gcc. I read from the projects list on the gcc site about the proposed optimizations for the IA64 platform, I see that some of the requests were from 2001 or so timeframe, I am wondering

Re: Re[2]: [GSoC: DDG export][RFC] Current status

Hello, > An important missing piece is correction of exported information for > loop unrolling. As far as I can tell, for loop unrolled by factor N we > need to clone MEM_ORIG_EXPRs and datarefs for newly-created MEMs, create > no-dependence DDRs for those pairs, for which original DDR was > no-d

Re: Wrong lib address

"xchen" <[EMAIL PROTECTED]> writes: > I use gdbserver to debug my program. The problem is gdb can't load library > file correctly. This is the wrong mailing list. For gdb questions, I suggest [EMAIL PROTECTED]; see http://sourceware.org/gdb. Note that gcc@gcc.gnu.org is a mailing list for gcc

bootstrap failing on ppc linux

This is the error message I get (during stage2): /home/razya/mainline/build/./prev-gcc/xgcc -B/home/razya/mainline/build/./prev-gcc/ -B/home/razya//powerpc64-suse-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissin

Re: DFA Scheduler - unable to pipeline loads

Joey, My understanding was that the latency is used to figure out data delays and the reservation to figure out reservation delays and that these two are used independently. The post below seems to confirm this, http://gcc.gnu.org/ml/gcc/2006-08/msg00497.html I have latency 1 because there are

Re: bootstrap failing on ppc linux

Same thing here on Darwin: /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.3w/powerpc-apple-darwin8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedant

GLIBCXX_ dependency

Ive written a C++ program which is compiled on using gcc 4.1.0. The binary when it is run in a machine where libstdc++ version is 6.0.3 , i get errors that GLIBCXX_3.4.5 version is not found. I did a objdump on the binary and found on a symbol - F *UND* 0019 _ZNSs4_Rep26_M_s

Re: bootstrap failing on ppc linux (fixed)

Build succeeded with revision 128101. Thanks. Dominique

Someone has caused regressions in gfortran

Someone has committed a patch that is causing both gfortran.dg/do_3.F90 and gfortran.dg/c_char_tests.f03 to fail at -O3 on amd64-*-freebsd. A quick inspection of fortran/ChangeLog doesn't yield a pointer to any particular commit. This may be caused by some middle-end change, but I won't have time

Re: Someone has caused regressions in gfortran

> Someone has committed a patch that is causing both > gfortran.dg/do_3.F90 and gfortran.dg/c_char_tests.f03 > to fail at -O3 on amd64-*-freebsd. A quick inspection > of fortran/ChangeLog doesn't yield a pointer to any > particular commit. This may be caused by some middle-end > change, but I won

Re: DFA Scheduler - unable to pipeline loads

On 8/31/07, Adam Nemet <[EMAIL PROTECTED]> wrote: > "Matt Lee" <[EMAIL PROTECTED]> writes: > > > I am seeing poor scheduling in Dhrystone where a memcpy call is > > expanded inline. > > > > memcpy (&dst, &src, 16) ==> > > > > load 1, rA + 4 > > store 1, rB + 4 > > load 2, rA + 8 > > store 2, rB +

GCC 4.2.2 Status Report

Summary === The GCC 4.2.1 release was July 18, so our target for a 4.2.2 release is September 18th. I plan to build RC1 this Sunday, September 9. If all goes well, we'll have 4.2.2 out around the 18th; if not, we'll delay a bit from there. One critical issue: has GCC 4.2.x been fully conver

Re: GCC 4.2.2 Status Report

On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Summary > === > > The GCC 4.2.1 release was July 18, so our target for a 4.2.2 release is > September 18th. I plan to build RC1 this Sunday, September 9. If all > goes well, we'll have 4.2.2 out around the 18th; if not, we'll delay a > bit

Re: DFA Scheduler - unable to pipeline loads

Matt Lee writes: > In any case, I am trying to optimize the case where there is clearly no > aliasing. Your suggestion regarding movmemsi is interesting. I have not used > this pattern before and assumed that it was required only when something > special must be done to do block moves. In my archit

GCC 4.3.0 Status Report (2007-09-04)

Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'

Re: Someone has caused regressions in gfortran

On Wed, Sep 05, 2007 at 12:41:10AM +0200, Jan Hubicka wrote: > > Someone has committed a patch that is causing both > > gfortran.dg/do_3.F90 and gfortran.dg/c_char_tests.f03 > > to fail at -O3 on amd64-*-freebsd. A quick inspection > > of fortran/ChangeLog doesn't yield a pointer to any > > partic

Re: GCC 4.3.0 Status Report (2007-09-04)

Mark Mitchell <[EMAIL PROTECTED]> writes: > Are there Stage 1 or Stage 2 patches in need of review? Do you want the diagnostic pragma push/pop patch in?

Re: GCC 4.3.0 Status Report (2007-09-04)

DJ Delorie wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: >> Are there Stage 1 or Stage 2 patches in need of review? > > Do you want the diagnostic pragma push/pop patch in? In, if it works. :-) URL, please? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Someone has caused regressions in gfortran

On Tue, Sep 04, 2007 at 07:48:08PM -0700, Steve Kargl wrote: > > My fortran-fu is however not at level to figure out what precisely is > > going wrong in those two testcases. > > I'll try to reduce the do_3.F90 code to a minimum testcase. Unfortunately, > my middle/back-end knowledge is probably

Re: Someone has caused regressions in gfortran

On Tue, Sep 04, 2007 at 08:37:15PM -0700, Steve Kargl wrote: > On Tue, Sep 04, 2007 at 07:48:08PM -0700, Steve Kargl wrote: > > > My fortran-fu is however not at level to figure out what precisely is > > > going wrong in those two testcases. > > > > I'll try to reduce the do_3.F90 code to a minimu

Re: GCC 4.3.0 Status Report (2007-09-04)

> In, if it works. :-) Well, it does what it's supposed to do. Whether that's a "works" in the grand scheme of things is still debatable :-) I'd still need to write testcases and a changelog, as I was posing it as a what-if-example so far. Also, we still don't guarantee proper operation in all