[Bug fortran/28335] flush() / write() statement on closed units - error?
--- Comment #2 from patchapp at dberlin dot org 2006-07-25 05:10 --- Subject: Bug number PR28335 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01054.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug c++/28475] New: Internal error: Segmentation fault (program cc1plus)
g++ asked me to submit a report:
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
I was able to trim the code down to:
// bug_20060724.cc
// ===
template < typename T >
class pointer;
template < typename T >
struct pointer_ref {
pointer_ref ( pointer< T > r ) throw () {}
}; // pointer_ref<>
template < typename T >
struct pointer {
pointer ( pointer & other ) throw() {}
pointer ( pointer_ref< T > ref ) throw() {}
}; // pointer<>
pointer create ( void ) {}
int main ( void ) {
pointer bb ( create() );
}
// end of file
Specs are:
/added/pkg/gcc-4.1.0/usr/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/added/pkg/gcc-4.1.0/usr
--with-ld=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/ld
--with-as=/usr/i686-pc-linux-gnu/binutils-bin/2.16.1/as
--host=i686-pc-linux-gnu
Thread model: posix
gcc version 4.1.0
Best
Kai-Uwe Bux
--
Summary: Internal error: Segmentation fault (program cc1plus)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkherciueh at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28475
[Bug c/28473] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-25 02:12 --- Hmm, this works correctly on powerpc-darwin, where we get no round function at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-07-25 01:55 --- Fixed on mainline, 4.1 branch, and 4.0 branch. Some of the testcases still crash, but they crash in get_innermost_template_args. This problem is tracked in PR 27397. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-25 01:06 --- Subject: Bug 27572 Author: reichelt Date: Tue Jul 25 01:06:15 2006 New Revision: 115731 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115731 Log: PR c++/27572 * decl.c (grokdeclarator): Return error_mark_node after invalid typedef. * g++.dg/other/typedef1.C: New test. * g++.dg/template/typedef4.C: New test. * g++.dg/template/typedef5.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/typedef1.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/typedef4.C branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/typedef5.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-25 01:02 --- Subject: Bug 27572 Author: reichelt Date: Tue Jul 25 01:02:08 2006 New Revision: 115730 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115730 Log: PR c++/27572 * decl.c (grokdeclarator): Return error_mark_node after invalid typedef. * g++.dg/other/typedef1.C: New test. * g++.dg/template/typedef4.C: New test. * g++.dg/template/typedef5.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/typedef1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/typedef4.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/typedef5.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-25 00:57 --- Subject: Bug 27572 Author: reichelt Date: Tue Jul 25 00:57:10 2006 New Revision: 115729 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115729 Log: PR c++/27572 * decl.c (grokdeclarator): Return error_mark_node after invalid typedef. * g++.dg/other/typedef1.C: New test. * g++.dg/template/typedef4.C: New test. * g++.dg/template/typedef5.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/typedef1.C trunk/gcc/testsuite/g++.dg/template/typedef4.C trunk/gcc/testsuite/g++.dg/template/typedef5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #10 from hjl at lucon dot org 2006-07-25 00:36 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01048.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
--- Comment #3 from fjahanian at apple dot com 2006-07-24 23:16 ---
gcc generates two separate trees for compound literals in c and c++. As in this
test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
In c it generates compound_literal_expr and in c++ it generates target_expr.
But gimplifier treats them differently in the following areas:
1) in routine mostly_copy_tree_v we don;t copy target_expr but we do copy
compound_literal_expr. I see the following comment there:
/ * Similar to copy_tree_r() but do not copy SAVE_EXPR or TARGET_EXPR
nodes.
These nodes model computations that should only be done once. If we
were to unshare something like SAVE_EXPR(i++), the gimplification
process would create wrong code. */
Shouldn't compound_literal_expr be treated same as target_expr here?
2) gimplify_target_expr can be called more than once on the same target_expr
node because first time around its TARGET_EXPR_INITIAL is set to NULL.
This works as a guard and prevents its temporary to be added to the
temporary list more than once (when call is made to gimple_add_tmp_var).
On the other hand, such a guard does not exist for a compound_literal_expr
and when gimple_add_tmp_var is called, it asserts. So, I added check for
!DECL_SEEN_IN_BIND_EXPR_P (decl) in gimplify_compound_literal_expr before
call to gimple_add_tmp_var is made. As in the following diff:
% svn diff c-gimplify.c
Index: c-gimplify.c
===
--- c-gimplify.c(revision 116462)
+++ c-gimplify.c(working copy)
@@ -538,7 +538,7 @@
/* This decl isn't mentioned in the enclosing block, so add it to the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else is. */
- if (DECL_NAME (decl) == NULL_TREE)
+ if (DECL_NAME (decl) == NULL_TREE && !DECL_SEEN_IN_BIND_EXPR_P (decl))
gimple_add_tmp_var (decl);
This fixes the problem I am encouterring as well as the test case in this PR.
--
fjahanian at apple dot com changed:
What|Removed |Added
CC||fjahanian at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.2.0 Version|4.1.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-24 22:13 --- Created an attachment (id=11932) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11932&action=view) Don't prune options that can be "Joined" Seems to me like pruning Joined options is always wrong. But, HJ, since you're more into this option stuff and you caused the bug, I suppose you can tell whether my patch makes sense... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug c/28473] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #2 from pinskia at physics dot uc dot edu 2006-07-24 22:01 --- Subject: Re: New: with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX > > When compiling with -O or greater optimization, and if x > INT_MAX, then code > like this: > uint64_t y = (uint64_t)round(x); > assigns the wrong value to y (the top 32 bits are all 1s). But this code > assigns the right value to z: > double dz = round(x); > uint64_t z = dz; > > It almost seems as if gcc -O in some cases compiles using a built-in > declaration of round() that returns a 32-bit int. Yes this is wrong code, GCC is generating for some reason lround instead of llround. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
Re: [Bug c/28473] New: with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
> > When compiling with -O or greater optimization, and if x > INT_MAX, then code > like this: > uint64_t y = (uint64_t)round(x); > assigns the wrong value to y (the top 32 bits are all 1s). But this code > assigns the right value to z: > double dz = round(x); > uint64_t z = dz; > > It almost seems as if gcc -O in some cases compiles using a built-in > declaration of round() that returns a 32-bit int. Yes this is wrong code, GCC is generating for some reason lround instead of llround. Thanks, Andrew Pinski
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-24 21:51 --- HJ definitely caused this bug: Starting program: /home/steven/devel/build-trunk-test/gcc/xgcc -B. -fno-builtin-iswalpha -fno-builtin-iswalnum -S b.c Breakpoint 2, main (argc=6, argv=0x7fc7bbb8) at gcc.c:6096 6096 prune_options (&argc, &argv); (gdb) p argc $10 = 6 (gdb) p argv[0] $11 = 0x7fc7def0 "/home/steven/devel/build-trunk-test/gcc/xgcc" (gdb) p argv[1] $12 = 0x7fc7df1d "-B." (gdb) p argv[2] $13 = 0x7fc7df21 "-fno-builtin-iswalpha" (gdb) p argv[3] $14 = 0x7fc7df37 "-fno-builtin-iswalnum" (gdb) p argv[4] $15 = 0x7fc7df4d "-S" (gdb) p argv[5] $16 = 0x7fc7df50 "b.c" (gdb) next 6104 unlock_std_streams (); (gdb) p argc $17 = 5 (gdb) p argv[0] $18 = 0x7fc7def0 "/home/steven/devel/build-trunk-test/gcc/xgcc" (gdb) p argv[1] $19 = 0x7fc7df1d "-B." (gdb) p argv[2] $20 = 0x7fc7df37 "-fno-builtin-iswalnum" (gdb) p argv[3] $21 = 0x7fc7df4d "-S" (gdb) p argv[4] $22 = 0x7fc7df50 "b.c" (gdb) p argv[5] $23 = 0x0 (gdb) So prune_options prunes too much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug fortran/21143] cross-built gfortran installed as gfortran
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:47 --- I think this one is now fixed, at least on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[Bug driver/28437] [4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-24 21:47 --- Not an FSF GCC 4.1 bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.0 |4.0.0 4.1.1 Summary|[4.1/4.2 Regression]|[4.2 Regression] multiple |multiple fno-builtin-* flags|fno-builtin-* flags broken |broken | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug driver/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #6 from steven at gcc dot gnu dot org 2006-07-24 21:46 --- Also works with "GCC: (GNU) 4.1.2 20060724 (prerelease)", but fails with "GCC: (GNU) 4.2.0 20060723 (experimental)". So my guess is: HJ, no your patch is not in the FSF GCC 4.1 but it is in the Debian GCC 4.1. And I agree with Andrew that your patch is the first suspect for causing the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug fortran/24866] internal compiler error
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:30 --- This one is still here, segfaulting or giving incorrect error message depending on the optimization level used for building the front-end. We enter write_symbol1 with p->u.rsym->sym.name = "sub_module", we go to p->right->u.rsym->sym.name which is "str" and then p->right->left->u.rsym->sym.name is "UCS-2BE//", which suddenly doesn't make sense :) I know you're on vacation, Paul, but I think what looks troubling to us would look trivial to you, friendly as you are with the module code in gfortran! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||paulthomas2 at wanadoo dot ||fr Last reconfirmed|2006-05-21 20:37:51 |2006-07-24 21:30:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24866
[Bug java/28474] mangle_name.c mangles names unecessarily
--- Comment #1 from gcc-bugzilla at seibutsu dot mailsnare dot net 2006-07-24 21:07 --- Created an attachment (id=11931) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11931&action=view) patch to reset uuU variable when a non-underscore is encountered -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28474
[Bug java/28474] New: mangle_name.c mangles names unecessarily
There is a bug in mangle_name.c which leads to mangling any name containing two
underscores followed by a capital "U", even if those three characters are not
consecutive. For example, the following program will not link:
[begin Test.java]
public class Test {
public static final native void x_y_NewUser();
public static final native void xy__User();
public static void main(String[] args) {
x_y_NewUser();
xy__User();
}
}
[end Test.java]
[begin natTest.cpp]
#include "Test.h"
void Test::x_y_NewUser() {
return;
}
void Test::xy__User() {
return;
}
[end natTest.cpp]
I will attach a patch which fixes the first case but not the second (since I'm
not sure how the second case was intended to be handled).
--
Summary: mangle_name.c mangles names unecessarily
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at seibutsu dot mailsnare dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28474
[Bug fortran/28129] gfortran -fbounds-check: Shows invalid array out of bounds error
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:04 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.2 | Known to work|4.2.0 |4.2.0 4.1.2 Resolution||FIXED Summary|[4.1 only] gfortran - |gfortran -fbounds-check: |fbounds-check: Shows invalid|Shows invalid array out of |array out of bounds error |bounds error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
[Bug fortran/27874] Bad interaction between bounds checking, forall and derived types
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:04 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.2 | Known to work|4.2.0 |4.2.0 4.1.2 Resolution||FIXED Summary|[4.1 only] Bad interaction |Bad interaction between |between bounds checking,|bounds checking, forall and |forall and derived types|derived types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27874
[Bug fortran/20892] dummy procedure can't be generic
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:03 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.2 | Known to work|4.2.0 |4.2.0 4.1.2 Resolution||FIXED Summary|[4.1 only] dummy procedure |dummy procedure can't be |can't be generic|generic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20892
[Bug fortran/27874] [4.1 only] Bad interaction between bounds checking, forall and derived types
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:02 --- Subject: Bug 27874 Author: fxcoudert Date: Mon Jul 24 21:02:39 2006 New Revision: 115722 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115722 Log: PR fortran/28129 * trans-array.c (gfc_trans_array_bound_check): Add a locus argument, and use it in the error messages. (gfc_conv_array_index_offset): Donc perform bounds checking on the last dimension of assumed-size arrays. * gfortran.dg/bounds_check_4.f90: New test. PR fortran/27874 * trans-stmt.c (compute_inner_temp_size): Don't perform bounds checking when calculating the bounds of scalarization. PR fortran/20892 * interface.c (gfc_match_interface): Don't allow dummy procedures to have a generic interface. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_check_4.f90 - copied unchanged from r115231, trunk/gcc/testsuite/gfortran.dg/bounds_check_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27874
[Bug fortran/28129] [4.1 only] gfortran -fbounds-check: Shows invalid array out of bounds error
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:02 --- Subject: Bug 28129 Author: fxcoudert Date: Mon Jul 24 21:02:39 2006 New Revision: 115722 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115722 Log: PR fortran/28129 * trans-array.c (gfc_trans_array_bound_check): Add a locus argument, and use it in the error messages. (gfc_conv_array_index_offset): Donc perform bounds checking on the last dimension of assumed-size arrays. * gfortran.dg/bounds_check_4.f90: New test. PR fortran/27874 * trans-stmt.c (compute_inner_temp_size): Don't perform bounds checking when calculating the bounds of scalarization. PR fortran/20892 * interface.c (gfc_match_interface): Don't allow dummy procedures to have a generic interface. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_check_4.f90 - copied unchanged from r115231, trunk/gcc/testsuite/gfortran.dg/bounds_check_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
[Bug fortran/20892] [4.1 only] dummy procedure can't be generic
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-24 21:02 --- Subject: Bug 20892 Author: fxcoudert Date: Mon Jul 24 21:02:39 2006 New Revision: 115722 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115722 Log: PR fortran/28129 * trans-array.c (gfc_trans_array_bound_check): Add a locus argument, and use it in the error messages. (gfc_conv_array_index_offset): Donc perform bounds checking on the last dimension of assumed-size arrays. * gfortran.dg/bounds_check_4.f90: New test. PR fortran/27874 * trans-stmt.c (compute_inner_temp_size): Don't perform bounds checking when calculating the bounds of scalarization. PR fortran/20892 * interface.c (gfc_match_interface): Don't allow dummy procedures to have a generic interface. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/bounds_check_4.f90 - copied unchanged from r115231, trunk/gcc/testsuite/gfortran.dg/bounds_check_4.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/interface.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20892
[Bug c/28473] with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
--- Comment #1 from maxp at alum dot mit dot edu 2006-07-24 20:54 --- Created an attachment (id=11930) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11930&action=view) preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug c/28473] New: with -O, casting result of round(x) to uint64_t produces wrong values for x > INT_MAX
When compiling with -O or greater optimization, and if x > INT_MAX, then code
like this:
uint64_t y = (uint64_t)round(x);
assigns the wrong value to y (the top 32 bits are all 1s). But this code
assigns the right value to z:
double dz = round(x);
uint64_t z = dz;
It almost seems as if gcc -O in some cases compiles using a built-in
declaration of round() that returns a 32-bit int.
(1) GCC VERSION
gavia% gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
This is on Fedora Core 5. Same problem occurs with gcc 4.0.2 on FC4.
(2) COMMAND LINE, COMPILER OUTPUT, AND PROGRAM OUTPUT
gavia% gcc -Wall -std=c99 -O -save-temps -o x-opt x.c -lm
gavia% ./x-opt
x: 2147483648
y: 18446744071562067968
z: 2147483648
(3) C SOURCE
#include
#include
#include
int main(int c, char **v)
{
uint64_t x = 2147483648ULL; /* INT_MAX+1 */
printf("x: %llu\n", x);
uint64_t y = (uint64_t)round(x);
printf("y: %llu\n", y);
double dz = round(x);
uint64_t z = dz;
printf("z: %llu\n", z);
return 0;
}
(4) PREPROCESSED FILE
Included as attachment.
--
Summary: with -O, casting result of round(x) to uint64_t produces
wrong values for x > INT_MAX
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maxp at alum dot mit dot edu
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28473
[Bug driver/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #5 from steven at gcc dot gnu dot org 2006-07-24 20:52 --- Works with "GCC: (GNU) 4.1.1 20060518 (prerelease)". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-07-24 20:23 --- Created an attachment (id=11929) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11929&action=view) current status of patch This is the current status of the patch. As I wrote, this isn't yet complete. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #11926|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug java/28458] [ecj] Fails to build gnu.awt.LightweightRedirector
--- Comment #6 from gnu_andrew at member dot fsf dot org 2006-07-24 20:16 --- Does your compiled version of java.lang.Class contain a field class$0? This is what me and Tom narrowed the problem down to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28458
[Bug fortran/28416] ICE on allocatable codes
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-07-24 20:16 --- Subject: Bug 28416 Author: eedelman Date: Mon Jul 24 20:15:59 2006 New Revision: 115721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115721 Log: fortran/ 2006-07-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/28416 * trans-array.c (gfc_conv_array_parameter): Give special treatment for ALLOCATABLEs if they are themselves dummy variables. testsuite/ 2006-07-24 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/28416 * gfortran.dg/allocatable_dummy_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_dummy_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-07-24 20:12 --- (In reply to comment #4) > Don't you need a HAVE_GFC_REAL_16 section or is random_r10 used > for random_r16? Oops, I uploaded the wrong patch. Sorry 'bout that. However, I still need to think a bit about what constant to multiply with. What I currently have could also return 1. > > Also, I noticed that you've eliminated the normalize_* calls. > I think may actually be able to remove these functions and > the file that contains them. Correct. I would also have to remove the call to normalize_* from rand.c. Looks like a bit more work to be done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug bootstrap/28469] stage2 error: toplev.c redefines floor_log2
--- Comment #3 from gin at mo dot msk dot ru 2006-07-24 19:52 --- Subject: Re: stage2 error: toplev.c redefines floor_log2 On other system where that translation module compiles normally there are also 2 definitions of the same function, but even function type declarations in definitions are quite different. This certainly may have something to do with system headers. Have to suspect this, despite both conflicting function definitions gcc complains about are in gcc own code. If it so widely known to be caused by broken with kernel headers, that a description of these headers bug is published, please post a pointer to that description. There may be a patch that can easily be applied without rebuilding and reinstalling the full core system packages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28469
[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name with vectorizer
--- Comment #18 from patchapp at dberlin dot org 2006-07-24 19:50 --- Subject: Bug number PR26197 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
[Bug fortran/28465] [gomp] Statically linked OpenMP Fortran programs cause segment fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-24 19:46 --- This is a bug in glibc with TLS and static linking. It has been fixed already in newer glibcs. -- 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=28465
[Bug bootstrap/28469] stage2 error: toplev.c redefines floor_log2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-24 19:42 --- This is a bug in the kernel headers which have been fixed in a newer kernel. -- 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=28469
[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-07-24 19:41 --- *** Bug 28470 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gin at mo dot msk dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9079
[Bug c/28470] does not inline constant funargs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-24 19:41 --- *** This bug has been marked as a duplicate of 9079 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28470
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #9 from wilson at tuliptree dot org 2006-07-24 19:34 --- Subject: Re: [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips On Sat, 2006-07-22 at 14:14, echristo at apple dot com wrote: > --- Comment #7 from echristo at apple dot com 2006-07-22 21:14 --- > Jim, were you going to check this in or did you need some more testing on it? I haven't had time to test it yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #14 from raj dot khem at gmail dot com 2006-07-24 19:34 --- FWIW. I also have it working using current 4.1 branch snapshot and the patch in comment #8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug fortran/28443] gfortran does not implement the present intrinsic procedure correctly for optional character strings
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28443
[Bug fortran/28465] [gomp] Statically linked OpenMP Fortran programs cause segment fault
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-24 19:29 --- > All statically linked OpenMP Fortran programs cause segment fault when > executed > on i686-pc-linux-gnu platform. To help making further progress on this PR, could you report the different glibc version numbers on which you experienced that bug? It works fine for me with RedHat's glibc-2.4-8 and Debian testing glibc 2.3. $ cat hello.f PROGRAM HELLO INTEGER NTHREADS, TID, OMP_GET_NUM_THREADS, +OMP_GET_THREAD_NUM C Fork a team of threads giving them their own copies of variables !$OMP PARALLEL PRIVATE(NTHREADS, TID) C Obtain thread number TID = OMP_GET_THREAD_NUM() PRINT *, 'Hello World from thread = ', TID C Only master thread does this IF (TID .EQ. 0) THEN NTHREADS = OMP_GET_NUM_THREADS() PRINT *, 'Number of threads = ', NTHREADS END IF C All threads join master thread and disband !$OMP END PARALLEL END quatramaran /tmp $ ./irun/bin/gfortran -static hello.f -fopenmp quatramaran /tmp $ file ./a.out ./a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, statically linked, for GNU/Linux 2.4.1, not stripped $ OMP_NUM_THREADS=4 ./a.out Hello World from thread =0 Number of threads =4 Hello World from thread =1 Hello World from thread =2 Hello World from thread =3 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28465
[Bug c/28471] Error durin run make
--- Comment #2 from ivan at lasertech dot com dot br 2006-07-24 19:08 --- Sorry, my error -- ivan at lasertech dot com dot br changed: What|Removed |Added Severity|critical|minor Status|UNCONFIRMED |RESOLVED GCC host triplet| i386-conectiva-linux-gnu |i386-conectiva-linux-gnu Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28471
[Bug bootstrap/28469] stage2 error: toplev.c redefines floor_log2
--- Comment #1 from pinskia at physics dot uc dot edu 2006-07-24 18:07 --- Subject: Re: New: stage2 error: toplev.c redefines floor_log2 > > > > When executing `make bootstrap', the following error occurs. > > stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g > -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -DHAVE_CONFIG_H -I. -I. > -I../../share/src/gcc-4.0.3/gcc -I../../share/src/gcc-4.0.3/gcc/. > -I../../share/src/gcc-4.0.3/gcc/../include > -I../../share/src/gcc-4.0.3/gcc/../libcpp/include \ > -DTARGET_NAME=\"i686-pc-linux-gnu\" \ > -c ../../share/src/gcc-4.0.3/gcc/toplev.c -o toplev.o > ../../share/src/gcc-4.0.3/gcc/toplev.c: In function 'toplev_main': > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1713: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1717: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1719: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1723: sorry, unimplemented: called from > here > make[2]: *** [toplev.o] Error 1 This is a bug in the kernel headers which have been fixed in a newer kernel already. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28469
Re: [Bug bootstrap/28469] New: stage2 error: toplev.c redefines floor_log2
> > > > When executing `make bootstrap', the following error occurs. > > stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g > -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -DHAVE_CONFIG_H -I. -I. > -I../../share/src/gcc-4.0.3/gcc -I../../share/src/gcc-4.0.3/gcc/. > -I../../share/src/gcc-4.0.3/gcc/../include > -I../../share/src/gcc-4.0.3/gcc/../libcpp/include \ > -DTARGET_NAME=\"i686-pc-linux-gnu\" \ > -c ../../share/src/gcc-4.0.3/gcc/toplev.c -o toplev.o > ../../share/src/gcc-4.0.3/gcc/toplev.c: In function 'toplev_main': > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1713: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1717: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1719: sorry, unimplemented: called from > here > ../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining > failed in call to 'floor_log2': redefined extern inline functions are not > considered for inlining > ../../share/src/gcc-4.0.3/gcc/toplev.c:1723: sorry, unimplemented: called from > here > make[2]: *** [toplev.o] Error 1 This is a bug in the kernel headers which have been fixed in a newer kernel already. -- Pinski
[Bug bootstrap/28472] New: -B$(build_tooldir)/bin/
Some targets in `gcc/Makefile.in' built while `make bootstrap' specify `-B$(build_tooldir)/bin/'. All of this is done when nothing from gcc being built is installed in that directory yet. What is installed there, if any, generally has nothing to do with gcc at all. It may easily be files from older compiler version. Using them may do only harm. In this gcc version this is exactly the same in all build configurations on and for all systems. Detailed system description is irrelevant, leaving it empty. Environment: System: Architecture: host: build: target: configured with: How-To-Repeat: make bootstrap --- Comment #1 from gin at mo dot msk dot ru 2006-07-24 18:01 --- Fix: If in some build configurations bootstrap compiler must use some external software and find it though additional `-B' option, need a cleaner way to specify list of such `-B' options for these configurations. And leave it empty by default. -- Summary: -B$(build_tooldir)/bin/ Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28472
[Bug c/28471] Error durin run make
--- Comment #1 from ivan at lasertech dot com dot br 2006-07-24 17:49 --- Created an attachment (id=11928) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11928&action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28471
[Bug c/28471] New: Error durin run make
gcc command line: - gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I./zziplib -I./mspack -g -O2 -MT pe.lo -MD -MP -MF .deps/pe.Tpo -c pe.c -fPIC -DPIC -o .libs/pe.lo error: -- pe.c: In function `cli_scanpe': pe.c:1552: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. gcc -v -save-temps: - Reading specs from /usr/lib/gcc-lib/i386-conectiva-linux/3.2.2/specs Configured with: /usr/src/rpm/BUILD/gcc-3.2.2/configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --enable-shared --enable-threads=posix --enable-haifa --enable-libgcj --enable-languages=c,c++,f77,objc,java --with-system-zlib --with-gxx_include_dir=/usr/include/c++/3.2.2 --host=i386-conectiva-linux Thread model: posix gcc version 3.2.2 -- Summary: Error durin run make Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ivan at lasertech dot com dot br GCC build triplet: i386-conectiva-linux-gnu GCC host triplet: i386-conectiva-linux-gnu GCC target triplet: i386-conectiva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28471
[Bug c/28470] New: does not inline constant funargs
Observing it at least on stage 1 compiler, and exactly the same way as
in 3.3.2.
If inline function, later called a functional, is passed a function
argument that is constant and inline, and said argument is called in
the functional body, and when inline expansions are on, compiler
expand inline only said functional, but not function argument calls in
said expansion. Instead, it handles these calls just like those of
non- inline function, that is, outputs uninlined function body and
call instruction of that body, with all call overhead.
If argument is a nested function, 4.0.3 behaves a bit better than
3.3.2. It does not output full trampoline code unnecessarily.
Priority? How should I know? Depends on projects using the compiler.
Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c
How-To-Repeat:
Compile with `-O99'. `do_it_cb' code is output as a separate funtion,
and code output for `do_it_with_g_set_v0' calls `do_it_cb', not
`do_it'.
extern int g_set_v0 (void);
extern void g_restore_v (int);
extern void do_it (void);
static inline
with_g_set_v0 (void (f) (void))
{
int v = g_set_v0 ();
f ();
g_restore_v (v);
}
static inline void
do_it_cb (void)
{
do_it ();
}
void
do_it_with_g_set_v0 (void)
{
with_g_set_v0 (do_it_cb);
}
--
Summary: does not inline constant funargs
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
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=28470
[Bug bootstrap/28469] New: stage2 error: toplev.c redefines floor_log2
When executing `make bootstrap', the following error occurs.
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -DHAVE_CONFIG_H -I. -I.
-I../../share/src/gcc-4.0.3/gcc -I../../share/src/gcc-4.0.3/gcc/.
-I../../share/src/gcc-4.0.3/gcc/../include
-I../../share/src/gcc-4.0.3/gcc/../libcpp/include \
-DTARGET_NAME=\"i686-pc-linux-gnu\" \
-c ../../share/src/gcc-4.0.3/gcc/toplev.c -o toplev.o
../../share/src/gcc-4.0.3/gcc/toplev.c: In function 'toplev_main':
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1713: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1717: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1719: sorry, unimplemented: called from
here
../../share/src/gcc-4.0.3/gcc/toplev.c:548: sorry, unimplemented: inlining
failed in call to 'floor_log2': redefined extern inline functions are not
considered for inlining
../../share/src/gcc-4.0.3/gcc/toplev.c:1723: sorry, unimplemented: called from
here
make[2]: *** [toplev.o] Error 1
Will post full preprocessed code on request. It actually contains the
`floor_log2' declarations in order as follows. Describing their line
numbers in the same way as preprocessor does.
# 168 "../../share/src/gcc-4.0.3/gcc/toplev.h"
extern int floor_log2 (unsigned long);
# 183 "../../share/src/gcc-4.0.3/gcc/toplev.h"
extern __inline__ __attribute__((always_inline)) __attribute__((always_inline))
int
floor_log2 (unsigned long x)
{
/* skipping */
# 546 "../../share/src/gcc-4.0.3/gcc/toplev.c"
int
floor_log2 (unsigned long x)
{
Inline definition in `toplev.h' is not output by preprocessor with
older gcc versions, including that of old / stage 1 compiler.
Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686
Old compiler is `gcc-3.3.2-6mdk'. On stage 1 `GCC_VERSION' numeric
value is 3003.
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c
How-To-Repeat:
make bootstrap
--
Summary: stage2 error: toplev.c redefines floor_log2
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
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=28469
[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #5 from pluto at agmk dot net 2006-07-24 17:16 --- *** Bug 28459 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug c++/28459] bogus diagnostic / format '%p' expects type 'void*', but argument has type 'void (x::*)()';
--- Comment #1 from pluto at agmk dot net 2006-07-24 17:16 --- oops, duplicated, sorry. *** This bug has been marked as a duplicate of 26542 *** -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28459
[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #4 from vz-gcc at zeitlins dot org 2006-07-24 17:02 --- I'd like to (probably uselessly but still) argue for reopening this bug and removing this warning. The interpretation of the standard text is open to questions: IMHO an "A *" pointer is a pointer to void, too, as any pointer in C is, implicitely, pointer to void. But most importantly I think this warning is absolutely useless and the only way to get rid of it is ugly (you need an explicit cast to "void *"). But, again, the most important argument against this warning is that it's 100% useless. Conversion of any pointer to "void *" is well defined and unambiguous (even in presence of multiple inheritance) and there is just no situation whatsoever in which this warning can indicate a real problem. Please consider suppressing it, thanks in advance! -- vz-gcc at zeitlins dot org changed: What|Removed |Added CC||vz-gcc at zeitlins dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug fortran/28439] [4.1 only] Multiple evaluations of arithmetic if condition
--- Comment #10 from kargl at gcc dot gnu dot org 2006-07-24 16:54 --- Subject: Bug 28439 Author: kargl Date: Mon Jul 24 16:54:01 2006 New Revision: 115718 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115718 Log: 2006-07-24 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/28439 * gfortran.dg/arithmetic_if.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/arithmetic_if.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28439
[Bug driver/28437] [4.1/4.2 Regression] multiple fno-builtin-* flags broken
--- Comment #4 from hjl at lucon dot org 2006-07-24 15:42 --- Is my patch in 4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28437
[Bug c++/21615] Argument-dependent name lookup associated namespace search bug
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-24 15:33 --- (In reply to comment #3) > It would have been so say in case of int. There is a defect report about the case of int anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21615
[Bug c++/21615] Argument-dependent name lookup associated namespace search bug
--- Comment #3 from hbgku6602 at sneakemail dot com 2006-07-24 15:30 --- (In reply to comment #1) > All gcc versions I have take the template in namespace odd, and so does > icc in strict mode. I see nothing in 3.4.2 that should prevent this > from happening. What is relevant here is that the using declaration inside > the function introduces a name into the innermost namespace, thus preventing > name lookup from even looking outside the function. It would have been so say in case of int. But since A is a class-type, it has associated namespace odd, and according to 3.4.2/2a odd::f will be included in the set of declarations regardless of visibility of odd::f by ordinary rules. 3.4.2/1 "When an unqualified name is used as the postfix-expression in a function call (5.2.2), other namespaces not considered during the usual unqualified lookup (3.4.1) may be searched, and namespace-scope friend function declarations (11.4) not otherwise visible may be found." 3.4.2/2a "If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associated namespaces and classes are not considered. Otherwise the set of declarations found by the lookup of the function name is the union of the set of declarations found using ordinary unqualified lookup and the set of declarations found in the namespaces and classes associated with the argument types." -- hbgku6602 at sneakemail dot com changed: What|Removed |Added CC||hbgku6602 at sneakemail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21615
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #13 from edmar at freescale dot com 2006-07-24 15:05 --- For my part (e500v2) it works just fine. I have being using since april for my regression tests. As Andrew posted, the question is the impact on other targets... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug libgomp/28468] New: OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
Versions:
* gcc: gcc (GCC) 4.2.0 20060715 (experimental)
* cpu: AMD-K7 (i686)
* kernel: Linux 2.4.21-99 (SuSE 9.0)
* glibc: glibc-2.3.6 built with LinuxThreads, _not_ NPTL
Test program:
== omp-test1.c ===
#include
#include
/* A computational task whose duration depends on x. */
int job (int x)
{
int j = rand() % (100 + 10 * x);
int i;
for (i = j - 1; i > 0; i--)
if (j % i == 0)
break;
return i;
}
int main (int argc, char *argv[])
{
int n = 1;
int *mem = malloc (n * sizeof (int));
int i;
/* Because the tasks don't have all the same duration, a dynamic
schedule is best. */
#pragma omp parallel for schedule(dynamic)
for (i = 0; i < n; i++)
mem[i] = job (i);
for (i = 0; i < n; i++)
printf ("mem[%d] = %d\n", i, mem[i]);
return 0;
}
=
$ gcc -fopenmp -Wall -O omp-test1.c
The single-threaded program runs fine:
$ unset OMP_NUM_THREADS; ./a.out
or
$ export OMP_NUM_THREADS=1; ./a.out
But with more than one thread it crashes:
$ export OMP_NUM_THREADS=2; ./a.out
Segmentation fault (core dumped)
$ gdb a.out core.26661
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/gfs/ibook/Volumes/ExtData/bin.x86-linux/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1...done.
Loaded symbols for
/packages/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/iter.c:189
189 start = ws->next;
(gdb) where
#0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/iter.c:189
#1 0x4001c8e8 in gomp_loop_dynamic_next (istart=0xbfffe9c4, iend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/loop.c:248
#2 0x080486ed in main.omp_fn.0 ()
#3 0x0804861e in main ()
(gdb) print ws
$1 = (struct gomp_work_share *) 0x0
--
Summary: OpenMP-parallelized program crashes when OMP_NUM_THREADS
> 1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-suse-linux-gnu
GCC host triplet: i686-suse-linux-gnu
GCC target triplet: i686-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug c++/27572] [4.0/4.1/4.2 regression] ICE on typedef in parameter declaration
--- Comment #2 from patchapp at dberlin dot org 2006-07-24 14:15 --- Subject: Bug number PR c++/27572 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01036.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27572
[Bug bootstrap/28466] Cannot build inside an object tree with name including :
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-24 13:36 --- It could detect it early during configure maybe. Other than that I agree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28466
[Bug bootstrap/28466] Cannot build inside an object tree with name including :
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-24 13:35 --- I don't think there is anything GCC can do about this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28466
[Bug middle-end/28467] Internal compiler error (ICE) with segmentation fault for valid C++ test case
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28467
[Bug c++/28467] Internal compiler error (ICE) with segmentation fault for valid C++ test case
--- Comment #1 from prafullat at kpitcummins dot com 2006-07-24 12:54 --- Created an attachment (id=11927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11927&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28467
[Bug c++/28467] New: Internal compiler error (ICE) with segmentation fault for valid C++ test case
Hi,
I am working on a SH port with Gcc-3.4.5, and I am getting Internal Compiler
Error( Segmentation Fault).
I have inlcuded a CPP test case that helps to reproduce this bug on
Fedora Core 2 when compiled with optimization option "-O2".
I have debugged the Gcc code for this particular test case and found that
in function 'fixup_match_2()' from file 'regmove.c', Gcc is trying to access
'call_used_regs' with in-valid index (i.e. pseudo register).
Please refer to following code from 'regmove.c'.
/
if (call_used_regs[REGNO(dst)])
|| find_reg_fusage (p, CLOBBER, dst))
break;
/
Here, I have noticed that, when the attached CPP test case is compiled with
optimization option "-O2", the "REGNO(dst)" returns pseudo register value
(i.e. 24647).
Therefore, on some OS platform like "Fedora Core 2", the above check results
into segmentation fault.
Please note that, 'segmentation fault' may not occur on some other OS as the
memory read requested by above check may fall within the allocated memory
space for executable 'cc1plus'.
Please refer to following links, where similar behavior was reported
for Gcc-4.0.2 also.
http://gcc.gnu.org/ml/gcc/2006-03/msg00318.html
The 'call_used_regs' is character array (for hard registers) with maximum size
of
'FIRST_PSEUDO_REGISTER' (i.e. 153 for SH target). Refer to file 'regclass.c'.
I have found a patch which adds a check for array index less than
'FIRST_PSEUDO_REGISTER',
http://gcc.gnu.org/ml/gcc/2005-09/msg00368.html
However, I found that this patch is not accepted.
Kindly let me know whether this patch is right fix for this bug.
Command used:
#sh-linux-gcc -m4 -ml -O2 testcase.cpp -c
Test Case:
///
namespace std
{
template
class allocator;
template
struct char_traits;
template,
typename _Alloc = allocator<_CharT> >
class basic_string;
template<> struct char_traits;
typedef basic_string string;
}
namespace __gnu_cxx
{
template
class new_allocator
{
public:
typedef unsigned int size_type;
new_allocator() throw() { }
new_allocator(const new_allocator&) throw() { }
~new_allocator() throw() { }
};
}
namespace std
{
template
class allocator: public __gnu_cxx::new_allocator<_Tp>
{
public:
template
struct rebind
{};
};
}
namespace __gnu_cxx
{
int
__attribute__ ((__unused__))
__exchange_and_add(volatile int* __mem, int __val);
void
__attribute__ ((__unused__))
__atomic_add(volatile int* __mem, int __val);
}
namespace std
{
template
class basic_string
{
public:
typedef typename _Alloc::size_type size_type;
private:
struct _Rep_base
{
size_type _M_length;
size_type _M_capacity;
int _M_refcount;
};
struct _Rep : _Rep_base
{
static size_type _Se_r_p[];
static _Rep&
_S_empty_rep()
{ return *reinterpret_cast<_Rep*>(&_Se_r_p); }
_CharT*
_M_refdata() throw()
{ return reinterpret_cast<_CharT*>(this + 1); }
void
_M_dispose(const _Alloc& __a)
{
if (__builtin_expect(this != &_S_empty_rep(), false))
if (__gnu_cxx::__exchange_and_add(&this->_M_refcount, -1) <= 0)
_M_destroy(__a);
}
void
_M_destroy(const _Alloc&) throw();
};
struct _Alloc_hider : _Alloc
{
_Alloc_hider(_CharT* __dat, const _Alloc& __a)
: _Alloc(__a), _M_p(__dat) { }
_CharT* _M_p;
};
private:
mutable _Alloc_hider _M_dataplus;
_CharT*
_M_data() const
{ return _M_dataplus._M_p; }
_Rep*
_M_rep() const
{ return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }
static _Rep&
_S_empty_rep()
{ return _Rep::_S_empty_rep(); }
public:
inline
basic_string();
~basic_string()
{ _M_rep()->_M_dispose(this->get_allocator()); }
_Alloc
get_allocator() const { return _M_dataplus; }
};
template
inline basic_string<_CharT, _Traits, _Alloc>::
basic_string()
: _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
}
class CAbcDebugLog
{
public:
};
class My_Id
{
public:
bool IsValid() const;
};
namespace abc{
enum ME_IS
{
PST,
};
}
namespace abc {
enum UI_ERROR
{
};
}
namespace abc {
enum MY_CODE{};
}
class Two_up
{
public:
bool CanCO(const My_Id &id, const abc::MY_CODE &tgtMw, abc::UI_ERROR &err);
bool RemainCOCount( const My_Id &id, unsigned char & count );
bool IsIt( const My_Id& a1, const My_Id& a2 );
};
namespace std
{
template
struct _Vector_base
{
struct _Vector_impl: public _Alloc {
};
};
template >
class vector : protected _Vector_base<_Tp, _Alloc>
{};
}
using namespace std;
//class CCstrCommon {};
class CCstr {
private:
//
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #21 from hubicka at gcc dot gnu dot org 2006-07-24 11:54 --- OK, some summary ;) Mainline (after the first three patches) at -O now peaks 450MB (just because of register allocator's conflict matrix, otherwise it is about 150MB). Still not quite icc's 12 seconds/200MB, but we are out of regression land for -O relative to 4.0.I tested 3.0 and it bombs on the testcase, 2.95 however compile it quite fluently on 200MB peak, it needs 6 minutes however. life analysis : 25.92 (16%) usr 0.01 ( 0%) sys 26.18 (15%) wall 2565 kB ( 1%) ggc inline heuristics : 15.15 ( 9%) usr 0.01 ( 0%) sys 15.27 ( 9%) wall 1486 kB ( 1%) ggc integration : 21.37 (13%) usr 0.12 ( 5%) sys 21.66 (13%) wall 33445 kB (19%) ggc tree SSA to normal: 27.73 (17%) usr 0.03 ( 1%) sys 27.93 (16%) wall 17 kB ( 0%) ggc local alloc : 7.33 ( 4%) usr 0.03 ( 1%) sys 7.41 ( 4%) wall 1855 kB ( 1%) ggc global alloc : 13.67 ( 8%) usr 0.73 (32%) sys 15.85 ( 9%) wall 14178 kB ( 8%) ggc reload CSE regs : 30.88 (19%) usr 0.04 ( 2%) sys 31.09 (18%) wall 2393 kB ( 1%) ggc TOTAL : 164.46 2.27 169.53 173593 kB It would be interesting to see how dataflow branch score here after re-merging from mainline. Hopefully integration and register allocation issues should be tracked there. The inliner is still quadratic in time because of quadratic split_block and cgraph_node. Both can be made linear quite easilly (split_block by always renumbering the smaller area of block and cgraph_node by producing hashtables for nodes with many edges), but I am not sure I want to do that for 4.2. Inline heuristics might be trickier to get in speed. I duno about reload. Oprofile might be handy ;) -O2 expose problem in PRE DannyB has fix for. Regmove and into-SSA can also be significantly sped up by patches I attached and will commit them once testing converge. -O3 turns the testcase into quite different one (gigantic basic block is turned into many basic blocks by inlining min/max functions). There few problems are still visible - FRE consume unbounded amount of memory and we fail to synthetize fmin/fmax operators where we ought to. If the FRE problem is fixed, I would say it should no longer be considered as 4.2 blocker. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28463] [4.0/4.1/4.2 Regression] Using -fdump-tree-optimized causes a huge compile time memory regression
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-24 11:43 --- Subject: Bug 28463 Author: rguenth Date: Mon Jul 24 11:42:52 2006 New Revision: 115714 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115714 Log: 2006-07-24 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/28463 * cgraph.c (cgraph_remove_node): Do not check if dumps are enabled. * cgraphunit.c (cgraph_optimize): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28463
[Bug java/28458] [ecj] Fails to build gnu.awt.LightweightRedirector
--- Comment #5 from aph at gcc dot gnu dot org 2006-07-24 11:39 --- Works for me. $ ~/gcc/gcj-eclipse/obj-x86_64-unknown-linux-gnu/gcc/jc1 /tmp/LightweightRedirector.class -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase LightweightRedirector.class -mtune=generic -auxbase-strip gnu/.libs/awt.o -g -O2 -Wno-deprecated -version -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=$HOME/gcc/gcj-eclipse/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/classpath/lib/classes -fPIC -fbootclasspath=./:$HOME/gcc/gcj-eclipse/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/classpath/lib/ -faux-classpath /tmp/ccNqEVSq.zip -o /tmp/cc0NqHDH.s GNU Java version 4.2.0 20060604 (gcj-eclipse experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060604 (gcj-eclipse experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Class path starts here: /tmp/ccNqEVSq.zip/ (zip) ./ (system) /home/aph/gcc/gcj-eclipse/obj-x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/libjava/classpath/lib/ (system) $ -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28458
[Bug bootstrap/28466] New: Cannot build inside an object tree with name including :
because then we hit make[1]: Entering directory `/abuild/rguenther/obj-115527:115528/gcc' ../../gcc-4_1-branch/gcc/fortran/Make-lang.in:134: *** target pattern contains no `%'. Stop. that line looks like html:: $(htmldir)/gfortran/index.html and we have objdir = /abuild/rguenther/obj-115527:115528/gcc htmldir = $(objdir)/HTML/gcc-$(version) -- Summary: Cannot build inside an object tree with name including : Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28466
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #20 from hubicka at gcc dot gnu dot org 2006-07-24 11:28 --- Subject: Bug 28071 Author: hubicka Date: Mon Jul 24 11:27:53 2006 New Revision: 115713 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115713 Log: PR rtl-optimization/28071 * tree-cfg.c (tree_split_block): Do not allocate new stmt_list nodes. * tree-iterator.c (tsi_split_statement_list_before): Do not crash when splitting before first stmt. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-iterator.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #19 from hubicka at gcc dot gnu dot org 2006-07-24 11:24 --- Subject: Bug 28071 Author: hubicka Date: Mon Jul 24 11:23:21 2006 New Revision: 115712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115712 Log: PR rtl-optimization/28071 * ipa-inline.c (update_caller_keys): Remove edges that are no longer inline candidates. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug crypto/27228] java.security.InvalidAlgorithmParameterException
--- Comment #13 from raif at swiftdsl dot com dot au 2006-07-24 10:58 --- i'm marking this FIXED as per Casey's patch. i've also added a Mauve testlet to validate the current codebase: TestOfPR27228 in gnu.testlet.gnu.javax.crypto.jce. -- raif at swiftdsl dot com dot au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
[Bug tree-optimization/28238] [4.1 regression] verify_stmts failed (invalid operand to unary operator)
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-07-24 10:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug tree-optimization/28238] [4.1 regression] verify_stmts failed (invalid operand to unary operator)
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-24 10:28 --- Subject: Bug 28238 Author: rguenth Date: Mon Jul 24 10:27:53 2006 New Revision: 115711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115711 Log: 2006-07-24 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28238 * tree-inline.c (copy_bb): Check if we produced valid gimple copying and substituting a stmt. If not, gimplify it. * g++.dg/tree-ssa/pr28238.C: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr28238.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug java/28458] [ecj] Fails to build gnu.awt.LightweightRedirector
-- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-24 10:13:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28458
[Bug tree-optimization/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-24 08:33 --- Is this now fixed on the mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-07-24 08:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/27639] [4.1 regression] VRP miscompilation of simple loop
--- Comment #31 from rguenth at gcc dot gnu dot org 2006-07-24 08:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/27795] [4.1 Regression] optimizer produces faulty code [tree-vrp]
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-07-24 08:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27795
[Bug tree-optimization/27639] [4.1 regression] VRP miscompilation of simple loop
--- Comment #30 from rguenth at gcc dot gnu dot org 2006-07-24 08:26 --- Subject: Bug 27639 Author: rguenth Date: Mon Jul 24 08:25:57 2006 New Revision: 115709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115709 Log: 2006-07-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/27795 PR tree-optimization/27639 PR tree-optimization/26719 Backport from mainline 2006-05-24 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26719.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr26719.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27639.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr27639.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-chrec.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug tree-optimization/26719] [4.1 Regression] Computed (integer) table changes with -O
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-07-24 08:26 --- Subject: Bug 26719 Author: rguenth Date: Mon Jul 24 08:25:57 2006 New Revision: 115709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115709 Log: 2006-07-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/27795 PR tree-optimization/27639 PR tree-optimization/26719 Backport from mainline 2006-05-24 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26719.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr26719.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27639.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr27639.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-chrec.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
[Bug tree-optimization/27795] [4.1 Regression] optimizer produces faulty code [tree-vrp]
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-24 08:26 --- Subject: Bug 27795 Author: rguenth Date: Mon Jul 24 08:25:57 2006 New Revision: 115709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115709 Log: 2006-07-21 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/27795 PR tree-optimization/27639 PR tree-optimization/26719 Backport from mainline 2006-05-24 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-vrp.c (adjust_range_with_scev): Use scev_direction and adjust call to scev_probably_wraps_p. * tree-ssa-loop-niter.c (compare_trees, convert_step_widening, used_in_pointer_arithmetic_p, convert_step): Removed. (nowrap_type_p): New function. (scev_probably_wraps_p): Rewritten. * tree-scalar-evolution.c (instantiate_parameters_1): Do not call chrec_convert if chrec_convert_aggressive might have been used. * tree-chrec.c (convert_affine_scev, chrec_convert_1, scev_direction): New functions. (chrec_convert): Changed to a wrapper over chrec_convert_1. * tree-ssa-loop-ivopts.c (idx_find_step): Use convert_affine_scev instead of convert_step. * tree-flow.h (scev_probably_wraps_p): Declaration changed. (convert_step): Declaration removed. (convert_affine_scev, nowrap_type_p, scev_direction): Declare. * gcc.dg/pr27639.c: New test. * gcc.dg/pr26719.c: New test. * gcc.dg/tree-ssa/scev-cast.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26719.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr26719.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27639.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/pr27639.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c - copied unchanged from r114057, trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-chrec.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27795
[Bug tree-optimization/28029] [4.1 Regression] wrong optimization with -ftree-vectorize
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-24 08:19 --- Fixed. --- Comment #10 from rguenth at gcc dot gnu dot org 2006-07-24 08:19 --- Subject: Bug 28029 Author: rguenth Date: Mon Jul 24 08:18:51 2006 New Revision: 115708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115708 Log: 2006-07-24 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28029 Backport 2006-02-15 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-alias.c (get_tmt_for): Don't handle TYPE_READONLY specially here. * gcc.dg/vect/pr28029.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/pr28029.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-alias.c -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28029
[Bug tree-optimization/28029] [4.1 Regression] wrong optimization with -ftree-vectorize
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-07-24 08:19 --- Fixed. --- Comment #10 from rguenth at gcc dot gnu dot org 2006-07-24 08:19 --- Subject: Bug 28029 Author: rguenth Date: Mon Jul 24 08:18:51 2006 New Revision: 115708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115708 Log: 2006-07-24 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/28029 Backport 2006-02-15 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-alias.c (get_tmt_for): Don't handle TYPE_READONLY specially here. * gcc.dg/vect/pr28029.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/pr28029.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-alias.c -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28029
[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries
--- Comment #8 from anlauf at gmx dot de 2006-07-24 08:13 --- (In reply to comment #7) > (In reply to comment #6) > > Andy, please show me a testcase that fails on 32bit. > > Any old TLS testcase will do. Also I am not Andy but Andrew. So could you please point me to one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456
[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-24 08:09 --- (In reply to comment #6) > Andy, please show me a testcase that fails on 32bit. Any old TLS testcase will do. Also I am not Andy but Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456
[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries
--- Comment #6 from anlauf at gmx dot de 2006-07-24 08:06 --- (In reply to comment #5) > No, it is still the same bug in glibc even though it is a different target and > 32bit vs 64bit. > > *** This bug has been marked as a duplicate of 28351 *** Andy, please show me a testcase that fails on 32bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #5 from sayle at gcc dot gnu dot org 2006-07-24 07:29 --- Subject: Bug 28247 Author: sayle Date: Mon Jul 24 07:29:46 2006 New Revision: 115707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115707 Log: PR target/28247 * gthr-solaris.h: Prototype __gthrw forms of thr_self, mutex_init and mutex_destroy even when !_LIBOOBJC. Remove duplicate prototype of the __gthrw form of thr_keycreate. (__gthread_key_delete): Silence the unused argument warning. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/gthr-solaris.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #9 from thomas dot g dot girard at free dot fr 2006-07-24 07:23 --- For what it's worth: * I have been able to reproduce this problem on a cross compiler * the same code compiles without problem if inheritance is not virtual -- thomas dot g dot girard at free dot fr changed: What|Removed |Added CC||thomas dot g dot girard at ||free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
