Bootstrap failure (on FreeBSD)
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/./gcc/xgcc -B/usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/ -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/bin/ -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/lib/ -isystem /files/pfeifer/gcc/i386-unknown-freebsd6.2/include -isystem /files/pfeifer/gcc/i386-unknown-freebsd6.2/sys-include -DHAVE_CONFIG_H -I. -I/sw/test/GCC/trunk/libgomp -I. -I/sw/test/GCC/trunk/libgomp/config/posix -I/sw/test/GCC/trunk/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT team.lo -MD -MP -MF .deps/team.Tpo -c /sw/test/GCC/trunk/libgomp/team.c -fPIC -DPIC -o .libs/team.o libtool: compile: /usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/xgcc -B/usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/ -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/bin/ -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/lib/ -isystem /files/pfeifer/gcc/i386-unknown-freebsd6.2/include -isystem /files/pfeifer/gcc/i386-unknown-freebsd6.2/sys-include -DHAVE_CONFIG_H -I. -I/sw/test/GCC/trunk/libgomp -I. -I/sw/test/GCC/trunk/libgomp/config/posix -I/sw/test/GCC/trunk/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT team.lo -MD -MP -MF .deps/team.Tpo -c /sw/test/GCC/trunk/libgomp/team.c -o team.o >/dev/null 2>&1 gmake[4]: *** [team.lo] Error 1 gmake[4]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' gmake[1]: *** [all-target-libgomp] Error 2 gmake[1]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0907-2228' gmake: *** [bootstrap-lean] Error 2 Unfortunately, the log/error message does not appear very helpful. Any hints how to make some progress with this? Gerald
Re: Bootstrap failure (on FreeBSD)
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: > > libtool: compile: /usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/xgcc > -B/usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/ > -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/bin/ > -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/lib/ -isystem > /files/pfeifer/gcc/i386-unknown-freebsd6.2/include -isystem > /files/pfeifer/gcc/i386-unknown-freebsd6.2/sys-include -DHAVE_CONFIG_H -I. > -I/sw/test/GCC/trunk/libgomp -I. -I/sw/test/GCC/trunk/libgomp/config/posix > -I/sw/test/GCC/trunk/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT team.lo > -MD -MP -MF .deps/team.Tpo -c /sw/test/GCC/trunk/libgomp/team.c -fPIC -DPIC > -o .libs/team.o > libtool: compile: /usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/xgcc > -B/usr/nabil-files/pfeifer/OBJ-0907-2228/./gcc/ > -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/bin/ > -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/lib/ -isystem > /files/pfeifer/gcc/i386-unknown-freebsd6.2/include -isystem > /files/pfeifer/gcc/i386-unknown-freebsd6.2/sys-include -DHAVE_CONFIG_H -I. > -I/sw/test/GCC/trunk/libgomp -I. -I/sw/test/GCC/trunk/libgomp/config/posix > -I/sw/test/GCC/trunk/libgomp -Wall -pthread -Werror -O2 -g -O2 -MT team.lo > -MD -MP -MF .deps/team.Tpo -c /sw/test/GCC/trunk/libgomp/team.c -o team.o > >/dev/null 2>&1 > gmake[4]: *** [team.lo] Error 1 > gmake[4]: Leaving directory > `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory > `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory > `/usr/nabil-files/pfeifer/OBJ-0907-2228/i386-unknown-freebsd6.2/libgomp' > gmake[1]: *** [all-target-libgomp] Error 2 > gmake[1]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0907-2228' > gmake: *** [bootstrap-lean] Error 2 > > Unfortunately, the log/error message does not appear very helpful. Any > hints how to make some progress with this? 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). -- Pinski
Re: Bootstrap failure (on FreeBSD)
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, Andrew.
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 'gomp_thread_start':
/sw/test/GCC/trunk/libgomp/team.c:131: error: invalid rtl sharing found in the
insn
(insn 22 21 23 2 /sw/test/GCC/trunk/libgomp/team.c:89 (parallel [
(set (reg:SI 74)
(plus:SI (reg:SI 70)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags
0x22] )
] 5)
(const_int 8 [0x8])
(clobber (reg:CC 17 flags))
]) 170 {*addsi_1} (nil))
/sw/test/GCC/trunk/libgomp/team.c:131: error: shared rtx (const:SI (plus:SI
(unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0x22] )
] 5)
(const_int 8 [0x8])))
/sw/test/GCC/trunk/libgomp/team.c:131: internal compiler error: internal
consistency failure
Gerald
Re: GCC 4.3.0 Status Report (2007-09-04)
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 additional optimization requested by the "customer" in comment 11: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315#c11 -- Rask Ingemann Lambertsen
Re: Bootstrap failure (on FreeBSD)
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 'gomp_thread_start':
> /sw/test/GCC/trunk/libgomp/team.c:131: error: invalid rtl sharing found in
> the insn
> (insn 22 21 23 2 /sw/test/GCC/trunk/libgomp/team.c:89 (parallel [
> (set (reg:SI 74)
> (plus:SI (reg:SI 70)
> (const:SI (plus:SI (unspec:SI [
> (symbol_ref:SI ("gomp_tls_data") [flags
> 0x22] )
> ] 5)
> (const_int 8 [0x8])
> (clobber (reg:CC 17 flags))
> ]) 170 {*addsi_1} (nil))
> /sw/test/GCC/trunk/libgomp/team.c:131: error: shared rtx (const:SI (plus:SI
> (unspec:SI [
> (symbol_ref:SI ("gomp_tls_data") [flags 0x22] 0x48954ac8 gomp_tls_data>)
> ] 5)
> (const_int 8 [0x8])))
> /sw/test/GCC/trunk/libgomp/team.c:131: internal compiler error: internal
> consistency failure
>
> Gerald
bootstrap comparision failure with --enable-targets=all on i486-linux-gnu
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[4]: *** [compare] Error 1 make[4]: Leaving directory `/scratch/packages/gcc/snap/gcc-snapshot-20070907/build' make[3]: *** [stage3-bubble] Error 2 make[3]: Leaving directory `/scratch/packages/gcc/snap/gcc-snapshot-20070907/build' make[2]: *** [bootstrap-lean] Error 2
g++ std::max() performance
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]? opt[i-1]: opt[i-2];
Looking at the implementation std::max in stl_algobase.h
template
inline const _Tp&
max(const _Tp& __a, const _Tp& __b)
{
__glibcxx_function_requires(_LessThanComparableConcept<_Tp>)
//return __a < __b ? __b : __a;
if (__a < __b)
return __b;
return __a;
}
It is "inline" and the function arguments are const-references,
So shouldn't it be as fast as the ?: tri-operator version?
Can anyone else observe this?
Rds,
PS: I've noticed this on x86.
PS: I've come across some bug in Sun studio's compilers that seemed related,
but perhaps isn't:
http://bugs.sun.com/view_bug.do?bug_id=6498247
Re: g++ std::max() performance
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 tree-optimization/30738 (and 19431). Paolo.
Re: [RFC] Marking C++ new operator as malloc?
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 unclear whether this is safe. Nothing in the standard AFAIK > | > requires the operator new be implemented in terms of malloc, and > | > users are allowed to override it. > | > | The malloc property doesn't mean that operator new is defined in terms > | of malloc. It refers to the aliasing properties of the returned > | values; specifically, the compiler can assume that two separate calls > | return values that don't alias each other. > > I seem to remember we had had this discussion before -- in connection > with optimizations related to 'malloc' attribute -- and decided not to > apply the attribute because it was not clear whether it was permitted > by the standard. I don't seem to get my hands on reference to the > thread right now. > There is a related bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748 H.J.
RE: g++ std::max() performance
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 16:38 To: Hicham Mouline Cc: gcc@gcc.gnu.org Subject: Re: g++ std::max() performance 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 tree-optimization/30738 (and 19431). Paolo.
Re: can't reinterpret_cast to/from the same type
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 one of the listed conversions, so GCC is correct to give an error. Regards, Jon
Re: can't reinterpret_cast to/from the same type
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++ standard lists the conversions allowed by > reinterpret_cast. This is not one of the listed conversions, so GCC is > correct to give an error. It still seems odd, and this restriction could make the coding of templates more complex.
Re: [RFC] Marking C++ new operator as malloc?
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, Martin Jambor wrote: [ giving operator new the malloc property ] On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote: It is unclear whether this is safe. Nothing in the standard AFAIK requires the operator new be implemented in terms of malloc, and users are allowed to override it. The malloc property doesn't mean that operator new is defined in terms of malloc. It refers to the aliasing properties of the returned values; specifically, the compiler can assume that two separate calls return values that don't alias each other.
Re: [RFC] Marking C++ new operator as malloc?
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:
[ giving operator new the malloc property ]
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
It is unclear whether this is safe. Nothing in the standard AFAIK
requires the operator new be implemented in terms of malloc, and
users are allowed to override it.
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?
But I am not a C++ expert!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [RFC] Marking C++ new operator as malloc?
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 almost everything :) Richard.
Re: [RFC] Marking C++ new operator as malloc?
"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 breaks lose if you do so. A sane ::new | is required for almost everything :) I suspect the question is how to you distinguish a sane new from an an insane one. -- Gaby
gnu c reference manual : c dialects
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 ISO standard of the language, as implemented by GCC, along with the GNU extensions, but explicitly label which parts of the language are GNU-specific. With this in mind, I have a question: 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 that does not support C99, so for my group it would be useful -- but I suspect that we are the exception rather than the rule. Thoughts? -- Trevis Rothwell (please cc: me on replies as I am not subscribed to the GCC list)
The Linux binutils 2.18.50.0.1 is released
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 applied and
in what order they have been applied.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.18.50.0.1 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.17.50.0.18:
1. Update from binutils 2007 0908.
2. Fix an ELF linker for SHT_NOBITS sections. PR 2864/5006.
3. Improve TLS transition check in i386 and x86-64 linkers.
4. Fix a GD->LE/LD->LE TLS transition bug in i386 and x86-64 linkers.
PR 4918.
5. Update ELF linker to dump segment map when a section can't be allocated
in segment. PR 4909.
6. Clean up x86 disassembler to remove fixups and make it more
table driven.
7. Fix x86 disassember for SSE instructions in Intel mode. PR 4834.
8. Properly handle bss segments in ELF linker.
9. Add --string-dump to readelf.
10. Fix objcopy -R .debug_* --only-keep-debug regression. PR 4888.
11. Change x86 assembler to follow SVME specification.
12. Fix x86 assembler for cmpxchg8b, pextrb and pinsrb in Intel mode.
13. Update x86 assembler to better handle expressions with @GOT suffix.
PR 4079.
14. Properly handle section alignment >= 128 byte for PECOFF.
15. Fix an ELF linker --build-id option crash. PR 4923.
16. Fix binutils build on HP-UX. PR 4875.
17. Fix a regression of the a.out linker -N option. PR 4515.
18. Update x86 disassembler for invlpg, fxsave, fxrstor, ldmxcsr and
stmxcsr in Intel mode.
19. Fix x86 assembler for SSE4 instructions in Intel mode.
20. Fix various arm bugs.
21. Fix various mips bugs.
22. Fix various ppc bugs.
23. Fix various spu bugs.
24. Fix various xtensa bugs.
Changes from binutils 2.17.50.0.17:
1. Update from binutils 2007 0731.
2. Switching from GPLv2 to GPLv3.
3. Add a new ELF linker option, --build-id, to generate a unique
per-binary identifier embedded in a note section.
4. Remove COFF/x86-64 from PE-COFF/x86-64.
5. Fix a "nm -l" crash on DWARF info. PR 4797.
6. Match symbol type when creating symbol aliase in ELF shared library.
7. Fix addr2line on relocatable linux kernel. PR 4756.
8. Change disassembler to print addend as signed.
9. Support section alignment from 128 to 8192 bytes for PE-COFF.
10. Add attribute section to ELF linker.
11. Fix ELF linker to meet gABI alignment requirement. PR 4701.
12. Add support for reading in debug information via a .gnu_debuglink
section.
13. Fix string merge for ia64 linker. PR 4590.
14. Add --common to size to display total size for *COM* syms.
15. Fix "strip --strip-unneeded" on relocatable files. PR 4716.
16. Fix "objcopy/strip --only-keep-debug" for SH
Re: gnu c reference manual : c dialects
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 that does not support C99, so for my group it would be > useful -- but I suspect that we are the exception rather than the rule. Since gcc does have an option to run in C89 mode, the users need to know what this means (that is, what features are disabled).
Re: [RFC] Marking C++ new operator as malloc?
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 guarantees of attribute > | > malloc. > | > | Well, you can argue that all hell breaks lose if you do so. A sane ::new > | is required for almost everything :) > > I suspect the question is how to you distinguish a sane new from an an > insane one. Does it matter? If an insane new hands multiple callers the same memory without an intervening delete, whether or not the compiler optimizes on the assumption that new is sane doesn't matter; the program is still going to break.
Re: [RFC] Marking C++ new operator as malloc?
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 return value *always* aliases the memory you passed it to supply the place.
Re: [RFC] Marking C++ new operator as malloc?
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 the malloc attribute only to ::operator
> new but not to other new-s, in particular not to the placement new?
>
> But I am not a C++ expert!
Neither am I. However, I have done a small series of experiments that
showed this is exactly what happens with the patch I sent in the
original mail.
Obviously, this thread is not about placement new which I believe
definitely cannot have the flag set.
I compiled four small tests with both patched and untampered compiler
(revision 128277) and compared dumps. The exact dumps and some further
details are attached, here I'll just list three of the sources and
briefly summarize the effect of the patch.
1. Allocating a simple int (in fact the same example as in PR23383):
int f(void)
{
int t;
int *a = new int;
int *b = new int;
*a = 1;
*b = 2;
t = *a;
delete a;
delete b;
return t;
}
The patched compiler turnes return into "return 1" and removes the
load to t. The unpatched does neither.
2. Allocating a simple class:
class A
{
public:
int d;
};
int f(void)
{
int t;
A *a = new A;
A *b = new A;
a->d = 1;
b->d = 2;
t = a->d;
delete a;
delete b;
return t;
}
The same thing. Patched version returns 1, original performs load.
3. Allocating a simple class with a redefined new operator.
class A
{
public:
int d;
static void* operator new (size_t size);
static void operator delete (void *p);
};
static A pool[2];
static int n = 0;
__attribute__ ((noinline)) void* A::operator new (size_t size)
{
// the following should be dangerous enough:
void *p = &pool[n];
n++;
return p;
}
__attribute__ ((noinline)) void A::operator delete (void *p)
{
// no-op
}
int f(void)
{
int t;
A *a = new A;
A *b = new A;
a->d = 1;
b->d = 2;
t = a->d;
delete a;
delete b;
return t;
}
Both patched and original compiler produced exactly the same dump,
the patched version did not perform any (unsafe) transformations.
So my conclusion is that redefined new operators are not an issue and
the attribute does not affect them.
Martin
All dumps below are from *.121t.optimized files.
The only optimization related switch used was -O3.
==
test.int.cpp
Source:
---
#include
int f(void)
{
int t;
int *a = new int;
int *b = new int;
*a = 1;
*b = 2;
t = *a;
delete a;
delete b;
return t;
}
--
Unpatched compiler:
---
int f() ()
{
intD.2 * bD.1771;
intD.2 * aD.1770;
intD.2 tD.1769;
voidD.35 * D.1773;
voidD.35 * D.1772;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# SMT.6D.1783_9 = VDEF { SMT.6D.1783 }
D.1772 = operator new (4);
aD.1770 = (intD.2 *) D.1772;
# SMT.6D.1783_10 = VDEF { SMT.6D.1783 }
D.1773 = operator new (4);
bD.1771 = (intD.2 *) D.1773;
# SMT.6D.1783_11 = VDEF { SMT.6D.1783 }
*aD.1770 = 1;
# SMT.6D.1783_12 = VDEF { SMT.6D.1783 }
*bD.1771 = 2;
# VUSE { SMT.6D.1783 }
tD.1769 = *aD.1770;
# SMT.6D.1783_13 = VDEF { SMT.6D.1783 }
operator delete (aD.1770);
# SMT.6D.1783_14 = VDEF { SMT.6D.1783 }
operator delete (bD.1771);
return tD.1769;
# SUCC: EXIT [100.0%]
}
--
Patched compiler:
-
int f() ()
{
intD.2 * bD.1771;
intD.2 * aD.1770;
voidD.35 * D.1773;
voidD.35 * D.1772;
# BLOCK 2 freq:1
# PRED: ENTRY [100.0%] (fallthru,exec)
# HEAP.4D.1781_11 = VDEF
# HEAP.5D.1782_12 = VDEF
# SMT.8D.1785_13 = VDEF { HEAP.4D.1781 HEAP.5D.1782 SMT.8D
.1785 }
D.1772 = operator new (4);
aD.1770 = (intD.2 *) D.1772;
# HEAP.4D.1781_14 = VDEF
# HEAP.5D.1782_15 = VDEF
# SMT.8D.1785_16 = VDEF { HEAP.4D.1781 HEAP.5D.1782 SMT.8D.17
85 }
D.1773 = operator new (4);
bD.1771 = (intD.2 *) D.1773;
# HEAP.4D.1781_17 = VDEF { HEAP.4D.1781 }
*aD.1770 = 1;
# HEAP.5D.1782_18 = VDEF { HEAP.5D.1782 }
*bD.1771 = 2;
# HEAP.4D.1781_19 = VDEF
# HEAP.5D.1782_20 = VDEF
# SMT.8D.1785_21 = VDEF { HEAP.4D.1781 HEAP.5D.1782 SMT.8D.17
85 }
operator delete (aD.1770);
# HEAP.4D.1781_22 = VDEF
# HEAP.5D.1782_23 = VDEF
# SMT.8D.1785_24 = VDEF { HEAP.4D.1781 HEAP.5D.1782 SMT.8D.17
85 }
operator delete (bD.1771);
Re: [RFC] Marking C++ new operator as malloc?
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) as malloc-allocated. The cleanest
>> approach would probably be to mark the new operator function with the
>> malloc attribute. So I did that (see the extra-short patch below),
>> bootstrapped c and c++ on i686-linux (with "all,fold" checking) and
>> ran the test suite. To my surprise, there were no new regressions.
>>
>> I am now wondering why the function is not marked as malloc
>> already. In fact, its implementation always returns what it gets from
>> the built-in malloc. Are there any known issues or concerns with this
>> that the test suite cannot reveal? Can anyone comment on this?
>
> It is unclear whether this is safe. Nothing in the standard AFAIK requires
> the operator new be implemented in terms of malloc, and users are allowed
> to override it.
I have just explained in another email that user-overridden new's do
not seem to be a problem as the attribute is given only to the
libstdc++ one.
The reason why I believe the patch is safe not only in practice but
also in principle is that the libstc++ operator new implementation
(see below) returns what it gets from malloc which is hopefully
mallocish enough (and the operator does not do any dangerous stuff
with the pointer either).
Martin
--- cut here ---
_GLIBCXX_WEAK_DEFINITION void *
operator new (std::size_t sz) throw (std::bad_alloc)
{
void *p;
/* malloc (0) is unpredictable; avoid it. */
if (sz == 0)
sz = 1;
p = (void *) malloc (sz);
while (p == 0)
{
new_handler handler = __new_handler;
if (! handler)
#ifdef __EXCEPTIONS
throw bad_alloc();
#else
std::abort();
#endif
handler ();
p = (void *) malloc (sz);
}
return p;
}
--- cuthere ---
Re: [RFC] Marking C++ new operator as malloc?
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 attribute because it was not clear whether it was permitted > > by the standard. I don't seem to get my hands on reference to the > > thread right now. > > There is a related bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748 I followed that discussion in July and read it over again now (it starts with http://gcc.gnu.org/ml/gcc/2007-07/msg00513.html). However, I do not believe that it is relevant, because unlike realloc, new does not half-destroy half-retain an object. Martin
Re: [RFC] Marking C++ new operator as malloc?
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 | > | > 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 almost everything :) | > | > I suspect the question is how to you distinguish a sane new from an an | > insane one. | | Does it matter? No, it does not. The reason is 3.7.3.1/2 [...] If the request succeeds, the value returned shall be a nonnull pointer value (4.10) p0 different from any previously returned value p1, unless that value p1 was subsequently passed to an operator delete. -- Gaby
Re: [RFC] Marking C++ new operator as malloc?
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 'malloc' attribute will be in effect. The abstract semantics is that replaceable `operator new' functions are implicitly declared in *every* translation unit -- and that is what GCC does --, and you should have those implicit declarations carry the attributes, not just the one defined in libstdc++. -- Gaby
