[Bug target/33267] [4.3 Regression] libgomp testsuite timeouts
--- Comment #3 from debian-gcc at lists dot debian dot org 2007-09-02 08:24 --- sorry for the noise, seems to be something else, closing the report. Matthias WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O0 execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O1 execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O2 execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -O3 -g execution test WARNING: program timed out. FAIL: libgomp.fortran/do2.f90 -Os execution test -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33267
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #1 from tbm at cyrius dot com 2007-09-02 08:40 --- I can reproduce this with gcc-4.1 -c -mabi=64 -msym32 -mno-abicalls -O using Debian's gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #2 from tbm at gcc dot gnu dot org 2007-09-02 09:08 --- I can confirm this with FSF gcc 4.1.3 20070902 -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 09:08:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #3 from tbm at gcc dot gnu dot org 2007-09-02 09:26 --- This happens with 4.0 - 4.3. gcc 3.4 didn't have the -msym32 option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug target/33256] internal compiler error: in print_operand_reloc, at config/mips/mips.c:5579
--- Comment #4 from tbm at gcc dot gnu dot org 2007-09-02 09:27 --- Created an attachment (id=14149) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14149action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33256
[Bug libgcj/33278] New: [4.3 Regression] libjava fails to compile if configure argument contains version
When gcc is configured with, for example, --without-pkgversion, this part of
libjava configure script parses gcj -v output incorrectly, thus encoding
garbage as preprocessor macro and failing:
gcjversion=`$GCJ -v 21 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
An obvious fix would be:
Index: gcc43/libjava/configure.ac
===
--- gcc43.orig/libjava/configure.ac
+++ gcc43/libjava/configure.ac
@@ -1369,7 +1369,7 @@ AC_SUBST(toolexecmainlibdir)
AC_SUBST(toolexeclibdir)
# Determine gcj and libgcj version number.
-gcjversion=`$GCJ -v 21 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
+gcjversion=`$GCJ -v 21 | awk '/^gcc version/ { print $3 }'`
libgcj_soversion=`awk -F: '/^[[^#]].*:/ { print $1 }' $srcdir/libtool-version`
GCJVERSION=$gcjversion
AC_SUBST(GCJVERSION)
Introduced by:
r127025 | doko | 2007-07-29 00:32:27 +0400 (Sun, 29 Jul 2007) | 6 lines
2007-07-28 Matthias Klose [EMAIL PROTECTED]
* configure.ac: Encode the libgcj soversion in dbexecdir,
pass --with-native-libdir to classpath configure.
* configure: Regenerate.
--
Summary: [4.3 Regression] libjava fails to compile if configure
argument contains version
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains version
--- Comment #1 from doko at ubuntu dot com 2007-09-02 11:21 ---
Subject: Re: New: [4.3 Regression] libjava fails to compile
if configure argument contains version
belyshev at depni dot sinp dot msu dot ru schrieb:
When gcc is configured with, for example, --without-pkgversion, this part of
libjava configure script parses gcj -v output incorrectly, thus encoding
garbage as preprocessor macro and failing:
gcjversion=`$GCJ -v 21 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
An obvious fix would be:
-gcjversion=`$GCJ -v 21 | sed -n 's/^.*version \([[^ ]]*\).*$/\1/p'`
+gcjversion=`$GCJ -v 21 | awk '/^gcc version/ { print $3 }'`
doesn't look robust either; what about
gcjversion=`cat $srcdir/../gcc/BASE-VER`
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug bootstrap/32161] stage1 libgcc is being built unoptimized
--- Comment #4 from bonzini at gnu dot org 2007-09-02 11:29 --- *** This bug has been marked as a duplicate of 32009 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32161
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #18 from bonzini at gnu dot org 2007-09-02 11:29 --- *** Bug 32161 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug target/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 11:36 --- I saw this also asn asked about it on IRC. Note please don't CC anyone unless you know that they caused the bug. They don't want to be getting all bug reports. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com, debian-gcc at lists dot| |debian dot org, fxcoudert at| |gcc dot gnu dot org | Component|c |target GCC build triplet|rs600 | GCC host triplet|rs600 | GCC target triplet|rs600 |powerpc-linux-gnu Summary|[4.3.0 Regression] |[4.3 Regression] Bootstrap |Bootstrap check failures|check failures ICE's |ICE's | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 11:41 --- [18:22] apinski /home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5: error: could not split insn^M [18:22] apinski new failure [18:23] apinski on ppc-linux-gnu [18:23] apinski between 127935 and 128000 GPL3 has been dismissed by the world. WTF does this have to do with 930921-1.c ICE I am seriously thinking about ignoring all the bug reports from you from now on because of this crap. GCC is owned (copyrighted) by the FSF and GPLv3 is th official license from them and they get to decide on the license not us, we can influence somewhat but they are the official word. This and recent submissions by the Debian-gcc-team prove the point. You know, there are many different targets that GCC supports, sometimes the patch does not cause any regression on one target can cause regressions on others. This happens all the time. You need to understand the main reason why we have the testsuite is so we easily see when a target has a regression or not. Now if you want to report bugs, please do so without this extra crap because it gets in the way of actually fixing it and it makes people think you are crazy and should not be listened to. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug fortran/32382] missed optimization in internal read
--- Comment #3 from manfred99 at gmx dot ch 2007-09-02 11:53 --- Jerry, any news on this? I have seen this pattern many times in legacy fortran77 code, and the code authors seem to assume that ridiculously large loop stop values do not compromize performance. After all, in fortran77 you have to do something like this if you don't know the dimension to the data to read. Interestingly, ifort seems to have changed their mind, as ifort 8.1 seems to loop till the end (see comp.lang.fortran link in BUG 32257), whereas ifort 9.0 stops at value 4, like g77. And, as mentioned in BUG 32257, the compiler is free to choose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains version
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug tree-optimization/3713] Pointers to functions or member functions are not folded or inlined
--- Comment #14 from guillaume dot melquiond at ens-lyon dot fr 2007-09-02
11:56 ---
Created an attachment (id=14150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14150action=view)
Implements folding of (function 1)
I encountered the same issue with some heavy template code: GCC was generating
some really awful code, while it should have been optimized to almost anything.
It basically comes down to this kind of C++ code:
struct A { void a(); };
template void (A::*f)()
void g(A *t) { (t-*f)(); }
void h(A *t) { gA::a(t); }
After instantiation, it is somehow transformed to:
struct A { void a(); };
void h(A *t) { (t-*(A::a))(); }
And GCC is unable to optimize it. So I played a bit with the attached patch,
which does fix the issue for my template code.
Note that GCC does inline the member function for my code (just add an empty
body to A::a to test it), but it doesn't inline it in Andrew Pinski's last
testcase. I have no idea why; perhaps because the address goes through a
variable. But at least the generated code no longer contain any crap and it
directly calls the correct function, even if it doesn't inline it.
(As for why the C++ front-end generates this code in the first place, it is
because the lower bit of the pointer indicates whether an extra indirection is
needed when calling the function through the pointer to member. The C++
front-end actually assumes that functions have an alignment of 2 at least, so
that this trick can work.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
[Bug fortran/33276] [4.3 Regression] 465.tonto in SPEC CPU 2006 fails to compile
--- Comment #3 from hjl at gcc dot gnu dot org 2007-09-02 12:23 --- Subject: Bug 33276 Author: hjl Date: Sun Sep 2 12:23:04 2007 New Revision: 128024 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128024 Log: gcc/fortran/ 2007-09-02 H.J. Lu [EMAIL PROTECTED] PR fortran/33276 * array.c (expand_iterator): Initialize frame.prev. gcc/testsuite/ 2007-09-02 H.J. Lu [EMAIL PROTECTED] PR fortran/33276 * gfortran.fortran-torture/compile/pr33276.f90: New. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr33276.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33276
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains version
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2007-09-02 12:28 --- (In reply to comment #1) doesn't look robust either; what about gcjversion=`cat $srcdir/../gcc/BASE-VER` Agreed, that's much better. To be even more robust, add quotes: gcjversion=`cat $srcdir/../gcc/BASE-VER` -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug fortran/33276] [4.3 Regression] 465.tonto in SPEC CPU 2006 fails to compile
--- Comment #4 from hjl at lucon dot org 2007-09-02 12:36 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33276
[Bug c++/33208] Broken diagnostic: 'component_ref' not supported by dump_decl
--- Comment #10 from paolo at gcc dot gnu dot org 2007-09-02 13:02 --- Subject: Bug 33208 Author: paolo Date: Sun Sep 2 13:02:31 2007 New Revision: 128025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128025 Log: /cp 2007-09-02 Paolo Carlini [EMAIL PROTECTED] PR c++/33208 * typeck.c (build_unary_op): Fix error message for Boolean expression as operand to operator--. /testsuite 2007-09-02 Paolo Carlini [EMAIL PROTECTED] PR c++/33208 * g++.dg/other/error18.C: New. * g++.dg/expr/bitfield3.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/other/error18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/expr/bitfield3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33208
[Bug c++/33208] Broken diagnostic: 'component_ref' not supported by dump_decl
--- Comment #11 from pcarlini at suse dot de 2007-09-02 13:03 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33208
[Bug middle-end/33279] New: Failed to warn uninitialized stack variable
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
iterator_stack frame;
bar (frame.value);
x = frame.prev;
}
[EMAIL PROTECTED] uninit-2]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -Wuninitialized -S x.c
It seems that gcc is confused by
typedef int mpz_t[1];
--
Summary: Failed to warn uninitialized stack variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
Re: [Bug middle-end/33279] New: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
iterator_stack frame;
bar (frame.value);
x = frame.prev;
}
[EMAIL PROTECTED] uninit-2]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -Wuninitialized -S x.c
Not really because this is the same as
bar (frame.value[0]);
Where bar can do pointer tricks to get back to original struct and
then change prev, trust me, this is allowed. There is a comment in
GCC sources about this specific issue.
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #1 from pinskia at gmail dot com 2007-09-02 13:26 ---
Subject: Re: New: Failed to warn uninitialized stack variable
On 2 Sep 2007 13:19:45 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] uninit-2]$ cat x.c
typedef int mpz_t[1];
typedef struct iterator_stack
{
struct iterator_stack *prev;
mpz_t value;
} iterator_stack;
iterator_stack *x;
void bar (mpz_t);
void
foo ()
{
iterator_stack frame;
bar (frame.value);
x = frame.prev;
}
[EMAIL PROTECTED] uninit-2]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -Wuninitialized -S x.c
Not really because this is the same as
bar (frame.value[0]);
Where bar can do pointer tricks to get back to original struct and
then change prev, trust me, this is allowed. There is a comment in
GCC sources about this specific issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 13:32 --- As mentioned by me in comment #1, we cannot warn about this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #3 from hjl at lucon dot org 2007-09-02 13:37 --- Subject: Re: New: Failed to warn uninitialized stack variable Not really because this is the same as bar (frame.value[0]); Where bar can do pointer tricks to get back to original struct and then change prev, trust me, this is allowed. There is a comment in GCC sources about this specific issue. How does bar know it is called by bar (frame.value); not mpz_t value; ... bar (value); -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 --- [18:23] apinski between 127935 and 128000 Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from regress, it can be narrowed between 127961 (working) and 127997 (non working). Note that the last change of final.c is 127941 (outside the range). From an uneducated guess, I'l say 127989, but I may be completely wrong. You know, there are many different targets that GCC supports, sometimes the patch does not cause any regression on one target can cause regressions on others. This happens all the time. You need to understand the main reason why we have the testsuite is so we easily see when a target has a regression or not. Yes indeed! but the maintainers could look at the above URL to check that there is no unexpected regression on untested platforms. If they have no access to some of them, there could be a list of people to ask for details about the failure (I volunteer for Darwin!). Otherwise I fully agree with Andrew Pinski about what should not put in bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:43 --- bar (frame.value); That call to bar causes the whole frame struct escapes here, not just the array element. void bar (mpz_t); is really: void bar(int*); because of array decaying in parameters. Again with pointer arithmetic, bar can get back to the original struct and be able to set prev. So again there is no bug here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
Re: [Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 --- [18:23] apinski between 127935 and 128000 Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from regress, it can be narrowed between 127961 (working) and 127997 (non working). Note that the last change of final.c is 127941 (outside the range). From an uneducated guess, I'l say 127989, but I may be completely wrong. From looking closer to the changes, the scheduler changes is not likely because this happens at -O1 :) I am more thinking it was: 2007-08-31 Richard Sandiford [EMAIL PROTECTED] Which changed optabs which is part of the expansion. The IV change could not have cause this issue as there is no loop in that function so the last change would be the optabs change. -- Pinski
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-02 13:50 --- Subject: Re: [4.3 Regression] Bootstrap check failures ICE's On 2 Sep 2007 13:42:42 -, dominiq at lps dot ens dot fr [EMAIL PROTECTED] wrote: --- Comment #3 from dominiq at lps dot ens dot fr 2007-09-02 13:42 --- [18:23] apinski between 127935 and 128000 Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from regress, it can be narrowed between 127961 (working) and 127997 (non working). Note that the last change of final.c is 127941 (outside the range). From an uneducated guess, I'l say 127989, but I may be completely wrong. From looking closer to the changes, the scheduler changes is not likely because this happens at -O1 :) I am more thinking it was: 2007-08-31 Richard Sandiford [EMAIL PROTECTED] Which changed optabs which is part of the expansion. The IV change could not have cause this issue as there is no loop in that function so the last change would be the optabs change. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #5 from hjl at lucon dot org 2007-09-02 13:56 ---
(In reply to comment #4)
bar (frame.value);
That call to bar causes the whole frame struct escapes here, not just the
array
element.
void bar (mpz_t);
is really:
void bar(int*);
because of array decaying in parameters.
Again with pointer arithmetic, bar can get back to the original struct and be
able to set prev. So again there is no bug here.
When bar is called from
mpz_t value;
...
bar (value);
there is no original struct to go back to and there can be another
struct
typedef struct iterator_stack_2
{
struct iterator_stack_2 *prev;
mpz_t value;
int foo;
} iterator_stack_2;
iterator_stack_2 x;
..
bar (x.value);
What does bar get back to? Are you saying if a pointer is passed to bar,
it can get back to any original struct where the pointer is a field?
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #6 from hjl at lucon dot org 2007-09-02 13:58 --- (In reply to comment #5) What does bar get back to? Are you saying if a pointer is passed to bar, it can get back to any original struct where the pointer is a field? If you can write such a function, I can pass you a pointer and your function will be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
Re: [Bug middle-end/33279] Failed to warn uninitialized stack variable
On 2 Sep 2007 13:56:13 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: What does bar get back to? Are you saying if a pointer is passed to bar, it can get back to any original struct where the pointer is a field? It only matters at the context at the point bar is called with the struct. No other place matters. It does not matter if bar can be called with a simple array (that will cause undefined code if bar tries to go before the array) as it still can be using pointer arithmetic.
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #7 from pinskia at gmail dot com 2007-09-02 14:01 --- Subject: Re: Failed to warn uninitialized stack variable On 2 Sep 2007 13:56:13 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: What does bar get back to? Are you saying if a pointer is passed to bar, it can get back to any original struct where the pointer is a field? It only matters at the context at the point bar is called with the struct. No other place matters. It does not matter if bar can be called with a simple array (that will cause undefined code if bar tries to go before the array) as it still can be using pointer arithmetic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
Re: [Bug middle-end/33279] Failed to warn uninitialized stack variable
On 2 Sep 2007 13:58:23 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: If you can write such a function, I can pass you a pointer and your function will be wrong. yes so but that call would be undefined, not the one we are talking about currently. --Pinski
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #8 from pinskia at gmail dot com 2007-09-02 14:02 --- Subject: Re: Failed to warn uninitialized stack variable On 2 Sep 2007 13:58:23 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: If you can write such a function, I can pass you a pointer and your function will be wrong. yes so but that call would be undefined, not the one we are talking about currently. --Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-02 14:03 --- What does bar get back to? Are you saying if a pointer is passed to bar, it can get back to any original struct where the pointer is a field? No, but if you pass a pointer to a field of a struct the callee may derive the address of the containing object and modify it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33280] New: FAIL: gcc.c-torture/execute/990404-1.c execution at -O3
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc -B/home/dave/gcc-4.3/objdi r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/990404-1.c -w -O3 -fomit-frame-pointer -fno-show-column -lm -o /home/dave/gcc-4.3/objdir /gcc/testsuite/gcc/990404-1.x3(timeout = 300) PASS: gcc.c-torture/execute/990404-1.c compilation, -O3 -fomit-frame-pointer Setting LD_LIBRARY_PATH to :/home/dave/gcc-4.3/objdir/gcc::/home/dave/gcc-4.3/ob jdir/gcc:/home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gcc- 4.3/objdir/hppa-linux/libmudflap/.libs:/home/dave/gcc-4.3/objdir/hppa-linux/libs sp/.libs:/home/dave/gcc-4.3/objdir/hppa-linux/libgomp/.libs:/home/dave/gcc-4.3/o bjdir/./gcc:/home/dave/gcc-4.3/objdir/./prev-gcc FAIL: gcc.c-torture/execute/990404-1.c execution, -O3 -fomit-frame-pointer Program aborts. This fail was first observed in 4.3.0 20070901 revision 128010. It was not present in revision 127946. -- Summary: FAIL: gcc.c-torture/execute/990404-1.c execution at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33280
[Bug fortran/33281] New: gfortran crt2.o not found under Vista
I'm trying to run gfortran under Windows Vista. I ran into ld: crt2.o: No such file. I've found several reports on this, but no solution... Is there a solution available already? -- Summary: gfortran crt2.o not found under Vista Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: DHConsultancy at skynet dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #5 from michelin60 at gmail dot com 2007-09-02 15:23 --- I am beginning to enjoy this: There are about 34 hours between the first indication of failure on regress an my report. There are about 8 hours between my report and the first acknowledgment by GCC. This came by master of obfuscation and arbitrariness: Mr Pinski. The management motto at GCC seems to be: Do as I say, do not do as I do There is one person on the steering committee, who has real experience in building and managing a grou of professionals. His name is Mark Mitchell of Codesourcery. There is another member, acting as chairman, who is decidedly mis-using GCC for the interest of one company. His name is Dr. Edelsohn of IBM. This is not my statement I posted, acknowledged by GGC, proof in an earlier posting PR3316. That posting caused Mr. Pinski to flaunt a few more rules of comity, ownership of intellectual property (the posting), etc. There is ample confirmation provided for this misuse of GCC by using Google to for Scott Handy IBM. Mr Handy is pretty far up in IBM management. Well as long as my name appears as poster of reporter I reserve the right to say whatever I please within the rules governing defamation and avoidance of foul language like used habitually by Mr. Pinski. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug c++/33051] g++-4.2: Internal error: Segmentation fault (program cc1plus)
--- Comment #2 from pcarlini at suse dot de 2007-09-02 15:23 --- Currently 4_2-branch and 4_1-branch also give the same. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33051
[Bug inline-asm/33220] impossible constraint in �asm�
--- Comment #2 from yakov at emc dot com 2007-09-02 15:44 --- Subject: Re: impossible constraint in asm pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-01 19:51 --- -msoft-float disables the floating register stack so this is not a bug. The error message is correct the constraint is impossible Does it mean that gcc-3x family has a bug: gcc -v -msoft-float f_powf.c Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.3 20030226 (prerelease) (SuSE Linux) /usr/lib/gcc-lib/i486-suse-linux/3.3/cc1 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 f_powf.c -quiet -dumpbase f_powf.c -msoft-float -auxbase f_powf -version -o /tmp/ccOIZkYJ.s GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C version 3.3 20030226 (prerelease) (SuSE Linux) (i486-suse-linux) compiled by GNU C version 3.3 20030226 (prerelease) (SuSE Linux). #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc-lib/i486-suse-linux/3.3/include /usr/i486-suse-linux/include /usr/include End of search list. /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/as -V -Qy -o /tmp/ccgzdkTv.o /tmp/ccOIZkYJ.s GNU assembler version 2.13.90.0.18 (i486-suse-linux) using BFD version 2.13.90.0.18 20030121 (SuSE Linux) /usr/lib/gcc-lib/i486-suse-linux/3.3/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../crt1.o /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../crti.o /usr/lib/gcc-lib/i486-suse-linux/3.3/crtbegin.o -L/usr/lib/gcc-lib/i486-suse-linux/3.3 -L/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/lib -L/usr/lib/gcc-lib/i486-suse-linux/3.3/../../.. /tmp/ccgzdkTv.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i486-suse-linux/3.3/crtend.o /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../crtn.o /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../crt1.o(.text+0x18): In function `_start': : undefined reference to `main' /tmp/ccgzdkTv.o(.text+0xf): In function `_f_powf': : undefined reference to `__gtsf2' /tmp/ccgzdkTv.o(.text+0x6b): In function `_f_powf': : undefined reference to `powf' collect2: ld returned 1 exit status usenmyakushnx1l[/emc/yakov]: gcc -v -msoft-float -c f_powf.c Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.3 20030226 (prerelease) (SuSE Linux) /usr/lib/gcc-lib/i486-suse-linux/3.3/cc1 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 f_powf.c -quiet -dumpbase f_powf.c -msoft-float -auxbase f_powf -version -o /tmp/ccGvb4Lt.s GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C version 3.3 20030226 (prerelease) (SuSE Linux) (i486-suse-linux) compiled by GNU C version 3.3 20030226 (prerelease) (SuSE Linux). #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc-lib/i486-suse-linux/3.3/include /usr/i486-suse-linux/include /usr/include End of search list. /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/as -V -Qy -o f_powf.o /tmp/ccGvb4Lt.s GNU assembler version 2.13.90.0.18 (i486-suse-linux) using BFD version 2.13.90.0.18 20030121 (SuSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33220
[Bug libgomp/33275] Transient libgomp.fortran/omp_parse3.f90 -O0 failure
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-02 15:55 --- I see this as well from time to time. SLES10-SP1 x86_64. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 15:55:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33275
[Bug middle-end/33277] [4.3 Regression] gcc.c-torture/execute/930921-1.c ICEs on ppc
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-09-02 16:01:12 date|| Summary|[4.3 Regression] Bootstrap |[4.3 Regression] gcc.c- |check failures ICE's|torture/execute/930921-1.c ||ICEs on ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug fortran/32382] missed optimization in internal read
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-02 16:08 --- Well, it has not been on my top burner. Looking at -fdump-tree-original the problem can be seen easily. Fixing is not so straight forward. This will probably not happen until 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/33269] Diagnose missing ( in PRINT ('a'),
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 16:16:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 16:33:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/31229] kind parameter in function declaration fails to find use-associated parameters
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-02 16:38 --- See also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/11acfc0d9e65566e/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
[Bug fortran/33282] New: ICE in find_array_section when using vector subscripts
The following Fortran 90 program crashes gfortran-4.2.1: program test real(kind=8),parameter :: beta0(3) = (/ 1.0, 1.0, 1.0 /) integer :: i(3) real(kind=8) :: beta(3), beta_coef i = (/ 1, 2, 3 /) beta_coef = 1.0 beta = beta0(i) * beta_coef end program test (Workaround: beta = beta0(i) ; beta = beta * beta_coef) Compiler output: $ gfortran -g -O2 -march=pentium4 -mfpmath=sse -ffree-form -ffree-line-length-none -Wall -W -Wno-unused -Wimplicit-interface -Wtabs -fimplicit-none -ffpe-trap=invalid,zero,overflow -o arraybug arraybug.f90 arraybug.f90:0: internal compiler error: in find_array_section, at fortran/expr.c:1079 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.1/configure --prefix=/home/r6144/apps/gcc-4.2.1 --enable-languages=c,fortran --with-mpfr=/home/r6144/apps/mpfr-2.3.0 --disable-bootstrap Thread model: posix gcc version 4.2.1 $ gfortran --version GNU Fortran (GCC) 4.2.1 Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING -- Summary: ICE in find_array_section when using vector subscripts Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainy6144 at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug c++/28239] [4.2/4.3 regression] ICE in gimple_add_tmp_var, at gimplify.c:720
--- Comment #4 from pcarlini at suse dot de 2007-09-02 17:12 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28239
[Bug middle-end/33279] Failed to warn uninitialized stack variable
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-09-02 17:19 --- As mentioned by Richard and I, this bug is invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33279
[Bug middle-end/33277] [4.3 Regression] gcc.c-torture/execute/930921-1.c ICEs on ppc
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-09-02 17:49 --- Lets see, IBMers working on GCC: more than 11. Intel folks working on GCC: ~3 or so. AMDers working on GCC: at least 4 but growing (includes Michael Meissner). Googlers: who knows any more :) (but at least 10). Redhat: unknown anymore (at least 12 still) Codesourcery: ~ 16 Novell (including Suse): ~14 (maybe more) I don't know why you are dissing IBM here really, it is really becoming a joke. IBM is like any big company that supports open source in providing suport for GCC. If you want to look at some trend, then you should question goolge (then again I would not). Also there are many other companies support powerpc work for GCC (including Sony for the Cell BEA [me] ). Freescale has some problems with their mangement to be able submitting stuff. The other thing you should be looking into is a cygnus conspiracy (then again that conspiracy has been going since 1999 and does not go away every year). But seriously there is no conspiracy when it comes to either IBM or cygnus (aka redhat). The GCC SC is made up of a people who work for different companies (and most of the time don't represent them during SC talk. Also the SC does not do day to day mangement of GCC. Maintainers do that. And maintainers in GCC come from all different companies. I think you need to look into MAINTAINERS file to see that. Yes David is a maintainer for the rs6000 backend but that does not mean he cause all the issues when it comes to the back-end. He does try to fix them every time something comes up and quicky at that. Just take a look at PR 33151 (within 4 days of the bug being opened the bug was fixed). The problem here though is not really target related except it only shows up on rs6000 since the target independent changes caused it. One should note that this is a long weekend in the US. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com, mark at codesourcery | |dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33283] New: [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
[18:22] apinski /home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/930921-1.c:5: error: could not split insn^M [18:22] apinski new failure [18:23] apinski on ppc-linux-gnu [18:23] apinski between 127935 and 128000 [18:32] Rhyolite I guess it could be due to my predicate change [18:33] apinski this was after that [18:33] Rhyolite okay, phew [18:33] apinski paired support was inbetween that though [18:33] Rhyolite sigh [18:34] Rhyolite Revital said that she regression tested [18:34] apinski but also Sandra's regclass changes [18:34] apinski and some optabs changes [18:34] apinski so it could be either of those three And then from PR 33277 #3: Fromp http://gcc.gnu.org/ml/gcc-testresults/, looking at the results from regress, it can be narrowed between 127961 (working) and 127997 (non working). Note that the last change of final.c is 127941 (outside the range). From an uneducated guess, I'l say 127989, but I may be completely wrong. And from #4: From looking closer to the changes, the scheduler changes is not likely because this happens at -O1 :) I am more thinking it was: 2007-08-31 Richard Sandiford [EMAIL PROTECTED] Which changed optabs which is part of the expansion. The IV change could not have cause this issue as there is no loop in that function so the last change would be the optabs change. -- Summary: [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: powerpc-*-* (32bits) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33283
[Bug middle-end/33283] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 --- This shows up on both powerpc-linux-gnu and powerpc-darwin. Confirmed because it shows up in many different testresults. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 17:53:09 date|| Summary|[4.3 Regression] gcc.c- |[4.3 Regression] gcc.c- |torture/execute/930921-1.c |torture/execute/930921-1.c |fails at -O1 and above now |fails at -O1 and above now Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33283
[Bug middle-end/33277] [4.3 Regression] gcc.c-torture/execute/930921-1.c ICEs on ppc
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 --- I just filed a new bug without any of the extra crap: PR 33283. *** This bug has been marked as a duplicate of 33283 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33283] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-02 17:53 --- *** Bug 33277 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michelin60 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33283
[Bug fortran/33284] New: ENTRY and INTRINSIC with same name
I think the following is invalid, but not rejected: SUBROUTINE a intrinsic cos entry cos(x) real x x = 0 end subroutine end NAG f95 shows: Error: a.f90, line 5: Multiply defined symbol COS Ifort shows: fortcom: Error: a.f90, line 2: Conflicting attributes or multiple declaration of name. [COS] -- Summary: ENTRY and INTRINSIC with same name Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33284
[Bug fortran/33285] New: integer too big compile error in gfortran
On Mandriva 2008 beta 2 [EMAIL PROTECTED] Ftest]$ gcc -v Using built-in specs. Target: x86_64-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.1 20070828 (prerelease) (4.2.1-6mdv2008.0) Test Program: program testint integer(4) i,j,k,ii parameter (ii=-2147483648) k = -2147483648 print *, k,ii= ,k,ii do i=20,32 j=2**i print *,i= ,i, 2^i= ,j j=-2**i print *,i= ,i, -2^i= ,j enddo end Compilation: [EMAIL PROTECTED] Ftest]$ gfortran -c testint.for testint.for:3.33: parameter (ii=-2147483648) 1 Error: Integer too big for its kind at (1) testint.for:4.24: k = -2147483648 1 Error: Integer too big for its kind at (1) [EMAIL PROTECTED] Ftest]$ ~ Integer (4) can have range : -2^31 to + ((2^31)-1) OK to compile on gcc-4.1.2 -- Summary: integer too big compile error in gfortran Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlaw at uoguelph dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug fortran/33282] ICE in find_array_section when using vector subscripts
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-02 18:12 --- Could you try with GCC gfortran 4.3.0? I can reproduce the problem with gfortran 4.2.x but not with gfortran 4.3.0 which indicates that this has been fixed meanwhile. If you don't want to build GCC yourself (as you seem to do), you can use the binaries from http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug fortran/33269] Diagnose missing ( in PRINT ('a'),
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-02 18:27 ---
(In reply to comment #3)
No, the syntax is:
READ format[, io-list]
and ('f.3.3') as a constant-string expression for the format; this is similar
to PRINT ('f3.3'), a.
This should be distinguished from:
READ(io-control-spec-list)
The distinction is simple: If there is no ( and an * or a label, it must be
READ format; if the first item after the ( is a default-char-expression
(constant or not) and there is no ...= (e.g. fmt=) in there, then it is
also a READ format statement.
This is wrong. In READ(20) x, 20 is not a format but a unit number.
Additionally, we allow READ(20), x as an extension which makes this even more
annoying to fix.
I'll be leaving for vacation on Thursday. Given that my first attempts at
fixing this failed, I don't think I'll be able to attend these bugs before the
end of the month. Fortunately, they're not important issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #26 from marcus at jet dot franken dot de 2007-09-02 18:35 --- btw, this went latent again with commit r127834: +2007-08-27 Daniel Berlin [EMAIL PROTECTED] + + Fix PR tree-optimization/33173 + * tree-ssa-alias.c (find_used_portions): Fix reversed test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/33282] ICE in find_array_section when using vector subscripts
--- Comment #2 from rainy6144 at gmail dot com 2007-09-02 18:38 --- Thank you. The bug appears to have been fixed in the latest 4.3.0 snapshot (r128023). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug fortran/33269] Diagnose missing ( in PRINT ('a'),
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-02 18:42 --- (In reply to comment #4) if the first item after the ( is a default-char-expression (constant or not) and there is no ...= (e.g. fmt=) in there, then it is also a READ format statement. This is wrong. In READ(20) x, 20 is not a format but a unit number. I don't think that this is wrong: I would argue that 20 is not a default-char-expression ;-) Additionally, we allow READ(20), x as an extension which makes this even more annoying to fix. Agreed. Fortunately, they're not important issues. Fortunately not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug fortran/33269] Diagnose missing ( in PRINT ('a'),
--- Comment #6 from tobi at gcc dot gnu dot org 2007-09-02 18:48 --- (In reply to comment #5) (In reply to comment #4) if the first item after the ( is a default-char-expression (constant or not) and there is no ...= (e.g. fmt=) in there, then it is also a READ format statement. This is wrong. In READ(20) x, 20 is not a format but a unit number. I don't think that this is wrong: I would argue that 20 is not a default-char-expression ;-) Sorry, you're right of course. Unfortunately, the type can't be determined in all cases, so this criterion doesn't work. I tried. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33269
[Bug middle-end/33283] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #3 from michelin60 at gmail dot com 2007-09-02 18:57 ---
Well here it is for interfering with Mr Guenther doing the reasonable thing.
This arbitrariness and unwarranted interference led me to do this.
It is also interesting to look a the GCC.mailing.list for June and July to
realize what is really going on within GCC
Mr. Mark Mitchell was overruled on his misgivings regarding the status of
gcc-4.2.0 . Hence gcc-4.2.0 is not really serviceable and can not even compile
glibc on some architectures. The linux distributors are staying away from
gcc-4.2.0 save for SUSE. However, SUSE made it impossible to find out
readily which gcc version compiled their executables and libraries. Thus a
statement that their latest available beta or release candidate compiler is
gcc-4.2.x is not verifiable.
What follows is a verbatim copy of PR33271 tentatively suppressed by Mr.
Pinski, who appears to be a protege of Dr. Edelsohn.
The summary results are pretty obvious:
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O1 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O2 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -g (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -Os (internal compiler
error)
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
This are __not__ the mayalias failures which continue to fail with 4.3.0 and
are __not__
marked XFAIL
There is only on category, namely rs6000, both in the config tree and in the
MAINTAINERS LIST, so do expect the submitters to devine any other name dujour.
Also if the supposedly scarce manpower available can process hundreds of
pretty irrelevant GPL3 and whitespace elimination patches ( even for an already
released 4.2.x series) then submitters should not be harassed about submitting
superfluous details.
GPL3 has been dismissed by the world. Just look at the trade press, slashdot,
dig, and others.
There is neither adequate management for the steering committee down nor other
than lip-service to quality control. This and recent submissions by the
Debian-gcc-team prove the point.
Just to gild the lily here goes:
#include stdlib.h
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) 32) 1;
}
main ()
{
unsigned i;
for (i = 0; i 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,fortran,c++ --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070901 (experimental) (GCC)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
-Asystem=unix -Asystem=posix 930921-1.c -quiet -dumpbase 930921-1.c -mcpu=G4
-auxbase 930921-1 -O1 -version -o /tmp/ccCd2Hre.s
ignoring nonexistent directory
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/libffi
/usr/local/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.0 20070901 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070901 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fe13efd375927cd9d7414827707b954b
930921-1.c: In function 'f':
930921-1.c:6: error: could not split insn
(insn 6 3 31 930921-1.c:4 (set (reg:SI 0 0 [123])
(const_int 2863311531 [0xaaab])) 265 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 2863311531 [0xaaab])
(nil)))
930921-1.c:6: internal compiler error: in final_scan_insn, at final.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- Comment #1 From Andrew Pinski 2007-09-02 11:36 [reply] ---
[Bug target/33286] New: All exception related tests fail
All exception related tests fail on this target. For example,
Executing on host: /home/gnu/gcc/objdir/gcc/xgcc -B/home/gnu/gcc/objdir/gcc/
/xx
x/gnu/gcc/gcc/gcc/testsuite/gcc.dg/cleanup-5.c -fexceptions -fno-show-column
-lm -o ./cleanup-5.exe(timeout = 300)
PASS: gcc.dg/cleanup-5.c (test for excess errors)
Setting LD_LIBRARY_PATH to :/xxx/gnu/gcc/objdir/gcc::/xxx/gnu/gcc/objdir/gcc
FAIL: gcc.dg/cleanup-5.c execution test
I find in debugging this failure that the tests fail because
init_dwarf_reg_size_table is not being called. This leads to an
assert failure in _Unwind_SetSpColumn.
Sadly, checking must have been disabled in previous testing on this
target. The problem doesn't occur in hpux11.11 because a fix was added
to the libc version of pthread_once to call init_dwarf_reg_size_table.
This was added in PHCO_29495.
The fundamental problem is that threads are not active unless programs
are compiled and linked with -pthreads. The shared version of libc
contains stub implementations of the pthread, and as noted the hpux11.00
stub for pthread_once doesn't call the init routine.
I think the simplest fix is to provide an hppa-hpux specific version of
__gthread_active_p():
/* Return TRUE is application is linked with libpthread. */
extern int __get_ismt (void);
static inline int
__gthread_active_p (void)
{
return __get_ismt () == 2;
}
__get_ismt() appears to have been introduced in PHCO_22923 on hpux11.00,
so we may need a configure test for it. On the otherhand, I don't really
want to support old versions of libc.
The other approach to fixing this would be to always link against libpthread
when exception support is needed.
--
Summary: All exception related tests fail
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa*-*-hpux11.00
GCC host triplet: hppa*-*-hpux11.00
GCC target triplet: hppa*-*-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33286
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-09-02 20:57 --- This is assuming that an asymmetric range is permitted in Fortran which I think it is not. You can use -fno-range-check to disable this check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #2 from kargl at gcc dot gnu dot org 2007-09-02 21:04 --- The number 2147483648 is too big. The minus sign is a unary operator. Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1' -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug c++/33287] New: namespace hides class definition
class C1
{
public:
C1();
static int x;
};
#if 1
namespace C1
{
int x;
};
#else
int C1::x;
#endif
class C2
{
public:
C2();
C1 c; // ! error here
};
when the static field is defined inside the namespace block, the definition of
the C1 class is no longer visible in the reference.
I'm using the WinAVR-20070525 version of the AVR port.
--
Summary: namespace hides class definition
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ilgb at livius dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33287
[Bug c++/29388] [4.0/4.1/4.2/4.3 regression] ICE with invalid nested name specifier
--- Comment #4 from pcarlini at suse dot de 2007-09-02 23:00 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug c++/29388] [4.0/4.1/4.2/4.3 regression] ICE with invalid nested name specifier
--- Comment #5 from pcarlini at suse dot de 2007-09-02 23:29 --- Humm, too tricky. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #3 from jlaw at uoguelph dot ca 2007-09-03 01:50 --- (In reply to comment #1) This is assuming that an asymmetric range is permitted in Fortran which I think it is not. You can use -fno-range-check to disable this check. In the IBM XL Fortran 90 manual: pg 19 I quote: for Integer Kind parameter 4 range of value -2147483648 through to 2147483647 namely -(2^31) to (2^31 -1) Compiling this using gcc-gfortran-4.1.X and gcc-g77-3.X works It is a Fortran standard! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #4 from jlaw at uoguelph dot ca 2007-09-03 02:32 --- (In reply to comment #2) The number 2147483648 is too big. The minus sign is a unary operator. Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1' option: -fno-range-check is supposed to be the default for the compiler In some cases, options have positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default.' It is in 4.1.X, looks like it has changed in 4.2.1 In using this option: 4.2.1 compiles the test code. This change from the default is NOT documented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #5 from kargl at gcc dot gnu dot org 2007-09-03 03:43 --- (In reply to comment #4) (In reply to comment #2) The number 2147483648 is too big. The minus sign is a unary operator. Either use the compiler option that Jerry mentioned or use 'k = - huge(k) - 1' option: -fno-range-check is supposed to be the default for the compiler Huh? No, the default for the compiler is to perform range checking. In some cases, options have positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default.' Looks like a bug in the documentation. I'll fix that shortly. It is in 4.1.X, looks like it has changed in 4.2.1 There was a bug in gfortran that allowed it to accepted -2147483648. I fixed the bug with 2006-09-07 Steven G. Kargl [EMAIL PROTECTED] * gfortran.h (gfc_integer_info): Eliminate max_int. * arith.c (gfc_arith_init_1): Remove initialization of max_int. (gfc_arith_done_1): Remove clearing of max_int. (gfc_check_integer_range): Fix range chekcing of overflow. * simplify.c (gfc_simplify_not): Construct mask that was max_int. You can read about the problem here: http://gcc.gnu.org/ml/fortran/2006-09/msg8.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
[Bug fortran/33285] integer too big compile error in gfortran
--- Comment #6 from kargl at gcc dot gnu dot org 2007-09-03 03:58 --- (In reply to comment #3) (In reply to comment #1) This is assuming that an asymmetric range is permitted in Fortran which I think it is not. You can use -fno-range-check to disable this check. In the IBM XL Fortran 90 manual: pg 19 I quote: for Integer Kind parameter 4 range of value -2147483648 through to 2147483647 namely -(2^31) to (2^31 -1) The IBM XL manual isn't the Fortran standard. Compiling this using gcc-gfortran-4.1.X and gcc-g77-3.X works It was a bug in older versions of gfortran. It is a Fortran standard! The Fortran 95 standard doesn't specify the values that an integer can take. It does specify the model numbers for integer. There is a difference! In i = - 2147483648, the RHS is an expression. It is a unary minus operator with the operand 2147483648, which is greater than 2^31-1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33285
