On 1/17/07, Mircea Namolaru <[EMAIL PROTECTED]> wrote:
> Thanks. Another question I have is that, in this case, will the
following
>
> http://gcc.gnu.org/wiki/Sign_Extension_Removal
>
> help in removal of the sign / zero extension ?
First, it seems to me that in your case:
(1) a = a | 1 /* a |=
Also this is removed for the case of integers by the CSE pass
IIRC . The problem arises only for the type being a char or a short.
Yes, That is true. With gcc 4.1 one of the 'or's gets eliminated for
'int'. I am putting below two sets of logs. The first just before
cse_main and the second just a
Joe Buck wrote:
(off topic!)
On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
H .. I wish some of the more important bugs in gcc received
the attention that this very unimportant issue is receiving :-)
I guess the difference is that lots of people can understand
this issue.
On Jan 17, 2007, at 6:46 PM, Gabriel Dos Reis wrote:
(1) the ABI I was talking about is that of libstdc++
(2) numeric_limits<> cannot change from translation unit to
translation
unit, within the same program otherwise you break the ODR. I
guess
we all agree on that.
Doh! Did I
On Wed, 17 Jan 2007, Mike Stump wrote:
| On Jan 17, 2007, at 4:44 PM, Gabriel Dos Reis wrote:
| > C++ forces compilers to reveal their semantics for built-in types
| > through numeric_limits<>. Every time you change the behaviour,
| > you also implicilty break an ABI.
|
| No, the ABI does not doc
On Jan 17, 2007, at 4:44 PM, Gabriel Dos Reis wrote:
C++ forces compilers to reveal their semantics for built-in types
through numeric_limits<>. Every time you change the behaviour,
you also implicilty break an ABI.
No, the ABI does not document that the answer never changes between
translat
On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
> H .. I wish some of the more important bugs in gcc received
> the attention that this very unimportant issue is receiving :-)
>
> I guess the difference is that lots of people can understand
> this issue.
Yes, this phenomenon has
On Wed, 17 Jan 2007, Andrew Pinski wrote:
| >
| > One use of -Wconversion is to draw attention to
| >
| >int x = 2.3; // warning: be careful, is this what you want?
| > // this is a potential bug as it is value altering.
| >
| > and in an upcoming revision to C++, it is ver
>
> One use of -Wconversion is to draw attention to
>
>int x = 2.3; // warning: be careful, is this what you want?
> // this is a potential bug as it is value altering.
>
> and in an upcoming revision to C++, it is very likely that implicit
> conversion that may lose info
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes.
| >
|
| Then, why Wconversion has warned about it at leas
I noticed today that gcc 4.2 branch seems to create a bogus symlink
on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that
points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad
binary...
file libgcc_s.1.dylib
libgcc_s.1.dylib: Mach-O fat file with 2 architectures
libgcc
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| Does that apply also to:
|
| unsigned int y = -10;
Yes.
Then, why Wconversion has warned about it at least since
http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11 ?
Moreover, mo
On Thu, 18 Jan 2007, Joseph S. Myers wrote:
[...]
| > Furthermore, elsewhere (in the overflow thread) it has been suggested
| > that people should convert to the unsigned variants, do computations there,
| > and convert back to the signed variants. We have just promised an
| > invariant that we
On Wed, 17 Jan 2007, Gabriel Dos Reis wrote:
> The specific cases I'm concerned about here (and if you have a chance
> to build firefox for example, you'll see) is when T and U differ only
> in signedness, that is
>
>T = int, U = unsigned
>T = long, U = unsigned long
>T = long long, U
Gabriel Paubert <[EMAIL PROTECTED]> writes:
| On Wed, Jan 17, 2007 at 04:15:08PM -0800, Ian Lance Taylor wrote:
| > Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| > > Ian Lance Taylor wrote:
| > >
| > > > We do want to generate a trap for x / 0, of course.
| > >
| > > Really? Is this really def
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > | > ... thanks a lot Gaby both for your practical and theoretical
| > |
Ian Lance Taylor wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
As far as I know, but I think it would be a surprising cha
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > ... thanks a lot Gaby both for your practical and theoretical
| > investigations into this issue, both right to the point! Now, in
On Wed, Jan 17, 2007 at 04:15:08PM -0800, Ian Lance Taylor wrote:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor wrote:
> >
> > > We do want to generate a trap for x / 0, of course.
> >
> > Really? Is this really defined to generate a trap in C?
> > I would be surprised if so
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Robert Dewar <[EMAIL PROTECTED]> writes:
|
| > Ian Lance Taylor wrote:
| >
| > > We do want to generate a trap for x / 0, of course.
| >
| > Really? Is this really defined to generate a trap in C?
| > I would be surprised if so ...
|
| As far as I
On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > ... thanks a lot Gaby both for your practical and theoretical
| > investigations into this issue, both right to the point! Now, in my
| > opinion, we should simply remove the bits about sign
Robert Dewar <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> > We do want to generate a trap for x / 0, of course.
>
> Really? Is this really defined to generate a trap in C?
> I would be surprised if so ...
As far as I know, but I think it would be a surprising change for x /
0 to si
On 17/01/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
I agree this warning is of questionable use and should be not enabled
with -Wall.
But... -Wconversion is not enabled by -Wall! It is not even enabled by
Wextra! It is only enabled by -Wconversion.
Getting confused,
Manuel.
On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
... thanks a lot Gaby both for your practical and theoretical
investigations into this issue, both right to the point! Now, in my
opinion, we should simply remove the bits about signed -> unsigned from
-Wconversion.
I am not sure I am follo
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
Joe Buck wrote:
If GCC winds up having to fix the bug in the compiler itself for PPC,
then everyone could have the option of using a kernel fix or a compiler
fix. But how are you going to do the kernel fix? What if the user did
an integer divide and not a modulo? I suppose you could just say
H .. I wish some of the more important bugs in gcc received
the attention that this very unimportant issue is receiving :-)
I guess the difference is that lots of people can understand
this issue.
Reminds me of the hullabaloo over the Pentium division problem.
The fact of the matter was that
Is there any reason why libgomp and libdecnumber don't have a
svn:ignore property containing autom4te.cache? I noticed the
following always showing up in my "svn status" after a maintainer-
mode build:
? libdecnumber/autom4te.cache
? libgomp/autom4te.cache
Thanks,
FX
I wrote:
> | Careful. As you suggest, let's restrict ourselves to two's complement
> | platforms. I would want the compiler to warn if the identity holds for an
> | ILP32 machine but not an LP64 machine, even if I'm running on an ILP32.
> | But if the two types are going to be the same size ever
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
| > I just built firefox (CVS) with GCC mainline. The compiler spitted
| > avalanches of non-sensical warning about conversions signed ->
| > unsigned may alter values, when in fact the compil
Joe Buck wrote:
Careful. As you suggest, let's restrict ourselves to two's complement
platforms. I would want the compiler to warn if the identity holds for an
ILP32 machine but not an LP64 machine, even if I'm running on an ILP32.
But if the two types are going to be the same size everywhere
On Wed, 17 Jan 2007, Richard Guenther wrote:
| On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Paolo Carlini <[EMAIL PROTECTED]> writes:
| >
| > | Joe Buck wrote:
| > |
| > | >In the case of the containers, we are asserting/relying on the fact that
| > | >the pointer
On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
> I just built firefox (CVS) with GCC mainline. The compiler spitted
> avalanches of non-sensical warning about conversions signed ->
> unsigned may alter values, when in fact the compiler knows that
> such things cannot happen.
>
... thanks a lot Gaby both for your practical and theoretical
investigations into this issue, both right to the point! Now, in my
opinion, we should simply remove the bits about signed -> unsigned from
-Wconversion.
Paolo.
Snapshot gcc-4.2-20070117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread idiom: people write their own code in the STL style. If STL
| >code now ha
My suggestion is that
(EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM
would avoid the warning. But we would not put the casts in the macro
FIXNUM_OVERFLOW_P itself, since that would negate the purpose of the
macro. Instead we would put the cast in the argument, when the
argument is an `int' anyway
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 07:42:38PM +, Andrew Haley wrote:
| > Gabriel Dos Reis writes:
| > > You believe there is one solution, except that it does not work for
| > > the supported target.
| >
| > Sorry, I don't understand what you mean by that.
|
| I s
On Wed, Jan 17, 2007 at 07:42:38PM +, Andrew Haley wrote:
> Gabriel Dos Reis writes:
> > You believe there is one solution, except that it does not work for
> > the supported target.
>
> Sorry, I don't understand what you mean by that.
I suspect that he meant to write "one supported target"
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> | Gabriel Dos Reis writes:
> | > On Wed, 17 Jan 2007, Andrew Haley wrote:
> | >
> | > [...]
> | >
> | > | > | "To a man with a hammer, all things look like a nail." It's very
> | > | > | tempting for us in gc
Dave Korn wrote:
On 17 January 2007 19:09, Joe Buck wrote:
How will the kernel know whether the overflow in the divide instruction
is because the user's source code has a '%' and not a '/'? We generate
the exact same instruction for i / minus_one(), after all, and in that
case the trap reall
On Wed, Jan 17, 2007 at 11:17:36AM -0800, Ian Lance Taylor wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
> > > From a performance/convenience angle, the best place to handle this is
> > > either libc or the kernel. Either of thes
Ian Lance Taylor wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
How will the kernel know whether the overflow in the divide instruction
is because the user's source code has a '%' and not a '/'? We generate
the exact same instruction for i / minus_one(), after all, and in that
case the trap re
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| > On Wed, 17 Jan 2007, Andrew Haley wrote:
| >
| > [...]
| >
| > | > | "To a man with a hammer, all things look like a nail." It's very
| > | > | tempting for us in gcc-land always to fix things in gcc, not because
| >
Inder wrote:
Hi All
I have similar question as for arm
http://gcc.gnu.org/ml/gcc/2007-01/msg00691.html
consider the following program.
e.g..
- align.c -
int main()
{
int bc;
char a[6];
int ac;
bc = 0x;
/* fill with zeros. */
a[0] = 0x00;
a[1] = 0x01;
a[2
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
> > From a performance/convenience angle, the best place to handle this is
> > either libc or the kernel. Either of these can quite easily fix up
> > the operands when a trap happens, with zero pe
On Wed, Jan 17, 2007 at 07:03:43PM +, Andrew Haley wrote:
> It's an engineering problem. We have a widget that does the wrong
> thing*. We have several ways to make it do the right thing, only one
> of which has no adverse impact on the existing users of the widget.
> * (in some people's opi
On 17 January 2007 19:09, Joe Buck wrote:
> On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
>> From a performance/convenience angle, the best place to handle this is
>> either libc or the kernel. Either of these can quite easily fix up
>> the operands when a trap happens, with zero
On Wed, Jan 17, 2007 at 06:03:08PM +, Andrew Haley wrote:
> Gabriel Dos Reis writes:
> > On Wed, 17 Jan 2007, Andrew Haley wrote:
> >
> > |
> > | From a performance/convenience angle, the best place to handle this is
> > | either libc or the kernel.
> >
> > Hmm, that is predicated on a
On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
> From a performance/convenience angle, the best place to handle this is
> either libc or the kernel. Either of these can quite easily fix up
> the operands when a trap happens, with zero performance degradation of
> existing code. I d
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> [...]
>
> | > | "To a man with a hammer, all things look like a nail." It's very
> | > | tempting for us in gcc-land always to fix things in gcc, not because
> | > | it's technically the right place but because it'
On Wed, 17 Jan 2007, Andrew Haley wrote:
[...]
| > | "To a man with a hammer, all things look like a nail." It's very
| > | tempting for us in gcc-land always to fix things in gcc, not because
| > | it's technically the right place but because it's what we control
| > | ourselves.
| >
| >
Andrew Haley wrote:
>From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero performance degradation of
existing code. I don't think there's any need for gcc to be alter
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> | Gabriel Dos Reis writes:
> | > On Wed, 17 Jan 2007, Andrew Haley wrote:
> | >
> | > |
> | > | From a performance/convenience angle, the best place to handle this is
> | > | either libc or the kernel.
> | >
>
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| > On Wed, 17 Jan 2007, Andrew Haley wrote:
| >
| > |
| > | From a performance/convenience angle, the best place to handle this is
| > | either libc or the kernel.
| >
| > Hmm, that is predicated on assumptions not conveni
David Daney writes:
>
> That only works if the operation causes a trap.
Which it does in almost all cases. Let PPC do something different, if
that's what really PPC needs.
Andrew.
Gabriel Dos Reis writes:
> On Wed, 17 Jan 2007, Andrew Haley wrote:
>
> |
> | From a performance/convenience angle, the best place to handle this is
> | either libc or the kernel.
>
> Hmm, that is predicated on assumptions not convenient to users
> on targets that are not glibc-based or G
Andrew Haley wrote:
Ian Lance Taylor writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> > Ian, do you believe something along the line of
> >
> > # > I mean, could not we generate the following for "%":
> > # >
> > # > rem a b :=
> > # > if abs(b) == 1
> > # >
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Ian Lance Taylor writes:
| > Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| >
| > > Ian, do you believe something along the line of
| > >
| > > # > I mean, could not we generate the following for "%":
| > > # >
| > > # > rem a b :=
| > > #
On Jan 17, 2007, at 5:23 AM, Inder wrote:
void make(char* a) { *(unsigned long*)a = 0x12345678; }
stating address of the char array now starts from an unaligned
address and is acessed by the instruction
strbr3, [fp, #-26]
which gives a very wrong result
Is the compiler doing a righ
Ian Lance Taylor writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> > Ian, do you believe something along the line of
> >
> > # > I mean, could not we generate the following for "%":
> > # >
> > # > rem a b :=
> > # > if abs(b) == 1
> > # > return 0
> >
On 1/17/07, Mircea Namolaru <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Richard Kenner) wrote on 17/01/2007 18:04:20:
> > First, it seems to me that in your case:
> >
> > (1) a = a | 1 /* a |= 1 */
> > (2) a = a | 1 /* a |= 1 */
> >
> > the expressions "a | 1" in (1) and (2) are different as t
[EMAIL PROTECTED] (Richard Kenner) wrote on 17/01/2007 18:04:20:
> > First, it seems to me that in your case:
> >
> > (1) a = a | 1 /* a |= 1 */
> > (2) a = a | 1 /* a |= 1 */
> >
> > the expressions "a | 1" in (1) and (2) are different as the "a"
> > is not the same. So there is nothing to do f
> First, it seems to me that in your case:
>
> (1) a = a | 1 /* a |= 1 */
> (2) a = a | 1 /* a |= 1 */
>
> the expressions "a | 1" in (1) and (2) are different as the "a"
> is not the same. So there is nothing to do for CSE.
It's not a CSE issue, but after (1), you know that the low-order bit of
On Wed, Jan 17, 2007 at 12:43:40AM +0100, Vincent Lefevre wrote:
> On 2007-01-16 21:27:42 +, Andrew Haley wrote:
> > Ian Lance Taylor writes:
> > > I suspect that the best fix, in the sense of generating the best
> > > code, would be to do this at the tree level. That will give loop
> > > a
> Thanks. Another question I have is that, in this case, will the
following
>
> http://gcc.gnu.org/wiki/Sign_Extension_Removal
>
> help in removal of the sign / zero extension ?
First, it seems to me that in your case:
(1) a = a | 1 /* a |= 1 */
(2) a = a | 1 /* a |= 1 */
the expressions "a | 1
> Thanks. Another question I have is that, in this case, will the
following
>
> http://gcc.gnu.org/wiki/Sign_Extension_Removal
>
> help in removal of the sign / zero extension ?
First, it seems to me that in your case:
(1) a = a | 1 /* a |= 1 */
(2) a = a | 1 /* a |= 1 */
the expressions "a | 1
Hi All
I have similar question as for arm
http://gcc.gnu.org/ml/gcc/2007-01/msg00691.html
consider the following program.
e.g..
- align.c -
int main()
{
int bc;
char a[6];
int ac;
bc = 0x;
/* fill with zeros. */
a[0] = 0x00;
a[1] = 0x01;
a[2] = 0x02;
a[
[EMAIL PROTECTED] wrote on 16/01/2007 17:45:59:
> I succeeded to do it as follows:
>
> tree type_decl = lookup_name(get_identifier("MyType"));
> tree type_ptr = build_pointer_type(TREE_TYPE(type_decl));
> tree var_decl = build(VAR_DECL, get_identifier("t"), type_ptr);
> pushdecl(var_decl);
>
> I
On Wed, Jan 17, 2007 at 11:15:55AM +0200, Balint Cristian wrote:
> Is it a bug ?
>
> Maybe i still dont understand how this is emmited, but anyone knows why a
> cross-compiler vs normal compiler using the -fstack-protector option why
> will act differnetly ?
>
> e.g nm on same object compiled w
Hi,
I could successfully bootstrap the dataflow branch on s390 and s390x.
Configure options:
--enable-shared --with-system-zlib --enable-threads=posix
--enable-__cxa_atexit --enable-checking
--enable-languages=c,c++,fortran,java,objc
No testsuite regressions occurred comparing dataflow branch
Is it a bug ?
Maybe i still dont understand how this is emmited, but anyone knows why a
cross-compiler vs normal compiler using the -fstack-protector option why
will act differnetly ?
e.g nm on same object compiled with:
cross:
U __stack_chk_fail
U __stack_chk_guard
native
Thorsten Glaser <[EMAIL PROTECTED]> writes:
> Paul Eggert dixit:
>
>> […] gcc -O2 makes no promises without
>> -fwrapv.
>
> gcc -O1 -fwrapv even doesn't work correctly for gcc3,
> and gcc2 and gcc <3.3(?) don't even have -fwrapv:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
The latter wo
74 matches
Mail list logo
