[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #11 from dorit at il dot ibm dot com 2007-02-06 08:18 --- (In reply to comment #10) One thing I can think of that this description misses is that the two pointers must be based-on *different* restrict-qualified pointers, unless that case is already handled elsewhere. yes, at the beginning of this function we check if the two pointers are the same, and if so - we don't reach this part of the code. Since our implementation of based on is the pointer itself (i.e. is ptr_a based on some restricted pointer ptr_b is implemented as is ptr_a a restricted pointer, we are safe. You're right though that when the implementation of based on is extended, we'd need to compare the two restricted pointers (we now compare the two ptr_a's, we'd need to compare the two ptr_b's). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #29 from paolo dot bonzini at lu dot unisi dot ch 2007-02-06 08:26 --- Subject: Re: Shared libstdc++ fails to link Paolo, would you be able to undo the change to make foo not marked TREE_NOTHROW? IIUC, that would be different than the patch you posted in Comment #22, which appears to affect bar. My patch was related to Richi's comment when CCing me; the only patch I found from me that was related to TREE_NOTHROW subtly changed the semantics, and that patch sort of undone that change (I say sort of because it takes a little more care actually). Also, I didn't quite understand your patch, in that it would appear to result in fewer functions being marked TREE_NOTHROW It would result in more functions being marked TREE_NOTHROW, since those functions will not go through the insn loop in set_nothrow_function_flags if the front-end declared them nothrow. I'm attaching an updated version of the patch, which passes some internal (i.e. my brain and a small testcase using weak and nothrow) sanity checks, but I've not tried in any real world situation. It's actually an alternate fix for PR29323 which doesn't trigger this bug. I'll let other people consider if it makes any sense since I'm not at all expert in this area. I would think we want to remove the check for binds_local_p at the top of set_nothrow_function_flags? Agreed, and we have to move it elsewhere. (See the upcoming patch). Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #30 from bonzini at gnu dot org 2007-02-06 08:37 --- Created an attachment (id=13011) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view) proposed, untested patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug fortran/30609] Calculating masks twice
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-06 08:39 --- Confirmed, although I'm not exactly sure how we could detect that. Maybe we would need to add front-end optimization passes, between resolution and translation... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-06 08:39:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-02-06 09:26 --- The patch proposed makes sense, Dave can you verify it fixes this PR for you? I'll spin some testing on the trunk in a moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/30711] New: Ifstream bug using Red Hat g++-4.1.0 compared to g++-4.0.2
When an ifstream object is used in several open()-close() cycles, it seems to remember past cycles in the Red Hat gcc version. STEPS TO REPRODUCE: 1) Compile the attached code using gcc version 4.1.0 20060515 (Red Hat 4.1.0-18) 2) Compile the attached code using gcc version 4.0.2 3) Create a file named filetest.mat in the directory where you exectude the binaries 4) Compare the results: They are different ACTUAL RESULTS: (Output from program compiled with gcc 4.1.0 20060515 (Red Hat 4.1.0-18)) -- Try 1: ifstream-declaration outside loop (not working) could not open file ./not_existing_directory/filetest.mat could not open file ./filetest.mat -- Try 2: ifstream-declaration inside loop (working) could not open file ./not_existing_directory/filetest.mat could open file ./filetest.mat -- EXPECTED RESULTS: (Output from program compiled with gcc 4.0.2) -- Try 1: ifstream-declaration outside loop (not working) could not open file ./not_existing_directory/filetest.mat could open file ./filetest.mat -- Try 2: ifstream-declaration inside loop (working) could not open file ./not_existing_directory/filetest.mat could open file ./filetest.mat -- BUILD INFOS: Faulty version: --- gcc version 4.1.0 20060515 (Red Hat 4.1.0-18) Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.3 --enable-libgcj-multifile --enable-languages=c,c++,java,f95 --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix Working version: gcc version 4.0.2 Reading specs from /usr/pack/gcc-4.0.2-mo/amd64-debian-linux3.1/lib/gcc/x86_64-unknown-linux-gnu/4.0.2/specs Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/pack/gcc-4.0.2-mo --exec-prefix=/usr/pack/gcc-4.0.2-mo/amd64-debian-linux3.1 --with-gxx-include-dir=/usr/pack/gcc-4.0.2-mo/include/c++ --disable-nls --enable-languages=c,c++,f95 Thread model: posix -- Summary: Ifstream bug using Red Hat g++-4.1.0 compared to g++- 4.0.2 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steigers at phys dot ethz dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711
[Bug c++/30711] Ifstream bug using Red Hat g++-4.1.0 compared to g++-4.0.2
--- Comment #1 from steigers at phys dot ethz dot ch 2007-02-06 10:05 --- Created an attachment (id=13012) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13012action=view) Code for testing the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711
[Bug tree-optimization/30317] VRP cannot extract a range from (unsigned int) i + 0x0ffffffff 4
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-02-06 10:08 --- Created an attachment (id=13013) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13013action=view) alternate patch This patch tackes the issue by allowing a_2 = ASSERT_EXRP a_1, (unsigned)a_1 + 5 = 10 (and similar expressions). A variant of this patch which had not undergone a last-minute cosmetic cleanup survivied all-languages bootstrap and regtest on x86_64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
[Bug c++/30703] ICE Segmentation fault on using OpenMP
--- Comment #2 from jakub at gcc dot gnu dot org 2007-02-06 10:11 ---
Simplified testcase:
struct A
{
A() {}
~A() {}
int i;
};
void
foo (A a)
{
#pragma omp parallel firstprivate (a)
a.i++;
}
The problem is that while OpenMP 2.5 prohibits firstprivate etc. vars having
reference type (and we properly diagnose it), cp_genericize_r changes
TREE_ADDRESSABLE class parameters to reference type internally and this is
something cc1plus should handle.
--
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 |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-02-06 10:11:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #32 from amylaar at gcc dot gnu dot org 2007-02-06 10:18 --- (In reply to comment #30) Created an attachment (id=13011) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view) [edit] proposed, untested patch As far as I can tell, this patch takes care of the correctness issues, however at the expense of optimization. Declaring a function as nothrow will no longer enable optimizations in the callers that depend on the the callee to be nothrow. Including analysis that finds the caller to be nothrow, so again, exception handling information of libraries is likely to increase. I don't think it makes sense that you hijack the tree flag of the declaration to be not about the declaration at all. Andrew Pinski's observation in #12 that the root problem is to try to squish two bits int one still stands. IMO the bit formerly known as current_function_nothrow should be put into struct function, and then found via cfun. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/30711] Ifstream bug using Red Hat g++-4.1.0 compared to g++-4.0.2
--- Comment #2 from steigers at phys dot ethz dot ch 2007-02-06 10:33 --- Apparently if the close() statement is followed by a clear() statement it works. I t also works if close() is omitted and only clear() is called. I therefore suspect that someone forgot to change the status of the stream in the open() method of the fulty compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #33 from rguenth at gcc dot gnu dot org 2007-02-06 10:39 --- It does not work either: /abuild/rguenther/obj-29487/./gcc/xgcc -shared-libgcc -B/abuild/rguenther/obj-29487/./gcc -nostdinc++ -L/abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -D_GNU_SOURCE -I/abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/abuild/rguenther/gcc/libstdc++-v3/libsupc++ -O2 -g /abuild/rguenther/gcc/libstdc++-v3/include/precompiled/extc++.h -o x86_64-unknown-linux-gnu/bits/extc++.h.gch/O2g.gch In file included from /abuild/rguenther/gcc/libstdc++-v3/include/precompiled/extc++.h:65: /abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/exception.hpp: In function 'void pb_ds::__throw_insert_error()': /abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/exception.hpp:79: error: statement marked for throw, but doesn't D.155211_27 = D.155210_26; /abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/exception.hpp:79: error: statement marked for throw, but doesn't D.155275_49 = D.155274_48; /abuild/rguenther/obj-29487/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/exception.hpp:79: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [x86_64-unknown-linux-gnu/bits/extc++.h.gch/O2g.gch] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #34 from bonzini at gnu dot org 2007-02-06 10:41 --- The two bits were actually the same, since passes.c was doing this exactly after calling set_nothrow_function_flags if (current_function_nothrow) /* Now we know that this can't throw; set the flag for the benefit of other functions later in this translation unit. */ TREE_NOTHROW (current_function_decl) = 1; The patch I proposed does not hinder optimization that much. Declaring a function as nothrow will still enable optimizations in the callers that depend on the the callee to be nothrow, as far as the callee binds locally; this includes static functions, non-default visibility functions, and locally declared non-weak functions. Richard, another necessary hunk for correctness would be this: Index: cvs/gcc/gcc/tree-eh.c === --- cvs/gcc/gcc/tree-eh.c (revision 120669) +++ cvs/gcc/gcc/tree-eh.c (working copy) @@ -1979,8 +1979,7 @@ tree_could_trap_p (tree expr) case CALL_EXPR: t = get_callee_fndecl (expr); - /* Assume that calls to weak functions may trap. */ - if (!t || !DECL_P (t) || DECL_WEAK (t)) + if (!t || !DECL_P (t) || !targetm.binds_local_p (t)) return true; return false; Finally, let me remark again that I'm *no expert in this area*. I'd be pretty nervous if this patch ended up in 4.1.2 without huge scrutiny from experts. I'll prepare a patch to revert my 2004 change too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #35 from amylaar at gcc dot gnu dot org 2007-02-06 11:10 --- (In reply to comment #25) I think the analysis should be deeper than just binds_local_p, though; I think it should be based on whether attribute ((weak)) (or equivalent) explicitly appears, so that we don't pessimize bar if foo is in a template function, out-of-line inline, or other such function. The test ought to be based on the demonstrable intent of the user to replace the function, not on whether or not the function happens to be weak. Thinking a bit more about this, I agree. If the function is declared in the same translation unit, and no attribute or pragma prevents the function from being inlined, it is already fair game for inlining, irrespective of wether it binds locally or not. Thus, if we decide for pragmatic reasons (code size, snafus in analysis) not to inline such a function, we should still be able to use analysis results about nothrow, const and pure characteristics of the function. When we get to the point where we can do cross-module optimizations (LTO or otherwise), some other issues arise: The situation is a bit different if the function is defined in a different translation unit. For shared libraries, putting functions into separate translation unit is a common technique to show that the function should not be inlined into a function in a different translation unit, or any analysis results applied to a caller/callee in a different translation unit. But it would make sense to have an option to enable such inlining / analysis, and even to turn it on by default, since for any ordinary conformant program the one-definition rule applies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #36 from amylaar at gcc dot gnu dot org 2007-02-06 11:17 --- (In reply to comment #34) I'll prepare a patch to revert my 2004 change too. I suspect that a 100% literal reversion will run into problems where the use of a global variable will result in the the analysis of one function being applied to another function. It will probably work (modulo minor merge conflicts) if instead of bringing the global variable current_function_nothrow back, you define a nothrow bit in struct function and #define current_function_nothrow cfun-nothrow . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-06 12:12 --- (In reply to comment #5) Min/maxval should return (for REAL): +INF if there is an INF in the maxval argument array -INF if there is a -INF in the minval argument array NAN if the argument array only consists of NAN -HUGE or HUGE if there the array is zero-dimensional (after masking) (for the other cases the obvious min/max values of the arguments) For INTEGERs, we only have: -HUGE-1 / +HUGE for a zero-dimensional array (after masking) (for the other cases the obvious min/max) as NAN and +/-INF don't exists (cf. PR30512). I agree with that. I think we need separate m4 files for integers and reals, changing the Makefile in the following way: Index: Makefile.am === --- Makefile.am (revision 121506) +++ Makefile.am (working copy) @@ -175,10 +175,12 @@ generated/maxloc1_8_r16.c \ generated/maxloc1_16_r16.c -i_maxval_c= \ +i_maxval_i_c= \ generated/maxval_i4.c \ generated/maxval_i8.c \ -generated/maxval_i16.c \ +generated/maxval_i16.c + +i_maxval_r_c= \ generated/maxval_r4.c \ generated/maxval_r8.c \ generated/maxval_r10.c \ @@ -230,10 +232,12 @@ generated/minloc1_8_r16.c \ generated/minloc1_16_r16.c -i_minval_c= \ +i_minval_i_c= \ generated/minval_i4.c \ generated/minval_i8.c \ -generated/minval_i16.c \ +generated/minval_i16.c + +i_minval_r_c= \ generated/minval_r4.c \ generated/minval_r8.c \ generated/minval_r10.c \ @@ -419,9 +423,9 @@ generated/pow_c16_i16.c m4_files= m4/iparm.m4 m4/ifunction.m4 m4/iforeach.m4 m4/all.m4 \ -m4/any.m4 m4/count.m4 m4/maxloc0.m4 m4/maxloc1.m4 m4/maxval.m4 \ -m4/minloc0.m4 m4/minloc1.m4 m4/minval.m4 m4/product.m4 m4/sum.m4 \ -m4/matmul.m4 m4/matmull.m4 \ +m4/any.m4 m4/count.m4 m4/maxloc0.m4 m4/maxloc1.m4 m4/maxval_i.m4 \ +m4/maxval_r.m4 m4/minloc0.m4 m4/minloc1.m4 m4/minval_i.m4 m4/minval_r.m4 \ +m4/product.m4 m4/sum.m4 m4/matmul.m4 m4/matmull.m4 \ m4/ctrig.m4 m4/cexp.m4 m4/chyp.m4 m4/mtype.m4 \ m4/specific.m4 m4/specific2.m4 m4/head.m4 m4/shape.m4 m4/reshape.m4 \ m4/transpose.m4 m4/eoshift1.m4 m4/eoshift3.m4 m4/exponent @@ -429,8 +433,8 @@ m4/misc_specifics.m4 m4/rrspacing.m4 m4/spacing.m4 gfor_built_src= $(i_all_c) $(i_any_c) $(i_count_c) $(i_maxloc0_c) \ -$(i_maxloc1_c) $(i_maxval_c) $(i_minloc0_c) $(i_minloc1_c) $(i_minval_c) \ -$(i_product_c) $(i_sum_c) \ +$(i_maxloc1_c) $(i_maxval_i_c) $(i_maxval_r_c) $(i_minloc0_c) \ +$(i_minloc1_c) $(i_minval_i_c) $(i_minval_r_c) $(i_product_c) $(i_sum_c) \ $(i_matmul_c) $(i_matmull_c) $(i_transpose_c) $(i_shape_c) $(i_eoshift1_c) \ $(i_eoshift3_c) $(i_cshift1_c) $(i_reshape_c) $(in_pack_c) $(in_unpack_c) \ $(i_exponent_c) $(i_fraction_c) $(i_nearest_c) $(i_set_exponent_c) \ @@ -647,18 +651,24 @@ $(i_maxloc1_c): m4/maxloc1.m4 $(I_M4_DEPS1) $(M4) -Dfile=$@ -I$(srcdir)/m4 maxloc1.m4 $(srcdir)/$@ -$(i_maxval_c): m4/maxval.m4 $(I_M4_DEPS1) - $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval.m4 $(srcdir)/$@ +$(i_maxval_i_c): m4/maxval_i.m4 $(I_M4_DEPS1) + $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval_i.m4 $(srcdir)/$@ +$(i_maxval_r_c): m4/maxval_r.m4 $(I_M4_DEPS1) + $(M4) -Dfile=$@ -I$(srcdir)/m4 maxval_r.m4 $(srcdir)/$@ + $(i_minloc0_c): m4/minloc0.m4 $(I_M4_DEPS0) $(M4) -Dfile=$@ -I$(srcdir)/m4 minloc0.m4 $(srcdir)/$@ $(i_minloc1_c): m4/minloc1.m4 $(I_M4_DEPS1) $(M4) -Dfile=$@ -I$(srcdir)/m4 minloc1.m4 $(srcdir)/$@ -$(i_minval_c): m4/minval.m4 $(I_M4_DEPS1) - $(M4) -Dfile=$@ -I$(srcdir)/m4 minval.m4 $(srcdir)/$@ +$(i_minval_i_c): m4/minval_i.m4 $(I_M4_DEPS1) + $(M4) -Dfile=$@ -I$(srcdir)/m4 minval_i.m4 $(srcdir)/$@ +$(i_minval_r_c): m4/minval_r.m4 $(I_M4_DEPS1) + $(M4) -Dfile=$@ -I$(srcdir)/m4 minval_r.m4 $(srcdir)/$@ + $(i_product_c): m4/product.m4 $(I_M4_DEPS1) $(M4) -Dfile=$@ -I$(srcdir)/m4 product.m4 $(srcdir)/$@ I don't know what the status is of the other patch for MAXVAL/MINVAL, but we should probably combine them into a single patch (in particular to ease the backporting). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |libfortran Last reconfirmed|2007-02-05 19:40:47 |2007-02-06 12:12:21 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-06 12:25 --- $ cat pr29400-3.f90 integer,parameter :: i(1,1) = 0 logical :: l l = any(i==1) end $ gfortran pr29400-3.f90 ./a.out pr29400-3.f90: In function MAIN__: pr29400-3.f90:1: internal compiler error: in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.c:1339 Same thing happens for count. We try to walk the constant, and it doesn't work (we fail on the next assert). dot_product works, while seemingly doing the same thing, maybe we can borrow from it... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-09 12:44:16 |2007-02-06 12:25:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-06 12:30 --- I don't know what the status is of the other patch for MAXVAL/MINVAL, but we should probably combine them into a single patch (in particular to ease the backporting). The status of the other patch is: Waiting for review. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00260.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug middle-end/27302] Fold does not fold (i j) == (j i) to 1
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-02-06 12:38 --- Subject: Bug 27302 Author: rguenth Date: Tue Feb 6 12:38:32 2007 New Revision: 121644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121644 Log: 2007-02-06 Richard Guenther [EMAIL PROTECTED] PR middle-end/27302 * gcc.dg/torture/pr27302-2.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr27302-2.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27302
[Bug target/30712] New: Failures related to SSE2 starting Feb 5th 2007
I started to get failures bootstrapping trunk early this morning. For example: Executing on host: /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/xgcc -B/u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/ /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/pr13366.c -O -msse -fno-show-column -S -o pr13366.s(timeout = 300) In file included from /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/include/xmmintrin.h:1245,^M from /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/pr13366.c:4:^M /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/include/emmintrin.h:34: error: #error SSE2 instruction set not enabled compiler exited with status 1 output is: In file included from /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/include/xmmintrin.h:1245, from /u01/var/tmp/gcc_trunk_svn/gcc/gcc/testsuite/gcc.target/i386/pr13366.c:4: /u01/var/tmp/gcc_trunk_svn/gcc_20070206/gcc/include/emmintrin.h:34: error: #error SSE2 instruction set not enabled FAIL: gcc.target/i386/pr13366.c (test for excess errors) There were 13 new failures, all SSE2 related which passed until this morning. I'm assuming it is related to the check-ins from Harsha Jagasia. Let me know if you need more information. Brett Albertson -- Summary: Failures related to SSE2 starting Feb 5th 2007 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30712
[Bug fortran/29400] ANY and COUNT used on parameter arrays
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-06 13:41 --- I was wrong: the bug basically happens for all intrinsics which gfc_walk_expr one of their arguments and then simply assert that the ss != gfc_ss_terminator. This is a wrong thing to do for constant arguments. I audited all the intrinsics to find out which I could lead to an ICE, and here's the complete list: integer,parameter :: i(1,1) = 0, j(2) = 42 logical :: l ! print *, maxloc(j+j,mask=(j==2)) print *, size(j+j) print *, minval(j+j) print *, minval(j,mask=(j==2)) print *, maxval(j+j) print *, maxval(j,mask=(j==2)) print *, sum(j,mask=j==2) print *, sum(j+j) print *, product(j+j) print *, ubound(j+j) print *, lbound(j+j) print *, dot_product(j+j,j) print *, dot_product(j,j+j) print *, count(i==1) print *, any(i==1) print *, all(i==1) end I couldn't make maxloc/minloc ICE, although I'm pretty sure there should be a way to get it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29400
[Bug c/12963] Wrong and misleading warning encourages writing non-portable code
--- Comment #21 from manu at gcc dot gnu dot org 2007-02-06 13:48 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01933.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963
[Bug c++/11856] unsigned warning in template
--- Comment #22 from manu at gcc dot gnu dot org 2007-02-06 13:49 --- Not a definitive fix but at least the warning can be disabled: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01933.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug target/29120] Arm cross-compiler could not be created (assember error)
--- Comment #2 from s_j_newbury at yahoo dot co dot uk 2007-02-06 13:58 --- Sounds like you're trying to build a hard-float compiler for a soft-float (binutils) target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29120
[Bug fortran/29397] Constant logical expression with parameter array
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-06 14:05
---
We're passing a pointer to a logical instead of an array descriptor:
$ cat a.f90
integer :: k(3), l(1)
integer, parameter :: j(3) = 2
l = maxloc (k, j1)
end
$ cat a.f90.003t.original
MAIN__ ()
{
int4 l[1];
int4 k[3];
_gfortran_set_std (70, 127, 0, 0);
{
static logical4 C.1011 = 0;
struct array1_int4 parm.1;
struct array1_int4 parm.0;
parm.0.dtype = 265;
parm.0.dim[0].lbound = 1;
parm.0.dim[0].ubound = 1;
parm.0.dim[0].stride = 1;
parm.0.data = (void *) l[0];
parm.0.offset = 0;
parm.1.dtype = 265;
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 3;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) k[0];
parm.1.offset = 0;
_gfortran_mmaxloc0_4_i4 (parm.0, parm.1, C.1011);
}
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-10-08 21:50:42 |2007-02-06 14:05:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #37 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06 14:13 --- Subject: Re: Shared libstdc++ fails to link The patch proposed makes sense, Dave can you verify it fixes this PR for you? I'll spin some testing on the trunk in a moment. Yes. I'll try when an updated patch is ready. I understand the first candidate doesn't work. My hpux 10 system is just finishing a build and check. I'll also tweak the backend to use COMDAT support on hpux 11 and do a build on it. That's much faster. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug fortran/30713] New: Internal Complier Error
Attached code generates on Internal Complier Error when using -O3 on an Intel Mac -- Summary: Internal Complier Error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug driver/30714] New: [regression] gcj driver doesn't recognize files starting with II
at least seen on the redhat/gcc-4_1-branch-java-merge-20070117 branch; not yet validated on the trunk: $ touch IIFoo.java $ gcj -C IIFoo.java gcj: no input files -- Summary: [regression] gcj driver doesn't recognize files starting with II Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30714
[Bug target/29120] Arm cross-compiler could not be created (assember error)
--- Comment #3 from joaquinduran at adtelecom dot es 2007-02-06 14:26 --- Forget the bug. I submmited it because I wa not able to build it from Open Embedded meta-data. The fix was update the meda-data used to generate the images (which specifies the ./configure options; very similar to gentoo). I've build gcc 4.1.1 for arm and is performing very well. -- joaquinduran at adtelecom dot es changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29120
[Bug fortran/30715] New: [fortran, 4.3 regression]: ICE in operand_equal_p()
Current mainline ICEs on the code below: module coord_v_convert INTEGER, PARAMETER, public :: dp = SELECTED_REAL_KIND(12,200) contains Subroutine xcc_V_CONVERT(ivector,iepoch,oepoch,isys,osys,ovector) real(dp) :: IVECTOR(1:3) ! Input coordinate vector real(dp) :: IEPOCH ! Input epoch real(dp) :: OEPOCH ! Output epoch real(dp) :: OVECTOR(1:3) ! Output coordinate vector Character(len=*) ::ISYS ! Input system Character(len=*) ::OSYS ! Output system real(dp) :: XVECTOR(1:3) ! Temporary coordinate holder real(dp) :: YVECTOR(1:3) ! Temporary coordinate holder Character(len=20) ::isysu ! Input system, uppercase Character(len=20) ::osysu ! Output system, uppercase if (trim(isysu) /= 'E') then if (trim(isysu) == 'Q' .or. trim(isysu) == 'C') then call xcc_dp_q_to_e(ivector,iepoch,xvector) elseif (trim(isysu) == 'G') then call xcc_dp_g_to_e(ivector,iepoch,xvector) endif endif if (iepoch /= oepoch) then call xcc_dp_precess(xvector,iepoch,oepoch,yvector) else yvector(1:3)=xvector(1:3) endif if (trim(osysu) /= 'E') then if (trim(osysu) == 'Q' .or. trim(osysu) == 'C') then call xcc_dp_e_to_q(yvector,oepoch,ovector) elseif (trim(osysu) == 'G') then call xcc_dp_e_to_g(yvector,oepoch,ovector) endif endif end subroutine xcc_v_convert end module coord_v_convert ~/tmpgfortran -c -O -v coord_v_convert.F90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/martin/gcc/configure --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran Thread model: posix gcc version 4.3.0 20070206 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v coord_v_convert.F90 -mtune=generic -O -o /tmp/ccjN9yGi.f95 ignoring nonexistent directory /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /afs/mpa/data/martin/ugcc/include /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/include /usr/include End of search list. /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 /tmp/ccjN9yGi.f95 -ffree-form -quiet -dumpbase coord_v_convert.F90 -mtune=generic -auxbase coord_v_convert -O -version -fpreprocessed -fintrinsic-modules-path /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o /tmp/ccUyuIKr.s GNU F95 version 4.3.0 20070206 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070206 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 coord_v_convert.F90: In function 'xcc_v_convert': coord_v_convert.F90:29: internal compiler error: in operand_equal_p, at fold-const.c:2577 The 4.1 and 4.2 branches compile this properly. -- Summary: [fortran, 4.3 regression]: ICE in operand_equal_p() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de 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=30715
[Bug c++/30703] ICE Segmentation fault on using OpenMP
-- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||02/msg00501.html Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug libgomp/28296] [4.2/4.3 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #8 from sayle at gcc dot gnu dot org 2007-02-06 15:09 --- Subject: Bug 28296 Author: sayle Date: Tue Feb 6 15:09:17 2007 New Revision: 121649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121649 Log: PR libgomp/28296 Backport from mainline. * config/darwin.h (CPP_SPEC): Handle -pthread, transforming it into -D_REENTRANT. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/darwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug libgomp/28296] [4.2/4.3 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #9 from sayle at gcc dot gnu dot org 2007-02-06 15:15 --- Subject: Bug 28296 Author: sayle Date: Tue Feb 6 15:15:33 2007 New Revision: 121650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121650 Log: PR libgomp/28296 Backport from mainline. Revert: 2006-07-05 Eric Christopher [EMAIL PROTECTED] * configure.ac: Depend addition of -pthread on host OS. * configure: Regenerate. Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/configure branches/gcc-4_2-branch/libgomp/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug fortran/30713] Internal Complier Error
--- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 --- There is no attached code. Ray can you try adding the code, again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30713] Internal Complier Error
--- Comment #2 from ray at ultramarine dot com 2007-02-06 15:39 --- Subject: Re: Internal Complier Error On Tue, 6 Feb 2007, kargl at gcc dot gnu dot org wrote: --- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 --- There is no attached code. Ray can you try adding the code, again. Really sorry about that but got an internal bugzilla error when I tried. --- Comment #3 from ray at ultramarine dot com 2007-02-06 15:39 --- Created an attachment (id=13014) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13014action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30713] Internal Complier Error
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-06 16:34 --- Not that it much helps, but with today's gcc under x86_64-unknown-linux-gnu it does not crash. Maybe someone with Intel Mac can reproduce it. Oherwise: Compile with the -v option, e.g. gfortran -v -O3 env_grid.f After the line gcc-Version 4.3.0 20070206 (experimental) is the actual compilation command. On my computer it looks like: /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 env_grid.f -ffixed-form ... Run now (replace the argument with yours of above) gdb /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 (gdb) b real_abort (gdb) b fancy_abort (gdb) run env_grid.f -ffixed-form (... and the rest of the options) When it stops, enter (gdb) bt This gives a backtrace and a hint where the error occurs. What exact version of gfortran did you try? Do you know by chance whether this is a new problem or was present in a previous version of gfortran 4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30715] [4.3 regression]: ICE in operand_equal_p() with -O
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-06 16:52 --- Confirmed. It crashes with -O but not without optimization. Reduced test case: Subroutine xcc_V_CONVERT(iepoch) implicit none logical :: IEPOCH real:: XVECTOR(1:3) real:: YVECTOR(1:3) xvector = 0.0 if (iepoch) then yvector(1:3)=xvector(1:3) endif end subroutine xcc_v_convert #1 0x00551e7d in operand_equal_p (arg0=0x2b493e8fecc0, arg1=0x2b493e81b440, flags=0)at gcc/fold-const.c:2577 #2 0x0057977f in fold_ternary (code=COND_EXPR, type=0x2b493e82b0c0, op0=0x2b493e81b200, op1=0x2b493e8fecc0, op2=0x2b493e81b440) at gcc/fold-const.c:11773 #3 0x0057a9a1 in fold_build3_stat (code=10473456, type=0xa11, op0=0x9fcec0, op1=0xa, op2=0x70) at gcc/fold-const.c:12423 #4 0x00497321 in gfc_trans_if_1 (code=0xe60c40) at gcc/fortran/trans-stmt.c:612 #5 0x00468183 in gfc_trans_code (code=0xe61150) at gcc/fortran/trans.c:531 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2007-02-06 16:52:39 date|| Summary|[fortran, 4.3 regression]: |[4.3 regression]: ICE in |ICE in operand_equal_p()|operand_equal_p() with -O http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30715
[Bug fortran/30713] Internal Complier Error
--- Comment #5 from ray at ultramarine dot com 2007-02-06 17:00 --- Subject: Re: Internal Complier Error On Tue, 6 Feb 2007, burnus at gcc dot gnu dot org wrote: --- Comment #4 from burnus at gcc dot gnu dot org 2007-02-06 16:34 --- Not that it much helps, but with today's gcc under x86_64-unknown-linux-gnu it does not crash. Maybe someone with Intel Mac can reproduce it. Oherwise: Compile with the -v option, e.g. gfortran -v -O3 env_grid.f After the line gcc-Version 4.3.0 20070206 (experimental) is the actual compilation command. On my computer it looks like: /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 env_grid.f -ffixed-form ... Run now (replace the argument with yours of above) gdb /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 (gdb) b real_abort (gdb) b fancy_abort (gdb) run env_grid.f -ffixed-form (... and the rest of the options) When it stops, enter (gdb) bt This gives a backtrace and a hint where the error occurs. What exact version of gfortran did you try? Do you know by chance whether this is a new problem or was present in a previous version of gfortran 4.3? If you will look in the log file it contains the results of both uname -a and gfortran -v. It says gcc version 4.3.0 20070104 (experimental) I tried the above, but did not get any trace. Message said no stack. I have no idea if this is an old or a new problem. I am mostly using 4.1 on solaris, linux, and mac (power pc). This is the first time I have seen the problem. If it helps, I got around the problem by making the code from line 105 to 117 into a subroutine. Also, the problem does not exist without -O3. Sorry I could not be of more help, Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug middle-end/30715] [4.3 regression]: ICE in operand_equal_p() with -O
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-06 17:45 ---
Reduced test case:
The line xvector = 0.0 can also be removed. The dump-tree-original looks then
as follows:
xcc_v_convert (iepoch)
{
real4 xvector[3];
real4 yvector[3];
if (*iepoch)
{
(void) __builtin_memcpy ((void *) yvector, (void *) xvector, 12);
}
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Component|fortran |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30715
[Bug fortran/30713] ICE in insert_into_preds_of_block, at tree-ssa-pre.c:2750
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-02-06 17:50 --- This is most likely a dup of bug 29922. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug middle-end/30391] [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-02-06 17:52 --- *** Bug 30715 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30391
[Bug middle-end/30715] [4.3 regression]: ICE in operand_equal_p() with -O
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-06 17:52 --- *** This bug has been marked as a duplicate of 30391 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30715
[Bug fortran/30432] [4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #10 from sje at cup dot hp dot com 2007-02-06 18:01 --- This is fixed on mainline and the 4.2 branch now. Should it be closed? I don't think %VAL is in GCC 4.1 and the failing test is certainly not in the 4.1 branch. The underlying bug is in 4.1 but it may not be possible to trigger it without %VAL. -- sje at cup dot hp dot com changed: What|Removed |Added Known to fail|4.2.0 4.1.2 |4.1.2 Known to work|4.3.0 |4.3.0 4.2.0 Summary|[4.2/4.1 only] |[4.1 only] |gfortran.dg/c_by_val_1.f|gfortran.dg/c_by_val_1.f |fails on ia64-*-*, problem |fails on ia64-*-*, problem |with %VAL |with %VAL http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug driver/30714] [4.3 regression] gcj driver doesn't recognize files starting with II
--- Comment #1 from doko at ubuntu dot com 2007-02-06 18:02 --- confirmed with trunk 20070206 -- doko at ubuntu dot com changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.1.2 4.2.0 Summary|[regression] gcj driver |[4.3 regression] gcj driver |doesn't recognize files |doesn't recognize files |starting with II|starting with II http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30714
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-02-06 18:11 --- Subject: Bug 30540 Author: dfranke Date: Tue Feb 6 18:11:30 2007 New Revision: 121657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121657 Log: 2007-02-07 Daniel Franke [EMAIL PROTECTED] Backport from mainline: 2007-01-31 Ralf Wildenhues [EMAIL PROTECTED] * libgomp.texi: Fix spacing after abbreviations. Backport from mainline: 2007-01-29 Daniel Franke [EMAIL PROTECTED] PR libgomp/30540 * libgomp.texi: More about implementation-dependent settings. Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/libgomp.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug target/30272] Build failure under SGI Irix (GFortran)
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-02-06 18:12 --- Subject: Bug 30272 Author: dfranke Date: Tue Feb 6 18:12:22 2007 New Revision: 121658 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121658 Log: 2007-02-07 Daniel Franke [EMAIL PROTECTED] Backport from mainline: 2007-01-25 Daniel Franke [EMAIL PROTECTED] PR target/30272 * inclhack.def(broken_cabs): Also remove definition of cabsl. * fixincl.x: Regenerate. * tests/base/math.h: Update. Modified: branches/gcc-4_2-branch/fixincludes/fixincl.x branches/gcc-4_2-branch/fixincludes/inclhack.def branches/gcc-4_2-branch/fixincludes/tests/base/math.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
[Bug target/30272] Build failure under SGI Irix (GFortran)
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-02-06 18:14 --- Fixed in mainline and 4.2. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-02-06 18:15 --- Fixed in mainline and 4.2. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug target/30272] Build failure under SGI Irix (GFortran)
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-02-06 18:32 --- Solving for C++0x. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-02-06 18:48 --- Subject: Bug 30546 Author: dfranke Date: Tue Feb 6 18:48:11 2007 New Revision: 121661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121661 Log: 2007-02-07 Daniel Franke [EMAIL PROTECTED] Backport from mainline: 2007-01-31 Daniel Franke [EMAIL PROTECTED] PR libgomp/30546 * acx.m4 (ACX_PROG_CHECK_VER): Locate a program and check that its version is acceptable. Modified: branches/gcc-4_2-branch/config/ChangeLog branches/gcc-4_2-branch/config/acx.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #16 from dfranke at gcc dot gnu dot org 2007-02-06 18:50 --- Subject: Bug 30546 Author: dfranke Date: Tue Feb 6 18:49:55 2007 New Revision: 121662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121662 Log: 2007-02-07 Daniel Franke [EMAIL PROTECTED] Backport from mainline: 2007-01-31 Daniel Franke [EMAIL PROTECTED] PR libgomp/30546 * configure.ac: Add check for makeinfo * Makefile.am: Redefined target libgomp.info, build libgomp.info only if an appropiate version of makeinfo is found. * aclocal.m4: Regenerated. * configure: Regenerated. * Makefile.in: Regenerated. * testsuite/Makefile.in: Regenerated. Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/Makefile.am branches/gcc-4_2-branch/libgomp/Makefile.in branches/gcc-4_2-branch/libgomp/aclocal.m4 branches/gcc-4_2-branch/libgomp/configure branches/gcc-4_2-branch/libgomp/configure.ac branches/gcc-4_2-branch/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp when building from SVN because makeinfo is missing
--- Comment #17 from dfranke at gcc dot gnu dot org 2007-02-06 18:54 --- Fixed in mainline and 4.2. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug c++/30716] New: recursive templates compilation fault
I had tried to compile code like
templateint dim class cls {
clsdim-1 c[16];
};
template class cls0 {
};
int main() {
cls200 c;
return 0;
}
and had error:
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
I think, in this case better output maybe something like no enough memory,
unable to compile etc.
Information as defined in http://gcc.gnu.org/bugs.html
- the options given when GCC was configured/built
--prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
- the complete command line that triggers the bug
g++ bug.cpp
- the compiler output (error messages, warnings, etc.)
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
- the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below)
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++
Thread model: posix
gcc version 3.4.3
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE
bug.cpp -mtune=pentiumpro
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/backward
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
# 1 bug.cpp
# 1 built-in
# 1 command line
# 1 bug.cpp
templateint dim class cls {
clsdim-1 c[16];
};
template class cls0 {
};
int main() {
cls200 c;
return 0;
}
--
Summary: recursive templates compilation fault
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: generatorglukoff at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30716
[Bug c/30717] New: Compile error with e500 target on gcc 4.1/4.2
glibc 2.3.6 fails to compile with gcc 4.1.2 dated 11/24/06 or later, or
matching gcc version 4.2.x, if gcc is compiled for e500 or e500v2 CPUs.
The following code is a shortened test case.
#define testmacro(mem) \
({ \
__typeof (*(mem)) __val; \
__asm __volatile ( addi%0,%2,1\n\
: =b (__val), =m (*mem)\
: b (mem), m (*mem) \
: cr0, memory); \
__val;\
})
struct teststruct1
{
int count;
} __attribute__ ((packed));
struct teststruct2
{
int count;
};
void testfunc (struct teststruct1 *s1, struct teststruct2 *s2)
{
int v;
testmacro(v);// ok
testmacro(s1-count);// fails
testmacro(s2-count);// ok
}
Compilation output:
$ ppc-teak-linuxspe1-gcc -c testcc.c
testcc.c: In function 'testfunc':
testcc.c:26: error: output number 1 not directly addressable
testcc.c:26: warning: use of memory input without lvalue in asm operand 3 is
deprecated
$
The problem is caused by the addition of MASK_STRICT_ALIGN into the processor
mask for 8540 and 8548 CPUs in various locations; if the MASK_STRICT_ALIGN
definitions added between gcc-4.1-20061117 and gcc-4.1-20061124 are removed,
everything compiles fine.
Problem is not seen if gcc is compiled for ppc or powerpc targets.
--
Summary: Compile error with e500 target on gcc 4.1/4.2
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guenter at roeck-us dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug c/30717] Compile error with e500 target on gcc 4.1/4.2
--- Comment #1 from guenter at roeck-us dot net 2007-02-06 19:28 --- Turns out that compilation is fine if I compile with -mno-strict-align. Maybe this is not a bug after all but simply changed semantics ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug c/30717] Compile error with e500 target on gcc 4.1/4.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-06 19:30 --- You cannot really take the address of an elemenent of a packed struct on non strict alignment targets as if you deference them, it will try to do an aligned load which then fail as the alignment is wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug libstdc++/30711] Ifstream bug using Red Hat g++-4.1.0 compared to g++-4.0.2
--- Comment #3 from pcarlini at suse dot de 2007-02-06 19:32 --- I cannot reproduce the issue on official FSF compiler more recent than gcc4.0.0 (note that vendor releases are not supported here, sorry). In fact, since that release we are implementing the resolution of DR 409: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409 which implies that an user-code clear after a failed open is not necessary anymore. Also note that, in general, if you are not sure about the implementation of DR 409 in a given library, portable code should always call clear after a failed open (of course, constructing a new fstream, as per your Try 2, always works). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711
[Bug c/30719] New: gcc should probably warn if users compile without -O
Compiling without -O causes severe consequences that can easily be avoided, i.e. see the wontfix bug 25575. people expect to have warnings for use of uninitialized variables, I dont know if this behaviour has always been the same across gcc versions but regardless, the user cant be expected to read the whole manual to stumble upon this one alarming detail. If there is no reason to ever compile without -O, then that should probably be completely disabled, otherwise there should be a warning I think BEWARE!!! you are compiling without optimization - some warnings and errors will be missed This would have saved me 2 weeks of tracking down the uninitialized bytes without the compiler's help. -- Summary: gcc should probably warn if users compile without -O Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tvb at gnome dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug c/30717] Compile error with e500 target on gcc 4.1/4.2
--- Comment #3 from guenter at roeck-us dot net 2007-02-06 19:41 --- Does that mean this is really a glibc problem ? In glibc, the problem occurs with an atomic_increment() on an element of a packet structure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30717
[Bug inline-asm/28686] ebp from clobber list used as operand
--- Comment #7 from spark at gcc dot gnu dot org 2007-02-06 19:43 --- Subject: Bug 28686 Author: spark Date: Tue Feb 6 19:43:41 2007 New Revision: 121663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121663 Log: 2007-02-06 Seongbae Park [EMAIL PROTECTED] PR inline-asm/28686 * global.c (compute_regsets): New function. (global_alloc): Refactored ELIMINABLE_REGSET and NO_GLOBAL_ALLOC_REGS computation out. (rest_of_handle_global_alloc): Call compute_regsets() for non-optimizing case. Modified: trunk/gcc/ChangeLog trunk/gcc/global.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-06 19:48 --- If there is no reason to ever compile without -O, There are reasons, like getting much, much better debug info. -O1 enables lots of optimization that changes the code so much that debugging optimizated code is hard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug fortran/30720] New: runtime: check for empty array slices before allocating a negative amount of memory
The program below terminates with a runtime error due to an attempt to allocate a negative amount of memory. The error occurs while allocating memory for a temporary, empty, array slice. $ cat pr.f90 program runtime_error REAL:: a(5), b INTEGER :: l, u l = 4 u = 2 a = (/ 1.0, 2.0, 3.0, 4.0, 5.0 /) b = f(a(l:u) - 3.0) CONTAINS REAL FUNCTION f(x) REAL, DIMENSION(:), INTENT(in) :: x f = sum(x) end function END PROGRAM There are two issues here: a) the runtime error as described above $ gfortran-svn -O -fdump-tree-original -fdump-tree-optimized pr.f90 from dump-tree-original: int4 D.1036; void * D.1035; int4 D.1034; struct array1_real4 atmp.7; int4 D.1032; int4 D.1031; D.1031 = l; D.1032 = u; atmp.7.dtype = 281; atmp.7.dim[0].stride = 1; atmp.7.dim[0].lbound = 0; atmp.7.dim[0].ubound = u - D.1031; D.1034 = (u - D.1031) + 1; D.1035 = _gfortran_internal_malloc (D.1034 * 4); atmp.7.data = D.1035; from dump-tree-optimized: void * SR.31; [...] SR.31 = _gfortran_internal_malloc (-4); _gfortran_internal_free (SR.31); Here, if l u+1, D.1035 will be negative and trigger the runtime error. In this case, a runtime check whether the slice is empty before calling _gfortran_internal_malloc() would result in code not stopping with a (seemingly) unrelated error message. b) missed optimization during constant folding: from dump-tree-original: struct array1_real4 atmp.7; atmp.7.dtype = 281; atmp.7.dim[0].stride = 1; atmp.7.dim[0].lbound = 0; atmp.7.dim[0].ubound = -1; atmp.7.data = 0B; [...] _gfortran_internal_free (atmp.7.data); from dump-tree-optimzed: _gfortran_internal_free (0B); If the boundaries are known at compile time, e.g. a(4:2), no memory is allocated for the array descriptor, but _gfortran_internal_free(0B) is called nonetheless. This call is still visible after optimization. $ gfortran-svn -v gcc version 4.3.0 20070126 (experimental) -- Summary: runtime: check for empty array slices before allocating a negative amount of memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #2 from tvb at gnome dot org 2007-02-06 20:09 --- (In reply to comment #1) If there is no reason to ever compile without -O, There are reasons, like getting much, much better debug info. -O1 enables lots of optimization that changes the code so much that debugging optimizated code is hard. Agreed 100% on your comment, if your going to close the bug and say wontfix, would you care to explain why ? ... I mean this bug, not bug 25575. -- tvb at gnome dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug driver/30714] [4.3 regression] gcj driver doesn't recognize files starting with II
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-06 20:25:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30714
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-06 20:34 --- Confirming this bug (both of them, actually). For the missed-optimization, I think there's no reason to keep a library function _gfortran_internal_free(x) that is equivalent to if(x) free(x);, we should generate that code directly. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, wrong- ||code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-02-06 20:34:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug driver/30714] [4.3 regression] gcj driver doesn't recognize files starting with II
--- Comment #2 from tromey at gcc dot gnu dot org 2007-02-06 20:44 --- Subject: Bug 30714 Author: tromey Date: Tue Feb 6 20:43:55 2007 New Revision: 121666 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121666 Log: PR java/30714: * jvspec.c (lang_specific_driver): Check for the '-' in '-I'. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jvspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30714
[Bug driver/30714] [4.3 regression] gcj driver doesn't recognize files starting with II
--- Comment #3 from tromey at gcc dot gnu dot org 2007-02-06 20:45 --- Subject: Bug 30714 Author: tromey Date: Tue Feb 6 20:45:25 2007 New Revision: 121667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121667 Log: PR java/30714: * jvspec.c (lang_specific_driver): Check for the '-' in '-I'. Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/gcc/java/ChangeLog branches/redhat/gcc-4_1-branch-java-merge-20070117/gcc/java/jvspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30714
[Bug driver/30714] [4.3 regression] gcj driver doesn't recognize files starting with II
--- Comment #4 from tromey at gcc dot gnu dot org 2007-02-06 20:46 --- Fix checked in. -- tromey 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=30714
[Bug target/30370] [4.1 regression] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx
--- Comment #15 from mmitchel at gcc dot gnu dot org 2007-02-06 20:50 --- Subject: Bug 30370 Author: mmitchel Date: Tue Feb 6 20:50:37 2007 New Revision: 121668 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121668 Log: PR 30370 * config/rs6000/t-ppccomm: Correct Makefile typo. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/t-ppccomm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
[Bug target/30370] [4.1 regression] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx
--- Comment #16 from mmitchel at gcc dot gnu dot org 2007-02-06 20:58 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-06 21:00 --- The wrong-code bug happens in gfc_trans_create_temp_array. For some reason, the function argument to that function is false, and the code present to take care of negative extent is not triggered. Thomas, you're the one who introduced this argument: 2006-06-15 Thomas Koenig [EMAIL PROTECTED] * trans-array.h (gfc_trans_create_temp_array): Add bool argument. * trans-arrray.c (gfc_trans_create_temp_array): Add extra argument function to show if we are translating a function. If we are translating a function, perform checks whether the size along any argument is negative. In that case, allocate size 0. do you remember why always performing that check (ie, turn function to be always true) is not the right thing to do? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug target/30370] [4.1 regression] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-02-06 21:06 --- Subject: Bug 30370 Author: mmitchel Date: Tue Feb 6 21:06:36 2007 New Revision: 121669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121669 Log: PR 30370 * config/rs6000/t-ppccomm: Correct Makefile typo. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/rs6000/t-ppccomm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06 21:18 --- Subject: Re: Shared libstdc++ fails to link Created an attachment (id=13011) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view) proposed, untested patch I did a build and check of c and c++ on 4.1.2 using the above patch modified for the 4.1 branch on HP-UX 11.11 (attached). I modified the pa-hpux11.h file to disable TARGET_SOM_SDEF so that the COMDAT support used with HP-UX 10 was used for one-only support. I had to include target.h in one file but I didn't bother updating the Makefile dependencies. The build was successful and libstdc++-v3 linked successfully. There was one minor regression. nothrow1.C failed in the g++ testsuite. I've attached the tree dump. Dave --- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06 21:18 --- Created an attachment (id=13016) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13016action=view) --- Comment #40 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-06 21:18 --- Created an attachment (id=13017) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13017action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/30721] New: ICE on invalid template code
Attached test case ICEs. The code is AFAIK invalid:
---8---
#include stdio.h
template typename Numeric
class Table
{
typedef struct
{
const char * const name;
Numeric index;
} Tableitem;
static const Tableitem entries[];
public:
const char * const
operator[] (Numeric Tableindex)
{
for (int i=0; isizeof(entries)/sizeof(Tableitem); ++i)
if(entries[i].index==Tableindex)
return entries[i].name;
return 0;
}
};
enum funky { feeling, lost, somewhere, in, space };
templatefunky
const Tablefunky::Tableitem Tablefunky::entries[] =
{
{feeling, feeling},
{lost, lost},
{somewhere, somewhere},
{in, in},
{space, space},
};
int main (int argc, char **argv)
{
Tablefunky FunkyTable;
printf(Funkytable somewhere=[%s]\n, FunkyTable[somewhere]);
return 0;
}
---8---
The error:
logout::wilx:~/tmp g++42 -o ice ice.cxx
ice.cxx:14: internal compiler error: in import_export_decl, at cp/decl2.c:1956
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
GCC version:
logout::wilx:~/tmp g++42 -v
Using built-in specs.
Target: i386-portbld-freebsd6.2
Configured with: ./..//gcc-4.2-20070117/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.0
--with-gxx-include-dir=/usr/local/lib/gcc-4.2.0/include/c++/
--infodir=/usr/local/info/gcc42 --disable-rpath --prefix=/usr/local
i386-portbld-freebsd6.2
Thread model: posix
gcc version 4.2.0 20070117 (prerelease)
--
Summary: ICE on invalid template code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot haisman at sh dot cvut dot cz
GCC build triplet: i386-portbld-freebsd6.2
GCC host triplet: i386-portbld-freebsd6.2
GCC target triplet: i386-portbld-freebsd6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30721
[Bug c++/30721] ICE on invalid template code
--- Comment #1 from v dot haisman at sh dot cvut dot cz 2007-02-06 21:36 --- (In reply to comment #0) [...] logout::wilx:~/tmp g++42 -o ice ice.cxx ice.cxx:14: internal compiler error: in import_export_decl, at cp/decl2.c:1956 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [...] I submitted wrong error message, this is the right one: logout::wilx:~/tmp g++42 -o goezzi goezzi.cxx goezzi.cxx: In member function 'const char* const TableNumeric::operator[](Numeric) [with Numeric = funky]': goezzi.cxx:19: instantiated from 'const Tablefunky::Tableitem Tablefunky::entries [5]' goezzi.cxx:19: instantiated from 'const char* const TableNumeric::operator[](Numeric) [with Numeric = funky]' goezzi.cxx:41: instantiated from here goezzi.cxx:19: internal compiler error: in instantiate_decl, at cp/pt.c:12090 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30721
[Bug c++/30722] New: ICE on invalid template code #2
This has been derived from test case in PR 30721 but because it ICEs at
different place I report it as different bug.
-8--
template typename Numeric
struct Table
{
typedef struct
{
const char * const name;
} Tableitem;
static const Tableitem entries[];
};
enum funky { feeling };
templatefunky
const Tablefunky::Tableitem Tablefunky::entries[] = { {} };
-8--
Error:
logout::wilx:~/tmp g++42 -o ice ice.cxx
ice.cxx:14: internal compiler error: in import_export_decl, at cp/decl2.c:1956
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
GCC:
logout::wilx:~/tmp g++42 -v
Using built-in specs.
Target: i386-portbld-freebsd6.2
Configured with: ./..//gcc-4.2-20070117/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.0
--with-gxx-include-dir=/usr/local/lib/gcc-4.2.0/include/c++/
--infodir=/usr/local/info/gcc42 --disable-rpath --prefix=/usr/local
i386-portbld-freebsd6.2
Thread model: posix
gcc version 4.2.0 20070117 (prerelease)
--
Summary: ICE on invalid template code #2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot haisman at sh dot cvut dot cz
GCC build triplet: i386-portbld-freebsd6.2
GCC host triplet: i386-portbld-freebsd6.2
GCC target triplet: i386-portbld-freebsd6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30722
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-06 22:03 --- What is there to warn about? If you do -Winitialize without -O, you get a warning so ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #60 from hubicka at gcc dot gnu dot org 2007-02-06 22:05 --- Hi, small update on status. At -O3 -fno-tree-fre -fno-tree-pre we are now doing 1.1GB footprint, 800MB of this out of gimple. We still explode in FRE/PRE but majority of other problems was fixed: Execution times (seconds) garbage collection: 18.23 (12%) usr 0.04 ( 1%) sys 18.46 (10%) wall 0 kB ( 0%) ggc callgraph construction: 10.31 ( 7%) usr 0.04 ( 1%) sys 10.36 ( 5%) wall 2296 kB ( 0%) ggc life analysis : 4.08 ( 3%) usr 0.16 ( 3%) sys 4.26 ( 2%) wall 7350 kB ( 2%) ggc inline heuristics : 10.46 ( 7%) usr 0.12 ( 2%) sys 10.57 ( 6%) wall 2438 kB ( 1%) ggc integration : 16.48 (11%) usr 0.46 ( 9%) sys 17.00 ( 9%) wall 143049 kB (29%) ggc tree CFG cleanup : 4.69 ( 3%) usr 0.00 ( 0%) sys 4.69 ( 2%) wall 0 kB ( 0%) ggc tree SSA incremental : 2.32 ( 2%) usr 0.40 ( 8%) sys 2.76 ( 1%) wall 3276 kB ( 1%) ggc tree operand scan : 1.42 ( 1%) usr 0.22 ( 4%) sys 1.54 ( 1%) wall 27071 kB ( 6%) ggc dominator optimization: 2.25 ( 2%) usr 0.00 ( 0%) sys 2.24 ( 1%) wall 14657 kB ( 3%) ggc tree split crit edges : 0.39 ( 0%) usr 0.00 ( 0%) sys 0.39 ( 0%) wall 17558 kB ( 4%) ggc tree SSA to normal: 8.06 ( 5%) usr 0.40 ( 8%) sys 8.51 ( 4%) wall 22874 kB ( 5%) ggc expand: 3.83 ( 3%) usr 0.69 (14%) sys 38.08 (20%) wall 54312 kB (11%) ggc forward prop : 3.20 ( 2%) usr 0.82 (16%) sys 4.22 ( 2%) wall 2470 kB ( 1%) ggc if-conversion : 6.37 ( 4%) usr 0.00 ( 0%) sys 6.41 ( 3%) wall 9157 kB ( 2%) ggc global alloc : 12.12 ( 8%) usr 0.94 (19%) sys 15.48 ( 8%) wall 18801 kB ( 4%) ggc TOTAL : 147.90 5.02 191.03 486834 kB We get considerable usage in bitmaps (just those over 100MB of peak memory usage are listed): df-problems.c:2957 (df_chain_create_bb) 208MB df-problems.c:986 (df_rd_alloc) 207MB df-problems.c:987 (df_rd_alloc) 110MB tree-ssa-live.c:534 (new_tree_live_info) 110MB tree-ssa-live.c:538 (new_tree_live_info) 110MB At least 100MB, but probably more is consumed by the new linked lists used by scheduler. Hopefully this can be tracked by moving everyting to allocpools. I will send -O2 in separate post. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #61 from hubicka at gcc dot gnu dot org 2007-02-06 22:14 --- Also forgot to mention, integration is slow because of the split_block quadraticness. For -O2: We need 531MB of ram, GGC memory is peaking at 100MB, large portion of the non-GGC memory are definitly the scheduler dependency lists. xecution times (seconds) garbage collection: 14.26 ( 5%) usr 0.03 ( 1%) sys 14.27 ( 5%) wall 0 kB ( 0%) ggc life analysis : 73.96 (24%) usr 1.55 (46%) sys 75.52 (24%) wall 7207 kB ( 2%) ggc alias analysis: 0.92 ( 0%) usr 0.00 ( 0%) sys 0.87 ( 0%) wall 8530 kB ( 3%) ggc inline heuristics : 11.64 ( 4%) usr 0.12 ( 4%) sys 11.77 ( 4%) wall 2695 kB ( 1%) ggc integration : 16.71 ( 5%) usr 0.19 ( 6%) sys 16.91 ( 5%) wall 69808 kB (21%) ggc tree gimplify : 0.49 ( 0%) usr 0.07 ( 2%) sys 0.58 ( 0%) wall 14977 kB ( 4%) ggc tree operand scan : 1.25 ( 0%) usr 0.11 ( 3%) sys 1.29 ( 0%) wall 20889 kB ( 6%) ggc tree SRA : 1.20 ( 0%) usr 0.07 ( 2%) sys 1.37 ( 0%) wall 40364 kB (12%) ggc tree FRE : 1.14 ( 0%) usr 0.07 ( 2%) sys 1.21 ( 0%) wall 9230 kB ( 3%) ggc expand: 3.29 ( 1%) usr 0.10 ( 3%) sys 3.39 ( 1%) wall 45828 kB (14%) ggc PRE : 21.54 ( 7%) usr 0.00 ( 0%) sys 21.54 ( 7%) wall 898 kB ( 0%) ggc regmove : 93.59 (30%) usr 0.05 ( 1%) sys 93.64 (30%) wall 156 kB ( 0%) ggc local alloc : 5.34 ( 2%) usr 0.00 ( 0%) sys 5.33 ( 2%) wall 2838 kB ( 1%) ggc global alloc : 4.25 ( 1%) usr 0.06 ( 2%) sys 4.30 ( 1%) wall 19946 kB ( 6%) ggc reload CSE regs : 4.09 ( 1%) usr 0.00 ( 0%) sys 4.11 ( 1%) wall 11354 kB ( 3%) ggc scheduling 2 : 16.97 ( 6%) usr 0.44 (13%) sys 17.53 ( 6%) wall 20069 kB ( 6%) ggc TOTAL : 308.36 3.39 312.58 334207 kB total: 531915 kB regmove has the quadratic loop issues I added param for earliler in the track, but the parameter is now apparently bit too large since rest of compiler is a lot faster. Scheduler/out-of-SSA slowness is gone. There are no overly large bitmaps, one large allocpool: df_scan_ref pool 18 74449440 67061984 0 Looks like we are in pretty good shape on this one, only IMO important problems being the slowness of life (hopefully fixed by DFA) and memory houngryness of scheduler. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug fortran/30723] New: Freeing memory doesn't need to call a library function
Currently, allocated memory is freed by calling the library function
_gfortran_internal_free, which does nothing but:
/* Free internally allocated memory. Pointer is NULLified. Also used to
free user allocated memory. */
void
internal_free (void *mem)
{
if (mem != NULL)
free (mem);
}
Two things are worth noting:
+ although the comment says otherwise, the pointer is not NULLified.
+ this code could be generated directly by the front-end, leading to better
optimization.
An example of the missed optimization is the compilation of the following code:
REAL:: a(5), b
INTEGER :: l, u
l = 4
u = 2
a = (/ 1.0, 2.0, 3.0, 4.0, 5.0 /)
b = f(a(l:u) - 3.0)
call foo(b)
CONTAINS
REAL FUNCTION f(x)
REAL, DIMENSION(:), INTENT(in) :: x
f = sum(x)
end function
END PROGRAM
the optimized tree looks like:
SR.33 = _gfortran_internal_malloc (0);
b = 0.0;
_gfortran_internal_free (SR.33);
We sure could optimize away the use of SR.33. PR 30720 has another case where
such an optimization could happen.
--
Summary: Freeing memory doesn't need to call a library function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug fortran/30723] Freeing memory doesn't need to call a library function
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-06 23:05:58 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #18 from kkojima at gcc dot gnu dot org 2007-02-06 23:12 --- Subject: Bug 29746 Author: kkojima Date: Tue Feb 6 23:12:35 2007 New Revision: 121671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121671 Log: PR target/29746 * config/sh/sh.c (expand_cbranchdi4): Use scratch register properly. (sh_initialize_trampoline): Add parentheses to avoid a warning. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:13 --- To keep things separate, I filed PR30723 for the missed optimization. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:16 --- Created an attachment (id=13018) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13018action=view) Patch for this bug Here's the patch I propose. It makes the code simpler by using a cond_expr instead of using different statement blocks. Regtested in an earlier version on i686-linux, regtesting of the current version in progress. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug fortran/30432] [4.1 only] gfortran.dg/c_by_val_1.f fails on ia64-*-*, problem with %VAL
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-02-06 23:17 --- (In reply to comment #10) This is fixed on mainline and the 4.2 branch now. Should it be closed? I don't think %VAL is in GCC 4.1 and the failing test is certainly not in the 4.1 branch. The underlying bug is in 4.1 but it may not be possible to trigger it without %VAL. OK, that's reason enough to close it. Thanks for your work! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30432
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #19 from kkojima at gcc dot gnu dot org 2007-02-06 23:29 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug fortran/25714] concat of strings create an extra temporary variable
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 00:21
---
Here's another patch for concat, to have the front-end generate the code itself
instead of calling a library function. It still generates the extra temporary,
but can optimize other things.
Index: trans-expr.c
===
--- trans-expr.c(revision 121506)
+++ trans-expr.c(working copy)
@@ -934,6 +934,36 @@
}
+/* Helper for gfc_trans_array_copy, gfc_trans_array_constructor_copy
+ and gfc_conv_concat_op that constructs the call to __builtin_memcpy. */
+
+static tree
+gfc_build_memcpy_call (tree dst, tree src, tree len)
+{
+ tree tmp, args;
+
+ /* Convert arguments to the correct types. */
+ if (!POINTER_TYPE_P (TREE_TYPE (dst)))
+dst = gfc_build_addr_expr (pvoid_type_node, dst);
+ else
+dst = fold_convert (pvoid_type_node, dst);
+
+ if (!POINTER_TYPE_P (TREE_TYPE (src)))
+src = gfc_build_addr_expr (pvoid_type_node, src);
+ else
+src = fold_convert (pvoid_type_node, src);
+
+ len = fold_convert (size_type_node, len);
+
+ /* Construct call to __builtin_memcpy. */
+ args = build_tree_list (NULL_TREE, len);
+ args = tree_cons (NULL_TREE, src, args);
+ args = tree_cons (NULL_TREE, dst, args);
+ tmp = build_function_call_expr (built_in_decls[BUILT_IN_MEMCPY], args);
+ return fold_convert (void_type_node, tmp);
+}
+
+
/* Handle a string concatenation operation. A temporary will be allocated to
hold the result. */
@@ -942,11 +972,15 @@
{
gfc_se lse;
gfc_se rse;
- tree len;
+ tree destlen;
tree type;
- tree var;
+ tree dest;
tree args;
tree tmp;
+ tree d;
+ tree dlen;
+ tree cond1, cond2, action1, action2, expr_block1, expr_block2;
+ stmtblock_t block1, block2;
gcc_assert (expr-value.op.op1-ts.type == BT_CHARACTER
expr-value.op.op2-ts.type == BT_CHARACTER);
@@ -962,34 +996,92 @@
gfc_add_block_to_block (se-pre, rse.pre);
type = gfc_get_character_type (expr-ts.kind, expr-ts.cl);
- len = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
- if (len == NULL_TREE)
-{
- len = fold_build2 (PLUS_EXPR, TREE_TYPE (lse.string_length),
-lse.string_length, rse.string_length);
-}
+ destlen = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
+ if (destlen == NULL_TREE)
+destlen = fold_build2 (PLUS_EXPR, TREE_TYPE (lse.string_length),
+ lse.string_length, rse.string_length);
type = build_pointer_type (type);
- var = gfc_conv_string_tmp (se, type, len);
+ dest = gfc_conv_string_tmp (se, type, destlen);
- /* Do the actual concatenation. */
- args = NULL_TREE;
- args = gfc_chainon_list (args, len);
- args = gfc_chainon_list (args, var);
- args = gfc_chainon_list (args, lse.string_length);
- args = gfc_chainon_list (args, lse.expr);
- args = gfc_chainon_list (args, rse.string_length);
- args = gfc_chainon_list (args, rse.expr);
- tmp = build_function_call_expr (gfor_fndecl_concat_string, args);
+ /* Do the actual concatenation. The original code in libgfortran was:
+
+ void
+ concat_string (GFC_INTEGER_4 destlen, char * dest,
+ GFC_INTEGER_4 len1, const char * s1,
+ GFC_INTEGER_4 len2, const char * s2)
+ {
+ if (len1 = destlen)
+ {
+ memcpy (dest, s1, destlen);
+ return;
+ }
+ memcpy (dest, s1, len1);
+ dest += len1;
+ destlen -= len1;
+
+ if (len2 = destlen)
+ {
+ memcpy (dest, s2, destlen);
+ }
+ else
+ {
+ memcpy (dest, s2, len2);
+ memset (dest[len2], ' ', destlen - len2);
+ }
+ }
+
+ And that's exactly what we do here.
+ */
+
+ cond1 = fold_build2 (GE_EXPR, boolean_type_node, lse.string_length, destlen
+ action1 = gfc_build_memcpy_call (dest, lse.expr, destlen);
+
+ gfc_start_block (block1);
+ tmp = gfc_build_memcpy_call (dest, lse.expr, lse.string_length);
+ gfc_add_expr_to_block (block1, tmp);
+ dlen = gfc_create_var (TREE_TYPE (destlen), dlen);
+ d = gfc_create_var (pchar_type_node, d);
+ tmp = fold_build2 (MINUS_EXPR, TREE_TYPE (dlen), destlen, lse.string_length
+ gfc_add_modify_expr (block1, dlen, tmp);
+ tmp = fold_build2 (PLUS_EXPR, pchar_type_node, dest,
+fold_convert (pchar_type_node, lse.string_length));
+ gfc_add_modify_expr (block1, d, tmp);
+
+ gfc_init_block (block2);
+ tmp = gfc_build_memcpy_call (d, rse.expr, rse.string_length);
+ gfc_add_expr_to_block (block2, tmp);
+
+ /* Call to memset. */
+ args = fold_build2 (PLUS_EXPR, pchar_type_node, d,
+ fold_convert (pchar_type_node, rse.string_length));
+ args = gfc_chainon_list (NULL_TREE, args);
+ args = gfc_chainon_list (args, build_int_cst
+ (gfc_get_int_type (gfc_c_int_kind),
+
[Bug c++/30716] recursive templates compilation fault
--- Comment #1 from fang at csl dot cornell dot edu 2007-02-07 00:32 --- Ahh, exploding recursive templates... For future reference, you could limit the recursion depth explicitly, using -ftemplate-depth-n from a gcc-3.4.0 man page: Set the maximum instantiation depth for template classes to n. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17. I think 42 would seem more appropriate than 17, but that is for The Committee to decide. :) -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30716
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #18 from schlie at comcast dot net 2007-02-07 00:56 --- Subject: Re: C++ FE emitting assignments to read-only global symbols for 4.3? From: rguenth at gcc dot gnu dot org [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: 5 Feb 2007 22:51:25 - To: [EMAIL PROTECTED] Subject: [Bug c++/20912] C++ FE emitting assignments to read-only global symbols --- Comment #17 from rguenth at gcc dot gnu dot org 2007-02-05 22:51 --- ... to mark as WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912 --- 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=20912
[Bug fortran/30681] obsolescent vs. obsolete
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-02-07 02:10 --- From the dictionary: obsolescent - Going out of use; becoming obsolete; So this means its not obsolete yet, and thus still supported. I will fix this. Splitting hairs really, but what the heck. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-07 02:10:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30681
[Bug c/30724] New: Wrong code from -O2 taking ptr=(struct *)int_proc_parm on x86_64
gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp
--enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib
--with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
Compile the following with cc -O2, gets wrong code.
If you use -fno-strict-aliasing or -fno-schedule-insns2 it works.
cc -O1 works. cc -O1 -fstrict-aliaseing -fschedule-insns2 fails.
I might have prioritized this critical except I found the ref to
-fno-strict-aliasing in the 4.1.2rc1 thread...
/* -O2 compiles the fetch of lx_id-id_id before it stores
** external_lx_id into the stack:
movzwl 6(%rsp), %eax // oops, too soon
movl%edi, 4(%rsp)
testw %ax, %ax // tests garbage
*/
typedef int LG_LXID;
typedef int i4;
typedef unsigned short u_i2;
typedef struct _LG_ID {
u_i2 foo;
u_i2 id_id;
} LG_ID;
void
LGend(
LG_LXID external_lx_id,
i4 flag)
{
LG_ID *lx_id = (LG_ID*)external_lx_id;
if (lx_id-id_id == 0 || (i4)lx_id-id_id flag)
printf(barfo);
}
--
Summary: Wrong code from -O2 taking ptr=(struct *)int_proc_parm
on x86_64
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schendel at kbcomputer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30724
[Bug c++/30725] New: compile error when meet with ((A()()))
following example file can't compiled
$ cat bug.cpp
class A{
public:
bool operator()() const {
return true;
}
};
int main() {
if ((A()())) {}
}
$ g++-4.1 -c bug.cpp
bug.cpp: In function int main():
bug.cpp:9: error: type name declared as function returning a function
bug.cpp:9: error: type name declared as function returning a function
$ g++-4.1 --version
g++-4.1 (GCC) 4.1.2 20061212 (prerelease) (Ubuntu 4.1.1-21ubuntu3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: compile error when meet with ((A()()))
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lidaobing at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
[Bug fortran/30681] obsolescent vs. obsolete
--- Comment #4 from patchapp at dberlin dot org 2007-02-07 04:30 --- Subject: Bug number PR30681 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-02/msg00597.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30681
[Bug c++/30725] compile error when meet with ((A()()))
--- Comment #1 from fang at csl dot cornell dot edu 2007-02-07 05:04
---
Workaround:
if (A().operator()()) { }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
[Bug c++/30725] compile error when meet with ((A()()))
--- Comment #2 from fang at csl dot cornell dot edu 2007-02-07 05:05 --- looks familiar: PR 29234 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
[Bug c++/30725] compile error when meet with ((A()()))
--- Comment #3 from lidaobing at gmail dot com 2007-02-07 05:13 --- *** This bug has been marked as a duplicate of 29234 *** *** This bug has been marked as a duplicate of 29234 *** -- lidaobing at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30725
[Bug c++/29234] Call to operator() of temporary object wrongly parsed
--- Comment #2 from lidaobing at gmail dot com 2007-02-07 05:13 --- *** Bug 30725 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29234
[Bug c/30724] Wrong code from -O2 taking ptr=(struct *)int_proc_parm on x86_64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 06:51 --- If you use -fno-strict-aliasing and it works, that should tell you something right there really. Anyways you are violating C/C++ aliasing rules, see PR 21920. *** This bug has been marked as a duplicate of 21920 *** -- 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=30724
