On Apr 8, 2007, at 11:35 PM, Dave Korn wrote:
I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/
gcc/trunk". Is this a known problem?
It's the first I've heard of it, please file a PR. I'm slightly
amazed this
hasn't been causing bootstrap breakage already, it looks real
On 09 April 2007 02:51, Bill Wendling wrote:
> (on my iMac). The problem seems to be that, in the TConvertType
> function passes
> "type->precision" as an HI instead of SI to the "bork" function. The
> asm code is:
>
> movl $1104150528, (%esp)
> movl$0, -4(%ebp)
> m
> > 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
On Apr 8, 2007, at 6:50 PM, Bill Wendling wrote:
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm("movl $
"Mike Stump" <[EMAIL PROTECTED]>
??:[EMAIL PROTECTED]
> On Apr 8, 2007, at 2:37 AM, Uros Bizjak wrote:
>> My docs say that "INC/DEC does not change the carry flag".
>
> Personally, I'm having a hard time envisioning how the semantics of the
> instruction are relevant at all. This is all abo
Hi all,
This program:
#include
struct tree_type {
unsigned int precision : 9;
};
void *bork(const void *Ty, unsigned Subpart) {
printf("Subpart == %08x\n", Subpart);
return 0;
}
const void *TConvertType(tree_type* type) {
asm("movl $1104150528, (%%esp)" : : );
const void *Ty = 0;
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
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),
?
In the original patch in:
2006-11-18 Vladimir Makarov <[EMAIL PROTECTED]>
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
Mike Stump wrote:
But you have better resources that I, so if you think that C2D should
be left out of X86_TUNE_USE_INCDEC, then the patch is pre-approved
for mainline.
I'm confused again, it isn't that it should be left out, it is that it
should be included. My patch adds inc/dec selection
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
Mike Stump wrote:
On Apr 8, 2007, at 2:37 AM, Uros Bizjak wrote:
My docs say that "INC/DEC does not change the carry flag".
Personally, I'm having a hard time envisioning how the semantics of
the instruction are relevant at all. This is all about instructing
tuning, so, semantics cannot m
On Apr 8, 2007, at 2:37 AM, Uros Bizjak wrote:
My docs say that "INC/DEC does not change the carry flag".
Personally, I'm having a hard time envisioning how the semantics of
the instruction are relevant at all. This is all about instructing
tuning, so, semantics cannot matter, otherwise, i
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 Sun, Apr 08, 2007 at 11:37:43AM +0200, Uros Bizjak wrote:
> H. J. Lu wrote:
>
> >>>inc/dec has the same performance as add/sub on Core 2 Duo. But
> >>>inc/dec is shorter.
> >>>
> >>>
> >>What about partial flag register dependency of inc/dec?
> >>
> >
> >There is no partial flag regi
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
>>
>>
Uros Bizjak wrote:
My docs say that "INC/DEC does not change the carry flag". But you have
better resources that I, so if you think that C2D should be left out of
X86_TUNE_USE_INCDEC, then the patch is pre-approved for mainline.
Absolutely INC/DEC do not change the carry flag, this is an impo
H. J. Lu wrote:
inc/dec has the same performance as add/sub on Core 2 Duo. But
inc/dec is shorter.
What about partial flag register dependency of inc/dec?
There is no partial flag register dependency on inc/dec.
My docs say that "INC/DEC does not change the carry flag". But
* 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) {
>
Hi Guys,
Sorry to bother you with that old issue...
But..
Is there a chance someone has a secret stash with a working
version of the VCG graph viewer ? please ?
thank you ppl
sunzir
Re: Looking for Cygnus' modified VCG graph viewer
To: drepper at cygnus dot com (Ulrich Drepper)
Subject: Re
Hello Diego.
On 3/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Sunzir Deepur wrote on 03/14/07 05:36:
> any idea where I can find a (free) graphical VCG viewer suitable
> for gcc's vcg outputs ?
I'd recommend the attached script. Feed the output to GraphViz. The
script may need changes if
Hello Joe.
On 3/14/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Wed, Mar 14, 2007 at 11:36:24AM +0200, Sunzir Deepur wrote:
> any idea where I can find a (free) graphical VCG viewer suitable
> for gcc's vcg outputs ?
See http://www.graphviz.org/
Checked on graphviz, I don't think it supports V
34 matches
Mail list logo
