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 Sat, Apr 07, 2007 at 05:23:42AM +0200, J.C. Pizarro wrote:
> I've probed the profiling of p7zip-4.44 (c++, lzma,
> linux-2.6.20.5.tar as data).
>
> There is an absolute lack of profile timing information because of
> a lot of 0.00 and little bit of 0.01. There is not entry of >0.01 seconds.
Y
The name 'seconds' must be replaced by 'us' (microseconds) or 'ms'
(milliseconds).
So, then, they won't have many 0.00 us instead of 0.00 s.
An advice, extend it from 2 to 4 decimal digits for
better comparison between similar functions.
* 0. us instead of 0.00 us
* 0. ms instead of 0.0
I've probed the profiling of p7zip-4.44 (c++, lzma,
linux-2.6.20.5.tar as data).
There is an absolute lack of profile timing information because of
a lot of 0.00 and little bit of 0.01. There is not entry of >0.01 seconds.
Its output really confuses me and your.
The name 'seconds' must be repl
> 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
Brian Dessent wrote:
"Aaron W. LaFramboise" wrote:
I don't really see any compelling reason that win32 threads shouldn't
work on Cygwin. As far as I know, nothing about this choice is
ultimately exposed to the user. In fact, Win32 threads are quite likely
to yield superior performance anywher
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)
{
Snapshot gcc-4.3-20070406 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070406/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Apr 06, 2007 at 01:27:09PM -0700, Mike Stump wrote:
> I was wondering, if:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_CORE2 | m_GENERIC),
>
> is correct. Should it be:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_GENERIC),
>
> ?
inc/dec has the same p
I was wondering, if:
/* X86_TUNE_USE_INCDEC */
~(m_PENT4 | m_NOCONA | m_CORE2 | m_GENERIC),
is correct. Should it be:
/* X86_TUNE_USE_INCDEC */
~(m_PENT4 | m_NOCONA | m_GENERIC),
?
In the original patch in:
2006-11-18 Vladimir Makarov <[EMAIL PROTECTED]>
* doc/invoke.texi
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)
{
return new int[n];
}
with gcc-
Joe Buck wrote:
It might be worth doing. I think that, in addition to a patch,
I'd like to see measurements (maybe just the size increase in
libstdc++.{a,so}). If the cost is small, I will not object.
If the cost turns out non-small, this could be enabled at -g3?
Cheers,
Pedro Alves
On Fri, Apr 06, 2007 at 11:38:50AM +0100, Rob Quill wrote:
> So the general concensus is that's it's not worth doing?
> Hypothetically, if I did it and it didn't make much difference, would
> it be worth submitting a patch? Or should I just give up before I
> start?
It might be worth doing. I thi
On Fri, Apr 06, 2007 at 11:50:01AM +0100, Rob Quill wrote:
> >int i = 0;
> >int j = 2;
> >int n = CalculateSomething( j, &i );
> >int k = 3;
>
> I don't really understand, because the problem remains that if you
> break before int n... and do print n you get a value, whereas you
> should get an er
> On 05/04/07, Brian Ellis <[EMAIL PROTECTED]> wrote:
> >
> > Now if there were actual function calls in the initialization, and no
> > records were emitted, I would consider that to be a problem (haven't tested
> > this at the moment though), however, static initializers like that could
> > eas
On 05/04/07, Brian Ellis <[EMAIL PROTECTED]> wrote:
Now if there were actual function calls in the initialization, and no records
were emitted, I would consider that to be a problem (haven't tested this at the
moment though), however, static initializers like that could easily be skipped
as a
So the general concensus is that's it's not worth doing?
Hypothetically, if I did it and it didn't make much difference, would
it be worth submitting a patch? Or should I just give up before I
start?
Rob
On 06/04/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Thu, Apr 05, 2007 at 09:46:18A
I built gcc 4.1.2 again on Cygwin but this time with pthreads. No
problems at all during compilation.
Output of config.guess:
i686-pc-cygwin
Output of gcc -v:
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /home/jesper/gcc-4.1.2/configure
--enable-threads=posix --with-cpu=i686 -
29 matches
Mail list logo
