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 -
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
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
> 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 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 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
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
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-
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
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
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
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)
{
> 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.
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
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
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
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
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
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
"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
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:
[...]
| 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
o
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
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
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
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
29 matches
Mail list logo
