Basically i'd like to have the cake and also eat it.
With g++-4.2-20060805/cygwin on a k8 box on some software path with
lots of sp float ops but no transcendentals or library calls
-mfpmath=sse,387: 5.2 Mray/s
-mfpmath=sse: 6 Mray/s
That 15% performance difference is no surprise when yo
The second missing symbol generated by gcc trunk on
MacOS X 10.4 when compiling with -m64 can be demonstrated with
this test case...
main()
{
__int128_t a, b;
b= a / 10;
}
which when compiled with "gcc-4 -m64 division.c" produces the
linkage error...
can't resolve symbols:
___divti3, refer
I can produce the first missing symbol with current gcc trunk on
MacOS X 10.4 using this testcase...
main()
{
__int128_t a, b;
b= a % 10;
}
When compiled with "gcc-4 -m64 modulo.c", this produces the linkage
failure of...
can't resolve symbols:
___modti3, referenced from:
_main in cc8
While testing the state of gfortran in gcc trunk at -m64 on MacOS X 10.4
I discovered a huge number of test failures (848 compared to 26 with -m32).
Almost all of these failures appear to be due to two undefined symbols in
libgfortran's shared library in the ppc64 version...
http://gcc.gnu.org
On Sat, Aug 05, 2006 at 09:03:34PM +0200, Wolfgang Mües wrote:
> First, I have had a problem with loading a register with a constant.
> (no clobber). I have solved this problem by adding
>
> > (define_insn "_arm_movqi_insn_const"
[cut]
>
> I am very shure that this does only cure the symptoms, a
Rask,
On Friday 21 July 2006 15:26, Rask Ingemann Lambertsen wrote:
> I found that this peephole optimization improves the code a whole
> lot:
Done.
> Another way of improving the code was to swap the order of the two
> last alternatives of _arm_movqi_insn_swp.
Done.
Anyway, the problems with
Snapshot gcc-4.2-20060805 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060805/
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/trunk
Aaron Graham wrote:
It appears that sjlj exceptions are broken (PRs 19774/25266/28493).
I'm not sure this is true for _every_ target, but it appears to be
true for many.
The real bug is PR28493, not PR19774. The latter (and PR25266 which is
related) only affect less common cases, i.e. using a
It appears that sjlj exceptions are broken (PRs 19774/25266/28493).
I'm not sure this is true for _every_ target, but it appears to be
true for many.
So it seems that those of us affected by this bug have three workarounds:
1) compile everything with -fno-exceptions and remove all eh from project
On 8/4/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
Hi
Is there a specification that describes a set of routines for
libgcc-math? I read through previous emails on this topic and it seems
that it has been removed from head. I'd like to contribute but not
sure what direction to go in. Is there
[EMAIL PROTECTED] (Frank Ch. Eigler) wrote:
> Vesselin Peev" <[EMAIL PROTECTED]> writes:
> [...] I have a feature request for mudflap. It should have an
> option to run glibc's _libc_freeres function that forces the C
> runtime library to free all of its memory [...]
Good idea. (It should no
11 matches
Mail list logo
