[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From irar at il dot ibm dot com 2005-05-24 07:01 --- Thanks for fixing the patch. I can't reproduce vect-106.c failure on i686-pc-linux-gnu. Could you please give me some information? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug tree-optimization/21732] New: -ftree-dump-all-details hangs during *.c.t24.copyprop or *.c.t38.copyprop2
When dumping the trees during compilation GCC-4.1-2005010[1,8] went into an endless loop during the *.c.t22.copyprop or the *.c.t37.copyprop2 dump, thus generating larger and larger files. After the file reaches 2GB in size gcc stops. The same happens with gcc-4.1-20050515 in the steps *.c.t24.copyprop or *.c.t38.copyprop2. The dumper seems to follow and print a copy propagation chain like this in all the cases: A-B-A-B-A-B-... I've observed this behaviour with many source files. -- Summary: -ftree-dump-all-details hangs during *.c.t24.copyprop or *.c.t38.copyprop2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf_Recker at gmx dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21732
[Bug tree-optimization/21733] New: filecmp.c:252: warning: #n1# may be used uninitialized in this function
if I understand the code flow in FileCmpCmd correctly, the first loop will initialize n1 and n2 because e1 = e2 = 0, and k1 k2 is always BSIZE. Even if the read() will return an error, the last check to return either TCL_ERROR or TCL_OK is not undefined. This is from http://ozlabs.org/~paulus/dirdiff-2.1.tar.gz /usr/lib/gcc/powerpc64-suse-linux/4.0.1/cc1 -fpreprocessed filecmp.i -quiet -dumpbase filecmp.c -auxbase filecmp -O3 -Wall -version -fPIC -o filecmp.s GNU C version 4.0.1 20050521 (prerelease) (SUSE Linux) (powerpc64-suse-linux) compiled by GNU C version 4.0.1 20050521 (prerelease) (SUSE Linux). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 filecmp.c: In function #FileCmpCmd#: filecmp.c:252: warning: #n2# may be used uninitialized in this function filecmp.c:252: warning: #n1# may be used uninitialized in this function -- Summary: filecmp.c:252: warning: #n1# may be used uninitialized in this function Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olh at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21733
[Bug tree-optimization/21733] filecmp.c:252: warning: #n1# may be used uninitialized in this function
--- Additional Comments From olh at suse dot de 2005-05-24 07:48 --- Created an attachment (id=8957) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8957action=view) /tmp/filecmp.i.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21733
[Bug tree-optimization/21734] New: ICE: -ftree-vectorize, segfault
Segfault on compilation of following source:
struct _matrix {
double lineardata[4 * 4];
double operator()(int row, int col = 0) {
return lineardata[col * 4 + row];
}
};
struct matrix : public _matrix {
typedef _matrix parent;
double operator()(int row, int col = 0)
{ return parent::operator()(row,col); }
};
void add(matrix __restrict in1, matrix __restrict in2, matrix __restrict
result) {
for (int col=0; col4; ++col)
for (int row=0; row4; ++row)
result(row, col) = in1(row, col) + in2(row, col);
}
--- end of source ---
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /esat/alexandria1/sderoeck/src/gcc/main/configure
--prefix=/esat/olympia/install --program-suffix=-cvs --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0 20050523 (experimental)
/esat/olympia/install/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -quiet -v
-I/users/visics/sderoeck/projects/clean/CaveIn/Whistler -D_GNU_SOURCE test13.cpp
-quiet -dumpbasetest13.cpp -march=pentium4 -auxbase-strip test13.S -O9 -version
-fverbose-asm -fdump-tree-vect-stats -fdump-tree-vect-details -funroll-all-loops
-ftree-vectorize -o test13.S
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/esat/olympia/install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/users/visics/sderoeck/projects/clean/CaveIn/Whistler
/esat/olympia/install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0
/esat/olympia/install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/i686-pc-linux-gnu
/esat/olympia/install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward
/esat/olympia/install/include
/esat/olympia/install/lib/gcc/i686-pc-linux-gnu/4.1.0/include
/usr/include
End of search list.
GNU C++ version 4.1.0 20050523 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050523 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 99f1919b6616caa4cacd62f3245b1e14
test13.cpp: In function 'void add(matrix, matrix, matrix)':
test13.cpp:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE: -ftree-vectorize, segfault
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefaandr at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
libcpp/configure
libcpp/configure falls over on a Solaris 9 machine (not tested on others) [EMAIL PROTECTED] libcpp]1% uname -a SunOS taskmaster 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V240 [EMAIL PROTECTED] libcpp]0% Adding quotes to the appropriate line fixes the problem: [EMAIL PROTECTED] libcpp]1% diff configure /software/system/src/gcc/gcc-4.0.0/libcpp/ 2760c2760 if test $GCC = yes; then --- if test $GCC = yes; then [EMAIL PROTECTED] libcpp]1% These quotes are in place in other tests: [EMAIL PROTECTED] libcpp]0% grep -n GCC configure | grep test 2145:GCC=`test $ac_compiler_gnu = yes echo yes` 2205: if test $GCC = yes; then 2211: if test $GCC = yes; then 2760:if test $GCC = yes; then 6386:if test $GCC = yes; then 6721: if test -n $GCC; then 6765:if test -n $GCC; then [EMAIL PROTECTED] libcpp]0%
[Bug rtl-optimization/21015] [3.4 Regression] Bad loop optimization with -O2
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24 08:12 --- Fixed by Ulrich's patch http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00950.html http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg01066.html -- What|Removed |Added CC||uweigand at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21015
[Bug target/21719] program using initgroups() fails with stack corruption
--- Additional Comments From Ulrich dot Windl at rz dot uni-regensburg dot de 2005-05-24 08:31 --- Created an attachment (id=8958) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8958action=view) Log file with revised source, disassemblies for both compilers I've revised the source to fix all warnings (except unused formal parameters). Including the declaration or not does not make any difference BTW. I've also added gdb's disassembly of function main for both compilers; gcc-3.4.3, and that of HP-UX 11.11. Finally let me remark that the OS runs 64 bit, but all binaries are 32 bit (which is no problem at all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From pcarlini at suse dot de 2005-05-24 08:38 --- Indeed, Benjamin, I also get this, and that't why probably the issue is not serious as I was afraid it was. However, we are basically relying on inlining to happen for this to work, and that's brittle (as Jonathan also pointed out). At minimum, we have to document this behavior of string debug-mode in the docs... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug tree-optimization/21732] -ftree-dump-all-details hangs during *.c.t24.copyprop or *.c.t38.copyprop2
--- Additional Comments From giovannibajo at libero dot it 2005-05-24 09:27 --- Can you provide one preprocessed source of those many? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21732
Re: libcpp/configure
Chris Webb [EMAIL PROTECTED] wrote: libcpp/configure falls over on a Solaris 9 machine (not tested on others) Thanks for the report. This used to be PR bootstrap/21230 and has been already fixed a few days ago, for both GCC 4.1.0 and GCC 4.0.1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230 Giovanni Bajo
[Bug c++/21735] New: g++ internal error
Whe i try to compile with a simple make obtain this error: g++: Internal error: Terminated (program cc1plus) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for istructions. make: *** [kismet_server.o] Error 1 -- Summary: g++ internal error Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nandochan at tiscali dot it CC: gcc-bugs at gcc dot gnu dot org,nandochan at tiscali dot it GCC build triplet: Configured with: ../gcc-3.3.5/configure --prefix=/usr -- enable-s GCC host triplet: Linux Slackware 10.1 with 2.6.10 GCC target triplet: g++ -I/lib/modules/2.6.10/build/include/ -Ilibpcap-0.8.3 -O2 -Wa http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21735
[Bug libgcj/21736] New: MessageFormat({0,time,medium}) fails
Attempting to create a MessageFormat with a time element styled as medium
raises an exception. The error, in MessageFormat.setLocale(), happens because
DateFormat.DEFAULT has the same value as DateFormat.MEDIUM, and the code was
obviously written with the assumption that this is not the case.
--
Summary: MessageFormat({0,time,medium}) fails
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gbenson at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug libgcj/21736] MessageFormat({0,time,medium}) fails
--- Additional Comments From gbenson at redhat dot com 2005-05-24 10:01 --- Created an attachment (id=8959) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8959action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug libgcj/21736] MessageFormat({0,time,medium}) fails
--- Additional Comments From gbenson at redhat dot com 2005-05-24 10:02 --- Created an attachment (id=8960) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8960action=view) Fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 11:53
---
I can reproduce this problem on powerpc-apple-darwin, even without the
options -maltivec -mabi-altivec (which means that no simd vectorization takes
place). What happens is that the scalar_evolution_info hash table is corrupted
between vectorization pass and tree_unroll_loops_completely pass. It looks like
this corruption takes place during pass_lower_vector_ssa (which is enabled by -
ftree-vectorize), when executing the todo_flags_finish for this pass.
The scalar_evolution_info htab before pass_lower_vector_ssa looks like this:
==
after execute pass:
(classify_chrec {0, +, 1}_1
affine_univariate
)
(classify_chrec
(classify_chrec {1, +, 1}_2
affine_univariate
)
(classify_chrec {0, +, 1}_2
affine_univariate
)
(
-
3 affine univariate chrecs
0 affine multivariate chrecs
0 degree greater than 2 polynomials
0 chrec_dont_know chrecs
-
4 total chrecs
1 with undetermined coefficients
-
21 chrecs in the scev database
55 sets in the scev database
73 gets in the scev database
-
)
==
After pass_lower_vector_ssa the scalar_evolution_info htab looks like this:
==
(classify_chrec Unknown tree:
)
(classify_chrec
(classify_chrec Unknown tree:
)
(classify_chrec Unknown tree:
)
(
-
0 affine univariate chrecs
0 affine multivariate chrecs
0 degree greater than 2 polynomials
0 chrec_dont_know chrecs
-
4 total chrecs
1 with undetermined coefficients
-
21 chrecs in the scev database
55 sets in the scev database
73 gets in the scev database
-
)
==
Removing the TODO_ggc_collect from the todo_flags_finish of
pass_lower_vector_ssa solves the problem (in tree-complex.c):
==
struct tree_opt_pass pass_lower_vector_ssa =
{
veclower, /* name */
gate_expand_vector_operations, /* gate */
expand_vector_operations,/* execute */
NULL,/* sub */
NULL,/* next */
0, /* static_pass_number */
0, /* tv_id */
PROP_cfg,/* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
TODO_dump_func | TODO_update_ssa /* todo_flags_finish */
-| TODO_ggc_collect | TODO_verify_ssa
+| TODO_verify_ssa
| TODO_verify_stmts | TODO_verify_flow,
0/* letter */
};
==
Paolo, is the above solution ok with you? If so, I'll go ahead and prepare a
patch. Alternatively, if ggc_collect is really required here, then adding a
call to scev_reset() would also solve the problem (again, in tree-complex.c):
==
expand_vector_operations (void)
{
block_stmt_iterator bsi;
basic_block bb;
FOR_EACH_BB (bb)
{
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (bsi))
{
expand_vector_operations_1 (bsi);
update_stmt_if_modified (bsi_stmt (bsi));
}
}
+
+ scev_reset ();
+
}
==
--
What|Removed |Added
CC||paolo dot bonzini at lu dot
||unisi dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From irar at il dot ibm dot com 2005-05-24 11:57 --- I committed the patch, since I am not able to reproduce vect-106.c failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-05-24 11:59 --- Subject: Re: poisoned ggc memory used for -ftree-vectorize Paolo, is the above solution ok with you? If so, I'll go ahead and prepare a patch. Alternatively, if ggc_collect is really required here, then adding a call to scev_reset() would also solve the problem (again, in tree-complex.c): Is there a rule that ggc_collect should not be called during loop optimizations? If not, you should not have to modify my pass since it is only showing the problem by doing TODO_ggc_collect. You have to make sure that scev_reset is called at the appropriate time, or that the contents of the scalar evolution hash table are reached during garbage collection. In other words, Janis is correct saying that this is a latent bug. Doing a TODO_ggc_collect after lower_vector_ssa may be overkill, and I'm ok with removing it, but then you are only papering over the real problem. If you have some time to spare, use a --enable-checking=gcac compiler, and the failure will likely happen much earlier. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 12:54 --- Is there a rule that ggc_collect should not be called during loop optimizations? I don't know. (Zdenek?) I think passes within the loop optimizer can assume that the scev information cached in the scev htab can be safely used. During vectorization analysis some new entries in the scev htab are initialized, and these are valid to be used by subsequent passes. If no transformation takes place during vectorization then there's no need to invalidate this information. So I don't think we're missing a call to scev_reset in the vectorizer. The problem is more likely around the fact that ggc_collect, for some reason seems to free up data that is still pointed to from scalar_evolution_info. If you have some time to spare, use a --enable-checking=gcac compiler, and the failure will likely happen much earlier. thanks for the tip You have to make sure that ... the contents of the scalar evolution hash table are reached during garbage collection. any (other) hints on how to do that? (by the way, I actually found a few places where don't properly free up information in the vectorizer, but fixing those didn't solve this particular problem). -- What|Removed |Added CC||rakdver at atrey dot karlin ||dot mff dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-24 13:36 --- Patch for 3.4.x: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html -- What|Removed |Added Keywords||patch Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug c++/21735] g++ internal error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 13:39 --- Can you provide the preprocessed source? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING GCC build triplet|Configured with: ../gcc-| |3.3.5/configure -- | |prefix=/usr --enable-s | GCC host triplet|Linux Slackware 10.1 with | |2.6.10 | GCC target triplet|g++ - |i?86-pc-linux-gnu |I/lib/modules/2.6.10/build/i| |nclude/ -Ilibpcap-0.8.3 -O2 | |-Wa | Summary|g++ internal error |g++ internal error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21735
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-24 13:46 --- scev_info_str should be ggc_alloc-ed. Then, the hash table with the cache should be marked with GTY((param_is (struct scev_info_str))) If this fixes the bug, you can remove the TODO_ggc_collect from lower_vector_ssa. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-24 13:46:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:07 ---
Confirmed.
Reduced testcase (-O2 -ftree-vectorize -march=pentium4):
=
struct A
{
int a[4];
int operator[](int i) { return a[i]; }
};
struct B : public A
{
int operator[](int i) { return A::operator[](i); }
};
void foo(B b)
{
for (int i=0; i4; ++i)
b[i] = 0;
}
=
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code, monitored
Known to fail||4.1.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-05-24 14:07:09
date||
Summary|ICE: -ftree-vectorize, |[4.1 regression] ICE: -
|segfault|ftree-vectorize, segfault
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug c++/21670] segv after error
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24 14:20 --- Looks like it to me too, and I easily could have fallen into the same hole twice because it comes from a use of a shared library. Does a single fix make both go away? One never knows for sure until the patch is applied, but we already have two similar PRs (PR 20789, PR 20668), so chances are very high. Marking this as a duplicate then. *** This bug has been marked as a duplicate of 20789 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21670
[Bug c++/20789] [3.4/4.0/4.1 regression] ICE with incomplete type in template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24 14:20 --- *** Bug 21670 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
14:21 ---
Here is a C testcase:
struct a
{
int aa[4];
};
struct b
{
struct a aa;
};
void foo(struct b *bb)
{
int i;
for (i=0; i4; ++i)
{
struct a *aa = bb-aa;
struct a *aa1 = aa;
struct a *aa2 = aa1;
int *d = aa2-aa[i];
*d = 0;
}
}
I think this is caused by the forwprop changes. (Notice the extra variables to
reproduce this bug).
--
What|Removed |Added
CC||law at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-05-24 14:24 --- Subject: Re: poisoned ggc memory used for -ftree-vectorize Is there a rule that ggc_collect should not be called during loop optimizations? I don't know. (Zdenek?) there are several places in loop opts that are not GGC-safe (in particular the tree nodes refered from loop structures are not seen by garbage collector, and I think there are some other instances). So at the moment, you cannot run ggc_collect inside loop opts. I think passes within the loop optimizer can assume that the scev information cached in the scev htab can be safely used. During vectorization analysis some new entries in the scev htab are initialized, and these are valid to be used by subsequent passes. If no transformation takes place during vectorization then there's no need to invalidate this information. So I don't think we're missing a call to scev_reset in the vectorizer. The problem is more likely around the fact that ggc_collect, for some reason seems to free up data that is still pointed to from scalar_evolution_info. If you have some time to spare, use a --enable-checking=gcac compiler, and the failure will likely happen much earlier. thanks for the tip You have to make sure that ... the contents of the scalar evolution hash table are reached during garbage collection. any (other) hints on how to do that? (by the way, I actually found a few places where don't properly free up information in the vectorizer, but fixing those didn't solve this particular problem). -- What|Removed |Added CC||rakdver at atrey dot karlin ||dot mff dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-05-24 14:26 --- Subject: Re: poisoned ggc memory used for -ftree-vectorize there are several places in loop opts that are not GGC-safe (in particular the tree nodes refered from loop structures are not seen by garbage collector, and I think there are some other instances). So at the moment, you cannot run ggc_collect inside loop opts. Is this going to change? If not, I guess removing TODO_ggc_collect is the simpliest thing to do. But then please a PR on this should be opened, or this one should be modified appropriately, as an enhancement request for making loop optimizations GGC-safe. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug middle-end/21733] filecmp.c:252: warning: #n1# may be used uninitialized in this function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 14:29 --- This is not a regression, oh and this is much harder to get right which is why this is a may/might warning. -- What|Removed |Added Component|tree-optimization |middle-end Keywords||diagnostic Known to fail||3.3.3 3.4.0 4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21733
[Bug c++/21731] ambiguous error is not really clear
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 14:35 --- This is invalid code, the a after the declaration of the namespace is ambiguous. Confirmed, this is only diagnostic problem. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-05-24 14:35:42 date|| Summary|Loses two declartions for |ambiguous error is not |the price of one|really clear http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21731
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:46 ---
Even shorter testcase:
templateint struct A;
struct B
{
templateint N void foo()
{
AN::X::Y;
}
};
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-05-24 15:06 --- Subject: Re: poisoned ggc memory used for -ftree-vectorize there are several places in loop opts that are not GGC-safe (in particular the tree nodes refered from loop structures are not seen by garbage collector, and I think there are some other instances). So at the moment, you cannot run ggc_collect inside loop opts. Is this going to change? If not, I guess removing TODO_ggc_collect is the simpliest thing to do. But then please a PR on this should be opened, or this one should be modified appropriately, as an enhancement request for making loop optimizations GGC-safe. It will need some work (most of the loop structures are mallocated at the moment), so this might indeed be a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21639] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 15:16 --- (In reply to comment #7) So at the moment, you cannot run ggc_collect inside loop opts. Is this going to change? If not, I guess removing TODO_ggc_collect is the simpliest thing to do. But then please a PR on this should be opened, or this one should be modified appropriately, as an enhancement request for making loop optimizations GGC-safe. It will need some work (most of the loop structures are mallocated at the moment), so this might indeed be a good idea. I'll go ahead and prepare the patch then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-24 15:45 --- Regression tested with a updated copy of gcc 4.1 CVS and with patch. Test summary is available at http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01563.html. The test failure is gone! The problem has caused by my system running out of PTYs, so I compiled a linux kernel with more of them in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 15:47 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug tree-optimization/21638] [4.1 regression] ADDR_EXPR invariancy not recomputed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 15:57 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
[Bug c/21737] New: long double incorrect result
Starting from file 20040208-2.c provided in the gcc testsuite I've obtained an equivalent version performing an abort. By changing the following two lines: Internal = x_0 * 0x0.8000p+2L; x = Internal; in x = x_0 * 0x0.8000p+2L; everything work well. I've obtained the same bug on gcc 2.96, 3.3.4, 3.4.3 and 4.0.0. -- Summary: long double incorrect result Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ferrandi at elet dot polimi dot it CC: gcc-bugs at gcc dot gnu dot org 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=21737
[Bug c/21737] long double incorrect result
--- Additional Comments From ferrandi at elet dot polimi dot it 2005-05-24 16:13 --- Created an attachment (id=8961) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8961action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
[Bug target/21737] long double incorrect result
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 16:18 --- 4.0.0 and 4.1.0 works for me on i686-pc-linux-gnu. 3.4.0 fails though. -- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
[Bug pch/21654] [4.1 Regression] gcc.dg/pch/inline-4.c fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 16:27 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
[Bug target/21737] long double incorrect result
--- Additional Comments From ferrandi at elet dot polimi dot it 2005-05-24 16:31 --- Created an attachment (id=8962) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8962action=view) i386 assembler of 20040208-2.c.t12.eh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
[Bug target/21738] New: MIPS libsupc++ built with small data
MIPS does not yet have relaxation support in binutils. Instead, in line with MIPS's own compiler, there is support for small data/bss sections, with appropriate shorter relocations. What size of data goes in those sections is determined with the MIPS target specific command line option -G. However libstdc++ and libsupc++ are built with the default -G value of 8. This means that if a sufficiently large application is built which requires the user to use a smaller value of -G, they are stuck. When brought up on the gcc mailing list around 2005-04-18, three solutions were suggested: a) multilibbing with -G 0. However this adds to multilib hell, and doesn't allow users to have some sdata support with e.g. -G 4. b) providing a configure time option to set the default -G option. However the choice of whether that is needed or not is application specific, not compiler specific. Completely separate compiler builds should not be needed for different applications. c) A new -m option to allow the MIPS backend to generate relocations that assume data is not in the small data section, but still output data into the small data sections. Then libstdc++ / libsupc++ would be built with this new option. Some other ports have this option such as PowerPC where this is the default method of operation (-msdata-data). This would admittedly result in some relocations within the libraries being larger than necessary. However application references to the libraries would be unaffected. No conclusion was reached, but it seemed to me and Zack Weinberg that the latter seemed a reasonable compromise. The PowerPC precedent is compelling. However I have looked at the MIPS backend and it requires someone more familiar with this code than I am to implement this option. My thoughts now are that I believe the easiest approach is to introduce a new mips_section_reloc_threshold variable that would default to the same value as mips_section_threshold (the present -G value). On supplying the new -mno-sdata-relocs option, mips_section_reloc_threshold would be set to 0. Almost all existing uses of mips_section_threshold in mips.c would be renamed to mips_section_reloc_threshold. But the rest is a bit fuzzier to me: sdata appears easy to handle in mips_select_rtx_section(), but sbss would require a change to mips_in_small_data_p, which is also used for TARGET_IN_SMALL_DATA_P. I would appreciate someone helping fill in the last blank. -- Summary: MIPS libsupc++ built with small data Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jifl-bugzilla at jifvik dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: mipsisa32-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738
[Bug c++/21681] [4.0/4.1 Regression] ICE with nested types in template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24 16:53 --- Nathan, this appeared with your binfo work last summer: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00902.html http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00663.html Could you please have a look? -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] ICE |Internal Compiler Error |with nested types in ||template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug libgcj/21736] MessageFormat({0,time,medium}) fails
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-24 17:17 --- I'm handling this. Thanks for the test case; looks like there is already one in mauve, but I'll verify that first. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug bootstrap/21739] New: ../../.././libstdc++-v3/libmath/stubs.c:268: error: parse error before '(' token
AIX 5.2.0 IBM pSeries 9117.570 (Power5 arch)
ML 5200-04
AIX 5XL does not have a libm.a installed by default. I do not have the
package to install it.
Attempting to build gcc-344
./configure --prefix=/usr/local --enable-shared --enable-threads=aix --enable-
aix64 --disable-nls --disable-checking --enable-clocale=gnu --disable-
libunwind-exceptions --enable-languages=c,c++,ada,f77,objc,java
gcc -v
Reading specs from /usr/local/lib/gcc/powerpc-ibm-aix5.2.0.0/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --disable-nls --disable-aix64
Thread model: aix
gcc version 3.4.3
make --version
GNU Make 3.80 Using native AIX 5.2.0 ld and ar (not gnu)
autoconf --version
autoconf (GNU Autoconf) 2.59
automake --version
automake (GNU automake) 1.9.5
last command before the error
/usr/local/bin/make bootstrap
make[7]: Entering directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/pthread/libstdc++-v3/libmath'
../../../.././libstdc++-v3/libmath/stubs.c:268: error: `hypot' declared as
function returning a function
../../../.././libstdc++-v3/libmath/stubs.c:268: error: conflicting types
for 'hypot'
../../../.././libstdc++-v3/libmath/stubs.c:268: error: conflicting types
for 'hypot'
../../../.././libstdc++-v3/libmath/stubs.c:268: error: parse error
before double
make[7]: *** [stubs.lo] Error 1
make[7]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/pthread/libstdc++-v3/libmath'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/pthread/libstdc++-v3'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/pthread/libstdc++-v3'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/libstdc++-v3'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4/powerpc-ibm-
aix5.2.0.0/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/rxmccaf/src/gcc-3.4.4'
make: *** [bootstrap] Error 2
--
Summary: ../../.././libstdc++-v3/libmath/stubs.c:268: error:
parse error before '(' token
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ray dot mccaffity at usbank dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: gcc-3.4.4
GCC host triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21739
[Bug c++/21681] [4.0/4.1 Regression] ICE with nested types in template
--- Additional Comments From nathan at gcc dot gnu dot org 2005-05-24 17:46 --- ok -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-21 14:49:05 |2005-05-24 17:46:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug regression/21740] New: template mismatch in 3.4 and 4.1
hi, the following code compiled properly in 3.3.5:
#begin code
/* bind 2nd parameter in a 2 parameters metafunction */
template templatetypename A, typename B class MetaFunc, typename B
struct bind_2 {
templatetypename T
struct bound {
typedef typename MetaFuncT,B::type type;
}; };
templatetypename A, typename B
struct Fx{
/* refer int 2 steps to FxA,int */
typedef typename bind_2 Fx, int ::template boundA::type type;
};
templatetypename A
struct FxA,int{
typedef double type;
};
#end code
When compiling with gcc 3.4.3 or 4.1 (recent CVS) i get:
bug.cpp:16: error: type/value mismatch at argument 1 in template parameter list
for `templatetemplateclass A, class B class MetaFunc, class B struct bind_2'
bug.cpp:16: error: expected a class template, got `FxA, B'
bug.cpp:16: error: expected unqualified-id before template
The strange thing is that if Fx is defined bi-recursively (instead that
recursively) it compiles on 3.4 and 4.1 too:
This is the working workaround:
#begin code
templatetypename A, typename B
struct Fx;
templatetypename A, typename B
struct Fy;
templatetypename A, typename B
struct Fx{
typedef typename bind_2 Fy, int ::template boundA::type type;
};
templatetypename A
struct FxA,int{
typedef double type;
};
templatetypename A, typename B
struct Fy{
typedef typename bind_2 Fx, int ::template boundA::type type;
};
templatetypename A
struct FyA,int{
typedef double type;
};
#end code
--
Summary: template mismatch in 3.4 and 4.1
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: monge at sns dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-linux
GCC host triplet: i386-pc-linux
GCC target triplet: i386-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21740
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24 18:04 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02298.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug c++/21740] [3.4/4.0/4.1 Regression] template mismatch
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
18:10 ---
Confirmed, here is a reduced testcase (which is not accepted in 3.3.3 though):
template templatetypename A class MetaFunc struct bind_2;
templatetypename A struct Fx
{
typedef typename bind_2Fx::template boundA::type type;
};
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|regression |c++
Ever Confirmed||1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2005-05-24 18:10:09
date||
Summary|template mismatch in 3.4 and|[3.4/4.0/4.1 Regression]
|4.1 |template mismatch
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21740
[Bug libgcj/21692] [4.1 Regression] unexpected java.lang.NoClassDefFoundError
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 18:15 --- Confirmed, here is some analysis from RTH on IRC: [16:54] rth we hashed a plt entry. [16:54] rth grrr. [17:30] tromey ah [17:30] tromey I'm glad you debugged this then [17:32] rth so the problem is that we're not marking some methods as local, which means the make_local_function_alias trick fails. [17:35] tromey in make_local_function_alias I see: [17:35] tromey if (DECL_EXTERNAL (method)) [17:35] tromey return method; [17:35] tromey the problem here is that all CNI native methods will be DECL_EXTERNAL, I think [17:35] tromey is this even fixable? (I have no idea about this code either) [17:35] rth oh, is forName a cni method? [17:36] tromey there are 2 overloads, one is native [17:36] tromey oh, wait, both are native [17:36] tromey I didn't realize that [17:37] rth it's very tricky. [17:37] tromey ok [17:37] rth we would have to create hidden aliases for all native methods, and Just Know to use that alias when building the class table. [17:38] rth so i guess it's not that tricky. just a bit o coordination between c++ and java front ends. [17:38] tromey oh, I see... modify g++ to also emit the hidden aliases [17:38] rth It does assume that cni methods are linked together with its java class. [17:38] rth yes. [17:39] tromey at the moment there is no other way to really use cni methods [17:39] tromey so that is fine, I think [17:40] rth i'll see what i can come up with. [17:40] tromey thank you And this is reason why it works just fine on ppc-darwin, because darwin always use the function address and not a stub/plt entry for the function pointers. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-24 18:15:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug libgcj/21736] MessageFormat({0,time,medium}) fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24 18:16 --- Subject: Bug 21736 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-24 18:16:11 Modified files: libjava: ChangeLog libjava/java/text: MessageFormat.java Log message: 2005-05-24 Gary Benson [EMAIL PROTECTED] PR libgcj/21736: * java/text/MessageFormat.java (MessageFormatElement.setLocale): Handle DateFormat.DEFAULT case correctly. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.75r2=1.3391.2.76 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/text/MessageFormat.java.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23r2=1.23.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug libgcj/21736] MessageFormat({0,time,medium}) fails
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-24 18:17 --- I've checked this in to the 4.0 branch and Classpath. I'm leaving the PR open for now; I will check this in and close it once the trunk is out of its slushy state. Thanks for the patch and test case. -- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
[Bug c++/21740] [3.4/4.0/4.1 Regression] template mismatch
--- Additional Comments From giovannibajo at libero dot it 2005-05-24 18:28 --- Invalid, use ::Fx. Read http://gcc.gnu.org/gcc-3.4/changes.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21740
[Bug c++/21645] [4.1 Regression] C++ ICE in cxx_types_compatible_p
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24 19:06 --- Subject: Bug 21645 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-24 19:06:20 Modified files: gcc/cp : ChangeLog optimize.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: ctor5.C Log message: 2005-05-24 Andrew Pinski [EMAIL PROTECTED] PR C++/21645 * g++.dg/init/ctor5.C: New test. 2005-05-24 Andrew Pinski [EMAIL PROTECTED] PR C++/21645 * optimize.c (update_cloned_parm): Copy the TYPE also from the original one. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4751r2=1.4752 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/optimize.c.diff?cvsroot=gccr1=1.114r2=1.115 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5510r2=1.5511 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/ctor5.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21645
[Bug c++/21645] [4.1 Regression] C++ ICE in cxx_types_compatible_p
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 19:06 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21645
[Bug libgcj/21741] New: Need configure option to set java.library.path
We need a configure option to set java.library.path.
Right now libgcjawt.so in installed in ${prefix}/lib.
In FC4 we use java-gcj-compat to create a libjawt.so symlink in
/usr/lib/jvm/jre/lib/i386 (via alternatives).Programs running
System.loadLibrary(jawt) should find this without users having to set
LD_LIBRARY_PATH or -Djava.library.path. One answer is to let packagers set the
default java.library.path at configure time.
--
Summary: Need configure option to set java.library.path
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
[Bug libgcj/21741] Need configure option to set java.library.path
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 19:52 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-24 19:52:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
[Bug libfortran/21621] Inconsistency with binary sequential output
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24 20:02 --- Well no, the standard does not specify how unformatted sequential record markers are implemented. In short, gfortran uses markers of type off_t, which is 64 bits on operating systems with large file (LFS) support. Today, that is most OS:es in common use. g77 AFAIK uses markers of type long, that is 32-bits on most 32-bit platforms and 64 bits on 64-bit platforms. See also PR 19303. Also note that Bud Davis is apparently currently working on pluggable record markers, which should allow gfortran to add some kind of g77 compatibility flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21621
[Bug c++/21731] ambiguous error is not really clear
--- Additional Comments From bangerth at dealii dot org 2005-05-24 20:33 --- This is a duplicate of a dozen other bugs where gcc reports that there is no declaration even though there are ambiguous ones. Can someone please go through the list of open PRs and find it? We get a similar PR every other week... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21731
[Bug libstdc++/21530] libstdc++ not supported on this target
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 20:36 --- This patch looks fine to me. I suggest just posting this, with a ChangeLog entry, to gcc-patches. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From guptan at hotmail dot com 2005-05-24 20:39 --- Andrew, I was able to strip the worksround mentioned in http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00482.html and apply the patch at PR target/13674 to avoid this bug. If its of interest, I can post a patch for gcc-3.4 . I need to do a little bit of cleanup before that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug other/20055] Many source files are unnecessarily executable
--- Additional Comments From ian at airs dot com 2005-05-24 20:43 --- I believe these are all now fixed in the CVS repository. Let me know if I missed any. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20055
[Bug libstdc++/20823] frv-unknown-elf doesn't build: GCC_NO_EXECUTABLES unexpanded
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 20:48 --- Kelley, any chance you can take a look at this? This is most probably related to the (welcome) changes you did around this time. -benjamin -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kcook at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20823
[Bug target/21742] New: unrecognized insn for struct-layout-1 tests with complex members
Generated tests t154 and t199 from gcc.dg/compat/struct-layout-1 fail with an ICE compiling c_compat_y_tst.o with -m64 on powerpc64-linux. The first started failing on 20050424, the second on 20050501, and both have failed regularly since then, but it seems to be a latent bug because results for regression hunts don't match up with those dates. I'll attach minimized test cases for both. Here's the output I get from today's mainline: elm3b11% /opt/gcc-nightly/mline/bin/gcc -m64 -c bug_t154.c bug_t154.c: In function check13995: bug_t154.c:36: error: unrecognizable insn: (insn 25 24 26 1 (set (reg:DF 130 [ D.1250+8 ]) (subreg:DF (mem/s/j:DC (plus:DI (reg/f:DI 114 virtual-stack-vars) (const_int 33112 [0x8158])) [0 variable.e.m+0 S16 A64]) 8)) -1 (nil) (nil)) bug_t154.c:36: internal compiler error: in extract_insn, at recog.c:2082 elm3b11% /opt/gcc-nightly/mline/bin/gcc -m64 -c bug_t199.c bug_t199.c: In function check18102: bug_t199.c:23: error: unrecognizable insn: (insn 29 28 30 1 (set (reg:SF 130 [ D.1239+4 ]) (subreg:SF (mem/s/j:SC (plus:DI (reg/f:DI 114 virtual-stack-vars) (const_int 56000 [0xdac0])) [0 arg2.y+0 S8 A512]) 4)) -1 (nil) (nil)) bug_t199.c:23: internal compiler error: in extract_insn, at recog.c:2082 -- Summary: unrecognized insn for struct-layout-1 tests with complex members Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
[Bug target/21742] unrecognized insn for struct-layout-1 tests with complex members
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 20:55 --- Created an attachment (id=8963) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8963action=view) Minimized test case for struct-layout-1 test t154. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
[Bug target/21742] unrecognized insn for struct-layout-1 tests with complex members
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 20:56 --- Created an attachment (id=8964) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8964action=view) Minimized test case for struct-layout-1 t199 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
[Bug libgcj/21692] [4.1 Regression] unexpected java.lang.NoClassDefFoundError
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg02328.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-05-24 18:15:46 |2005-05-24 21:15:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug fortran/17283] UNPACK issues
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24 21:26 --- (In reply to comment #4) as a note: UNPACK also has issues with as scalar mask, maybe also with memory allocation I have just submitted a patch for the memory allocation issue. A scalar mask for unpack is invalid, AFAIR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17283
[Bug libfortran/18857] [4.0 only] MATMUL failing with ALLOCATED matrices, unless base indices given
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24 21:55 --- This has been fixed on mainline, still outstanding in 4.0 -- What|Removed |Added Known to fail||4.0.1 Known to work||4.1.0 Summary|MATMUL failing with |[4.0 only] MATMUL failing |ALLOCATED matrices, unless |with ALLOCATED matrices, |base indices given |unless base indices given Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18857
[Bug middle-end/21743] New: Enable __builtin_clog
This builtin, that would be *so* useful in the implementation of std::complex cannot be enabled at the moment due to this issue (see also builtins.def): http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00510.html We should *really* find a way to work around the problem! (not sure whether the proper component is middle-end or libstdc++-v3 ;) -- Summary: Enable __builtin_clog Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21743
[Bug tree-optimization/15457] [tree-ssa] Convert a sign bit testing into a 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 22:04 --- All three are now done by PR 15459. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15457
[Bug middle-end/21743] Enable __builtin_clog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 22:07 --- We could just define the __builtin_ version of the function. I keep on wondering if (and when) C++ gets the C99 complex functions and types, what would they do about complex log. Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-24 22:07:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21743
[Bug middle-end/21743] Enable __builtin_clog
--- Additional Comments From pcarlini at suse dot de 2005-05-24 22:14 --- We could just define the __builtin_ version of the function. I don't understand, can you explain? In my understanding everything is in place, indeed all the other builtins are there, *only* we cannot do that for clog because ends up conflicting with iostream's clog. That's the whole point: it conflicts. If you don't believe that, just enable it and run the testsuite: it conflicts as soon as you do 'using std::clog;' in the global namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21743
[Bug middle-end/21743] Enable __builtin_clog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24 22:20 --- If you uncomment what is in builtins.def, you get both clog and __builtin_clog. If we define it as DEF_LIB_BUILTIN instead of DEF_C99_BUILTIN, we only get __builtin_clog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21743
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24 22:22 --- Subject: Bug 18495 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-24 22:22:10 Modified files: libgfortran: ChangeLog libgfortran/intrinsics: spread_generic.c gcc/testsuite : ChangeLog gcc/testsuite/gfortran.fortran-torture/execute: intrinsic_spread.f90 Log message: 2005-05-25 Thomas Koenig [EMAIL PROTECTED] Backport from mainline: PR libfortran/18495 * intrinsics/spread_generic.c (spread): Remove const from return array descriptor. New variables: rrank (rank of return array), rs (for calculating the size of the return array), srank (rank of the source array). Generate runtime error if the dim= argument is larger than the rank of the return array. Generate runtime error if the needed rank of the return array is larger than 7. If ret-data is null, populate the return array descriptor and initialize the variables for the actual operation. Otherwise, set ret-dim[0].stride to one if it is zero. Change second, independent use of variable dim to srank. 2005-05-25 Thomas Koenig [EMAIL PROTECTED] Backport from mainline: PR libfortran/18495 * gfortran.fortran-torture/execute/intrinsic_spread.f90: Test callee-allocated version of return array with a write statement. Test spread with a temporary with another write statement. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.40r2=1.163.2.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/spread_generic.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.6.12.1r2=1.6.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.194r2=1.5084.2.195 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_spread.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2r2=1.2.46.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24 22:23 --- The fix in 4.0 was incomplete, it is complete now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug libfortran/21333] in_pack / in_unpack alignment issues
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
22:40 ---
For 4-byte complex, an option is to check the alignment at runtime.
If the complex is aligned on an 8-byte boundary, it should be
perfectly OK to call the 8-byte-integer routines.
The check could be done with a macro like this:
#define GFC_ALIGNMENT_I8(a) (((size_t) (a)) 7 == 0)
#define GFC_ALIGNMENT_I4(a) (((size_t) (a)) 3 == 0)
and the code look like
if (size == 8)
{
if (GFC_ALIGNMENT_I8(ptr))
return internal_pack_8(whatever)
else if (GFC_ALIGNMENT_I4(ptr))
return internal_pack_c4(whatever)
/* Fall through to generic routine */
}
OK in principle? Too horrible to contemplate?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21333
[Bug middle-end/21743] Enable __builtin_clog
--- Additional Comments From pcarlini at suse dot de 2005-05-24 22:46 --- Ah, ah, cool, thanks! I'm going to propose that! -- 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=21743
[Bug tree-optimization/19833] bogus uninitialized variable warning for powerpc64
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 23:02 --- Diego, can this PR be closed as fixed? Test gcc.dg/uninit-4.c started to XPASS with this patch from dnovillo: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00529.html On the same day, test uninit-9.c also started to XPASS on: hppa2.0w-hp-hpux11.11 hppa2.0w-hp-hpux11.* hppa64-hp-hpux11.* i686-pc-cygwin i686-pc-linux-gnu ia64-unknown-linux-gnu mips-sgi-irix6.5 powerpc64-unknown-linux-gnu powerpc-apple-darwin7.4.0 powerpc-ibm-aix5.2.0.0 s390-ibm-linux-gnu x86_64-unknown-linux-gnu I'd like to remove the xfail for these two tests and close this PR. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug tree-optimization/19833] bogus uninitialized variable warning for powerpc64
--- Additional Comments From dnovillo at redhat dot com 2005-05-24 23:06 --- Subject: Re: bogus uninitialized variable warning for powerpc64 On Tue, May 24, 2005 at 11:02:09PM -, janis at gcc dot gnu dot org wrote: Diego, can this PR be closed as fixed? Yes. Apologies for not having done this before. The uninitialized warning machinery needs to be re-designed, though. Right now, we are at the mercy of whether certain passes were done in some specific order. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug tree-optimization/19833] bogus uninitialized variable warning for powerpc64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24 23:42 --- Subject: Bug 19833 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-24 23:41:53 Modified files: gcc/testsuite/gcc.dg: uninit-4.c uninit-9.c gcc/testsuite : ChangeLog Log message: 20005-05-24 Janis Johnson [EMAIL PROTECTED] PR tree-optimization/19833 gcc.dg/uninit-4.c: Remove xfail. gcc.dg/uninit-9.c: Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/uninit-4.c.diff?cvsroot=gccr1=1.5r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/uninit-9.c.diff?cvsroot=gccr1=1.4r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5517r2=1.5518 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From stevenj at alum dot mit dot edu 2005-05-24 23:51 --- I doubt that merely omitting close() from the end of the library will entirely fix the problem. You really need to add an fflush before every output to stdio. For example, modify ciotst.f to: program ciotst call cio write(*,*) 'Hello world.' call cio end The g77 output is: foo bar baz Hello world. foo bar baz as you would expect, but the gfortran output is in the wrong order (as well as missing the final baz in my unpatched gfortran) because of missing flushes: foo bar Hello world. bazfoo bar (If you look in libf2c you'll see that it uses fflush in a number of places.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug bootstrap/21744] New: Internal compiler error during build
Trying to build m6812 cross compiler causes an internal compiler error.
Configured with ../../
gcc-4.0.0/configure --prefix=/usr/cross/m6812 --target=m6812 (using the
gcc-core-4.0.0, using
only the c compiler). Re-running the command that failed with a -v causes the
following error..
/usr/cross/build/m6812/gcc/gcc/xgcc -v -B/usr/cross/build/m6812/gcc/gcc/
-B/usr/cross/m6812/
m6812/bin/ -B/usr/cross/m6812/m6812/lib/ -isystem
/usr/cross/m6812/m6812/include -isystem /
usr/cross/m6812/m6812/sys-include -Os -mrelax -DUSE_GAS -DIN_GCC
-Dinhibit_libc -g -
DIN_LIBGCC2 -I. -I. -I../../../gcc-4.0.0/gcc -I../../../gcc-4.0.0/gcc/.
-I../../../gcc-4.0.0/gcc/../include
-I../../../gcc-4.0.0/gcc/../libcpp/include -DL_mulsc3 -c
../../../gcc-4.0.0/gcc/libgcc2.c -o libgcc/./
_mulsc3.o
Reading specs from /usr/cross/build/m6812/gcc/gcc/specs
Target: m6812
Configured with: ../../gcc-4.0.0/configure --prefix=/usr/cross/m6812
--target=m6812
Thread model: single
gcc version 4.0.0
/usr/cross/build/m6812/gcc/gcc/cc1 -quiet -v -I. -I. -I../../../gcc-4.0.0/gcc
-I../../../gcc-4.0.0/
gcc/. -I../../../gcc-4.0.0/gcc/../include
-I../../../gcc-4.0.0/gcc/../libcpp/include -iprefix /usr/cross/
build/m6812/gcc/gcc/../lib/gcc/m6812/4.0.0/ -isystem
/usr/cross/build/m6812/gcc/gcc/include -
D__INT__=32 -Dmc6812 -DMC6812 -Dmc68hc12 -DUSE_GAS -DIN_GCC -Dinhibit_libc
-DIN_LIBGCC2
-DL_mulsc3 -isystem /usr/cross/m6812/m6812/include -isystem
/usr/cross/m6812/m6812/sys-
include ../../../gcc-4.0.0/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mrelax
-auxbase-strip libgcc/./
_mulsc3.o -g -Os -version -o /var/tmp//ccn0buJh.s
ignoring nonexistent directory /usr/cross/m6812/m6812/include
ignoring nonexistent directory /usr/cross/m6812/m6812/sys-include
ignoring nonexistent directory
/usr/cross/build/m6812/gcc/gcc/../lib/gcc/m6812/4.0.0/include
ignoring nonexistent directory
/usr/cross/build/m6812/gcc/gcc/../lib/gcc/m6812/4.0.0/../../../../
m6812/sys-include
ignoring nonexistent directory
/usr/cross/build/m6812/gcc/gcc/../lib/gcc/m6812/4.0.0/../../../../
m6812/include
ignoring nonexistent directory /usr/cross/m6812/lib/gcc/m6812/4.0.0/include
ignoring nonexistent directory /usr/cross/m6812/lib/../m6812/sys-include
ignoring nonexistent directory /usr/cross/m6812/lib/../m6812/include
ignoring duplicate directory .
ignoring duplicate directory ../../../gcc-4.0.0/gcc/.
#include ... search starts here:
#include ... search starts here:
.
../../../gcc-4.0.0/gcc
../../../gcc-4.0.0/gcc/../include
../../../gcc-4.0.0/gcc/../libcpp/include
/usr/cross/build/m6812/gcc/gcc/include
End of search list.
GNU C version 4.0.0 (m6812)
compiled by GNU C version 4.0.0 20041026 (Apple Computer, Inc. build
4061).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
../../../gcc-4.0.0/gcc/libgcc2.c: In function '__mulsc3':
../../../gcc-4.0.0/gcc/libgcc2.c:1696: error: insn does not satisfy its
constraints:
(insn:HI 743 742 744 103 ../../../gcc-4.0.0/gcc/libgcc2.c:1695 (parallel [
(set (mem/s:SF (plus:HI (mem/f:HI (plus:HI (reg/f:HI 9 *_.frame)
(const_int 33 [0x21])) [13 S2 A8])
(const_int 4 [0x4])) [3 result+4 S4 A8])
(reg:SF 0 x [191]))
(clobber (scratch:HI))
]) 22 {movsf_internal} (insn_list:REG_DEP_TRUE 742 (nil))
(nil))
../../../gcc-4.0.0/gcc/libgcc2.c:1696: internal compiler error: in
reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: Internal compiler error during build
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastient at otii dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-apple-darwin8-gcc-4.0.0
GCC target triplet: m6812
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21744
[Bug bootstrap/21744] Internal compiler error during build
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25 00:23 --- *** This bug has been marked as a duplicate of 19960 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21744
[Bug target/19960] internal compiler error: in extract_insn, at recog.c:2175
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25 00:23 --- *** Bug 21744 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sebastient at otii dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19960
[Bug c++/13452] No error on invalid (I think) C++ code
--- Additional Comments From ian at airs dot com 2005-05-25 00:33 --- Just a note that this still fails to issue an error on mainline. -- What|Removed |Added Last reconfirmed|2003-12-23 18:22:24 |2005-05-25 00:33:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13452
[Bug libstdc++/20823] frv-unknown-elf doesn't build: GCC_NO_EXECUTABLES unexpanded
--- Additional Comments From kcook at gcc dot gnu dot org 2005-05-25 01:11 --- /home/hp/cvs_areas/combined/combined/libstdc++-v3/configure: line 1545: GCC_NO_EXECUTABLES: command not found This was due to my changes. This error was simply due to a mismatch in aclocal versions back when I was nuking the acconfig.h. Specifically this checkin: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc%2b%2b-v3/configure.diff?r1=1.429r2=1.430only_with_tag=MAINf=h Note the date corresponds perfectly with the error. It was corrected with the next checkin to configure the next day. Moreover, I updated the documentation to show the automake 1.9.3 requirement, as the GCC_NO_EXECUTABLES macro is using AC_DEFUN_ONCE which aclocal ignored until version 1.9.3. Marking bug as fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20823
[Bug libstdc++/21745] New: ICE during build of h8300 cross-compiler
While building a cross-compiler on my Linux x86 box, I got this error in the middle of the libstdc++ build: Command: /usr/local/src/build-gcc/gcc/xgcc -shared-libgcc -B/usr/local/src/build-gcc/gcc/ -nostdinc++ -L/usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/src -L/usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/src/.libs -nostdinc -B/usr/local/src/build-gcc/h8300-hms/h8300s/normal/newlib/ -isystem /usr/local/src/build-gcc/h8300-hms/h8300s/normal/newlib/targ-include -isystem /usr/local/src/gcc-3.4.4/newlib/libc/include -B/usr/local/h8300-hms/bin/ -B/usr/local/h8300-hms/lib/ -isystem /usr/local/h8300-hms/include -isystem /usr/local/h8300-hms/sys-include -ms -mn -I/usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/h8300-hms -I/usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include -I/usr/local/src/gcc-3.4.4/libstdc++-v3/libsupc++ -O2 -g -O2 -g -O2 -ms -mn -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -c ../../../../../../gcc-3.4.4/libstdc++-v3/src/locale-inst.cc -o locale-inst.o Error: /usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc: In member function `_InIter std::money_get_CharT, _InIter::do_get(_InIter, _InIter, bool, std::ios_base, std::_Ios_Iostate, std::basic_string_CharT, std::char_traits_CharT, std::allocator_CharT ) const [with _CharT = char, _InIter = std::istreambuf_iteratorchar, std::char_traitschar ]': /usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc:702: error: unrecognizable insn: (insn 434 253 355 5 /usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/basic_string.h:1465 (set (mem:SI (pre_dec:HI (reg/f:HI 7 sp)) [0 S4 A32]) (reg:SI 7 sp)) -1 (nil) (nil)) /usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/include/bits/locale_facets.tcc:702: internal compiler error: in extract_insn, at recog.c:2083 If more information is needed, I'll be glad to provide it. -- Summary: ICE during build of h8300 cross-compiler Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aarestad at gmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: h8300-hms http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21745
[Bug libstdc++/21745] ICE during build of h8300 cross-compiler
-- What|Removed |Added CC||aarestad at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21745
[Bug target/21745] ICE during build of h8300 cross-compiler
-- What|Removed |Added Component|libstdc++ |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21745
[Bug AWT/21598] rendering problem with button text
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-25 01:57:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
[Bug AWT/21599] transparent images don't work
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 01:59 --- Fixed by Sven de Marothy in GNU Classpath. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21599
[Bug AWT/21600] race condition with java applet
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-25 01:59:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600
[Bug AWT/21604] strange refresh behavior when moving mouse
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 02:01 --- Are you using focus-follows-mouse? If so, this is a known problem; a change in a window's active state causes an expose event on the entire window, which triggers a repaint. We need to find a way to prevent that expose event in the gtk peers. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-25 02:01:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21604
[Bug AWT/21649] errors when exiting gcjappletviewer
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 02:03 --- Do you still see this on HEAD? I can't reproduce it. What applet are you running? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21649
[Bug AWT/21660] FileDialog.SAVE broken
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-25 02:04:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21660
[Bug c++/21746] New: Compiler will not create references of abstract types
Consider the code:
class A {
public:
virtual void foo() = 0;
};
class B : public A {
public:
virtual void foo() {}
};
int main()
{
const A a = B(); // -- here
return 0;
}
in g++-4.0, as it comes pre-installed on Mac 10.4, I get the error:
$ g++ -c g++4-bug.cc
g++4-bug.cc: In function `int main()':
g++4-bug.cc:15: error: cannot allocate an object of abstract type 'A'
g++4-bug.cc:3: note: because the following virtual functions are pure within
'A':
g++4-bug.cc:5: note: virtual void A::foo()
However, this code compiles without complaint on the g++-3.4 that comes
preinstalled on this system. I don't know whether this has been fixed since
gcc-4.0, but it doesn't seem to me like there's any reason for gcc to reject
this code.
Thanks,
Michael
--
Summary: Compiler will not create references of abstract types
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vircum at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.1.0
GCC host triplet: powerpc-apple-darwin8.1.0
GCC target triplet: powerpc-apple-darwin8.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21746
[Bug libgcj/21747] New: JAWT_X11DrawingSurfaceInfo missing depth field
The native code in the lwjgl distribution refers to an int depth field in JAWT_X11DrawingSurfaceInfo. We don't have that in our version. This code won't build without it. -- Summary: JAWT_X11DrawingSurfaceInfo missing depth field Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
[Bug c++/21746] Compiler will not create references of abstract types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25 02:35 --- This is not a bug in the FSF released GCC, only Apple's report it to them. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21746
[Bug AWT/21747] JAWT_X11DrawingSurfaceInfo missing depth field
-- What|Removed |Added Component|libgcj |AWT http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
