Daniel Berlin wrote:
> >As some few people might already know, the GGCC (globalgcc) project is
> >just starting (partly funded within the ITEA framework by french,
> >spanish, swedish public money) - its kick off meeting is next week in
> >Paris.
> >
> >GGCC aims to provide a (GPL opensource) exten
I'm experiencing building libmudflap cross, as libtool seems not to
pass --sysroot arguments to the compiler driver in link mode:
/bin/sh ./libtool --mode=link
/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.2-20060731/obj-i586-suse-li
Follows the build info:
config.guess:
i386-pc-mingw32
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.2-20060826/configure --prefix=/mingw
--host=mingw32
--target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe
--with-ld=/mingw/bin/ld.exe
--with-gcc --
On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
> I think this is probably moot, since I believe that Kenny feels DWARF is
> not suitable for reasons other than the abbreviation table issue, but
> this is a clever technique.
... for GIMPLE; when I discussed with him, I got the imp
Hello Everyone,
I am trying to link the object file emitted by a Cross Compiler IDE
with the GCC Coldfire Linker and its libraries.
The Problem that i faced was:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits ou
Daniel Jacobowitz wrote:
> On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
>
>> I think this is probably moot, since I believe that Kenny feels DWARF is
>> not suitable for reasons other than the abbreviation table issue, but
>> this is a clever technique.
>>
>
> ... for GI
Rohit Arul Raj wrote:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits out
the labels prefixed with a '_' (_main, _printf etc).
Is there any way i can make gcc-coldfire compiler emit the lables
prefixed with
Kenneth Zadeck wrote on 08/28/06 09:57:
> I have not done this because I do not rule the earth. That was not
> what I was assigned to do, and I agreed that DWARF3 sounded like a
> reasonable way to go. Now that I understand the details of DWARF3, I
> have changed my mind about the correct direct
Rohit Arul Raj wrote:
The gcc-coldfire compiler spits out the labels as it is in the
assembly file (main, printf etc), where as the IDE compiler spits out
the labels prefixed with a '_' (_main, _printf etc).
Is there any way i can make gcc-coldfire compiler emit the lables
prefixed with
On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
> Given that Mark, and for that matter no one else, did not really push
> back, I am pretty much committed not to use dwarf.
Then... what are you going to do about things like types? Invent a new
serialization for those too? I thin
Daniel Jacobowitz wrote:
> On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
>
>> Given that Mark, and for that matter no one else, did not really push
>> back, I am pretty much committed not to use dwarf.
>>
>
> Then... what are you going to do about things like types? Inve
On Fri, Sep 01, 2006 at 10:19:07AM -0400, Kenneth Zadeck wrote:
> Daniel Jacobowitz wrote:
> > On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
> >
> >> Given that Mark, and for that matter no one else, did not really push
> >> back, I am pretty much committed not to use dwarf.
>
First of all, thanx all for all your help, I'm finally seeing the
light at the end of this long tunnel ;-)
one possibility is that the t[i-1] load got moved out of the loop by
PRE; could you check that the load is still present in the loop?
Zdenek
You're right, the load was moved to the out
Diego Novillo wrote:
> Kenneth Zadeck wrote on 08/28/06 09:57:
>
>
>> I have not done this because I do not rule the earth. That was not
>> what I was assigned to do, and I agreed that DWARF3 sounded like a
>> reasonable way to go. Now that I understand the details of DWARF3, I
>> have changed
On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
>
> > +#if STUPID_TYPE_SYSTEM
> >
> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
Well it right now it is stupid, this is just a work around anyways until
people fix the type mismatches really. Is it more insulting than ha
On Fri, 2006-09-01 at 13:08 +0200, Richard Guenther wrote:
> I'm experiencing building libmudflap cross, as libtool seems not to
> pass --sysroot arguments to the compiler driver in link mode:
> /opt/cross/bin/sh4-linux-ld: crti.o: No such file: No such file or
> directory
> collect2: ld returned
Andrew Pinski wrote:
> On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
>
>>> +#if STUPID_TYPE_SYSTEM
>>>
>>>
>> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
>>
>
> Well it right now it is stupid, this is just a work around anyways until
> people fix the typ
Hi folks!
You might have thought I've been drinking pi~na coladas in the sun, but
alas, I've been beating my head mercilessly with this gimple tuple business.
What I have so far is getting so big (280k), it's getting hard to manage and
keep track of things in my brain. What do you guys think abo
On Fri, 2006-09-01 at 11:21 -0400, Aldy Hernandez wrote:
> If this is ok, I would think a branch from mainline would be best, but
> I'm open for suggestions (lto?).
Yes PLEASE. LTO is broken for most unusual languages so it is hard to
test on weird parts of gimple so I would use the mainline.
Als
Aldy Hernandez wrote on 09/01/06 11:21:
> If this is ok, I would think a branch from mainline would be best, but
> I'm open for suggestions (lto?).
>
I too prefer a branch off of mainline. Even though LTO will probably
benefit from this, this is fairly independent and will probably be in
mergeab
Hi!
I like to test the weekly snapshots of the active development
branch against code that I am particularly interested in.
I realize that snapshots are just that - and so do not
worry unless I see the same failure a couple of weeks in row.
However for the past several weeks, I have not been ab
Hi,
I'd like to use gprmake to cross-compile a mixed language project, but
I don't know how to pass the RTS directory (--RTS=abc) to gprmake.
BTW, where can I find the documentation for gprmake?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail ha
On Fri, Sep 01, 2006 at 11:51:54AM -0400, Kate Minola wrote:
> Hi!
>
> I like to test the weekly snapshots of the active development
> branch against code that I am particularly interested in.
>
> I realize that snapshots are just that - and so do not
> worry unless I see the same failure a coupl
Miguel Angel Champin Catalan wrote:
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function "gets" it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one restriction was to use gcc t
Michael Eager wrote:
Miguel Angel Champin Catalan wrote:
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function "gets" it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one restri
Is there anyone out there who might have a SPARC environment with Ada
support who could run the attached Ada testcase on a version of gcc
patched with the attached patch? I'd like to verify whether the test
behaves correctly when compiled at -O0, -O1, and -O2. The expected
(correct) behavior is
Eric Botcazou wrote:
>> Is there anyone out there who might have a SPARC environment with Ada
>> support who could run the attached Ada testcase on a version of gcc
>> patched with the attached patch? I'd like to verify whether the test
>> behaves correctly when compiled at -O0, -O1, and -O2. The
Snapshot gcc-4.1-20060901 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Since we're making some headway on GCC 4.2, it's now time to start
thinking about GCC 4.3.
As for the past couple of releases, let's start by trying to gather
information about what people are planning to contribute for GCC 4.3.
Please add your project page to the bottom of:
http://gcc.gnu
On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote:
> Please add your project page to the bottom of:
>
> http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning
BTW, that page provides a link to "SampleProjectPage" which does not exist.
FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+,
[0-9]+,0,0,30
FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+,
[0-9]+,0,29,30
FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw
are a tad confusing because if I do...
gcc-4 -O2 -m64 -S -c ppc-a
Joe Buck wrote:
On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote:
Please add your project page to the bottom of:
http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning
BTW, that page provides a link to "SampleProjectPage" which does not exist.
Thanks! I forgot which Wiki syntax I
Hi,
a very recent compiler change (less than 24 hours: compare, for example,
the testresults for i386-unknown-netbsdelf3.0) is causing many ICEs in
the ext/pb_ds testcases:
FAIL: ext/pb_ds/example/basic_map.cc (test for excess errors)
WARNING: ext/pb_ds/example/basic_map.cc compilation failed
>
> Hi,
>
> a very recent compiler change (less than 24 hours: compare, for example,
> the testresults for i386-unknown-netbsdelf3.0) is causing many ICEs in
> the ext/pb_ds testcases:
And this part of the log helps us how?
We really need to know the ICE to figure out what is going wrong.
-
Andrew Pinski wrote:
And this part of the log helps us how?
But I don't want to help you, I want you to fix it ;) Just run the
testsuite to the end and you will see everything: all plain Segmentation
faults.
Paolo.
>
> Andrew Pinski wrote:
>
> >And this part of the log helps us how?
> >
> >
> But I don't want to help you, I want you to fix it ;) Just run the
> testsuite to the end and you will see everything: all plain Segmentation
> faults.
This was caused by:
http://gcc.gnu.org/viewcvs?view=rev&revis
Once the noise from those linker warnings is removed from the libstdc++-v3
testsuite
results at -m64 on Darwin PPC, we find that the failures drop from 54 to just
6. So
we actually only have four additional libstdc++-v3 testsuite failures at -m64
compared to -m32. These are...
FAIL: 21_strings/
37 matches
Mail list logo
