> 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
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
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
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
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?
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
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'
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
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
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
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 +
> 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
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
Build succeeded with revision 128101.
Thanks.
Dominique
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
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
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
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
"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
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
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
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
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.
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
24 matches
Mail list logo
