Mike Stump wrote:
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is there
some reason why you can't do that?
I thought the point was that that option is temporary and will go away.
Over my d
On Jan 9, 2006, at 10:46 AM, David Taylor wrote:
For a variety of reasons, we would like to be able to specify
individual compilation switches *within* individual files.
Dale added this to our gcc compiler, see the apple/trunk branch for
example, near APPLE LOCAL .* optimization pragmas lines
On Jan 17, 2006, at 10:30 PM, Mike Stump wrote:
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is
there
some reason why you can't do that?
I thought the point was that that option is temporary an
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote:
Steven Bosscher wrote:
... you can use --disable-bootstrap and do a regular make, or is
there
some reason why you can't do that?
I thought the point was that that option is temporary and will go
away.
Over my dead body. We will al
> > or if the memory model of the PIC18 is definitively a problem to
> > gcc porting ?
>
> Weird chips make porting harder. :-)
Hey, if I can get the m32c series supported...
But yeah, gcc *really* wants to see a standard RISC chip these days.
On Jan 9, 2006, at 7:41 AM, [EMAIL PROTECTED] wrote:
I actually want to do coverage analysis on bootloader code from
YAMON (used mostly on MIPS board). Obviously, I cannot invoke
'gcov' on bootloader code and thus the conundrum.
Don't see why not, just arrange to save it out to memory somepl
On Jan 8, 2006, at 3:11 PM, [EMAIL PROTECTED] wrote:
So can you tell me more about your experience with the Microchip
18F, if
somebody is currently working on this device,
Nope, don't think so.
or if the memory model of the PIC18 is definitively a problem to
gcc porting ?
Weird chips mak
On Jan 17, 2006, at 8:45 PM, Andrew Pinski wrote:
The testsuite is way broken and does not run all the tests:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html
http:
The testsuite is way broken and does not run all the tests:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00898.htm
On Jan 16, 2006, at 11:48 PM, Laurent GUERBY wrote:
Hi, you've provided me with ACATS testing results on powerpc-darwin in
the past, we currently don't know the state of Ada on the GCC 4.1
branch
for powerpc-darwin as of 20060117:
http://gcc.gnu.org/ml/gcc/2006-01/msg00578
Hi, Dave,
Thanks a lot for your help.
Best Regards
Jian-ping
-"Dave Korn" <[EMAIL PROTECTED]> wrote: -
To: <[EMAIL PROTECTED]>,
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: 01/17/2006 07:04PM
cc: <[EMAIL PROTECTED]>
Subject: RE: Forward declaration issue on gcc 3.4.3(New)
Jian-ping.Hu
Andrew Pinski wrote:
On Jan 17, 2006, at 5:57 PM, Frank Ch. Eigler wrote:
If not would it be a good idea to disable mudflap by default on mips?
Tried native? If that also doesn't work I'd be up for disabling.
I was under the impression that libmudflap was disabled by default
almost everyw
The overall patch is OK. Please could add testcases that test
-Wno-conversion? Thanks for doing this.
Thanks. I've committed the patch and a testcase that makes sure we
don't emit a warning if Wconversion is turned off.
-eric
On Jan 17, 2006, at 5:57 PM, Frank Ch. Eigler wrote:
If not would it be a good idea to disable mudflap by default on mips?
Tried native? If that also doesn't work I'd be up for disabling.
I was under the impression that libmudflap was disabled by default
almost everywhere. Unless libmudflap
Gunther Nikl wrote :
> On Tue, Jan 17, 2006 at 01:35:59PM +0100, Philippe De Muyter wrote:
> > Where is that AmigaOS port availaible ?
> > That seems to be an easier solution.
>
> GCC diffs upto 3.4.0 are available here:
>
>ftp://ftp.back2roots.org/pub/geekgadgets/amiga/m68k/alpha/gcc/
I ha
Hi -
> >Has anyone ever gotten mudflap working on mips?
> I've never tried, but I think that mudflap isn't guaranteed to work
> for cross compilers. Frank?
The compiler portion (tree-mudflap.c) should work about as well for
crosses as for native builds. The part that poses porting problems is
"Philippe De Muyter" <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote :
>> "Philippe De Muyter" <[EMAIL PROTECTED]> writes:
>>
>> >* config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory
>> >operands.
>>
>> This is ok, but please send the patch to [EMAIL PROTECTED]
>>
>> Andre
On Jan 17, 2006, at 1:54 PM, David Daney wrote:
I am running make -k check on a 4.1 mipsel-linux cross compiler.
It seems that many of the libmudflap tests enter some sort of
endless loop. Strace shows no system calls, but they take 100% of
the cpu.
Has anyone ever gotten mudflap worki
Snapshot gcc-3.4-20060117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> ./config.guess
x86_64-unknown-linux-gnu
> gcc -v
Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.5/specs
Configured with: ../gcc-3.4.5/configure
Thread model: posix
gcc version 3.4.5
Distribution: SUSE LINUX 10.0 (X86-64)
> uname -srv
Linux 2.6.13-15.7-default #1 Tue Nov 29
config.guess output: i686-pc-linux-gnu
gcc -v output:
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.5/specs
Configured with: ../gcc-3.4.5/configure
Thread model: posix
gcc version 3.4.5
Distribution: SUSE LINUX 10.0 (i586)
uname -srv output:Linux 2.6.13-15.7-default #1 Tue Nov 29 1
I am running make -k check on a 4.1 mipsel-linux cross compiler. It
seems that many of the libmudflap tests enter some sort of endless loop.
Strace shows no system calls, but they take 100% of the cpu.
Has anyone ever gotten mudflap working on mips?
If not would it be a good idea to disable
Andreas Schwab wrote :
> "Philippe De Muyter" <[EMAIL PROTECTED]> writes:
>
> > * config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory
> > operands.
>
> This is ok, but please send the patch to [EMAIL PROTECTED]
>
> Andreas.
It is already there :)
http://gcc.gnu.org/ml
"Philippe De Muyter" <[EMAIL PROTECTED]> writes:
> * config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory
> operands.
This is ok, but please send the patch to [EMAIL PROTECTED]
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße
Someone's informed Richard Stallman that this (annoying) warning will not be
enabled by default in GCC 4.1. But, it currently seems to be. Should it be
turned off before the release? If not, who told RMS it was? :-)
--
Daniel Jacobowitz
CodeSourcery
On Sun, 15 Jan 2006, Olivier Hainque wrote:
> Bernd Trog wrote:
> > Will it output the real or worst case stack usage?
>
> The latter in any case, although I'm not sure what you mean by "real"
> stack usage. Could you please enligthen ?
By "real" I ment the actual stack usage (which is -Ox d
Hi,
GNU Classpath 0.20 was released last weekend. It contains a lot of new
standard library classes and bug fixes. See
http://www.gnu.org/software/classpath/announce/20060113.html
And the list of fixed bugs:
http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.20
We will i
> IMHO, the fact that GCC includes /usr/local/include by default in it's
> system header search path is brain damaged, but it's probably way too
> entrenched to revisit that. :-(
>
> --Kaveh
> --
> Kaveh R. Ghazi[EMAIL PROTECTED]
You can stop this by specifyi
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00833.html
> hppa2.0w-hp-hpux11.11 has some cxg problems, but I don't
> know if 4.0 worked at all there.
A testsuite run with ada for 4.0.3 is here:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00893.html.
The run terminated before completing.
Just so you guys know, a change in 1.3 will make large commits take a
longer than they used to.
We background the task that sends out the mail, and in 1.2, this used to
cause the post-commit hook that runs to return immediately.
However, 1.3, in order to catch output from the post-commit hooks, n
> Perry Smith writes:
Perry> While doing my RS/6000 work last week, I bumped into two bugs and two
Perry> other items which I would more consider suggestions. The bugs I will
Perry> submit via the prescribed method. But how to the maintainers want to
Perry> see the suggestions?
While doing my RS/6000 work last week, I bumped into two bugs and two
other items which I would more consider suggestions. The bugs I will
submit via the prescribed method. But how to the maintainers want to
see the suggestions?
Thanks,
Perry Smith
Classification: UNCLASSIFIED
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/joshuang/joshuang/gcc-4.0.2/configure
--prefix=/home/joshuang/joshuang/local
Thread model: posix
gcc version 4.0.2
Red Hat Linux release 7.3 (Valhalla)
Kernel \r on an \m
Linux
Hello,
> > another point to consider is that perhaps there might be some common
> > way how to specify "detail level"; we already have -fsched-verbose=num
> > and -ftree-vectorizer-verbose=num, perhaps we should avoid having a
> > separate flag for each pass.
> >
> Good point. Would you be willin
On Tue, Jan 17, 2006 at 01:35:59PM +0100, Philippe De Muyter wrote:
> Gunther Nikl wrote :
> > On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote:
> > > For an embedded mmu-less m68k target, I would like to generate code
> > > that will always run at a fixed place in memory, thus no
Gunther Nikl wrote :
> On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote:
> > For an embedded mmu-less m68k target, I would like to generate code
> > that will always run at a fixed place in memory, thus not needing to be PIC,
> > but that would access a data+bss segment that could
On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote:
> For an embedded mmu-less m68k target, I would like to generate code
> that will always run at a fixed place in memory, thus not needing to be PIC,
> but that would access a data+bss segment that could be anywhere in memory,
> thu
Jian-ping.Hui wrote:
> Now my question is: Why there are such difference between the two version
> gcc?
This is a VFAQ. See http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
> Could I compile b.cpp by simply changing some compiler options?
No, you will have to fix the invalid code to be f
Sorry for the previous wrong format mail. Please ignore it.
I encountered an issue when building our program. The compilation will fail
when using gcc 3.4.3. However, the same program can be compiled
successfully with gcc 3.2.3.
I used the following example to reproduce the issue:
=
a.h
===
Hello everyone,
I have a doubt reagarding these trampolines, When i was going through
the details in an atricle named GCC-INTERNALS, It said that we have a
macro with the following name TRAMPOLINE_ADJUST_ADDRESS (addr).
The explaination to it said that this is used mainly to perform any
machine-
Hi,
I encountered an issue when building our program. The compilation will fail
when using gcc 3.4.3. However,
the same program can be compiled successfully with gcc 3.2.3.
I used the following example to reproduce the issue:
=
a.h
=
#ifndef A_H_
#define A_H_
class A
{
public:
> Please let me know the location of the gcc402.zip
If you are looking for GCC releases, please see:
http://gcc.gnu.org/releases.html
Ben
Please let me know the location of the gcc402.zip
Thanks
Amrith
43 matches
Mail list logo
