unsigned foo( unsigned i )
{
if ( i 0 )
i++;
if ( i = 0 )
i++;
return i;
}
g++ 412svn/420svn with `-O2 -Wall' reports no errors.
--
Summary: missed warnings about comparisons which are always
true/false.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-03 10:39 ---
Adding -W/-Wextra and we get a warning:
t.c: In function foo:
t.c:3: warning: comparison of unsigned expression 0 is always false
t.c:5: warning: comparison of unsigned expression = 0 is always true
I always
--- Comment #2 from pluto at agmk dot net 2006-11-03 10:44 ---
(In reply to comment #1)
Adding -W/-Wextra and we get a warning:
t.c: In function #65533;foo#65533;:
t.c:3: warning: comparison of unsigned expression 0 is always false
t.c:5: warning: comparison of unsigned expression
--- Comment #19 from bkoz at gcc dot gnu dot org 2006-11-03 10:46 ---
Is this actually fixed?
Here are my current testresults:
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00094.html
Still shows breakage on FC6. Sorry, hardware constrained at the moment and
don't have other
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-11-03 11:22 ---
Subject: Bug 29627
Author: tkoenig
Date: Fri Nov 3 11:22:27 2006
New Revision: 118453
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118453
Log:
2006-11-03 Thomas Koenig [EMAIL PROTECTED]
PR
extern void abort (void);
int
f1 (void)
{
int a = 128;
return (a 0x80) ? 0x80 : 0;
}
int
f2 (void)
{
unsigned char a = 128;
return (a 0x80) ? 0x80 : 0;
}
int
main (void)
{
if (f1 () != 128)
abort ();
if (f2 () != 128)
abort ();
return 0;
}
f2 () is miscompiled with -O2
--- Comment #1 from jakub at gcc dot gnu dot org 2006-11-03 11:24 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pcarlini at suse dot de 2006-11-03 11:28 ---
I can confirm that this specific regression disappeared for me. But I suspect
something also depends on the binutils version and other details, I'm using a
stock 2.17 on this machine...
--
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-03 11:30 ---
Fixed on 4.2 too; will need to regtest for backporting
to 4.1.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-11-03 11:51
---
Subject: Bug 27895
Author: fxcoudert
Date: Fri Nov 3 11:51:09 2006
New Revision: 118455
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118455
Log:
PR libfortran/27895
*
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-11-03 11:58
---
Is this actually fixed?
It is on my system, either x86_64-suse-linux -m64/-m32 or i586-suse-linux,
with binutils 2.17.
Here are my current testresults:
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-11-03 12:24
---
The patch in comments 10 and 12 will need to be backported to 4.2 and 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-11-03 12:29
---
Subject: Bug 29067
Author: fxcoudert
Date: Fri Nov 3 12:28:57 2006
New Revision: 118456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118456
Log:
PR fortran/29067
* decl.c
--- Comment #16 from rsandifo at gcc dot gnu dot org 2006-11-03 13:23
---
I'm testing a possible patch. I didn't want to reassign the bug
to myself in case H-P is still looking at it too.
At this stage I have no idea how successful the patch will be.
It seems to me that, as with most
--- Comment #17 from hp at gcc dot gnu dot org 2006-11-03 13:27 ---
(Re: comment #16)
Thank you, be my guest! :-)
Actually, it's a mistake that I'm still assigned; I should've unassigned myself
after a week with no activity from my side.
--
hp at gcc dot gnu dot org changed:
--- Comment #18 from rsandifo at gcc dot gnu dot org 2006-11-03 13:30
---
OK, I step up to the guillotine...
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mkl at pengutronix dot de 2006-11-03 13:49 ---
Created an attachment (id=12542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12542action=view)
fix target linker emulation for arm elf and eabi (take 2)
If you try to build a big-endian eabi toolchain, you need
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-11-03 14:11
---
Adding %REF and %DESCR to the summary. Documentation available here:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Functions-and-Subroutines.html
--
fxcoudert at gcc dot gnu dot org changed:
What
std::copy with reverse_iterator in this example doesn't work correctly on alpha
under Tru64 UNIX 5.1b
#include iostream
#include algorithm
#include iterator
#include string
class trans
{
public:
int operator()(char c) { std::clog c std::endl; return c - '0'; };
};
int main()
{
std::string
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-11-03 14:14
---
Commited to mainline as revision 118450. Maybe we want to include this into 4.2
before 4.2.0 is released? I think that would be the best thing to do; opinions?
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2006-11-03 14:26
---
Subject: Bug 29067
Author: fxcoudert
Date: Fri Nov 3 14:25:56 2006
New Revision: 118457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118457
Log:
PR fortran/29067
* decl.c
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2006-11-03 14:28
---
Fixed on all active branches.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tbm at cyrius dot com 2006-11-03 14:29 ---
(In reply to comment #2)
I posted the patch for this bug at:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00023.html
So I guess we're waiting for Ian (or someone) to approve the new patch in
--- Comment #1 from chris at bubblescope dot net 2006-11-03 15:00 ---
What exactly is the problem? It doesn't compile? It doesn't produce the right
output? It crashes?
--
chris at bubblescope dot net changed:
What|Removed |Added
hi
this is the error iam getting when i try to cross compile ltib BSP of linux
2.6.10 for arm11 platfrom from SUSE10 host
arm-none-linux-gnueabi-ranlib ./libgcov.a
arm-none-linux-gnueabi-gcc -O2 -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes
--- Comment #2 from pcarlini at suse dot de 2006-11-03 15:08 ---
Indeed, we badly need details. The correct output (which indeed I can see on
any machine I have at hand, any version of gcc) is:
0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0
--
pcarlini at suse dot
--- Comment #3 from lebedev at zhtw dot org dot ru 2006-11-03 15:29 ---
(In reply to comment #2)
Indeed, we badly need details. The correct output (which indeed I can see on
any machine I have at hand, any version of gcc) is:
0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
3 2 1 3 2 1 1 2 3 4 5 6
--- Comment #4 from pcarlini at suse dot de 2006-11-03 15:36 ---
Oh well, something seems seriously broken, certainly not in the
target-independent parts of the library proper, however. Did this ever work
with previous GCCs? Also, I would ask you to test a current compiler (4.1.1,
for
--- Comment #5 from pcarlini at suse dot de 2006-11-03 15:39 ---
(In reply to comment #4)
All in all, I'm afraid we are going to need the help of a target maintainer.
...to be sure, would you please post the output of 'gcc -v'? Thanks.
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-11-03 16:12
---
I agree and already tested for Brooks on 4.2 last night.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-11-03 16:30
---
This is probably a duplicate of 24978.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
I came accross this when implementing the volatile statement/attribute
(PR29601), where I used:
+ if (sym-attr.volatile_)
+ TREE_THIS_VOLATILE (decl) = 1;
Ian Lance Taylor noted that:
I think you will also want to give DECL a type which is
volatile-qualified:
build_qualified_type
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-03 17:03 ---
A good introduction into restricted can be found at
http://developers.sun.com/sunstudio/articles/cc_restrict.html
Maybe this is something for the array implementation in gfortran?
I don't fully understand how the
--- Comment #6 from lebedev at zhtw dot org dot ru 2006-11-03 17:19 ---
(In reply to comment #5)
(In reply to comment #4)
All in all, I'm afraid we are going to need the help of a target maintainer.
...to be sure, would you please post the output of 'gcc -v'? Thanks.
$ gcc -v
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-03 17:26 ---
Andy pointed out that TYPE_QUAL_VOLATILE only changes the dumped string,
nonetheless it makes checking things easier, I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697
--- Comment #7 from pcarlini at suse dot de 2006-11-03 17:44 ---
Ok, thanks. Ideally, in case the problem unfortunately persists with current
GCC, it would be also useful if you could provide outputs from a debugging
session, because right now what happens after the output of the
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-03 18:03 ---
For arguments, you missed that flag_argument_noalias is set to 2 (or is it 3
now).
It also changes debugging info which is needed in this case to get the correct
debuging info.
--
pinskia at gcc dot gnu dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
My OS is Fedora Core 6 - I'm using the compiler, that ships with it.
It crashes on this code:
===
#include iostream
#include algorithm
template typename INT
int foo(INT m)
{
return sizeof(std::pairint, int);
}
int main(void)
{
std::cout
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-03 18:29 ---
templateclass _T1, class _T2
struct pair{};
template typename INT
int foo(INT m)
{
return sizeof(pairint, int);
}
This was never broken in 4.1.1, this was only broken on the 4.1 branch and only
for two
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-03 18:29
---
*** Bug 29698 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pluto at agmk dot net 2006-11-03 18:56 ---
(In reply to comment #2)
Indeed, we badly need details. The correct output (which indeed I can see on
any machine I have at hand, any version of gcc) is:
0 9 8 7 6 5 4 3 2 1 1 2 3 1 2 3
3 2 1 3 2 1 1 2 3 4 5 6 7 8 9 0
The following program gives an ICE with todays 4.2-branch gfortran.
(I have to find out why gcc-trunk doesn't compile at the moment, then I will
check also gcc-trunk.)
I found the error with: ftp://ftp.nag.co.uk/sc22wg5/ISO_VARYING_STRING/
PROGRAM vocabulary_word_count
Changed nothing in sources, build just from unpacked
`gcc-4.1.1.tar.bz2'. Still tests try to run `autogen'.
make: Entering directory `gcc-4.1.1-rhysling'
make[1]: Entering directory `gcc-4.1.1-rhysling'
make[2]: Entering directory `gcc-4.1.1-rhysling/fastjar'
make[2]: Leaving directory
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-11-03 19:32
---
That this package is required to run tests is not even said in
INSTALL/test.html. Neither http://gcc.gnu.org/install/test.html
says so. If it indeed has to be required, this is documentation bug.
It is not,
--- Comment #2 from gin at mo dot msk dot ru 2006-11-03 19:43 ---
Subject: Re: check requires autogen
Certainly ran `make check' in top level build directory, and indicated
that by including parts of `make -w' output, printout of directories
entered and left by `make'.
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-11-03 19:52
---
Certainly ran `make check' in top level build directory,
Your mistake. Only 'make -k check' is supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
--- Comment #4 from burnus at gcc dot gnu dot org 2006-11-03 19:59 ---
I think we should issue a warning but not an error, because you can write code
that is [...]
Note that you should use contains for the code otherwise foo is regarded as
real function and the program does not
Attached preprocessed code compiles with gcc 3.4.4 and gcc 4.0.3, fails with
4.1.1. Compiler is not preferring a function template over a vararg function.
--
Summary: mpl/aux_/preprocessed/gcc/template_arity.hpp, bogus
overload ambiguity
Product: gcc
--- Comment #1 from eric dot niebler at gmail dot com 2006-11-03 20:01
---
Created an attachment (id=12543)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12543action=view)
preprocessed input file
preprocessed C++ source code.
--
--- Comment #4 from gin at mo dot msk dot ru 2006-11-03 20:03 ---
Subject: Re: check requires autogen
Sorry for not indicating that. Always specified `-k' in all `make'
runs. They yield the results as described.
The gist is that currently the only way to obtain actual test script,
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-03 20:08 ---
I think this is a dup of bug 29518 but since I have not looked to double check
I am going to mark it as a dup just yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29701
In the discussion of PR 29689, the following came up, and seems like a
reasonable request:
Original Message (excerpted)
Subject: Re: Emacs and GFortran
Date: Sat, 4 Nov 2006 07:59:04 +1300
From: Nick Roberts [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-devel@gnu.org
This little program:
class C;
template void (C::*pmf)(int) = (void(C::*)(int))0
struct S { };
S s;
yields this little ICE:
440-gcc-crash.cc:6: internal compiler error: in uses_template_parms, at
cp/pt.c:5024
Please submit a full bug report,
with preprocessed source if appropriate.
See
This bug applies at least to gcc version 4.0.3 and the current CVS 4.2.0
20061103. The assembly extracts included below were produced by gcc 4.2.0; the
gcc 4.0.3 extracts are analogous with respect to this problem but are different
in some respects. My particular host is an intel pentium4 xenon
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-03 22:35 ---
This is a dup of bug 19116 which was fixed in 4.3.0.
*** This bug has been marked as a duplicate of 19116 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-03 22:35
---
*** Bug 29705 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from r_ovidius at eml dot cc 2006-11-03 22:58 ---
Updated summary. (Happy 2 year birthday, stupid stubborn bug.)
--
r_ovidius at eml dot cc changed:
What|Removed |Added
This code snippet
struct V {
V(int) { }
};
struct B : virtual V
{
B() { } // does not mention constructor of V
};
struct D : B
{
D() : V(0) { }
};
D d; // most derived object of type D
should be valid according to the C++ standard 12.6.2 paragraph 6 (note that B
is not a most
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-03 23:20 ---
I think is really a dup of bug 19249.
Though the problem here is slightly different as B() is fully defined and calls
the default constructor which is not defined.
Comeau C/C++ 4.3.8 (Aug 19 2006 13:36:48) for
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-03 23:20
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-11-03 23:36
---
Sorry for not indicating that. Always specified `-k' in all `make'
runs. They yield the results as described.
'make check' and 'make -k check' are certainly not equivalent. The former
will stop if you don't
home/dave/gnu/gcc-4.3/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.3/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/inclu
de -isystem
--- Comment #1 from danglin at gcc dot gnu dot org 2006-11-04 00:42 ---
ll s-osinte.adb
lrwxrwxrwx 1 dave dave 53 Nov 3 02:33 s-osinte.adb -
/home/dave/gnu/gcc-4.3/gcc/gcc/ada/s-osinte-posix.adb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29707
--- Comment #13 from dje at gcc dot gnu dot org 2006-11-04 04:07 ---
Fixed on mainline, 4.2.0, and 4.1.2. Won't fix on 4.0 branch.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-11-04 04:15 ---
This was something that slipped in, IIRC. I was of Ian's viewpoint, that
may_alias_p should handle it, and it shouldn't be special to data-references.
But it can't, at least in it's current state, because it somehow
66 matches
Mail list logo
