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 would not be a
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
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
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 with:
[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);
It may not
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;
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 in
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 in
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
and VRP
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
a is a
[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 for CSE.
It's
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 the a
is not
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
#return
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
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 :=
| #if abs(b) ==
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
# return 0
#
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
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.
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 convenient to
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.
|
| Hmm, that
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
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.
|
| well,
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's what we
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
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 assumptions not
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 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
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
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;
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
| | |
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
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 these can quite
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
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 gcc-land always to
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; it
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 suspect
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'
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 has to
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
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
... 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.
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.
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 difference
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, 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 compiler
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
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
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
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 ...
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
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.
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 silently
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 signed -
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 know, but
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 ...
As far as
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 my
|
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
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
| |
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 defined to generate
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 =
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 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,
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
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 least since
|
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 information
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 very
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 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
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
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
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.
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
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 |= 1 */
--- Comment #6 from veksler at il dot ibm dot com 2007-01-17 08:49 ---
(In reply to comment #0)
The program below shows (at all the optimization levels) a miscompilation of
the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of
the i386 family.
For the record
--- Comment #10 from bugzilla at bennee dot com 2007-01-17 10:35 ---
(In reply to comment #9)
(In reply to comment #4)
Testcase compiles OK with gcc version 4.3.0 20070115 (experimental).
Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented
in comment #3.
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-17 10:44 ---
Confirmed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from mueller at gcc dot gnu dot org 2007-01-17 10:51
---
no, its going in real soon now (finally) :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 11:09 ---
Subject: Re: [regression] -Wconversion triggers warnings for
deque::push_back()
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Gaby, any news about the signed - unsigned warning itself? Are we going to
| keep
--- Comment #9 from msvoboda at ra dot rockwell dot com 2007-01-17 11:12
---
Created an attachment (id=12913)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12913action=view)
preprocessed file
I crossed this error too. I'm attaching required preprocessed file.
This bug occured
--- Comment #6 from dcb314 at hotmail dot com 2007-01-17 12:14 ---
(In reply to comment #5)
I can confirm this problem on recent snapshots as well (20070105 and
20070112).
Agreed.
Snapshot 20010112 goes wrong and it's definately the flag
--with-cpu=opteron that causes the trouble.
I just tried to compile package FlightGear-0.9.10-40
with the GNU C++ compiler version 4.3 snapshot 20070112.
The compiler said
replay.cxx: In function 'FGReplayData interpolate(double, FGReplayData,
FGReplayData)':
replay.cxx:224: internal compiler error: Segmentation fault
Please submit a full
--- Comment #1 from dcb314 at hotmail dot com 2007-01-17 12:17 ---
Created an attachment (id=12914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12914action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30490
--- Comment #20 from tromey at gcc dot gnu dot org 2007-01-17 12:32 ---
The particularity of such expressions is that they are constants.
I've thought about this a bit but I don't have a real conclusion.
I don't know why this warning was added in the first place... it seems
like
--- Comment #11 from ubizjak at gmail dot com 2007-01-17 12:39 ---
(In reply to comment #10)
What glibc version do you have? And what platform are you building on?
GNU C Library development release version 2.3.6
2.6.17-1.2142_FC4smp on i686-pc-linux-gnu and x86_64-pc-linux-gnu.
Checked this with gcc-3.4.6 and gcc 4.1.2 on an ubuntu edgy box.
[EMAIL PROTECTED]:~/try/bug$ cat makefile
all:
gcc-3.4 -c main.c -o obj-c/main.o -MMD -MF obj-c/main.d
gcc-3.4 -E main.c -o obj-E/main.i -MMD -MF obj-E/main.d
diff obj-c/main.d obj-E/main.d
[EMAIL
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-17 13:47 ---
Subject: Re: unsigned warning in template
tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The particularity of such expressions is that they are constants.
|
| I've thought about this a bit but I don't
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-17 13:47 ---
Perhaps Wundefined should warn for PR 29465 ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-17 13:49 ---
Also, not sure whether Wundefined or Wsequence-points should handle PR 24016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-17 13:52 ---
Another candidate is PR 30457.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #9 from felix-gcc at fefe dot de 2007-01-17 13:55 ---
Hey Andrew, do you really think this issue goes away if you keep closing the
bugs fast enough?
Let me tell you something: that INT_MAX way to do it is bogus. These checks
are there so that it is obvious the int overflow
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 13:56 ---
Unfortunately I still haven't been able to reproduce this.
I do have a few questions:
I'd like to see more of the build log, in particular what happened
before the failing command.
Does the failing gcj invocation
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-17 14:00 ---
Not so sure about this one PR 12411
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-17 14:04 ---
Not sure about this one either, there seems to be a warning in C++ but I am not
sure what option controls it now: PR 30368.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-17 14:06 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Perhaps Wundefined should warn for PR 29465 ?
Where feasable with minimum overhead, yes.
-- Gaby
--
--- Comment #8 from gdr at cs dot tamu dot edu 2007-01-17 14:08 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Also, not sure whether Wundefined or Wsequence-points should handle PR 24016.
unspecified beahviour is not the same as
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-17 14:09 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Another candidate is PR 30457.
agreed.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-17 14:11 ---
Expected: As elemental procedures are also allowed, a case
EXEC_ASSIGN_CALL:
has to be added.
This is the easy bit... You then get:
$ /irun/bin/gfortran pr30407.f90
pr30407.f90: In function 'MAIN__':
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-17 14:26
---
You need to improve your communication skills - pissing people off doesn't help
your agenda. Btw, pointer overflow is undefined and we use that fact.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 14:26 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Not so sure about this one PR 12411
order of evaluation is unspecified, should go under the
sequence-points umbrella.
--- Comment #11 from gdr at cs dot tamu dot edu 2007-01-17 14:29 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Not sure about this one either, there seems to be a warning in C++
| but I am not sure what option controls it now: PR
1 - 100 of 186 matches
Mail list logo
