-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/11 14:15, Iyer, Balaji V wrote:
> Thanks Jeff for your help!
>
> So, are the errors confined to these files? Or could it be
> anywhere?
It could be anywhere. That failure means that stage1 and stage2
compilers generated different code for th
> This should probably be on the gcc-help list.
I never really know which direction to go as the issues seem to be related
to how limits-exprparen.c gets tested. However, no problem, I'll jump ship
and get out of this ml.
> On 7 November 2011 01:08, Dennis Clarke wrote:
>>
>> Well, dear GCC user
> Dennis Clarke writes:
>
>> Only the new "go" language seems to be a major issue now.
>
> The implementation of Go in the 4.6 releases does not support Solaris.
>
> Go on Solaris works on mainline.
Well, I would not have seen that coming. I should look more closely at the
various README's and c
Good day!
I want to host a new mirror site Gcc.
Server name - Latvia ChampGround
Server admin - vt.avtm...@gmail.com, Vladimir
Server location - Latvia, Riga
Server address - champground.com
Server protocol - http
Connection speed - 100 Mbps
Thanks.
>> It's pending copyright paperwork from the author of the original patch.
>> (my copyright paperwork is in order, but since I didn't write all of it,
>> there's some crossing t's and dotting i's).
>Hmm, has he been contacted recently? The original patch was from ages
>ago...
>Thanks,
>-Miles
Jas
Message from Dennis Clarke at 2011-11-07 06:38:47
--
> > Have you checked your ulimit?
>
>I was thinking that too! I just recently increased the stack size limit to
>16 MB :
The 'fix' in mainline set it higher:
2011-07-22 Jakub Jelinek
PR c++/49756
* g
> Message from Dennis Clarke at 2011-11-07
> 06:38:47 --
>> > Have you checked your ulimit?
>>
>>I was thinking that too! I just recently increased the stack size limit
>> to
>>16 MB :
>
> The 'fix' in mainline set it higher:
>
> 2011-07-22 Jakub Jelinek
>
> PR c++/49
Hi to all.
I want to tell you about a bizarre behavior in executables compiled
with gcc 4.2.1 compiler.
A few weeks ago i did must to paralelize a lattice boltzmann algorithm
using OMP directives (with adding own optimizations) to pass my
High-performance computing course.
I compile my c program
On 11/07/2011 07:32 PM, Francisco Llaryora wrote:
With the purpose of measuring the SpedUp by changing the number of threads.
I did run fourty times by changing the value OMP_NUM_THREAD from 1 to 40.
I run it in a node with 40 cores Xenon.4 Processors with 10 cores each one.
The next is time in
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
Dear Release Managers...
We're pretty much done with the merge blockers, and even suggestions
that weren't blockers :). The only outstanding patch review is a
cleanup by Richard Henderson that is waiting for Richi's review here:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01033.html
I am s
Hi list.
On build gcc-trunk in OpenBSD-5.0 on staget 3 I get the following errors:
if [ x"-fpic" != x ]; then \
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc
-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/
-B/usr/local/i686-pc-openbsd5.0/bin/
-B/usr/local/i686-pc-openbsd5.0/bin/
-B/usr
niXman writes:
> in libiberty/config.h macro HAVE_LIMITS_H is undefined.
Look in libiberty/config.log to see why HAVE_LIMITS_H is not defined.
Also why HAVE_STDLIB_H is not defined.
Ian
Diffs between stage2 and stage3.
on configure libiberty for stage3 I see this warnings:
configure:4962: checking for limits.h
configure:4962: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc
-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/
-B/usr/local/i686-pc-openbsd5.0/bin/
-B/usr/local/
Diffs between stage2 and stage3.
on configure libiberty for stage3 I see this warnings:
configure:4962: checking for limits.hconfigure:4962:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/-B/usr/local/i686-pc-openbsd5.0/bin/-B/usr/local/i686-
On Mon, Nov 7, 2011 at 9:58 PM, Aldy Hernandez wrote:
> Dear Release Managers...
>
> We're pretty much done with the merge blockers, and even suggestions that
> weren't blockers :). The only outstanding patch review is a cleanup by
> Richard Henderson that is waiting for Richi's review here:
>
>
I suppose we can freeze for the TM merge once we leave stage1 (thus,
in a few hours).
If you are ready by then, of course, and the tree isn't too broken.
Richard.
Fine by me. In the meantime we will stabilize things on the branch,
merge from trunk, run tests, and have a patch ready to be ap
No anomalies. No regressions.
I will now post the full patchset I would like to post to trunk.
Hi,
powerpc-rtems does not compile on the head due
to what appear to be changes in the way CPU
features are represented for the arguments.
The compilation error is:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c: In fu
On 11/08/2011 04:44 AM, Joel Sherrill wrote:
Hi,
powerpc-rtems does not compile on the head due
to what appear to be changes in the way CPU
features are represented for the arguments.
The compilation error is:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
/users/joel/test
On Sun, 6 Nov 2011, Joern Rennecke wrote:
> Quoting David Brown :
>
> > Take an example using a processor I know well, the AVR (it is an 8-bit
> > device, which is a little unusual for gcc). It has an instruction will
> > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
> > 16
21 matches
Mail list logo
