Hi,
I am trying to understand why the MIPS backend's handling of
comparison modes seems to be different from what rtl.texi says:
The mode of the comparison operation is independent of the mode
of the data being compared. If the comparison operation is being tested
(e.g., the first operand
On Sun, Dec 04, 2005 at 06:09:54PM -0500, Jack Howarth wrote:
> I was happy to see some recovery in the c++ code generation with
> gcc 4.1. Now xplor-nih only exhibits a 7% speed loss using g++-4.1
> compared to g++-3.3. I assume this is due to the total rewrite of
> the optimizers in gcc > 4.0
Hi.
> Any chances that the GCC Internals documentation will be updated any
> time soon? http://gcc.gnu.org/onlinedocs/gccint/
It looks pretty current to me.
> There have been a lot of changes in GCC and it's hard to figure out
> the code by reading the old documentation and the new incomplete
>
Richard,
Actually, while the currently offending file, dint-node.cc which
must be built with -fno-strict-aliasing, doesn't report any strict
aliasing violations in gcc 4.2, I do find that the rest of xplor-nih
is filled with them. I will report these upstream. They seem to all be
of the form..
On Sun, 4 Dec 2005, Mark Wielaard wrote:
> We try really hard not to disrupt the normal flow of GCC development.
> For any large build/integration changes we contact Mark Mitchell as
> release manager, but should probably also more often post a note to the
> main gcc list in the future.
That would
Richard,
I built current gcc 4.2 branch under MacOS X 10.4.3 and unfortunately
while -Wstrict-aliasing does catch the error from PR 14024, it doesn't catch
whatever strict aliasing error exists in dint-node.cc of xplor-nih. Is there
a list somewhere of all those strict aliasing violations which
Dear Sir,
I am a student at the American University in Cairo, and I am facing
some problems with the gcc version 3.2.2. When installing a package on
linux, it tries to compile some files but outputs the following error:
/usr/include/c++/3.2.2/bits/fpos.h:60: 'streamoff' is used as a type,
but is
In benchmarking a build of xplor-nih (which is a mix of c++,c, and
fortran) built entirely under gcc 4.1 or built using gcc 4.1's gfortran
and either Apple's gcc 4.0.1 or gcc 3.3, I have noticed that there
was a significant speed regression in the c++ code generation between
gcc 3.3 and gcc 4.0
On 12/4/05, Jack Howarth <[EMAIL PROTECTED]> wrote:
> In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran)
> I discovered one of its c++ source files causes segfaults at optimization
> levels higher than -O1 unless I add -fno-strict-aliasing to the compile
> flags. In that c
In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran)
I discovered one of its c++ source files causes segfaults at optimization
levels higher than -O1 unless I add -fno-strict-aliasing to the compile
flags. In that case, there program passes all of its testsuite without
any s
On Sun, 4 Dec 2005, FX Coudert wrote:
> PS: I'm amazed that a "GNU project" can have exactly two developers,
> release source snapshots every two years, adopt the too common attitude
> of "every non-i686-linux platform is not mainstream", and so on.
There is a difference in focus between the Fre
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> Is anyone seeing this? With current 4.1 sources, on a machine with "only"
> 1GB of main memory + 1GB swap, the following part of `make install`
>
> Adding java source files from srcdir '/cvs/gcc/trunk/libjava/classpath'.
> Adding java source files
On Sunday 04 December 2005 17:48, H. J. Lu wrote:
> SPEC CPU 2K FP compiled with gcc 4.2 failed to run with libgfortran
> from gcc 4.1. Is this expected?
Yes.
SPEC CPU 2K FP compiled with gcc 4.2 failed to run with libgfortran
from gcc 4.1. Is this expected? If yes, I think we should bump up
libgfortran version in 4.2.
H.J.
On Sun, 2005-12-04 at 11:48 +0100, Mark Wielaard wrote:
> This might be caused by my patch to reduce compile time in classpath. I
> know I tested memory use back then, but this might have only been with
> respect to the gcj invocations. I'll try reversing this patch and retest
> later today or tomo
Hi all,
Probably bad timing just after possibly haven broken the build on small
memory machines but I thought it would be good to explain the GNU
Classpath development plan and how we integrate with gcc. (BTW I can
reproduce the problem now by artificially limiting the virtual memory
size with uli
On Sun, Dec 04, 2005 at 11:45:21AM +, Andrew Haley wrote:
> Alan Modra writes:
> > On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote:
> > > spawns a recursive make (GNU make 3.80) that consumes some 450MB of
> memory
> > > and triggers a system load of 12+, basically rendering
Alan Modra writes:
> On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote:
> > spawns a recursive make (GNU make 3.80) that consumes some 450MB of memory
> > and triggers a system load of 12+, basically rendering the machine dead
> > for about a minute.
> >
> > On a different mac
Hi Gerald,
On Sun, 2005-12-04 at 00:35 +0100, Gerald Pfeifer wrote:
> Is anyone seeing this? With current 4.1 sources, on a machine with "only"
> 1GB of main memory + 1GB swap, the following part of `make install`
>
> Adding java source files from srcdir '/cvs/gcc/trunk/libjava/classpath'.
>
On 12/4/05, FX Coudert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Below is the answer I got from the developer of GMP when I asked about
> support for ia64-hpux.
>
> > So, in short, my questions are: is gmp-4.1.4 supposed to work on
> > ia64-hpux?
> >
> > No, it is not. It might be possible to g
Hi all,
Below is the answer I got from the developer of GMP when I asked about
support for ia64-hpux.
So, in short, my questions are: is gmp-4.1.4 supposed to work on
ia64-hpux?
No, it is not. It might be possible to get either the LP64 or
the ILP32 ABI to work, but even that requires t
21 matches
Mail list logo
