On 4/9/07, Dave Korn [EMAIL PROTECTED] wrote:
On 09 April 2007 21:49, Lawrence Crowl wrote:
The optimization above would be wrong for such machines because
the allocation would be smaller than the requested size.
To request a size of ~size_t(0) is to request a size
of 0x or
Florian Weimer writes:
Yeah, but that division is fairly expensive if it can't be performed
at compile time. OTOH, if __compute_size is inlined in all places,
code size does increase somewhat.
Well, I believe the assumption was that __compute_size would be inlined.
If you want to minimize code
2007/4/9, Ross Ridge [EMAIL PROTECTED] wrote:
Florian Weimer writes:
Yeah, but that division is fairly expensive if it can't be performed
at compile time. OTOH, if __compute_size is inlined in all places,
code size does increase somewhat.
Well, I believe the assumption was that __compute_size
allocate_array_april2007.tar.gz
Description: GNU Zip compressed data
2007/4/9, J.C. Pizarro [EMAIL PROTECTED] wrote:
_Z29__allocate_array_of_RossRidgejjj:
[ gcc v3.4.6 : 9 instructions ]
movl4(%esp), %edx
cmpl12(%esp), %edx # comparing and ?? i lose me
movl8(%esp), %eax
orl $-1, %eax
imull %edx,
2007/4/9, Robert Dewar [EMAIL PROTECTED]:
J.C. Pizarro wrote:
The multiply is signed. It is need more researching a little bit.
So what, the low order 32 bits are unaffected. I think this is just
confusion on your part!
Yes, i accidently eliminated the lines containing the point '.' for
#include stddef.h
void *__allocate_array_of_RossRidge(size_t num, size_t size, size_t max_num) {
if (num max_num)
size = ~size_t(0);
else
size *= num;
return operator new[](size);
}
void *__allocate_array_of_JCPizarro(size_t num, size_t size, size_t
max_num) {
if (num
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't have the bug Joe's code had. That was
sort of the whole point. If
2007/4/9, Ross Smith [EMAIL PROTECTED] wrote:
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't have the bug Joe's
On Tue, Apr 10, 2007 at 03:44:26AM +1200, Ross Smith wrote:
On Monday, 9 April 2007 13:09, J.C. Pizarro wrote:
This code is bigger than Joe Buck's.
Joe Buck's code: 10 instructions
Ross Ridge's code: 16 instructions
Ross Smith's code: 16 instructions
Well, yes, but it also doesn't
On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
#include stddef.h
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size * num;
if (tmp =
2007/4/9, Joe Buck [EMAIL PROTECTED]:
On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
#include stddef.h
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size
4. Conditional moves (cmov).
J.C. Pizarro [EMAIL PROTECTED] writes:
To optimize even more the x86, it still has to use:
1. Use imul instead of mul because it's little bit faster in cycles.
2. Use jns/js (sign's conditional jump) instead of jnc/jc (carry's
conditional jump).
3. To modify the C-preprocessor and/or C/C++
2007/4/9, Lawrence Crowl [EMAIL PROTECTED]:
On 4/7/07, Joe Buck [EMAIL PROTECTED] wrote:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead of
n_elements*sizeof Foo to operator new, where
2007/4/9, Andrew Pinski [EMAIL PROTECTED]:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
3. To modify the C-preprocessor and/or C/C++ compiler for:
#if argument X is a constant then
use this code specific of constant X
#else if argument Y is not a constant then
Ross == Ross Ridge [EMAIL PROTECTED] writes:
Ross So long as whatever switch is used to enable this check isn't on by
Ross default and its effect on code size and speed is documented, I don't
Ross think it matters that much what those effects are. Anything that works
Ross should make the people
On Apr 9, 2007, at 12:14 PM, J.C. Pizarro wrote:
How many code's species are they?
One for every problem...
7. Code for IPA??? - i don't know this weird language. Is it with
attributes?.
8. Code for GIMPLE??? - i don't know this weird language.
9. Code for RTL??? - i don't know this weird
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
Of course, i'm a novice because i like and i don't like the
GCC development's model.
Of course the user manual explains all what I have mentioned in my
previous email so it sounds like you like 95% of the other people who
don't read the manual
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
2007/4/9, Lawrence Crowl [EMAIL PROTECTED]:
On 4/7/07, Joe Buck [EMAIL PROTECTED] wrote:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead
On Mon, Apr 09, 2007 at 01:49:09PM -0700, Lawrence Crowl wrote:
On 4/9/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
We've working in linear address spaces.
How for segmented address spaces? You give me examples.
Intel has had several popular processors with segmented addresses
including the
#include stddef.h // by J.C. Pîzarro
...
// See http://www.cs.sjsu.edu/~kirchher/CS047/multDiv.html
// One-operand imul: Unsigned mul:
// warning: 32 bit, i686, possible risk of -x * -y = valid x * y, ...
// warning: it's made quick dirty, possible to give clobbered situations.
//
#include stddef.h // by J.C. Pîzarro
...
// This function doesn't touch the ECX register that is touched by OptionC.
__volatile__ static const int minus_one = -1;
void *__allocate_array_OptionD(size_t num, size_t size) {
register unsigned int result;
__asm__ __volatile__
(
On 09 April 2007 21:49, Lawrence Crowl wrote:
The optimization above would be wrong for such machines because
the allocation would be smaller than the requested size.
To request a size of ~size_t(0) is to request a size
of 0x or 0xULL that the allocator
will always
* Joe Buck:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead of n_elements*sizeof Foo
to operator new, where __compute_size is
inline size_t __compute_size(size_t num, size_t size) {
size_t
On 08 April 2007 10:43, Florian Weimer wrote:
* Joe Buck:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead of n_elements*sizeof
Foo to operator new, where __compute_size is
inline size_t
Dave Korn [EMAIL PROTECTED] writes:
Wouldn't using -ftrapv do what we want?
-ftrapv only modifies signed arithmetic. Unsigned arithmetic never traps.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
On 08 April 2007 13:58, Andreas Schwab wrote:
Dave Korn [EMAIL PROTECTED] writes:
Wouldn't using -ftrapv do what we want?
-ftrapv only modifies signed arithmetic. Unsigned arithmetic never traps.
Andreas.
Meh, I'm an idiot. Still, maybe we want to create a -futrapv
In article [EMAIL PROTECTED] you write:
On Fri, Apr 06, 2007 at 06:51:24PM -0500, Gabriel Dos Reis wrote:
David Daney [EMAIL PROTECTED] writes:
| One could argue that issuing some type of diagnostic (either at
| compile time or run time) would be helpful for people that don't
| remember to
In article [EMAIL PROTECTED] you write:
The assert should not overflow. I suggest
#include stdlib.h
#include stdint.h
assert( n SIZE_MAX / sizeof(int) );
which requires two pieces of information that the programmer
otherwise wouldn't need, SIZE_MAX and sizeof(type).
Asking programmers to
Dave Korn wrote:
Wouldn't using -ftrapv do what we want? Would a possible answer be to make
an ftrapv attribute that could be selectively applied to security-critical
library routines such as operator new?
I have always been told that -ftrapv is nowhere near fully working or
reliable (I
Joe Buck writes:
inline size_t __compute_size(size_t num, size_t size) {
size_t product = num * size;
return product = num ? product : ~size_t(0);
}
Florian Weimer writes:
I don't think this check is correct. Consider num = 0x3334 and
size = 6. It seems that the check is
Robert Dewar wrote:
I have always been told that -ftrapv is nowhere near fully working or
reliable (I think Eric is the source of that advice).
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that it doesn't
work.)
On 4/8/07, Bradley Lucier [EMAIL PROTECTED] wrote:
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that it doesn't
work.)
If you look into the bugzilla, you will see now two bugs filed against
-ftrapv. One because the
Andrew Pinski writes:
On 4/8/07, Bradley Lucier [EMAIL PROTECTED] wrote:
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that it doesn't
work.)
If you look into the bugzilla, you will see now two bugs filed
* Ross Ridge:
Florian Weimer writes:
I don't think this check is correct. Consider num = 0x3334 and
size = 6. It seems that the check is difficult to perform efficiently
unless the architecture provides unsigned multiplication with overflow
detection, or an instruction to implement
Bradley Lucier wrote:
Robert Dewar wrote:
I have always been told that -ftrapv is nowhere near fully working or
reliable (I think Eric is the source of that advice).
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that
On Monday, 9 April 2007 10:23, Florian Weimer wrote:
* Ross Ridge:
Florian Weimer writes:
I don't think this check is correct. Consider num = 0x3334 and
size = 6. It seems that the check is difficult to perform
efficiently unless the architecture provides unsigned
multiplication
Joe Buck wrote:
inline size_t __compute_size(size_t num, size_t size) {
size_t product = num * size;
return product = num ? product : ~size_t(0);
}
2007/4/9, Ross Smith [EMAIL PROTECTED] wrote:
On Monday, 9 April 2007 10:23, Florian Weimer wrote:
* Ross Ridge:
Florian
Joe Buck wrote:
inline size_t __compute_size(size_t num, size_t size) {
size_t product = num * size;
return product = num ? product : ~size_t(0);
}
2007/4/9, Ross Smith [EMAIL PROTECTED] wrote:
On Monday, 9 April 2007 10:23, Florian Weimer wrote:
* Ross Ridge:
Florian
And this tarball.
J.C. Pizarro.
compute_size_april2007_2.tar.gz
Description: GNU Zip compressed data
One instruction more in GCC-4.1.x vs GCC-3.4.6?
Joe Buck's code: 10 instructions [ -Os of gcc-4.1.3-20070326 ]
__compute_size:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movl%eax, %edx
imull 12(%ebp), %edx
cmpl%eax, %edx
Florian Weimer writes:
I don't think this check is correct. Consider num = 0x3334 and
size = 6. It seems that the check is difficult to perform efficiently
unless the architecture provides unsigned multiplication with overflow
detection, or an instruction to implement __builtin_clz.
Joe Buck writes:
If a check were to be implemented, the right thing to do would be to throw
bad_alloc (for the default new) or return 0 (for the nothrow new).
What do you do if the user has defined his own operator new that does
something else?
There cases where the penalty for this check could
* Karl Chen:
4 * n, unchecked, is vulnerable to integer overflow. On IA-32,
new int[0x4001] becomes equivalent to new int[1]. I've
verified this on gcc-2.95 through 4.1. For larger objects the
effects are exaggerated; smaller counts are needed to overflow.
This PR19351, by the way.
Florian Weimer wrote:
This PR19351, by the way.
The most widespread interpretation of the standard is that conforming
implementations aren't allowed to raise an exception in this case:
the arithmetic is defined to occur in terms of an unsigned type.
Well for sure the standard does not allow
2007/4/7, Ross Ridge [EMAIL PROTECTED]:
Joe Buck writes:
If a check were to be implemented, the right thing to do would be to throw
bad_alloc (for the default new) or return 0 (for the nothrow new).
What do you do if the user has defined his own operator new that does
something else?
The
J.C. Pizarro wrote:
A solution is using the -shared option to generate .so library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Another future solution is pack the big .so library with UPX
(Ultimate Packer for eXecutables) or
2007/4/7, Robert Dewar [EMAIL PROTECTED]:
A solution is using the -shared option to generate .so library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Use -Os and strip --strip-all. And remove code if you don't like it.
Another
2007/4/7, Robert Dewar [EMAIL PROTECTED]:
A solution is using the -shared option to generate .so library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Use -Os and strip --strip-all. And remove code if you don't like it.
[EMAIL PROTECTED] (Ross Ridge) writes:
| Joe Buck writes:
| If a check were to be implemented, the right thing to do would be to throw
| bad_alloc (for the default new) or return 0 (for the nothrow new).
|
| What do you do if the user has defined his own operator new that does
| something else?
On Sat, Apr 07, 2007 at 12:15:10PM +0200, Florian Weimer wrote:
* Karl Chen:
4 * n, unchecked, is vulnerable to integer overflow. On IA-32,
new int[0x4001] becomes equivalent to new int[1]. I've
verified this on gcc-2.95 through 4.1. For larger objects the
effects are
Joe Buck writes:
If a check were to be implemented, the right thing to do would be to throw
bad_alloc (for the default new) or return 0 (for the nothrow new).
Ross Ridge writes:
What do you do if the user has defined his own operator new that does
something else?
Gabriel Dos Reis writes:
More
[EMAIL PROTECTED] (Ross Ridge) writes:
| Joe Buck writes:
| If a check were to be implemented, the right thing to do would be to throw
| bad_alloc (for the default new) or return 0 (for the nothrow new).
|
| Ross Ridge writes:
| What do you do if the user has defined his own operator new that
[EMAIL PROTECTED] (Ross Ridge) writes:
Well, for example, like all other things that a new_handler can do,
like throwing an exception derived from bad_alloc or calling exit().
In addition, any number of side effects are possible, like printing
error messages or setting flags.
Gabriel Dos Reis
Gabriel Dos Reis writes:
I believe you're confused about the semantics.
The issue here is that the *size of object* requested can be
represented. That is independent of whether the machine has enough
memory or not. So, new_handler is a red herring
On Sat, Apr 07, 2007 at 06:05:35PM
On Sat, Apr 07, 2007 at 04:01:57PM -0500, Gabriel Dos Reis wrote:
[EMAIL PROTECTED] (Ross Ridge) writes:
| Joe Buck writes:
| If a check were to be implemented, the right thing to do would be to throw
| bad_alloc (for the default new) or return 0 (for the nothrow new).
|
| Ross Ridge
On Sat, Apr 07, 2007 at 07:41:59AM -0400, Robert Dewar wrote:
J.C. Pizarro wrote:
A solution is using the -shared option to generate .so library.
That does not solve things in environments like embedded
environments where there are no shared libraries.
Another future solution is pack
Joe Buck [EMAIL PROTECTED] writes:
| This is why I suggested that, should we implement a better check,
| there should be an option to turn it off, so programmers who cannot
| afford an extra byte are taken care of.
I agree.
-- Gaby
[EMAIL PROTECTED] (Ross Ridge) writes:
[...]
| Gabriel Dos Reis writes:
| I believe you're confused about the semantics.
| The issue here is that the *size of object* requested can be
| represented. That is independent of whether the machine has enough
| memory or not. So, new_handler is a
Joe Buck writes:
Consider an implementation that, when given
Foo* array_of_foo = new Foo[n_elements];
passes __compute_size(elements, sizeof Foo) instead of n_elements*sizeof Foo
to operator new, where __compute_size is
inline size_t __compute_size(size_t num, size_t size) {
size_t
or throw bad_alloc.
At least one other compiler already specifically guards against
integer overflow in 'operator new'.
--
Karl 2007-04-06 07:30
)
to 'operator new' and let it return NULL or throw bad_alloc.
At least one other compiler already specifically guards against
integer overflow in 'operator new'.
--
Karl 2007-04-06 07:30
You've reason! There was not anything about this issue in gcc mailing
list archives.
But, i've more discussion about
On 2007-04-06 15:35 PDT, J C Pizarro writes:
J A possible workaround could be it but it's vulnerable if
J it's defined with -DNDEBUG :
J int * allocate_int(size_t n) {
J // it's another integer overflow, a positive can
J // become to a negative.
J
On 4/6/07, Karl Chen [EMAIL PROTECTED] wrote:
Regarding negatives, I believe 'operator new' takes a size_t,
which is unsigned, but if it were signed it, the multiplication
would indeed be in danger of creating a negative.
Actually if it was signed, the whole result would be undefined if
there
Andrew Pinski wrote:
On 4/6/07, Karl Chen [EMAIL PROTECTED] wrote:
Regarding negatives, I believe 'operator new' takes a size_t,
which is unsigned, but if it were signed it, the multiplication
would indeed be in danger of creating a negative.
Actually if it was signed, the whole result would
Good points.
Regarding negatives, I believe 'operator new' takes a size_t,
which is unsigned, but if it were signed it, the multiplication
would indeed be in danger of creating a negative.
If possible, I would prefer a solution that's built-in to operator
new. I was thinking it should be
On 4/6/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 4/6/07, Karl Chen [EMAIL PROTECTED] wrote:
Regarding negatives, I believe 'operator new' takes a size_t,
which is unsigned, but if it were signed it, the multiplication
would indeed be in danger of creating a negative.
Actually if it was
The assert should not overflow. I suggest
#include stdlib.h
#include stdint.h
assert( n SIZE_MAX / sizeof(int) );
which requires two pieces of information that the programmer
otherwise wouldn't need, SIZE_MAX and sizeof(type).
Asking programmers to write extra code for rare events, has
not
David Daney [EMAIL PROTECTED] writes:
| One could argue that issuing some type of diagnostic (either at
| compile time or run time) would be helpful for people that don't
| remember to write correct code 100% of the time.
I raised this very issue a long time ago; a long-term GCC contributor
J.C. Pizarro [EMAIL PROTECTED] writes:
[...]
| The compiler should be able to eliminate many of the conditionals.
| Yes but no, there are cases that the compiler can't eliminate the
| conditionals that depend on run-time, e.g., n is non-constant parameter.
What is the performance penalty
J.C. Pizarro [EMAIL PROTECTED] writes:
| Good points.
|
| Regarding negatives, I believe 'operator new' takes a size_t,
| which is unsigned, but if it were signed it, the multiplication
| would indeed be in danger of creating a negative.
|
| If possible, I would prefer a solution that's
06 Apr 2007 18:53:47 -0500, Gabriel Dos Reis [EMAIL PROTECTED]:
J.C. Pizarro [EMAIL PROTECTED] writes:
[...]
| The compiler should be able to eliminate many of the conditionals.
| Yes but no, there are cases that the compiler can't eliminate the
| conditionals that depend on run-time, e.g., n
J.C. Pizarro [EMAIL PROTECTED] writes:
[...]
| But if someone implements one fastest bucket-based quickallocator then
| the performance penalty with this check is considerable.
I would like to see the actual performance penalty numbers for such
thingy deployed in the real world.
-- Gaby
On 2007-04-06 16:12 PDT, Lawrence Crowl writes:
Lawrence Asking programmers to write extra code for rare
Lawrence events, has not been very successful.
Well put Lawrence, I agree; I didn't expect strong opposition.
I doubt we'd find much code in the wild that checks for integer
On Fri, Apr 06, 2007 at 06:51:24PM -0500, Gabriel Dos Reis wrote:
David Daney [EMAIL PROTECTED] writes:
| One could argue that issuing some type of diagnostic (either at
| compile time or run time) would be helpful for people that don't
| remember to write correct code 100% of the time.
I
76 matches
Mail list logo
