> GCC 4.0.3 has been released.
You need to add a link on the page
http://gcc.gnu.org/gcc-4.0
Similarly for the 4.1.0 release on the page
http://gcc.gnu.org/gcc-4.1
And don't you need to display the release date instead of "current changes"
for 4.1.0 on the main page?
--
Eric Botcazou
On 11/mar/2006, at 02:09, Tom Tromey wrote:
Yes, one of the test cases in the libjava test suite checks this.
Offhand I forget which one... but if you do a 'make check' and send
the list of FAILs we can help analyze them. (This would be better
done on the gcj list, [EMAIL PROTECTED])
This is
On Mar 11, 2006, at 1:04 AM, Mark Mitchell wrote:
Gerald Pfeifer wrote:
Looking at the current sizes
gcc-core-4.2-20060304.tar.bz2 = 15703096
gcc-g++-4.2-20060304.tar.bz2 = 3905138
gcc-objc-4.2-20060304.tar.bz2 = 191280
gcc-fortran-4.2-20060304.tar.bz2 = 793478
Gerald Pfeifer wrote:
> Looking at the current sizes
>
> gcc-core-4.2-20060304.tar.bz2 = 15703096
> gcc-g++-4.2-20060304.tar.bz2 = 3905138
> gcc-objc-4.2-20060304.tar.bz2 = 191280
> gcc-fortran-4.2-20060304.tar.bz2 = 793478
> gcc-testsuite-4.2-20060304.tar.bz2 =
On Wed, 2006-03-08 at 16:43 -0600, Joel Sherrill wrote:
> Andreas Schwab wrote:
>
> >Joel Sherrill <[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>RPM invoked make install with the prefixes overriden:
> >>
> >>make
> >>prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0
I apologize in advance if this is a bit long or off-topic, but you might be
interested to hear first-hand what some of current Sun customers have to say.
On Fri, 10 Mar 2006, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, Steven Bosscher wrote:
> > On Friday 03 March 2006 02:46, Alexey Starovoy
On 3/11/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Unlikely, since you haven't described at all what the problem is.
> That's why we prefer bug reports with testcases.
"...segfaults due to bogus SSE alignments"
40666a: movaps %xmm0,0x348(%esp)
The GCC 4.0 branch is now open, under the usual release-branch rules.
However, I do not plan to make any further releases from the 4.0
branch.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
GCC 4.0.3 has been released.
This release is a bug-fix release for problems in GCC 4.0.2. GCC
4.0.3 contains changes to correct regressions from previous releases,
but no new features.
GCC 4.1.0 is the most current release of GCC and is our recommended
version for most users. However, curren
On Sat, Mar 11, 2006 at 03:43:45AM +0100, tbp wrote:
> I haven't made a bugreport yet, as that would require disclosing large
> amounts of code, but i'd like to know if it's a known issue by any
> chance.
Unlikely, since you haven't described at all what the problem is.
That's why we prefer bug r
On Mar 10, 2006, at 10:13 PM, Toon Moene wrote:
autogen -T ../../trunk/fixincludes/check.tpl
../../trunk/fixincludes/inclhack.def
make[2]: autogen: Command not found
Maybe we should change this to be
autogen || true
so that we don't get that many complaints about this. Anyways the
re
Gentlemen,
I get the following building 111952 (all languages except treelang):
/home/toon/compilers/obj-t/./gcc/gfortran
-B/home/toon/compilers/obj-t/./gcc/
-B/usr/snp/x86_64-unknown-linux-gnu/bin/
-B/usr/snp/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/snp/x86_64-unknown-linux-gnu/include -
This bug is really transient, and AFAIK i only trigger it when using
the cluebat on g++, that is bloating every function in sight
appropriately with always_inline/noinline attributes, in a unit that
inflates much.
Tracked one occurence to something like that:
union float4_t {
float f[4];
I have strange ICEs (that come and go as I rearrange the source - like the
sequence of include statements). They appear also to affect different files
on different machines we compile on.
This one here seems to go away if I remove -fprofile-arcs -ftest-coverage
from the commandline.
It would be gr
> "Sandro" == Sandro Tolaini <[EMAIL PROTECTED]> writes:
>> For best results you will want to make sure that the code to turn
>> signals into exceptions works properly. This is both OS- and
>> architecture dependent. I haven't looked at the x86 darwin port,
>> perhaps some gcc hacking is req
> Alexey Starovoytov writes:
Alexey> I doesn't look that my opinion here worth even 1 cent,
Alexey> but here are few things:
...
Alexey> All of the above is done by sun compiler and gcc4ss (except openmp).
Alexey> A lot of other things are coming.
None of the items you listed are SP
Morning all!
Sorry to bore everyone with old-fashioned 3.x stuff :) but I was just
wondering if there's a little loophole here that I may have fallen into?
`FUNCTION_OK_FOR_SIBCALL (DECL)'
A C expression that evaluates to true
Ross Ridge wrote:
> Why isn't there a console window? The Cygwin version of rxvt, and I
> think xterm, creates (and keeps hidden) a console window that should
> be inherited by gcc and as. If there wasn't console window for gcc to
> inherit, why didn't Windows create one for gcc?
I can't answer
On Fri, 2006-03-10 at 12:34 -0800, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, David Edelsohn wrote:
>
> > > Alexey Starovoytov writes:
> >
> > > If Sun starts improving GCC backend now it will never be able to catch up
> > > with Sun's own backend.
> >
> > This is a completely ridicu
On Fri, 2006-03-10 at 14:06 -0800, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, Andrew Pinski wrote:
>
> >
> > On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote:
> >
> > > Few major infrastructure features needs to be done first.
> >
> > Like? Please give examples. If link time optimizat
Ross Ridge wrote:
> I think you're barking up the wrong tree here. Windows only creates
> console windows automagically when a console application starts that
> can't inherit its parent's console window.
Mark Mitchell wrote:
> Exactly -- there is no parent console window here.
Why isn't there a
On 10/mar/2006, at 20:42, Tom Tromey wrote:
libffi and mudflap were covered by Paolo and Andrew.
I have done some work on sysv.S and now libffi compiles fine on OSX/
Intel. Unfortunately, I had to put some #ifdef __APPLE__ this file
because Apple ships an old cctools with as that doesn't u
The gcc documentation says:
Use `-fmudflapth' instead of `-fmudflap' to compile and to link if
your program is multi-threaded.
but the mudflap gate is
static bool
gate_mudflap (void)
{
return flag_mudflap != 0;
Snapshot gcc-4.1-20060310 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060310/
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
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote:
- prefetch
It rather hurts performance when I tried it. Check -xprefetch* flags
There is a new tree level prefetching pass on the mainline, maybe you
should try it again.
-- Pinski
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote:
- value profiling
doesn't look anything is done
Done and already in 3.4.0 and improved for the tree level in 4.1.0.
- openmp
I think it needs to be fully platform dependent, but anyway.
Certainly would be interesting to compa
On Fri, 10 Mar 2006, Andrew Pinski wrote:
>
> On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote:
>
> > Few major infrastructure features needs to be done first.
>
> Like? Please give examples. If link time optimizations,
> that is already starting to be worked on.
I doesn't look that my opi
Ross Ridge wrote:
> Mark Mitchell wrote:
>> The new pex-win32.c code doesn't operate correctly when used for
>> MinGW-hosted tools invoked from a Cygwin window. In particular, process
>> creation ("gcc" invoking "as", say) results in a DOS console window
>> popping up. When invoked from a DOS win
On Fri, 10 Mar 2006, Steven Bosscher wrote:
> On Friday 03 March 2006 02:46, Alexey Starovoytov wrote:
> > We are pleased to announce the availability of GCC for SPARC (R) Systems
> > (GCCfss) at http://cooltools.sunsource.net/gcc/
>
> Instead of pleased, I'd be ashamed for announcing this. To me
Mark Mitchell wrote:
>The new pex-win32.c code doesn't operate correctly when used for
>MinGW-hosted tools invoked from a Cygwin window. In particular, process
>creation ("gcc" invoking "as", say) results in a DOS console window
>popping up. When invoked from a DOS window, things are fine.
What
On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote:
Few major infrastructure features needs to be done first.
Like? Please give examples. If link time optimizations,
that is already starting to be worked on.
-- Pinski
On Mar 10, 2006, at 3:14 PM, Andrew Pinski wrote:
And it turned out I was correct in saying libstdc++ is also effected.
See PR 26633. So this is not a libfortran specific issue any more.
Actually that turned out to the TLS not be updated correctly for
threads issue with static linking problem
On Fri, 10 Mar 2006, David Edelsohn wrote:
> > Alexey Starovoytov writes:
>
> > If Sun starts improving GCC backend now it will never be able to catch up
> > with Sun's own backend.
>
> This is a completely ridiculous assertion. Do you have any
> evidence to back this up? There is no r
In fact, the url of the project seams to be http://rtlcheck.sourceforge.net/
CJ
"Moritz Muehlenhoff" <[EMAIL PROTECTED]> a écrit dans le message de
news:[EMAIL PROTECTED]
> Hi,
> I'm working on a research project that performs static source code
vulnerability
> analysis on the RTL layer. (http://
On Fri, 10 Mar 2006, Eric Botcazou wrote:
> Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more
> resource-consuming than designing and maintaining a hybrid compiler. If I'm
gcc4ss wasn't a big effort. gimple form made it easy for us.
> not mistaken, the gap is wide for FP
On Friday 03 March 2006 02:46, Alexey Starovoytov wrote:
> We are pleased to announce the availability of GCC for SPARC (R) Systems
> (GCCfss) at http://cooltools.sunsource.net/gcc/
Instead of pleased, I'd be ashamed for announcing this. To me
it feels like you're announcing with pride how you ri
On Mar 7, 2006, at 6:31 PM, Andrew Pinski wrote:
I bet the same issue now will happen with libstdc++ (and in 4.1.0 in
fact).
I want to say the weak references is the wrong way of doing things for
non
shared libraries.
And it turned out I was correct in saying libstdc++ is also effected.
S
> "Sandro" == Sandro Tolaini <[EMAIL PROTECTED]> writes:
Sandro> Hi everyone, I would like to port gcj/libgcj to i386-darwin. Is there
Sandro> someone already working on that?
Not that I know of.
Sandro> target-zlib: should be sufficient to add i386-darwin to the supported
Sandro> platforms
> Alexey Starovoytov writes:
> If Sun starts improving GCC backend now it will never be able to catch up
> with Sun's own backend.
This is a completely ridiculous assertion. Do you have any
evidence to back this up? There is no reason that GCC could not intercept
Sun CC if some effo
I suspect it isn't matching pattern #2, because it couldn't get a QI
register, and instead it falls back to the general case of moving to a
normal register. I believe the gcc_assert should contain a check for
CONST_INT as well as a QI register or memory.
-Original Message-
From: [EMAIL PR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there
how is it possible to emit regular register names (e.g. for the MIPS
to use $31 and not $ra) when producing assembly output (with
mips-elf-gcc -S)?
I want to just use the arithmetic names ($0 to $31).
regards
Nikolaos Kavvadias
-BEGIN
Hi,
I'm working on a research project that performs static source code vulnerability
analysis on the RTL layer. (http://rtl-check.sf.net)
For the analysis we need to manually annotate the amount of memory needed
to represent local variables and global static variables. For the stack level
this
in
> When you're a company like Intel with a relatively small gap between gcc
> on x86 and icl, it's worth improving the gcc backend, but on Sparc
> the gap is much wider, so the effort to bridge it may not be justified
> from a resource point of view.
Eh, SPARC is not IA-64 so improving the SPARC ba
I'll happily test a patch to that file for you...the only box at my
house runs Windows... =-O
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular,
Paolo Bonzini writes:
>
> > target-zlib: should be sufficient to add i386-darwin to the supported
> > platforms
>
> zlib is being skipped only because libjava is.
>
> > target-boehm-gc: a patch exists for porting to the new platform, so it
> > should be a matter of applying it
>
> W
target-zlib: should be sufficient to add i386-darwin to the supported
platforms
zlib is being skipped only because libjava is.
target-boehm-gc: a patch exists for porting to the new platform, so it
should be a matter of applying it
Well, good.
target-libffi, target-libmudflap, target-libj
Hi everyone, I would like to port gcj/libgcj to i386-darwin. Is there
someone already working on that?
Considering that powerpc-darwin is a supported platform, it should
not prove to be too hard. However, I need some hints on how to
proceed. At configure phase, GCC woes for:
target-libmud
47 matches
Mail list logo
