Hello
(I don't know if the good mailing list for this is gcc@ or gcc-patches@)
Apparently trunk rev 121458 don't bootstrap on linux debian sid amd64 ie
x86_64-unknown-linux-gnu
I'm getting
make[4]: Leaving directory
`/usr/src/Lang/gcc-trunk/_BootObj2/x86_64-unknown-linux-gnu/libgcc'
/us
Hello all,
In arithmetic expressions we need to conversion when the operands are
of different data types.
In gcc 4.1.1 where is this process started?
Is this in c-typeck.c, particularly in the function c_common_type ?
Thanks in advance,
Regards,
Shafi.
Tom Tromey wrote:
"David" == David Daney <[EMAIL PROTECTED]> writes:
David> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic,
David> even though that symbol is defined in libgcj.so. The assembler and
David> linker conspire to jump to address 0x for this call.
Could a
David Daney wrote:
David Daney wrote:
Andrew Haley wrote:
David Daney writes:
> Richard,
> > Sometime between 1/7 and 1/16 on the trunk I started getting
wrong code > on a bunch of java testcases under mipsel-linux.
OK, it was r120621 (The gcj-elipse branch merge) where things started
b
David Daney wrote:
Andrew Haley wrote:
David Daney writes:
> Richard,
> > Sometime between 1/7 and 1/16 on the trunk I started getting
wrong code > on a bunch of java testcases under mipsel-linux.
OK, it was r120621 (The gcj-elipse branch merge) where things started
being broken.
There
Snapshot gcc-4.2-20070131 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070131/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Paulo J. Matos wrote on 01/31/07 11:26:
So, ideally, I would like just the gcc part until the first part of
the middleend where you have a 'no optimizations', language
independent AST of the source file.
OK, so you probably want to inject your pass right before pass_build_ssa
(in init_optimiza
> "Benjamin" == Benjamin Kosnik <[EMAIL PROTECTED]> writes:
Benjamin> but I am
Benjamin> somewhat concerned with the response of the java maintainers (and
Benjamin> others) that it's OK to require >512MB to bootstrap gcc with java, or
Benjamin> that make times "WORKSFORME."
My proposal was mo
Andrew Haley wrote:
David Daney writes:
> Richard,
>
> Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
> on a bunch of java testcases under mipsel-linux.
>
> It looks related to (but not necessarily caused by) this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> Ouch. I can confirm that on a 32-bit box of mine it fails with about
Gerald> 500MB of main memory.
It is interesting that it is the HTML parser that is causing
problems. For me, gnu-xml.lo is usually the awful one.
Does that o
Hi,
the gcc 4.1 testsuite currently shows a failure for the libstdc++ abi_check
testcase
on s390 and s390x and I see this one failing on several other targets as well.
On s390x abi_check complains about 22 missing functions in libstdc++.so:
FUNC:acosl@@GLIBCXX_3.4.3
FUNC:asinl@@GLIBCXX_3.4.3
FU
> "David" == David Daney <[EMAIL PROTECTED]> writes:
David> The call to _ZN4java4lang6ObjectC1Ev is being generated as non-pic,
David> even though that symbol is defined in libgcj.so. The assembler and
David> linker conspire to jump to address 0x for this call.
Could also be the prob
On 1/31/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/30/07 10:11:
> Well, I spent the morning looking at the code and since what I need is
> only the flow of gcc up until I have the GIMPLE tree, I could add a
> pass after the pass which generates the gimple tree, in th
Paulo J. Matos wrote on 01/30/07 10:11:
Well, I spent the morning looking at the code and since what I need is
only the flow of gcc up until I have the GIMPLE tree, I could add a
pass after the pass which generates the gimple tree, in that pass I do
what I need with the gimple tree and then call
Marcin Dalecki wrote:
512MB is *certainly* resonable. It's the most common amount of
shipping RAM
for in esp. notebooks and it's what usually get's allocated to
virtualization
solutions.
I agree 512M is reasonable (really a compiler taking more than
half a gigabyte for any normal sources i
Wiadomość napisana w dniu 2007-01-31, o godz12:50, przez Andrew Haley:
Benjamin Kosnik writes:
I am somewhat concerned with the response of the java maintainers
(and others) that it's OK to require >512MB to bootstrap gcc with
java, or that make times "WORKSFORME."
Well, I didn't say that,
Benjamin Kosnik writes:
>
> I am somewhat concerned with the response of the java maintainers
> (and others) that it's OK to require >512MB to bootstrap gcc with
> java, or that make times "WORKSFORME."
Well, I didn't say that, so I hope you aren't referring to me. But
before we do anything
On Wed, Jan 31, 2007 at 11:42:12AM +, Andrew Haley wrote:
> Andrew Haley writes:
> > >
> > > It does look like we are scaring away some people with the long
> > > build times and memory hungry build of libjava. I only started
> > > building libgcj again recently when I got a
> > > 3G
On Tue, 2007-01-30 at 17:26 -0800, Mark Mitchell wrote:
> Robert Schwebel wrote:
>
> > What about PR28516, would it be acceptable for 4.1.2?
>
> There are two issues:
>
> (1) it's not marked as a 4.1 regression, let alone a regression from
> 4.1.x. Did this test case work with older versions of
May I respectfully point out that the gcc make process already has
hard-coded hackery to work around the limitations of certain machines,
oses, non-GNU makes, linkers, and assembers, etc? (The thing that comes
to mind is the 42 item limit for make rules on AIX: see
libstdc++-v3/include/Makefi
Andrew Haley writes:
> >
> > It does look like we are scaring away some people with the long
> > build times and memory hungry build of libjava. I only started
> > building libgcj again recently when I got a
> > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an
> > compile/ins
Mark Wielaard writes:
> On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
> > > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > Andrew> Anyway, I tried again, this time with the right file, and it took
> > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgda
Le Wed, Jan 31, 2007 at 09:45:04AM +, Andrew Haley écrivait/wrote:
>
> I'd want a bit more information. There's no reason that a 512M box
> couldn't cope with a 550M process. Sure, it'll be slow, but it should
> still work, and this is an extreme case. If there is to be a maximum
> process
On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> Anyway, I tried again, this time with the right file, and it took
> Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k
> Andrew> and in
Gerald Pfeifer writes:
> On Tue, 30 Jan 2007, Andrew Haley wrote:
> > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> > 0maxresident)k
> >
> > and indeed, it does want a lot of memory - at peak some 550m. It'll
> > be smaller on a 32-bit box, but not much smaller.
>
> Ou
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> Anyway, I tried again, this time with the right file, and it took
> Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k
> Andrew> and indeed, it does want a lot of
David Daney writes:
> Richard,
>
> Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
> on a bunch of java testcases under mipsel-linux.
>
> It looks related to (but not necessarily caused by) this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > I am getting this when I try to compile gcc trunk:
> >
> > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
> > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -W
I wrote:
<< I'd appreciate feedback on general questions from these observations:
Is it generally known/expected that xcoff/stabs debugging capabilities
degrade when moving from 3.4 to 4.x ?
If yes, how is that considered by AIX GCC developers ? (how serious the
issue, is it fixable
Anyway, I tried again, this time with the right file, and it took
78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
and indeed, it does want a lot of memory - at peak some 550m. It'll
be smaller on a 32-bit box, but not much smaller.
I want to get rid of TREE_COMP
Gerald Pfeifer wrote:
On Tue, 30 Jan 2007, Andrew Haley wrote:
78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
and indeed, it does want a lot of memory - at peak some 550m. It'll
be smaller on a 32-bit box, but not much smaller.
Ouch. I can confirm that on a 32-
31 matches
Mail list logo
