Martin Jambor <[EMAIL PROTECTED]> writes:
[...]
| The reason why I believe the patch is safe not only in practice but
| also in principle
However, I do not believe it is sufficient. The reason being that
if the user does not include a header that pulls in that declaration,
then that 'mallo
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]> writes:
| >
| > | On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
| > | > I understand, but allowing users to override new means that the actual
Hi,
On Sat, Sep 08, 2007 at 07:45:32AM -0700, H.J. Lu wrote:
> On Sat, Sep 08, 2007 at 12:57:13AM -0500, Gabriel Dos Reis wrote:
> > I seem to remember we had had this discussion before -- in connection
> > with optimizations related to 'malloc' attribute -- and decided not to
> > apply the attrib
Hi,
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
> On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
>> when trying to analyse dynamically allocated objects in C++, I came
>> across the need to identify results of the new operator (at least the
>> non-overridden standard one
Hi,
On Sat, Sep 08, 2007 at 10:16:41PM +0200, Basile STARYNKEVITCH wrote:
> Chris Lattner wrote:
>> I understand, but allowing users to override new means that the actual
>> implementation may not honor the aliasing guarantees of attribute malloc.
>> -Chris
>
> Maybe it could make sense to give t
On Sat, Sep 08, 2007 at 10:16:41PM +0200, Basile STARYNKEVITCH wrote:
> Maybe it could make sense to give the malloc attribute only to
> ::operator new but not to other new-s, in particular not to the
> placement new?
It would be completely wrong to give the attribute to placement new,
as the re
On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> | On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
> | > I understand, but allowing users to override new means that the actual
> | > implementation may not honor the aliasing
On Sat, Sep 08, 2007 at 06:28:18PM -0400, Trevis Rothwell wrote:
> 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?
> In my day job, we, for rather unusual reasons, are using a very old
> version of GCC
This is the beta release of binutils 2.18.50.0.1 for Linux, which is
based on binutils 2007 0908 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Hello!
I have been hacking away for some time, and now am nearing completion, on
writing
the "GNU C Reference Manual", covering the C language sans libraries and
preprocessing
directives (which are already documented in other GNU manuals).
The plan is to have the base of the manual cover the I
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
| > I understand, but allowing users to override new means that the actual
| > implementation may not honor the aliasing guarantees of attribute
| > malloc.
|
| Well, you can argue that all hell b
On 9/8/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
> I understand, but allowing users to override new means that the actual
> implementation may not honor the aliasing guarantees of attribute
> malloc.
Well, you can argue that all hell breaks lose if you do so. A sane ::new
is required for almos
Chris Lattner wrote:
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute malloc.
-Chris
On Sep 7, 2007, at 10:12 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
[ g
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute
malloc.
-Chris
http://nondot.org/sabre
http://llvm.org
On Sep 7, 2007, at 10:12 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
On Sep 7, 2007, at 1:53 PM, Mar
On Sat, Sep 08, 2007 at 05:51:39PM +0100, Jonathan Wakely wrote:
> On 06/09/2007, Peter A. Felvegi <[EMAIL PROTECTED]> wrote:
> > i don't know if it's a bug, please clarify:
> > int y = reinterpret_cast(x);
> > rc.cpp:4: error: invalid cast from type 'int' to type 'int'
>
> 5.2.10 in the C
On 06/09/2007, Peter A. Felvegi <[EMAIL PROTECTED]> wrote:
> i don't know if it's a bug, please clarify:
> int y = reinterpret_cast(x);
> rc.cpp:4: error: invalid cast from type 'int' to type 'int'
5.2.10 in the C++ standard lists the conversions allowed by
reinterpret_cast. This is not on
Right. I haven't used 4.3 yet.
I googled around and the only other compiler I saw that fixed this
was SU's, in my previous post. (if I understood correctly)
They fixed it just a few months back.
tx
-Original Message-
From: Paolo Carlini [mailto:[EMAIL PROTECTED]
Sent: 08 September 2007 1
On Sat, Sep 08, 2007 at 12:57:13AM -0500, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
> | > [ giving operator new the malloc property ]
> |
> | On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
> | > It is uncl
Hicham Mouline wrote:
Can anyone else observe this?
You are observing it on gcc4.2.x or gcc4.1.x, right? Because mainline
(would be 4.3.0) is able to optimize both exactly to the same tree.
Actually, should be one of the very few compilers around implementing
that optimization ;) See PRs t
With -O3, in a inner loop, that iterates perhaps 10^9 times,
using
double opt[100];
for ()
for (...)
opt[i] = std::max( opt[i-1] , opt[i-2] );
is much much slower than
for ()
for (...)
opt[i] = opt[i-1]>opt[i-2]
seen with r128264, was sucessful on 20070906
Matthias
make[5]: Leaving directory
`/scratch/packages/gcc/snap/gcc-snapshot-20070907/build'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./cfgloopmanip.o differs
make
same failure on i486-linux-gnu
Gerald Pfeifer writes:
> Turns out it is an RTL sharing issue on i386. Jan, that's probably one
> for you?
>
>
> [bootstrap/33352] invalid rtl sharing -- bootstrap failure compiling
> libgomp/team.c on i386
>
> /sw/test/GCC/trunk/libgomp/team.c: In function 'go
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
> Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html
It's blocking work on the a
On Sat, 8 Sep 2007, Andrew Pinski wrote:
> Rerun the command without the ">/dev/null 2>&1", libtool likes to say
> that PIC mode will give the same output as non PIC mode (which is not
> always true).
Blind me. Obviously that redirection removed all traces of the real
error. Ahem. Thanks, Andre
On 9/8/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> I have been getting the following for a couple of days, but it seems
> nobody else is seeing this? This is on a FreeBSD 5.4 machine which has
> been bootstrapping mainline for months w/o problems, apart from the usual
> short-lived breakages:
I have been getting the following for a couple of days, but it seems
nobody else is seeing this? This is on a FreeBSD 5.4 machine which has
been bootstrapping mainline for months w/o problems, apart from the usual
short-lived breakages:
libtool: compile: /usr/nabil-files/pfeifer/OBJ-0907-2228/./
26 matches
Mail list logo
