Hi Jim,
On 9/12/07, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Sunzir Deepur wrote:
> > recently I've encountered a problem in which some removals of
> > (what seems to be unneeded) lines of header files inflicted changes in
> > the resulting binary. further inverstigation showed
> > that the chages
Stephen,
I have been working on the x86_64-pc-mingw32 toolchain with Kai Tietz
(Kai is the main person, I am doing much more learning than helping).
I put together a built script that requires no tweaking whatsoever of
any of the projects incorporated in the toolchain. It is very
straightforward.
Trevis Rothwell <[EMAIL PROTECTED]> writes:
> Would it be useful to delineate not only between ISO C features and
> GNU C extensions, but also to delineate between the C89 and C99
> standards?
Yes.
Ian
Jim Wilson <[EMAIL PROTECTED]> writes:
> I'm not sure if anyone has ever done this before. The
> assembler/linker/etc have no support for odd sized variables.
> Usually the partial int modes were just used internal to gcc. For
> instance, if you have 24-bit address registers, you would use 32-bi
Tal Agmon wrote:
I see many references in gcc code to SImode. Isn't this problematic for
ports such as this when SImode does not represent the natural int?
In the gcc dir, "grep SImode *.[ch] | wc" shows only 67 lines. That
isn't a large number relatively speaking. Many of these are in
commen
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 9/9/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > Which brings back the fact that you cannot implement malloc in C
> > (you certainly remember the discussions about C++ placement new
> > handling wrt aliasing). To re-use the machinery
Sunzir Deepur wrote:
recently I've encountered a problem in which some removals of
(what seems to be unneeded) lines of header files inflicted changes in
the resulting binary. further inverstigation showed
that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
xxx symbol names)
GCC 4.3.0 will enter Stage 3 as of Wednesday, September 12th, at 11:59
PM PDT. (I've pushed this back from the previously announced September
10th date, since I failed to send out a final warning before that point.)
I appreciate everyone taking the development guidelines seriously, and
the fact t
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
4.2 branch should now be considered slushy; please get my explicit
approval before check-in. Obviously, there was no way anyone could have
known that, so if things have been checked in since the announcement
that's fine; I'll
On 9/11/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007, Tom Tromey wrote:
> >> Also, I recently added a new -fdirectives-only option which improves
> >> distcc and ccache performance. Does that merit a release note update
> > as well?
> > IMO, yes.
>
> Seconded. :-)
OK. I'll
Richard Guenther wrote:
>> So, for something like:
>>
>> char *pool;
>> void *operator new[] (size_t s) { /* return memory from pool */ }
>> ...
>> pool = new char[1024];
>> char *c = new char[16];
>>
>> IIUC, your claim is that if pool and c now have the same value, then any
>> indirect
Hello,
Since mainline is in, or is about to enter very soon, stage 3, I have
created a new branch "gc-improv" for GC work and related changes that
are not strictly bug fixes. The difference from the old boehm-gc
branch is that this one will not contain Boehm's GC integration.
As my previous email
On Tue, 11 Sep 2007, Tom Tromey wrote:
>> Also, I recently added a new -fdirectives-only option which improves
>> distcc and ccache performance. Does that merit a release note update
> as well?
> IMO, yes.
Seconded. :-)
Gerald
2007/9/10, John David Anglin <[EMAIL PROTECTED]>:
> > I succeed past this failure if I revert Zdenek's iv-opts patch
> (r128272).
>
> Same here. The failure also occurs on all hppa targets.
>
> Dave
> --
> J. David Anglin [EMAIL PROTECTED]
> National Research Counc
> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
Ollie> Also, I recently added a new -fdirectives-only option which improves
Ollie> distcc and ccache performance. Does that merit a release note update
Ollie> as well?
IMO, yes.
Tom
On 9/9/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> Ollie, would you mind adding a snippet to htdocs/gcc-4.3/changes.html
> in the wwwdocs module of our CVS repository? If you need any help with
> that, please let me know.
Sent to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg010
hi list,
recently I've encountered a problem in which some removals of
(what seems to be unneeded) lines of header files inflicted changes in
the resulting binary. further inverstigation showed
that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
xxx symbol names).
can someon
Hello!
>
>> This is using the Polyhedron Fortran test.
>> http://www.polyhedron.co.uk/MFL6VW74649
>
>> Using several options, the gas_dyn test got much slower; however,
with
>> some options, the performance remained roughly the same.
>> In terms of the geometric mean, it is a slowdown of around 1%.
>> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/
>> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron
I
>> think).
>> 14.59s -> 21.06s (44% slower)
>
I will look into it right now, but at first glance it does not look like
this benchmark is built with the cost mod
Hello!
> This is using the Polyhedron Fortran test.
> http://www.polyhedron.co.uk/MFL6VW74649
> Using several options, the gas_dyn test got much slower; however, with
> some options, the performance remained roughly the same.
> In terms of the geometric mean, it is a slowdown of around 1%.
> The
On Tue, Sep 11, 2007 at 03:50:39PM +0100, Fran?ois-Xavier Coudert wrote:
> The last few days have seen a regression in the Fortran testsuite on
> i386-linux and x86_64-linux (filed as PR33391). The following code
> gives wrong results at -O2 while it works at -O1:
>
> program test
> integer(
The last few days have seen a regression in the Fortran testsuite on
i386-linux and x86_64-linux (filed as PR33391). The following code
gives wrong results at -O2 while it works at -O1:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end pro
This is using the Polyhedron Fortran test.
http://www.polyhedron.co.uk/MFL6VW74649
Using several options, the gas_dyn test got much slower; however, with
some options, the performance remained roughly the same.
In terms of the geometric mean, it is a slowdown of around 1%.
The run time of the othe
On 11 Sep 2007 07:24:44 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > I think I'm getting confused. Perhaps you could sum up in a single
> | > email the argument for why putting this attribute in our standard
> | > headers is
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| > I think I'm getting confused. Perhaps you could sum up in a single
| > email the argument for why putting this attribute in our standard
| > headers is safe, even in view of possible replacement in user programs?
|
| My argument goes like
On 9/11/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote:
>You shouldn't define them, they'll only hide the problem.
You're right, and getting REG_OK_STRICT right solved the problem!
That was probably the best answer I ha
On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote:
> Thanks a lot for your input, I think I understand some of that code better
> now.
>
> I stumbled upon a solution last night, on realizing that the problem
> was with the DFmode powidf2 and seeing that I had not defined the
> movsf
(I'm turning this into a thread of it's own, it's really the
continuation of "error compiling libgcc with ported cross-compiler"
from yesterday.)
I am porting GCC to a new target, and got the following error when
cross-compiling libgcc towards the end of the make process:
/cygdrive/c/home/risc/sr
On 9/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > Well, we have that now:
> >
> > int *q = new int;
> > delete q;
> > int *p = new int;
> > delete p;
> > if (q != p)
> > cout << "different";
> >
> > we cannot optimize the test to be always true. The
Hi,
I'm working on a port in which BITS_PER_UNIT is 16, Therefore HImode
represent 32 bits int and SImode is actually long long.
I see many references in gcc code to SImode. Isn't this problematic for
ports such as this when SImode does not represent the natural int?
I would like to define PSImod
30 matches
Mail list logo
