[Bug c/30762] [4.2/4.3 Regression] IMA messes up with inlining
--- Comment #14 from jakub at gcc dot gnu dot org 2007-03-20 08:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30762
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- Comment #9 from jakub at gcc dot gnu dot org 2007-03-20 08:09 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug c/31275] ICE During Gettext Build
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-03-20 08:21 --- This is a dup of PR 29826. The testcase (and 29826) succeeds on gcc version 4.2.0 20070319 (prerelease) and on gcc version 4.3.0 20070318 (experimental) with mingw32 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31275
[Bug middle-end/30907] [4.3 regression] Propagation of addresses within loops pessimizes code
--- Comment #5 from bonzini at gnu dot org 2007-03-20 08:31 --- Subject: Bug 30907 Author: bonzini Date: Tue Mar 20 08:31:13 2007 New Revision: 123084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123084 Log: 2007-03-19 Paolo Bonzini <[EMAIL PROTECTED]> PR rtl-optimization/30907 * fwprop.c (forward_propagate_into): Never propagate inside a loop. (fwprop_init): Always call loop_optimizer_initialize. (fwprop_done): Always call loop_optimizer_finalize. (fwprop): We always have loop info now. (gate_fwprop_addr): Remove. (pass_fwprop_addr): Use gate_fwprop as gate. PR rtl-optimization/30841 * df-problems.c (df_ru_local_compute, df_rd_local_compute, df_chain_alloc): Call df_reorganize_refs unconditionally. * df-scan.c (df_rescan_blocks, df_reorganize_refs): Change refs_organized to refs_organized_size. (df_ref_create_structure): Use refs_organized_size instead of bitmap_size if refs had been organized, and keep refs_organized_size up-to-date. * df.h (struct df_ref_info): Change refs_organized to refs_organized_size. (DF_DEFS_SIZE, DF_USES_SIZE): Use refs_organized_size instead of bitmap_size. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/df-scan.c trunk/gcc/df.h trunk/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug rtl-optimization/30841] [4.3 regression] Missed optimizations for sbi/cbi instructions
--- Comment #4 from bonzini at gnu dot org 2007-03-20 08:31 --- Subject: Bug 30841 Author: bonzini Date: Tue Mar 20 08:31:13 2007 New Revision: 123084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123084 Log: 2007-03-19 Paolo Bonzini <[EMAIL PROTECTED]> PR rtl-optimization/30907 * fwprop.c (forward_propagate_into): Never propagate inside a loop. (fwprop_init): Always call loop_optimizer_initialize. (fwprop_done): Always call loop_optimizer_finalize. (fwprop): We always have loop info now. (gate_fwprop_addr): Remove. (pass_fwprop_addr): Use gate_fwprop as gate. PR rtl-optimization/30841 * df-problems.c (df_ru_local_compute, df_rd_local_compute, df_chain_alloc): Call df_reorganize_refs unconditionally. * df-scan.c (df_rescan_blocks, df_reorganize_refs): Change refs_organized to refs_organized_size. (df_ref_create_structure): Use refs_organized_size instead of bitmap_size if refs had been organized, and keep refs_organized_size up-to-date. * df.h (struct df_ref_info): Change refs_organized to refs_organized_size. (DF_DEFS_SIZE, DF_USES_SIZE): Use refs_organized_size instead of bitmap_size. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/df-scan.c trunk/gcc/df.h trunk/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
[Bug rtl-optimization/30841] [4.3 regression] Missed optimizations for sbi/cbi instructions
--- Comment #5 from bonzini at gnu dot org 2007-03-20 08:31 --- fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
[Bug middle-end/30907] [4.3 regression] Propagation of addresses within loops pessimizes code
--- Comment #6 from bonzini at gnu dot org 2007-03-20 08:32 --- patch committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #23 from anlauf at gmx dot de 2007-03-20 08:51 --- (In reply to comment #22) > Error 5001 would be ERROR_OPTION_CONFLICT. There are 18 different errors > associated with that code. To find out which one, you must remove the iostat > from the offending line so that gfortran will print the error message for you. OK, this is what I get with iostat removed and compiled with -fbacktrace: At line 264 of file ../../../../oo-model/mo_thinning.f90 Fortran runtime error: Missing format for FORMATTED data transfer Backtrace for this error: + function data_transfer_init (0x89C9B92) at line 1806 of file transfer.c + function __mo_thinning__read_nml_thin (0x83570AC) at line 264 of file mo_thinning.f90 [...] The code in question does a: rewind (nnml) [...] call position_nml (nnml, 'THINNING', ...) [...] read (nnml, nml=THINNING) ! This is line 264 The read is only executed when the position_nml succeeds. > Another option is to use iomsg and get the string. Thanks, I did not know this F2003 feature. In that case I get for iomsg = "" read (nnml, nml=THINNING, iostat=ios, iomsg=iomsg) the following output: iostat =5001 iomsg = Missing format for FORMATTED data transfer No crash, of course, at least in the read statement. > You can access the code base at gcc.gnu.org/viewcvs or better, I will bookmark that. > download with > anonymous svn. See instructions here: http://gcc.gnu.org/svn.html. If you do > the svn approach, its very simple to get latest update and you are a few > keystrokes from building it yourself. :) My next computer and internet connection will probably be powerful enough. ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug c++/31277] New: incorrect c++ code produces g++ internal error
The code is
templateclass b{friend ba::c();};
templateba::c(){return b();}
The preprocessed code is
# 1 "stupid.cc"
# 1 ""
# 1 ""
# 1 "stupid.cc"
templateclass b{friend ba::c();};
templateba::c(){return b();}
gcc was built on Fedora Core 4; configured with command:
../gcc-4.1.2/configure --prefix=$HOME/gcc412 --enable-languages=c,c++
the command line producing error is
g++ -v --save-temp -Wall -c stupid.cc 2> err
the error message is:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.2/configure --prefix=/home/dti/gcc412
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.2
/home/dti/gcc412/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus -E -quiet -v
-D_GNU_SOURCE stupid.cc -mtune=pentiumpro -Wall -fpch-preprocess -o stupid.ii
ignoring nonexistent directory
"/home/dti/gcc412/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/dti/gcc412/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../include/c++/4.1.2
/home/dti/gcc412/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i686-pc-linux-gnu
/home/dti/gcc412/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/home/dti/gcc412/include
/home/dti/gcc412/lib/gcc/i686-pc-linux-gnu/4.1.2/include
/usr/include
End of search list.
/home/dti/gcc412/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus -fpreprocessed
stupid.ii -quiet -dumpbase stupid.cc -mtune=pentiumpro -auxbase stupid -Wall
-version -o stupid.s
GNU C++ version 4.1.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64266
Compiler executable checksum: bf947049f66570c1ab11b37642201042
stupid.cc:2: internal compiler error: in is_ancestor, at cp/name-lookup.c:2236
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
g++ 4.0.4 made similarly produces Segmentation fault:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.4/configure --prefix=/home/dti/gcc404
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.4
/home/dti/gcc404/libexec/gcc/i686-pc-linux-gnu/4.0.4/cc1plus -quiet -v
-D_GNU_SOURCE stupid.cc -quiet -dumpbase stupid.cc -mtune=pentiumpro -auxbase
stupid -Wall -version -o /tmp/cc85lGkB.s
ignoring nonexistent directory
"/home/dti/gcc404/lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/dti/gcc404/lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../include/c++/4.0.4
/home/dti/gcc404/lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../include/c++/4.0.4/i686-pc-linux-gnu
/home/dti/gcc404/lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../include/c++/4.0.4/backward
/usr/local/include
/home/dti/gcc404/include
/home/dti/gcc404/lib/gcc/i686-pc-linux-gnu/4.0.4/include
/usr/include
End of search list.
GNU C++ version 4.0.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64266
stupid.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
g++ 3.4.6 works fine (complains about the stupid.cc with no internal error)
--
Summary: incorrect c++ code produces g++ internal error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ineiev at yahoo dot co dot uk
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=31277
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #5 from mimo2 at free dot fr 2007-03-20 08:56 --- OK but in the present situation, the execution could be different wether you have -fbounds-check or not. Let's change the code by program toto implicit none real:: a(100) integer :: i, k a(:) = 1. do i=1,100 if( i <= 10 .and. a(k(i)) > 0. ) write(*,*) i,a(i) enddo end which is perfectly legitimate, and with k(i) a function. I've understood that when i>10, k will not be called when no bound-checking (there is presently short-circuit) while it will be called if bound checking. As k(i) may have some side effects, this could lead to different execution path. I still think that having a consistent behaviour between the two options is the right thing to do. As short-circuit seems to be an extension of the standard, the most sensible way would be to have an additionnal flag -short-circuit which would allow the user to choose if he wants it or not, and that this flag apply to all situations (i.e. bound-checking or not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug c++/30847] [4.1/4.2/4.3 regression] ICE with invalid statement expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg01264.html Status|NEW |ASSIGNED Last reconfirmed|2007-03-09 04:16:46 |2007-03-20 09:12:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30847
[Bug middle-end/31263] Misoptimization of constant function expressions
--- Comment #3 from o dot mangold at gmx dot de 2007-03-20 09:21 --- Maybe I should remark, that on my system the assembler output looks I little different than yours. Good: .L2: pushl %edi fildl (%esp) addl$4, %esp fstpl (%esp) callSquare fstpl (%esi,%ebx,8) addl$1, %ebx cmpl$5000, %ebx jne .L2 Bad: .L2: movl$0, (%esp) movl$1083129856, 4(%esp) callSquare fstpl -8(%esi,%ebx,8) addl$1, %ebx cmpl$5001, %ebx jne .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31263
[Bug fortran/31262] -fno-range-check with large integer values triggers ICE
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-20 09:27
---
Here's a patch:
Index: trans-const.c
===
--- trans-const.c (revision 123017)
+++ trans-const.c (working copy)
@@ -165,23 +165,31 @@
}
else
{
- unsigned HOST_WIDE_INT words[2];
- size_t count;
+ unsigned HOST_WIDE_INT *words;
+ size_t count, numb;
+ /* Determine the number of unsigned HOST_WIDE_INT that are required
+ for represent the value. */
+ numb = 8*sizeof(HOST_WIDE_INT);
+ count = (mpz_sizeinbase (i, 2) + numb-1) / numb;
+ if (count < 2)
+ count = 2;
+ words = (unsigned HOST_WIDE_INT *) alloca (count *
sizeof(HOST_WIDE_INT));
+
/* Since we know that the value is not zero (mpz_fits_slong_p),
we know that at least one word will be written, but we don't know
about the second. It's quicker to zero the second word before
than conditionally clear it later. */
words[1] = 0;
-
+
/* Extract the absolute value into words. */
- mpz_export (words, &count, -1, sizeof (HOST_WIDE_INT), 0, 0, i);
+ mpz_export (words, &count, -1, sizeof(HOST_WIDE_INT), 0, 0, i);
- /* We assume that all numbers are in range for its type, and that
-we never create a type larger than 2*HWI, which is the largest
-that the middle-end can handle. */
- gcc_assert (count == 1 || count == 2);
-
+ /* We don't assume that all numbers are in range for its type.
+ However, we never create a type larger than 2*HWI, which is the
+largest that the middle-end can handle. So, we only take the
+first two elements of words, which is equivalent to wrapping the
+value if it's larger than the type range. */
low = words[0];
high = words[1];
And there's a small testcase, to see that the constant trees created for
overflowing values have the same value than the naturally overflowing
calculation done at run-time:
$ cat uu.f90
integer :: a
integer(kind=8) :: b
a = -3
b = -huge(b) / 7
a = a ** 73
b = 7894_8 * b - 78941_8
print *, (-3)**73, a
print *, 7894_8 * (-huge(b) / 7) - 78941_8, b
end
$ gfortran -fno-range-check uu.f90 && ./a.out
-1534976995 -1534976995
2635249153387000989 2635249153387000989
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Known to fail||4.1.3 4.2.0 4.3.0
Summary|-fno-range-check can trigger|-fno-range-check with large
|ICE |integer values triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31262
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-20 09:34 --- I didn't notice before, but can we have a testcase for the testsuite please? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c/31136] [4.2 Regression] FRE ignores bit-field truncation
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-20 10:00 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.2.0 Known to work||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-20 10:00:19 date|| Summary|FRE ignores bit-field |[4.2 Regression] FRE ignores |truncation |bit-field truncation Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-20 10:09 --- > > All compilers I know reject this code, except g95. The list includes Lahey, > > which is a reason for me to doubt whether this code is legal or not. The code is legal because the interface to test2 only needs the characteristics of the result to convert the actual arguments and to allocate space for the temporary. > > In any case, an ICE is an error. > Yes indeed! This is one of the most difficult diagnostic problems that I have faced with gfortran. It should be noted that character(10) :: ch(3) ... ch = test2(0) compiles and runs correctly. After a lot of head scratching and adding diagnostics all over the place, I found that the reason for this is that the compiler is able to take the lhs to determine the scalarization loop size, whereas this is not possible for write(*,*) len(test2(10)) The compiler is failing in trans-array.c (gfc_set_loop_bounds_from_array_spec), during the calls to gfc_apply_interface_mapping. If the block for upper is substituted by upper = gfc_index_one_node, the code compiles; it cannot run correctly because the temporary descriptor does not have the right bounds and the data allocation is incorrect. Apparently, the interface mapping is failing to substitute the actual values correctly and should, in any case treat LEN as a special case by substituting LEN (arg) by the expression for the character length of the argument. I am on to it! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-20 10:09:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug middle-end/31271] Missing simple optimization
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-20 10:39 --- Confirmed. This is neither done at the tree nor at the rtl level. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|rtl-optimization|middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-20 10:39:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31271
[Bug rtl-optimization/31272] gcc is being too clever
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:43 --- I see on x86_64 with -O2 (vrp can cleanup this somewhat): in_canforward: .LFB2: movl%edi, %eax andl$240, %eax cmpl$240, %eax je .L4 cmpl$224, %eax je .L4 testb %dil, %dil movl$1, %eax js .L5 movl%edi, %eax andl$255, %eax sete%dl cmpl$127, %eax sete%al orl %eax, %edx xorl$1, %edx movzbl %dl, %eax .L5: rep ; ret .p2align 4,,7 .L4: xorl%eax, %eax ret which looks in structure like what you are expecting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31272
[Bug tree-optimization/31274] [4.1 Regression] gcc 4.1 side effect missed (call clobbering is broken)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:54 --- Confirmed. Also related to PR28778 - call clobbering is broken in 4.1. I don't see us fixing this on the 4.1 branch though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work|4.3.0 |4.3.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-03-20 10:54:58 date|| Summary|[4.1 Regression] gcc 4.1|[4.1 Regression] gcc 4.1 |side effect missed |side effect missed (call ||clobbering is broken) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31274
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:04 --- I agree it's surprising to get user-visible effects with the TARGET_C99_FUNCTIONS difference between the frontends, but they are (supposed to) providing C99 runtime completion by their runtime libraries. And they rely on full C99 support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:05 --- A slightly related testcase is now properly optimized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug c++/31267] #'typename_type' not supported by dump_decl#
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-03-20
11:22 ---
I just encountered another instance of a missing typename diagnostic. This time
with a different message, so I add it here for completeness:
a.cpp:5: error: dependent-name T::#typename_type not supported by
pp_cxx_unqualified_id#::D is parsed as a non-type, but instantiation yields a
type
a.cpp:5: note: say typename T::#typename_type not supported by
pp_cxx_unqualified_id#::D if a type is meant
Testcase:
template
struct A
{
typedef typename T::B C;
void f() { C::D(); }
};
struct U
{
struct B { struct D {}; };
};
void g() { A().f(); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug c++/31267] #'typename_type' not supported by dump_decl#
--- Comment #2 from pcarlini at suse dot de 2007-03-20 11:45 --- Related to C++/30982? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
[Bug tree-optimization/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- Comment #6 from aph at gcc dot gnu dot org 2007-03-20 12:45 ---
Subject: Bug 31264
Author: aph
Date: Tue Mar 20 12:45:19 2007
New Revision: 123085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123085
Log:
2007-03-19 Andrew Haley <[EMAIL PROTECTED]>
PR tree-optimization/31264
* tree-vrp.c (register_edge_assert_for_1): Don't look though
VIEW_CONVERT_EXPRs.
2007-03-20 Andrew Haley <[EMAIL PROTECTED]>
* testsuite/libjava.lang/PR31264.java: New test.
Added:
trunk/libjava/testsuite/libjava.lang/PR31264.jar (with props)
trunk/libjava/testsuite/libjava.lang/PR31264.java
trunk/libjava/testsuite/libjava.lang/PR31264.out
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c
trunk/libjava/ChangeLog
Propchange: trunk/libjava/testsuite/libjava.lang/PR31264.jar
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
[Bug middle-end/30864] [4.3 Regression] ice for legal code with -O2
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-20 12:48 --- testcase works after PR31146 fix *** This bug has been marked as a duplicate of 31146 *** -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30864
[Bug tree-optimization/31146] forwprop does not look through casts
--- Comment #8 from mueller at gcc dot gnu dot org 2007-03-20 12:48 --- *** Bug 30864 has been marked as a duplicate of this bug. *** -- mueller at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-20 13:57 --- > The only reason why cexp is slow on PPC darwin is because the ABI is stupid. > Complex float arguments are passed via the GPR and returned also the same way > instead of via the FPRs. So you will get a transfer of registers. This is > also true of PPC64 darwin, why they made the same mistake twice I have no > idea, > guess they did not expect people to use complex that much. Is this also true for complex double on 32 bit architectures (i.e., 4 GPRs) or do you mean the GPR is used to pass a pointer? > ... . The number of cycles used up by this issue > can add up with both sides of the function having this hazard. You are comforting my prejudice against using procedures in critical loops. Now if you cannot convince darwin people to fix the problem, I cannot how I could. My short term interests are: (1) to understand how this reverse optimization is triggered. (2) to know what are the non-Linux platform that are affected beside Darwin. (3) to get a work around less hackish that what I did in my first example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug c/31275] ICE During Gettext Build
--- Comment #3 from arcangelpip at hotmail dot com 2007-03-20 13:58 --- I just tried with the latest sources for 4.1 and it still ICE with that. Same place same message. It may work on 4.2 and 4.3 but it doesn't work for me on 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31275
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-20 14:03 --- > I agree it's surprising to get user-visible effects with the > TARGET_C99_FUNCTIONS difference between the frontends, > but they are (supposed to) providing C99 runtime completion > by their runtime libraries. And they rely on full C99 support. Do you mean that g++ and gfortran set TARGET_C99_FUNCTIONS on their own? If yes, the cexpi optimization should probably another condition: what is the point to replace sin+cos by a call to a function calling sin+cos? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-20 14:26 --- That sin+cos is practically sincos (so you get one for free). Just not every library exports that sincos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug fortran/31278] New: Backtrace/coredump for array-out-of-bounds errors (-fbounds-check)
A backtrace (or coredump) would be nice for array out of bounds. It would have to be implemented in as library call. This could be combined with given more information (accessed index, allowed index) which is often requested, e.g. PR 31270). -- Summary: Backtrace/coredump for array-out-of-bounds errors (- fbounds-check) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31278
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #11 from dominiq at lps dot ens dot fr 2007-03-20 14:57 --- Subject: Re: pseudo-optimzation with sincos/cexpi > That sin+cos is practically sincos (so you get one for free). Just not every > library exports that sincos. Does not this assume that it exists a real sincos(x) and not a faked one thorugh cexp((1,x))? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-20 15:06 --- Depends on how you name it ;) You can propose that we only enable sincos transformation if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to that. (The targets I care for have a sincos) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 --- *** Bug 31275 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||arcangelpip at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug target/31275] ICE During Gettext Build
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 --- *** This bug has been marked as a duplicate of 29826 *** -- 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=31275
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-20 15:21 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug rtl-optimization/30841] [4.3 regression] Missed optimizations for sbi/cbi instructions
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-20 15:29 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #9 from pthaugen at us dot ibm dot com 2007-03-20 15:31 --- Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when building galgel benchmark from cpu2000. (My FORTRAN skills are lacking, so couldn't whittle down to a single testcase, but got close) 178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64 -ffixed-form -O2 -ftree-loop-linear modules.f90 178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64 -ffixed-form -O2 -ftree-loop-linear sysnsL.f90 sysnsL.f90: In function #sysnsl#: sysnsL.f90:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. (gdb) run Starting program: /home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64-linux/4.3.0/f951 sysnsL.f90 -quiet -dumpbase sysnsL.f90 -m64 -auxbase sysnsL -O2 -version -ffixed-form -ftree-loop-linear -fintrinsic-modules-path /home/pthaugen/install/gcc/trunk/lib/gcc/powerpc64-linux/4.3.0/finclude -o sysnsL.s GNU F95 version 4.3.0 20070314 (experimental) (powerpc64-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. remove_referenced_var (var=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-dfa.c:771 771 ggc_free (*loc); (gdb) bt 5 #0 remove_referenced_var (var=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-dfa.c:771 #1 0x103d1238 in remove_unused_locals () at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-live.c:518 #2 0x1026f204 in execute_function_todo (data=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:865 #3 0x1026ee44 in do_per_function (callback=0x1026efe0 , data=0x21) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:757 #4 0x1026ef4c in execute_todo (flags=33) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:935 (More stack frames follow...) -- pthaugen at us dot ibm dot com changed: What|Removed |Added CC||pthaugen at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-20 15:37 --- > Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when > building galgel benchmark from cpu2000. This is a different issue and should be filed in a different bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug middle-end/31279] New: Uninitialized warning for call-by-reference arguments with known intent(in)
In Fortran one can specify the intent of variables thus if all arguments have INTENT(IN) then GCC should be able to detect that alist in the call to cshift is uninitialized. This depends on the middle end support of intents (PR31094) plus using these in gfortran. Example (using an intrinsic function): program testcshft integer :: alist(4) alist =cshift(alist,-1) write(*,*) alist end program testcshft -- Summary: Uninitialized warning for call-by-reference arguments with known intent(in) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 31094 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #17 from spark at gcc dot gnu dot org 2007-03-20 15:42 --- Subject: Bug 30590 Author: spark Date: Tue Mar 20 15:42:37 2007 New Revision: 123087 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123087 Log: 2007-03-19 Seongbae Park <[EMAIL PROTECTED]> PR tree-optimization/30590 * g++.dg/opt/pr30590.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr30590.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug tree-optimization/31280] New: segfault in remove_referenced_var
Seeing the following with mainline using -O2 -ftree-loop-linear when building galgel benchmark from cpu2000. I couldn't whittle down to a single testcase so will attatch both source files. 178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64 -ffixed-form -O2 -ftree-loop-linear modules.f90 178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64 -ffixed-form -O2 -ftree-loop-linear sysnsL.f90 sysnsL.f90: In function #sysnsl#: sysnsL.f90:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. (gdb) run Starting program: /home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64-linux/4.3.0/f951 sysnsL.f90 -quiet -dumpbase sysnsL.f90 -m64 -auxbase sysnsL -O2 -version -ffixed-form -ftree-loop-linear -fintrinsic-modules-path /home/pthaugen/install/gcc/trunk/lib/gcc/powerpc64-linux/4.3.0/finclude -o sysnsL.s GNU F95 version 4.3.0 20070314 (experimental) (powerpc64-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGSEGV, Segmentation fault. remove_referenced_var (var=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-dfa.c:771 771 ggc_free (*loc); (gdb) bt 5 #0 remove_referenced_var (var=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-dfa.c:771 #1 0x103d1238 in remove_unused_locals () at /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-live.c:518 #2 0x1026f204 in execute_function_todo (data=) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:865 #3 0x1026ee44 in do_per_function (callback=0x1026efe0 , data=0x21) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:757 #4 0x1026ef4c in execute_todo (flags=33) at /home/pthaugen/src/gcc/trunk/gcc/gcc/passes.c:935 (More stack frames follow...) -- Summary: segfault in remove_referenced_var Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pthaugen at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug tree-optimization/31280] segfault in remove_referenced_var
--- Comment #1 from pthaugen at us dot ibm dot com 2007-03-20 15:53 --- Having trouble attatching source files, will keep trying... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #11 from pthaugen at us dot ibm dot com 2007-03-20 15:54 --- 31280 opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-20 16:08 --- > You can propose that we only enable sincos transformation > if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to > that. (The targets I care for have a sincos) Sound reasonable: replacing: return (TARGET_HAS_SINCOS || TARGET_C99_FUNCTIONS) && optimize; by return TARGET_HAS_SINCOS && optimize; in gcc/tree-ssa-math-opts.c, isn't it? I can even do a preliminary test to check that it does not break anything. What's bother me is that i suspect the problem is present for all non-Linux platforms and to have no feedback from them. If you have some idea about the way to trigger their interest, it would be nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-20 16:12 --- The recommended way is to post a message to gcc@gcc.gnu.org or [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-20 16:14 --- > Is this also true for complex double on 32 bit architectures (i.e., 4 GPRs) > or do you mean the GPR is used to pass a pointer? 4 GPRS Yes this was a stupid decission on Apple's part for not looking at fixing GCC before setting an ABI. And really this problem is only with PPC no other target has this stupid ABI issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #18 from spark at gcc dot gnu dot org 2007-03-20 16:44 --- Subject: Bug 30590 Author: spark Date: Tue Mar 20 16:44:00 2007 New Revision: 123089 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123089 Log: 2007-03-20 Seongbae Park <[EMAIL PROTECTED]> PR tree-optimization/30590 * g++.dg/opt/pr30590.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/pr30590.C Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #19 from spark at gcc dot gnu dot org 2007-03-20 16:45 --- Subject: Bug 30590 Author: spark Date: Tue Mar 20 16:44:54 2007 New Revision: 123090 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123090 Log: 2007-03-20 Seongbae Park <[EMAIL PROTECTED]> PR tree-optimization/30590 * g++.dg/opt/pr30590.C: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr30590.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug objc/31281] New: ICE on ObjC try-catch blocks
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
Summary: ICE on ObjC try-catch blocks
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug libstdc++/31282] New: SegV on AIX 5.3 due to uninit'ed static object when using -pthread
Just a note on the severity, I've marked this as a "blocker" because it seems
quite basic and it makes it impossible for us to use GCC/G++ to generate a
thread safe shared object for use with JNI. Please adjust as appropriate.
I'm not sure if this is a g++ bug or a libstdc++ bug, I've followed David
Edelsohn's suggestion that it's a library problem, but it's triggered by a
difference in a compiler option and the resulting initialization code, with the
complications produced by AIX xcoff linking thrown in for good measure.
I've reduced this to a three file example. The first file contains a main and
tries to use a static string declared in the second (header) file which it
includes. The third file contains the actual definition of the static string.
If I compile this with -pthread it dies with a SEGV because the string objects
are uninitialized and it's trying to follow a null pointer. Compiled without
-pthread it works just fine. David and I have comfirmed this with multiple
versions of the OS (5.2, 5.3) and gcc (4.1.1, 4.1.2, 4.2). According to him it
works in 4.3, but since that's still a development version it's not really a
viable option for production software yet.
I'd love to hear that this isn't a bug and that we just need to change some
copilation or link flag, but
[EMAIL PROTECTED] aix_gcc_problem]$ g++ -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../gcc-4.1.1/configure --prefix=/usr/local
--enable-languages=c,c++ --enable-long-long --enable-threads=aix
--enable-version-specific-runtime-libs --enable-shared --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --with-ar=/usr/bin/ar
Thread model: aix
gcc version 4.1.1
[EMAIL PROTECTED] aix_gcc_problem]$ cat main.cpp
#include
#include
#include
#include
using namespace std;
namespace foo {
extern const string a;
}
namespace foo {
extern const string a = "Hello world!";
}
int main(int argc, char **argv)
{
std::cout << foo::a << std::endl;
std::cout << Res::InvalidDayOfWeek << std::endl;
for (int i = 0 ; i < argc ; ++i)
std::cout << argv[i] << std::endl;
}
[EMAIL PROTECTED] aix_gcc_problem]$ cat StatusMessageIDs_mini.h
#ifndef STATUSMESSAGEIDS_INCLUDE_GUARD
#define STATUSMESSAGEIDS_INCLUDE_GUARD
#include
namespace Res // contains all resource ids
{
typedef const std::string ID;
extern ID InvalidDayOfWeek;
} // namespace Res
#endif // STATUSMESSAGEIDS_INCLUDE_GUARD
[EMAIL PROTECTED] aix_gcc_problem]$ cat StatusMessageIDs_mini.cpp
#include "StatusMessageIDs_mini.h"
namespace Res // contains all resource ids
{
extern ID InvalidDayOfWeek("engine.status.agorai.invalidDayOfWeek");
} // namespace Res
[EMAIL PROTECTED] aix_gcc_problem]$ cat example.sh
#!/bin/bash
CXX=g++
CXX_OPTS="-fPIC -Wall -Werror -mminimal-toc -ggdb3"
#CXX_OPTS="-pthread $CXX_OPTS"
rm -f *.[oa] example
$CXX $CXX_OPTS -I. -o main.o -c main.cpp
$CXX $CXX_OPTS -o StatusMessageIDs_mini.o -c StatusMessageIDs_mini.cpp
/usr/bin/ar cr libexample.a ./StatusMessageIDs_mini.o
/usr/bin/ranlib libexample.a
$CXX $CXX_OPTS main.o ./libexample.a -o example
echo
./example a b c
--
Summary: SegV on AIX 5.3 due to uninit'ed static object when
using -pthread
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tom dot culliton at oracle dot com
GCC build triplet: powerpc-ibm-aix5.3.0.0
GCC host triplet: powerpc-ibm-aix5.3.0.0
GCC target triplet: powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-20 17:09 --- Spill slots *are* being aligned, else you'd see SEGV, not incorrect data. Aliasing *is* the problem: pand(%esi), %xmm0 movl$1, (%ebx) movl$2, 4(%ebx) movl$3, 8(%ebx) movl$4, 12(%ebx) movdqa %xmm0, (%esi) note the pand before the 1,2,3,4 being stored. The problem here is our choice of vector on which to base __m128i. For some reason we chose V2DImode instead of V4SImode. It's probably easiest to fix this by adding the may_alias attribute to all of the user-visible types provided by the Intel API. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-20 17:09:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug objc/31283] New: ICE on ObjC try-catch blocks
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
Summary: ICE on ObjC try-catch blocks
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31283
[Bug objc/31281] ICE on ObjC try-catch blocks with next runtime
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:16 --- This works for me on the trunk on powerpc-linux-gnu with the GNU runtime and next runtime. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE on ObjC try-catch blocks|ICE on ObjC try-catch blocks ||with next runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug objc/31281] ICE on ObjC try-catch blocks with next runtime
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 --- *** Bug 31283 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug objc/31283] ICE on ObjC try-catch blocks
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 --- *** This bug has been marked as a duplicate of 31281 *** -- 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=31283
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug tree-optimization/31280] segfault in remove_referenced_var
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:34 --- You can just send them to me if you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug fortran/31278] Backtrace/coredump for array-out-of-bounds errors (-fbounds-check)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:36 --- It is not hard to do "b _gfortran_out_of_bounds" in gdb. I never understood why gfortran or any language these extra features when there is something called a debugger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31278
[Bug middle-end/31284] New: Uninitialized variable not detected
In the following program, the uninitialized "i" is only detected if one uncomments the print statement. program test implicit none integer :: i,j j = i*5 print*,i end program test -- Summary: Uninitialized variable not detected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
[Bug middle-end/31284] Uninitialized variable not detected
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-20 17:38 --- Forgot to write that this is a Fortran program. Use gfortran -Wall -O to compile it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
[Bug middle-end/31284] Uninitialized variable not detected
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:43 --- And the issue here is really PR19430 For some reason gfortran decided that print will cause a pass via reference :). *** This bug has been marked as a duplicate of 19430 *** -- 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=31284
[Bug middle-end/19430] Missing uninitialized warning
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 17:43 --- *** Bug 31284 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug fortran/31278] Backtrace/coredump for array-out-of-bounds errors (-fbounds-check)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-20 17:45 --- > It is not hard to do "b _gfortran_out_of_bounds" in gdb. Well, it is not always easy to find the symbol. In C it is much easier: Essentially all you type is what you get. Fortran with all its hidden library calls is more difficult. How does one quickly find _gfortran_out_of_bounds if one is not experienced in debugging and does not have the source of GCC? And after all, we do have now coredump/backtrace support, why not use it? > I never understood why gfortran or any language these extra features when > there is something called a debugger. Well, it is easier to have a backtrace directly rather than messing around with a debugger, finding all the needed symbols, finding the right executable. (I know several Fortran programs, which are glued together by a huge cascade of shell scripts, last but not least because Fortran 95 does not support command line arguments. There, even finding the program which crashed is challenging.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31278
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-20 17:50 --- I don't see why nobody besides me thinks that consistency, whether it's mandated by the standard or not is a user-friendly feature. Yes I understand the arguments for our current behavior, but I'm not going to discuss this any further, I don't think it's important enough as I said on the mailing list. I'd just like to note that I'd prefer if Andrew had chosen not to outvote an --admittedly inactive-- Fortran maintainer (myself) twice, and had instead left it to the other Fortran maintainers to decide. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 18:03 --- > I don't see why nobody besides me thinks that consistency Because the code is undefined either way you look at it :). Yes GCC might allow it to work without -fbounds-check but that does not mean it will work somewhere else. Also Steve agreed with me ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug tree-optimization/31280] segfault in remove_referenced_var
--- Comment #3 from pthaugen at us dot ibm dot com 2007-03-20 18:09 --- Created an attachment (id=13238) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13238&action=view) Fortran source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug tree-optimization/31280] segfault in remove_referenced_var
--- Comment #4 from pthaugen at us dot ibm dot com 2007-03-20 18:10 --- Created an attachment (id=13239) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13239&action=view) Fortran source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #21 from pluto at agmk dot net 2007-03-20 18:52 --- http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #8 from mimo2 at free dot fr 2007-03-20 18:52 --- Why do you say the code is undefined. The last version (comment #5) is totally valid, but possible side effects in the function k could lead to different results depending on the fact that the -fbounds-check is set or no. And this is not a sane behaviour. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-20 18:57 --- (In reply to comment #8) > Why do you say the code is undefined. The last version (comment #5) is totally > valid, but possible side effects in the function k could lead to different > results depending on the fact that the -fbounds-check is set or no. No, the last one just shows how the code is really undefined. > And this is not a sane behaviour. Fortran is not C here sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #22 from manu at gcc dot gnu dot org 2007-03-20 19:01 --- (In reply to comment #21) > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html > Hint, if you use the patch queue[1], it takes care of adding a comment pointing to the patch. Also, your patch lacks a Changelog [2]. See also an example [3]. [1] http://www.dberlin.org/patchdirections.html [2] http://gcc.gnu.org/codingconventions.html [3] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg8.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #10 from tobi at gcc dot gnu dot org 2007-03-20 19:11 --- Mimo, you rely on behavior that is not specified by the standard. It says explicitly that only, in order to determine the value of an expression, only as much of it needs to be evaluated, as is needed to determine the vlaue of the entire expression. E.g. in "sqrt(x) + f(y)" f(y) needs not be executed if x is < 0. The result will be NaN after all. But this doesn't mean that negative x implies that f(y) won't be executed. If you want sane behavior, the general rule is to follow the standard. Now I personally think that, since we're using shortcut logic, it's perfectly sane to, so to say, shortcut bounds checking as well. Other people have disagreed, and they have strong arguments in their favor. As for side-effects, one can easily come up with weird cases, which is why the standard refrains from defining them. Think e.g. about b .and. f(b) .and. b where f may change its argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug libfortran/31286] New: cshift uses uninitialized variables
As found by Salvatore Filippone using valgrind.
---
program testcshft
integer :: alist(4)
!!$alist = (/1,2,3,4/)
alist =cshift(alist,-1)
write(*,*) alist
end program testcshft
-
==6801== Conditional jump or move depends on uninitialised value(s)
> ==6801==at 0x1B98AF30: cshift0 (cshift0.c:193)
> ==6801==by 0x8048673: MAIN__
Analysis by me:
alist = cshift(alist,-1)
This calls cshift0(ret, array, shift, which, size)
where size = GFC_DESCRIPTOR_RANK (array)
and "which" is the dimension (not given -> 1)
Thus: which == size == 1.
In cshift0 one finds:
which = which - 1;
for (dim = 0; dim < GFC_DESCRIPTOR_RANK (array); dim++)
{
if (dim == which) { ... }
else
{ sstride[n] = ... }
}
if (sstride[0] == 0)
That is: If which == rank of the array, sstride gets never initialized.
Index: libgfortran/intrinsics/cshift0.c
===
*** libgfortran/intrinsics/cshift0.c(revision 123083)
--- libgfortran/intrinsics/cshift0.c(working copy)
*** cshift0 (gfc_array_char * ret, const gfc
*** 103,108
--- 103,110
runtime_error ("Argument 'DIM' is out of range in call to 'CSHIFT'");
which = which - 1;
+ sstride[0] = 0;
+ rstride[0] = 0;
extent[0] = 1;
count[0] = 0;
--
Summary: cshift uses uninitialized variables
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code, patch
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31286
[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor
--- Comment #23 from patchapp at dberlin dot org 2007-03-20 19:42 --- Subject: Bug number PR7302 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/2007-03/msg01347.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
[Bug c++/31277] incorrect c++ code produces g++ internal error
--- Comment #1 from bangerth at dealii dot org 2007-03-20 20:02 --- Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.0.0 4.0.4 4.1.2 Known to work||3.4.6 Last reconfirmed|-00-00 00:00:00 |2007-03-20 20:02:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31277
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #11 from mimo2 at free dot fr 2007-03-20 20:12 --- hi tobi, may-be they have strong arguments as you say, but I've not catched them. And I still believe that if there is an ambiguity in the standard, the solution is to have a -fshort-circuit to let the user decide what he wants, and more importantly that this option applies equally to bound-checking or not. The other thing I wanted to add is that I've worked on alpha with f90, and I could bound-check my program, so I guess they were short-circuiting it. Then I switched to linux with pgf90, and there also bound-check was working with my program. Now I'm trying free compilers, i.e. gfortran and g95. With g95, short-circuit is also applied on bound-checks. There is only gfortran which has this singular behaviour. I agree this doesn't prove anything, and may-be gfortran is the only "standard compliant" program. But I'll stop this discussion here, and will stay with g95 when I want to bound-check my program. Thanks anyway to all for the time spent to answer my questions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-03-20 20:17 --- Subject: Re: short-circuit in -fbounds-check I'm on your side, mimo, no need to convince me :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 20:58 --- > But I'll stop this discussion here, and will stay with g95 when I want to > bound-check my program. Why short circuiting is legal and so is not short circuiting. Yes Gfortran's behavior is semi inconstaint but that does not make gfortran's behavior incorrect. In fact I want to say Gfortran's behavior with -fbounds-check with not short circuiting is actually a good thing because you catch more invalid/undefined fortran code that way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug c++/31287] New: Infinite for loop while initializing char array
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
name_array[i][0] = '\0';
}
return 1;
}
Here are my compile options
g++ -o testloop testloop.cpp
Example of the output
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
Loop i: 7
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
Loop i: 7
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
--
Summary: Infinite for loop while initializing char array
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryan_sauser at pa-ucl dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
[Bug c++/31287] Infinite for loop while initializing char array
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:01 --- Note you are going over name_array's bounds so you are invoking undefined behavior. 7 <= 7. arrays go from 0 to last-1 in C or (0, last-1] in math notation for C arrays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
[Bug c++/31287] Infinite for loop while initializing char array
--- Comment #2 from bryan_sauser at pa-ucl dot com 2007-03-20 21:03 --- Was code given to me by Contract programmer. Released person simple mistake after reviewing. -- bryan_sauser at pa-ucl dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
[Bug c++/31288] New: Infinite for loop while initializing char array
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
name_array[i][0] = '\0';
}
return 1;
}
Here are my compile options
g++ -o testloop testloop.cpp
Example of the output
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
Loop i: 7
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
Loop i: 7
Loop i: 1
Loop i: 2
Loop i: 3
Loop i: 4
Loop i: 5
Loop i: 6
--
Summary: Infinite for loop while initializing char array
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bryan_sauser at pa-ucl dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31288
[Bug fortran/31269] short-circuit in -fbounds-check
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-03-20 21:04 --- Subject: Re: short-circuit in -fbounds-check pinskia at gcc dot gnu dot org wrote: >> But I'll stop this discussion here, and will stay with g95 when I want to >> bound-check my program. > > Why short circuiting is legal and so is not short circuiting. Yes Gfortran's > behavior is semi inconstaint but that does not make gfortran's behavior > incorrect. In fact I want to say Gfortran's behavior with -fbounds-check with > not short circuiting is actually a good thing because you catch more > invalid/undefined fortran code that way. How about we stop this discussion? I don't think anyone was volunteering to implement a solution anyway. To sum up the alternatives: you repeated the argument for one side above. Other people want their program to do the same thing whether bounds checking is enabled or not -- except in the case where the non bounds-checking program would have made an out-of-bounds access. Neither party is "right", I consider this latter behavior preferable. Thank you, and goodbye. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #30 from sje at cup dot hp dot com 2007-03-20 21:13 --- I tried the C++ and Fortran tests (in addition to C) with version 122821 using a non-boostrapped compiler but I got no new failures. It looks like the only failing test case we have is the compiler itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug c++/31287] Infinite for loop while initializing char array
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 --- *** Bug 31288 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
[Bug c++/31288] Infinite for loop while initializing char array
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 --- *** This bug has been marked as a duplicate of 31287 *** -- 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=31288
[Bug c/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:40 --- What tools are you using for the cross-compiler? Cross-compiling to AIX is not supported because the rest of the GNU crosstools are incomplete for AIX 5. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org GCC target triplet|powerpc-ibm-aix5.3.0|powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:43 ---
Compiling with -pthread adds -D_THREAD_SAFE to the defined macros, which causes
different header files to be included. Prior to GCC 4.3, this appears to cause
a non-unique name to be chosen for the global constructor in the file. When
compiling with -pthread, the first global object seen is:
struct thread_credentials {
uint flags;
cred_ext_t cred;
int reserved[9];
} thread_creds_t;
in /usr/include/sys/thread.h
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
CC||dje at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-03-20 21:43:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug c/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #2 from kstemen at centeris dot com 2007-03-20 21:45 --- I'm trying to create rpms of cross compilers. I looked on the crosstools website, but it doesn't look like it supports that. So I am more or less building the cross compiler from scratch. I noticed that C++ is unsupported when cross compiling to AIX. I attempted to fix it, but I got stuck on this bug. If it would help you, I can give you the options I used to configure binutils, and a list of the AIX libraries in my AIX sysroot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #2 from dje at gcc dot gnu dot org 2007-03-20 21:47 --- Andrew Pinski pointed out that this is known with a workaround: http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=747&thread=119546&cat=72 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:48 --- http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html According to IBM, the fix for this APAR IY90737 is incorporated into Service Pack 5300-05-04. Do you have that installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug other/31282] SegV on AIX 5.3 due to uninit'ed static object when using -pthread
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-20 21:48 --- and more info http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:59 --- >If it would help you, I can give you the options I used to configure binutils, > and a list of the AIX libraries in my AIX sysroot. Does not matter, binutils does not support AIX 5.3 features. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #4 from kstemen at centeris dot com 2007-03-20 22:10 --- Tell me what binutils doesn't support and I'll file a bug on binutils. I already filed a bug about the default rpath in the cross compiler version of gnu ld for AIX 5.3.0.0, and they fixed it. They didn't say anything about not supporting AIX. If cross-compiling to AIX 5 is not supported, why don't you say that in the AIX specific notes at http://gcc.gnu.org/install/specific.html#x-ibm-aix instead of letting people waste their time trying to get it to work? From all the searching I've done online to get parts of it to work, this is the first time I'm hearing that it's unsupported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-20 22:15 --- "The native as and ld are recommended for bootstrapping on AIX 4 and required for bootstrapping on AIX 5L. The GNU Assembler reports that it supports WEAK symbols on AIX 4, which causes GCC to try to utilize weak symbol functionality although it is not supported. The GNU Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC. The native AIX tools do interoperate with GCC." It is there already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #6 from kstemen at centeris dot com 2007-03-20 22:19 --- That says you can't bootstrap GCC on AIX 5L with GNU ld and as. It doesn't say you can't build a cross compiler with them, and it doesn't say you can't use them after GCC is bootstrapped. In fact, I have looked at collect2's source code and using GNU ld and as would probably work on native AIX after GCC is bootstrapped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug other/31033] Collect2 will not allow shared gcc with cross compiler
--- Comment #7 from dje at gcc dot gnu dot org 2007-03-20 22:41 --- If GNU Binutils and Linker do not support AIX 5L sufficiently to bootstrap GCC, then you should infer that does not support AIX 5L sufficiently for anything "interesting", like shared libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
[Bug tree-optimization/31264] internal compiler error: in build_int_cst_wide, at tree.c:886
--- Comment #7 from membar at gcc dot gnu dot org 2007-03-20 22:45 --- This fix works for me. Thanks. Not sure who's responsible for closing this out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
