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 0xFFF
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
>
#include // 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__
(
"imull %2"
"Lawrence Crowl" <[EMAIL PROTECTED]> writes:
[...]
| Intel has had several popular processors with segmented addresses
| including the 8086, 80186, and 80286. (Actually, the 80386 and
| successors are segmented, but the operating systems typically hide
| that fact.) The also had the i432.
|
|
#include // 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.
// warning:
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
> includi
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, sizeo
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 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 weir
2007/4/9, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
2007/4/9, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> Well lets say this, we already support this to some extend, by using
> __builtin_constant_p and then just inlining. Also there exists
> alre
> "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 mak
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 consta
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, wher
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
use this code specific of non-c
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 __compute_size is
inline size_t __compute_size(size_t
"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
4. Conditional moves (cmov).
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
> >
> >void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
> > unsigned long long tmp = (unsigned long long)
On Mon, Apr 09, 2007 at 09:47:07AM -0700, Andrew Pinski wrote:
> On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> >#include
> >
> >void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
> > unsigned long long tmp = (unsigned long long)size * num;
> > if (tmp >= 0x800
On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
#include
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size * num;
if (tmp >= 0x8000ULL) tmp=~size_t(0);
return operator new[](tmp);
}
First this just h
#include
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size * num;
if (tmp >= 0x8000ULL) tmp=~size_t(0);
return operator new[](tmp);
}
void *__allocate_array_OptionB(size_t num, size_t size) { // 2nd best
u
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
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 J
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.
#include
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 > max_num) retur
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
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, %e
allocate_array_april2007.tar.gz
Description: GNU Zip compressed data
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_s
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
> > 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 __bu
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
And this tarball.
J.C. Pizarro.
compute_size_april2007_2.tar.gz
Description: GNU Zip compressed data
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 Rid
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 Rid
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
> >> mult
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
* 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
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 bug
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 r
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.)
B
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 d
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 thi
In article <[EMAIL PROTECTED]> you write:
>The assert should not overflow. I suggest
>
>#include
>#include
>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 ex
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
>> |
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
fla
"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 fin
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
>>
>>
* 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) {
>
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) {
>
[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
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
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 solutio
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 Ri
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:35P
[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 R
[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
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:
>Mor
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
[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?
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.
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.
>
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, 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 c
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 y
* 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 th
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 coul
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
> 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
o
"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
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
"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
"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
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
voc
The assert should not overflow. I suggest
#include
#include
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 been very succes
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
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 implem
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
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
> 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.
2007/4/6, Karl Chen <[EMAIL PROTECTED]>:
Hi all, apologies if this has been discussed before, but I
couldn't find anything about this issue in gcc mailing list
archives.
Use of operator new (et al) appears to have an integer overflow;
this function:
int * allocate_int(size_t n)
{
81 matches
Mail list logo
